From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: trunk r115265: * lisp/vc/vc-dispatcher.el (vc-log-edit): Setup the Summary&Author headers. Date: Sun, 01 Dec 2013 16:10:34 -0500 Message-ID: References: <871u1zes89.fsf@yandex.ru> <5298AA77.4060009@yandex.ru> <52991737.9000904@yandex.ru> <529A0C08.8010809@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385932249 14735 80.91.229.3 (1 Dec 2013 21:10:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Dec 2013 21:10:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 01 22:10:54 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VnEI1-0004NU-FF for ged-emacs-devel@m.gmane.org; Sun, 01 Dec 2013 22:10:53 +0100 Original-Received: from localhost ([::1]:32870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnEI0-00029u-Rg for ged-emacs-devel@m.gmane.org; Sun, 01 Dec 2013 16:10:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnEHr-00029l-OO for emacs-devel@gnu.org; Sun, 01 Dec 2013 16:10:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnEHk-00045X-2N for emacs-devel@gnu.org; Sun, 01 Dec 2013 16:10:43 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:22254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnEHj-00044V-I5 for emacs-devel@gnu.org; Sun, 01 Dec 2013 16:10:35 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCox4/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFFMCox4/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="40856819" Original-Received: from 76-10-140-120.dsl.teksavvy.com (HELO pastel.home) ([76.10.140.120]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 01 Dec 2013 16:10:34 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 89D0E60CCE; Sun, 1 Dec 2013 16:10:34 -0500 (EST) In-Reply-To: <529A0C08.8010809@yandex.ru> (Dmitry Gutov's message of "Sat, 30 Nov 2013 18:02:16 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165992 Archived-At: >> 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'? Can't tell you without looking at them. Presumably they do more than just kill the buffer and using a kill-buffer-hook was not an option.. In the case of message-kill-buffer' it seems to be trying to deal with the fact that the content of the buffer is like that of an unsaved file, but buffer-file-name is non-nil, so it can't rely on the standard kill-buffer handling. In the case of *VC-Log* we could have a kill-buffer-hook which prompts the user and aborts the kill if the user says he doesn't want to throw away his incomplete comment. But as you point out below, we could also instead have a kill-buffer-hook which saves the incomplete comment to log-edit-comment-ring so the buffer can be deleted without losing valuable info and hence without prompting. > 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 might indeed provide a key to "hide" the *VC-Log* buffer without killing it. And that should hide (or kill) the *log-edit-files* as well. > 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. As long as the data is stored in log-edit-comment-ring I think it's OK to kill without prompting. Stefan