On Wed, May 19, 2010 at 11:04 AM, Darin Adler <da...@apple.com> wrote: > On May 19, 2010, at 10:52 AM, Adam Barth wrote: >> Thanks for the feedback. Webkit-patch already respects the EDITOR >> environment variable. It should be a simple change to support the >> CHANGE_LOG_EDIT_APPLICATION environment variable also. The function that >> needs to change is: >> >> http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/system/user.py#L73 > > When I created the prepare-ChangeLog and commit-log-editor scripts 8 years > ago I did the following: > > - Had a separate CVS_LOG_EDITOR (later SVN_LOG_EDITOR) environment > variable in case someone wanted a different editor for this purpose than the > general case. > > - Added CHANGE_LOG_EDIT_APPLICATION to adapt the work flow better to a Mac > OS X application where you would not quit after editing the files. But I had > to come up with a different way to indicate “I’m done” in such cases. > Probably could do something similar to what we do after launching Safari to > browse the diff. > > There’s also a tool called xed that I could probably use as an EDITOR. The > xed command has an option "--wait" that can make it behave more like modal > vi. The xed tool was created many years after I wrote those scripts.
I'll check out how these work in prepare-ChangeLog. We can either replicate that logic here or pass the appropriate arguments to prepare-ChangeLog to trigger the editing there. Adam >>> 2) When it brings up the change logs in the editor, it does not show me >>> a diff until after I am done editing them. I can’t write a good change log >>> without having a diff to refer to. >> >> Would opening the pretty-diff in a browser be sufficient here? We can >> reverse the order of showing the diff and editing the ChangeLog. The >> trade-off here is that you won't see the exact diff that the script will >> upload to bugs.webkit.org. > > Or we could show the diff twice. It all depends on whether we think reviewing > change log entries after writing them in the context of the rest of the patch > is an important step. I wouldn’t mind seeing the diff a second time, > especially if we could figure out a way to make sure it doesn’t open a second > window. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
