-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API #8
Comments
This would start by converting all raw string references to |
Oh, @LeopoldArkham, it was a grave error to ask me for suggestions… but, well, here they come: I assume there are already methods (planned) to append an entry to a table in a specific format (index doesn't matter, I kinda want My ultimate goal is to do that in a way that still preserves the overall style of the file. Say, you are using short-and-sweet This is a ludicrous idea, I know! Luckily, a Cargo.toml is a pretty straightforward file, we are mostly dealing with the style of tables, and a hit rate of 60% is probably way better than probably anyone would expect. And maybe someone wants to write their Master's thesis on heuristics for text-based formats or something? I don't know. I've been thinking about this stuff for far too long without actually having time to implement this is a nice way. In the meantime: Forget the last two paragraphs. I'm absolutely fine with a simple API that allows me to add a line (string or inline table with decent formatting) to a table without fucking up all the comments or whitespace someone added to their file :) |
Ooh! I really want to see if I can do that! That said, if we want the user to be able to decide how the file looks, we'll need some equivalent of the ability to just add a string (preferably after parsing it and making sure there are no naming conflicts), since the computer is sure to get it wrong sometimes. So it's definitely worth doing the simpler version first. |
It should be fairly trivial to read existing entries in the document, see if they're |
Duplicating is a good idea, @LeopoldArkham! I'm a bit worried about getting a good heuristic to choose what style attributes to copy, i.e., choose a good style when the file is not consistent, and ignoring really weird formatting, or comments inside of the duplicate. But yeah, let's do the simplest version first and work from there. I'm sure you want to keep Molten's API as small and general-purpose as possible, so it's fine if cargo-edit needs to do more stuff. |
181: Start world domination r=killercup a=ordian cc #15, #69. This is an experiment with [toml_edit](https://github.com/ordian/toml_edit) to figure out what the right API (LeopoldArkham/Molten#8, cc @LeopoldArkham) is for the upcoming integration with Molten, but also can be useful by itself while Molten is not yet ready. Basically, all we need is an `Item`, which can represent anything (`None`, `Table`, `InlineTable`, `String`, ...), `IndexMut<&str, Output=Item>` implementation for Item and a bunch of downcasting methods (`is_table`, `as_table`, ...). Deleting an item is just replacing it with `None`.
After a quick look at the Molten's source code, I see a couple of blocking issues for using it in cargo-edit (modulo bugs), @LeopoldArkham, please, correct me if I'm wrong:
[a. "b" . c] the key will be struct Index<'a> {
doc: &TOMLDocument<'a>,
path: RefCell<Vec<&'a str>>, // index["a"]["b"] -> vec!["a", "b"]
} and implement Also, I've found a couple of bugs (should probably create a separate issue):
[[bin]] # comment 1
[dependencies]
[[bin]] # comment 2 Molten will map key |
Thanks for your comments, @ordian! Quoted/dotted keys are not fully implemented yet, that's a known issue, same with non-contiguous AoTs.
|
Discuss what features the API should have.
As far as implementing it, we should start with:
Any code that implements this needs to be vigorously tested as it's obviously a fragile part of the library.
#7 should be looked into before this
Whishlist later on includes:
The text was updated successfully, but these errors were encountered: