From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: trunk r115265: * lisp/vc/vc-dispatcher.el (vc-log-edit): Setup the Summary&Author headers. Date: Wed, 04 Dec 2013 02:43:26 +0200 Message-ID: <529E7AAE.202@yandex.ru> References: <871u1zes89.fsf@yandex.ru> <5298AA77.4060009@yandex.ru> <52991737.9000904@yandex.ru> <529A0C08.8010809@yandex.ru> <529BF309.4010109@yandex.ru> <529D3F52.3040304@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1386117829 28551 80.91.229.3 (4 Dec 2013 00:43:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2013 00:43:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 04 01:43:53 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 1Vo0ZF-0007AT-7K for ged-emacs-devel@m.gmane.org; Wed, 04 Dec 2013 01:43:53 +0100 Original-Received: from localhost ([::1]:45679 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vo0ZE-0001v7-Mo for ged-emacs-devel@m.gmane.org; Tue, 03 Dec 2013 19:43:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vo0Z4-0001uz-KW for emacs-devel@gnu.org; Tue, 03 Dec 2013 19:43:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vo0Ys-0001Pc-EX for emacs-devel@gnu.org; Tue, 03 Dec 2013 19:43:42 -0500 Original-Received: from mail-we0-x22c.google.com ([2a00:1450:400c:c03::22c]:62422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vo0Ys-0001PV-7K for emacs-devel@gnu.org; Tue, 03 Dec 2013 19:43:30 -0500 Original-Received: by mail-we0-f172.google.com with SMTP id w62so8706968wes.17 for ; Tue, 03 Dec 2013 16:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gru39DA1ympyFnULVydFDeKOmsypfz/b0UjCLRdOcKw=; b=axZahsBVc4n25/P2Y9YHRHJo45QGqq9XZfXibQmuT62dt8TjuRwE1ToK8zf0HFy26d 9R/A4/0nV8e6DDm1vp8184C1SvhnMkoBmfSAD4ywvYXGQXAq/AE8dKPObDNXKoWb83ml /H8cKqmAK+iKZte2+aP0b3B5Bx+flM6YSiK0zX0pVvxHHS6TJHUXNFo4fMOPVcblOILv m+jVRZ00NXahX2/x3pUP3KrN8Aaa6Hthw+HmVA2dSf8TZxEt2mc7kJKJIFS7HD3ZNn4f jvrnF7OC9p9ykre4Gm9bVxiy3cCNtRvhKPuiLxTWSqVcjd4EqSrtX8/uGAvYsmbiGjQ8 7MrQ== X-Received: by 10.194.142.142 with SMTP id rw14mr59288wjb.87.1386117809122; Tue, 03 Dec 2013 16:43:29 -0800 (PST) Original-Received: from [192.168.10.2] ([62.228.136.233]) by mx.google.com with ESMTPSA id pi6sm1882837wic.3.2013.12.03.16.43.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 16:43:28 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::22c 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:166058 Archived-At: On 03.12.2013 05:09, Stefan Monnier wrote: > I'm not sure it's better than what we have, indeed. I wouldn't be hard to present a scenario where the window displaying the files buffer has a non-empty history of previous buffers, and thus shouldn't be deleted, at least in principle. But all such scenarios that I can imagine are pretty convoluted, and it wouldn't really be much of a problem anyway. > I guess TRT is to "write a new display-buffer-function". But let's wait > until we bump into actual problems, so we know concrete examples to improve. Yes, let's wait for bug reports.