[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: trunk r115265: * lisp/vc/vc-dispatcher.el (vc-log-edit): Setup the S
From: |
Dmitry Gutov |
Subject: |
Re: trunk r115265: * lisp/vc/vc-dispatcher.el (vc-log-edit): Setup the Summary&Author headers. |
Date: |
Sat, 30 Nov 2013 18:02:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 |
On 30.11.2013 04:29, Stefan Monnier wrote:
Note that a solution that applies only to ChangeLog wouldn't help for
the `elpa' branch. And hopefully at some point it won't help for
`emacs' either because we'll have finally rid ourselves of the
ChangeLog files.
Ok, good point. If other contributors have no new suggestions, I'll be
content with a user option.
We could easily highlight Summary specially after the Nth character.
[ Not sure why it should be 50, and that number might need to
depend on the backend, but other than that, I don't see
any particular difficulty. ]
50 is just a convention, so it shouldn't be inherently different for any
other backend. And a safe-local user option will allow users to set it
per project.
Actually, now that I've checked, `C-c C-k' in both `message-mode' and
git-commit-mode' that Magit uses kill the buffer after doing some cleanup,
not bury it. Would you be fine with that?
Seems a bit pointless since C-x k (and kill-this-buffer) works as well
for *VC-Log*, AFAIK.
Why do we have `message-kill-buffer', `rcirc-multiline-minor-cancel' and
`org-kill-note-or-show-branches'?
As I see it, they mean "abort the current action, clean up its data,
restore the previous window configuration". Having a similar command
with the same binding in log-edit would be natural. Among other things,
it would delete the *log-edit-files* window and quit-window on the
current buffer (maybe deleting the window as a result).
We can go against the similar commands and refrain from killing the
buffer, but why keep it? We can also save the aborted commit message to
log-edit-comment-ring.
I think it can look better than using a separate window. But then again,
it's how other editors do it, so it might just be more familiar.
I used a separate window because it seemed easier, avoiding the usual
problems with display-only-text or with text-that-will-disappear, which
both can lead to surprising behaviors for the unsuspecting user.
Ok, I can work with either approach.