On Wed, May 25, 2011 at 9:23 PM, W. Trevor King <[email protected]> wrote: > I'll mail you a URL if I have something I actuall commit ;). I expect > the changes to the code will only be the addition of a few lines, so > it might just be a single commit.
Well, I've got your repo now, so I'll see it when you commit. >> Also, I separated and made it semi-redundant so that when you get >> "be set" working, you can simply "git revert" that third commit and >> it'll go back to saying "see be set --help". Forgot to mention that >> in the patch; sorry. > > Ah, I supose I did this by hand after your last patch ;). Oh well, I > think the history is clear enough. I'm sorry; I'm not sure I understand what you mean by that. > I think it's better to have your new documentation in `be set --help` > so we remain at least somewhat motivated to implement a good > command-line interface. Well, I thought putting it in "severity --help" and "status --help" is more of an incentive, as it's the "wrong" place for it, and it looks sort of out of place there. That should be incentive to get "be set" working and delete my ugly doc. ;) > On Wed, May 25, 2011 at 12:47:40PM +1000, Tim Guirgies wrote: >> I was just wondering how/where the name and location of the temporary >> files used for writing comments are placed. > > BE always pops up editors with `libbe.ui.util.editor.editor_string()`, > which is called directly from commands that support it, > e.g. `libbe.command.comment.Comment._run()`. > >> From what I can tell, they get put in as /tmp/tmp*, but I've not >> been able to locate this in the code. > > The tempfiles are created with `tempfile.mkstemp()` [1], and we don't > pass and options. I'm certainly open to adding options, but I think > they should be BE-specific, not BE-command-specific. Something like > > tempfile.mkstemp(suffix=".txt", prefix="bugs-everywhere-", text=True) The reason I asked for it to be command-specific is so that vim can tell the difference between the different file types. For example, a comment file will have different syntax to the settings file. Actually, come to think of it, do you generate temporary files for anything other than comments? > I'm uncertain about the `text` option. It will be a text file, but we > currently encode/decode the content by hand inside BE. Is that how > "text files" are expected to work? I don't have access to any systems > that make this distinction, so I'm not clear on the particulars. I have even less of an idea than you about this; sorry. >> As for how to deal with it, I can see two options: either keep it in the >> /tmp directory; or take the git approach and place it under the ".be" >> directory, deleting it after a successful comment creation. > > Currently we delete it either way, at the end of `editor_string()`. > You only find out if that command will be successful later in the > command, and I don't think it's worth saving the temp file until the > command finishes. > > If it *is* worth saving the temp files, `editor_string` should > probably become a class that remembers its tempfiles and has a > `.cleanup()` method that removes the temp files. Well, I was just throwing ideas out there. I don't really mind at this point if it's deleted even if something fails (though that is something to keep in mind); the more important thing is for vim to recognise the file with as few false positives as possible. >> I've also attached the vim syntax file. It's just a draft, though. >> >> I also don't really know how to go about including it with be, or how to >> install it using the Makefile. > > Things like this should go in `misc/`. Yours should probably be > `misc/editor/becomment.vim`, and any user savy enough to want it can > install it themselves ;). If that's your current policy. I'll clean it up a bit, and add it in. Should I wait until we resolve the file name issue, though? > That's the approach we take with the bash > completion script anyhow. If people have better ideas, I'm open to > suggestions. Well, I didn't know that. Easy enough for me to install it, but I had no idea that it existed. That seems to be a recurring theme with be, though; it has features, but I have no idea about them. Perhaps it's just me. _______________________________________________ Be-devel mailing list [email protected] http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
