Sean Whitton <spwhitton@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Debbugs Internal Request <help-debbugs@HIDDEN>
to internal_control <at> debbugs.gnu.org.
Full text available.Received: (at 80037) by debbugs.gnu.org; 23 Jan 2026 14:21:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 23 09:21:52 2026 Received: from localhost ([127.0.0.1]:34895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vjI2q-0007Jb-6j for submit <at> debbugs.gnu.org; Fri, 23 Jan 2026 09:21:52 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:47616) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vjI2n-0007In-Fm for 80037 <at> debbugs.gnu.org; Fri, 23 Jan 2026 09:21:50 -0500 DKIM-Signature: a=rsa-sha256; b=p9fSJA3s0dvfb4s9m4kBZNq5y+MlyWsM+c56eKbaVqPxBpMkhbWZatJ9j5z8bvq4E5MvTqB30p9Z80ehQ7/uFZ+r+DYEVFtokG0MhwJ+H5MXXdMwee8AxlzdTT3yHi2KcPx1EbeGsdkK7irtx8vMZ21wObcT/DkbLyDVRjdbsWt8W8dPj8dZkqjTnZMZratzUtbEXDniI5BptUROirPF+615Nn5bfYIRjFNJa3pCY/Uy7xqgDyv8iqOXYccl/BDHr9F/Qd1MIp9Uia6BRuRQbZW9I+sTL+Bm4zePa4/NT1cBj2W3Sn+KlEPlUT3+BeZ80qBpe0rzADTV0L0Xhp7OXg==; s=purelymail1; d=spwhitton.name; v=1; bh=BSlJuPCTpCgej2liOvJjCipF5bLqAxiD9FT8sE9gTX8=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=fRLkPLSvxT5QKQ1A+tAyiRzqxJRSlnFFLGFyMt4C7iTTnPJWG+pAcSu51t2EU46SRrC8e3jQ8puzUddPAYjr/KgV5KnagPeeqM+7j+7WpDufBeSKo1CI3eMUMkN7AkVpSiD7X+oCP/LHFEn/9O664cjn0haUTA8+mUe47qjLkGqav+UfOssxSZ7pOqeN5h4ZKnnj2XZjW/eHInup8h9JoDxYkG3XxmmX3GwUEIDBRaL5DD38tntdxx6wei916VWSVO+lTxFCfpWGyRq/anfb11zeE96L7bzvhnVym5UZ4EKgasDmE7WWXmIBsMLK1RuNuSf/qbL7jT9y+hNxSp+KPg==; s=purelymail1; d=purelymail.com; v=1; bh=BSlJuPCTpCgej2liOvJjCipF5bLqAxiD9FT8sE9gTX8=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80037 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -2065220938; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 23 Jan 2026 14:21:40 +0000 (UTC) Received: by melete.silentflame.com (Postfix, from userid 1000) id B68287E90C5; Fri, 23 Jan 2026 14:21:39 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' In-Reply-To: <c2afd251-4803-4473-8837-88f8d0ef3675@HIDDEN> References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <62465385-b020-4322-8bd9-cf9cc9072095@HIDDEN> <86ms24iyau.fsf@HIDDEN> <c2afd251-4803-4473-8837-88f8d0ef3675@HIDDEN> Date: Fri, 23 Jan 2026 14:21:39 +0000 Message-ID: <87a4y4quj0.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 80037 Cc: 80037 <at> debbugs.gnu.org, control@HIDDEN, sbaugh@HIDDEN, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) reopen 80037 retitle 31.0.50; Reducing default VC log LIMIT to 500, "Specify number of extra entries to show" button thanks Hello, Dmitry Gutov [23/Jan 3:40pm +02] wrote: > On 23/01/2026 09:27, Eli Zaretskii wrote: > >>> Personally, it's difficult to imagine a scenario where I would use >>> limit: because it's non-trivial to determine the number of commits it >>> would take to print a specific one. One would possibly filter by date >>> (in the terminal), or not at all, relying on paging. >> To my mind, LIMIT is a device intended to limit the time until the >> command presents its full output. It is a very rare situation, in my >> workflows, when I need to see the entire history of the tree. >> Currently, the default LIMIT is 2000, which IMO is too large. > > What I meant of course, is situations where I would specify the value of LIMIT > interactively, rather than having the command use the current default. > > A smaller default sounds fine to me too - especially if we give the users a > more accessible way to specify it using the button. > >>> So I'm pretty sure the vast majority of our users use the "Show 2X >>> entries" button instead, perhaps multiple times. >> I'm surprised to hear that many people need to see many thousands of >> revisions of log. Or are we talking about different things? > > To elaborate: > > I'm pretty sure that on the rare occasions that they need to see many > thousands of revisions at all, our users choose to click the "Show 2X > entries" button, rather than pass LIMIT to the command interactively. And > repeat clicking on the button until the revision they are looking for > appears in the log. > > This is something I _have_ done, many times, when digging into old history. A button which prompts for a new limit is a nice idea, thanks. I'd be happy with us adding that. 'C-x v L' is slow on the Linux kernel's git repository. A smaller default limit would probably help with this. How about reducing it to 500? -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 23 Jan 2026 14:17:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 23 09:17:45 2026 Received: from localhost ([127.0.0.1]:34808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vjHyr-0006xF-63 for submit <at> debbugs.gnu.org; Fri, 23 Jan 2026 09:17:45 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:46280) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vjHyn-0006wX-C2 for 80037 <at> debbugs.gnu.org; Fri, 23 Jan 2026 09:17:44 -0500 DKIM-Signature: a=rsa-sha256; b=OULE+JfdURyFV7xoSoj8mgANBGglFW3V4LQVWHp2pFLHe8xpwpETOVCIbgerfIaiVwG9WX2l3MR8GOKUu12Cm7aYh77y88Pz57TCY9F9ops3pdJYQ75WY5CILmFOuczd4PEretkK4lhyNzwsn+pSD0wj3ftFb+kAB/3Oi1Gd45qRo4R+HIP8hGdn1dEQ5mnxylyY5YRbQxsqJDbZRG5uZvxi2HAZugrPLoskfHiESHXjV5shlr1LK2NzuVRW17/ozesR/LghE4ytlaO6fu4oLkAvbhu/9oC81UfAB+qys3R+zhhVPOusSHdNBakehiIQlj+z3tvzlIuzUMXyvhdS7A==; s=purelymail1; d=spwhitton.name; v=1; bh=hAnwepCinCYwGauHLZi52lXZePcDmhxJAAaRKRrtZFM=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=S0MevEI/MG7cPB4JWgZt+ZpROIcRREq7Rn7emeS0zJRBNqmUo1L+n31RJI8y2S1GL+st9d/g/I2TJ0JmTD/RfgFMaEktrrfefXsWfNA6JypInmoA1fCsJeQky6Ui3TJ6xjwWvomU2+xP2vsFQ4Fsa7EiwpUbnDHFka30DO8NI4B3Gm1em1Cn8jv9nY4pq4iR69Ntc7HCzNCAR/IGndPe9opYzHIp48koT8R4wVYSe0QxfIP+AHNjrMVd+yFTEn/kkqLr1CEkB00pyNSzasV1m6pmoPOmQDU2vQutvlqOF2jplx5lPOde8am/48aPUHG/f9iOvV5uj0zxDa3iMZ3D1w==; s=purelymail1; d=purelymail.com; v=1; bh=hAnwepCinCYwGauHLZi52lXZePcDmhxJAAaRKRrtZFM=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80037 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1234679983; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 23 Jan 2026 14:17:32 +0000 (UTC) Received: by melete.silentflame.com (Postfix, from userid 1000) id 9A4C27E0588; Fri, 23 Jan 2026 14:17:31 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' In-Reply-To: <a7fe96cd-fb11-48fa-8eeb-c051d0602245@HIDDEN> References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <87y0mxgwie.fsf@HIDDEN> <867buhyzir.fsf@HIDDEN> <87wm2hfa97.fsf@HIDDEN> <87344tgvc1.fsf@HIDDEN> <8426fa71-2e9b-4679-9628-c75c10998c6e@HIDDEN> <86jyx8ixkh.fsf@HIDDEN> <a7fe96cd-fb11-48fa-8eeb-c051d0602245@HIDDEN> Date: Fri, 23 Jan 2026 14:17:31 +0000 Message-ID: <87ecngqupw.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 80037 Cc: 80037 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) Hello Dmitry, Dmitry Gutov [23/Jan 3:34pm +02] wrote: > On 23/01/2026 09:43, Eli Zaretskii wrote: > >>> They both don't seem distinct enough from the existing commands, so it's >>> difficult to grasp at a glance why we have both (ideally, names would >>> hint at the difference in behavior). But it can be okay if we intend to >>> replace the default bindings someday, deprecating the originals. >> They are deliberately similar, because they do the same jobs, just >> with a slightly different UI. >> And the difference is explained close to the beginning of the doc >> string, so I don't think users will be confused. > > Fair enough. > >>> But also they are called too similarly to another thing we have, and >>> that's ChangeLog files: in the same file we define vc-update-change-log >>> (operating on them), and we also have change-log-mode, >>> add-change-log-entry, etc. So maybe we could choose a different word. >> "Change log" and "change" are not the same thing, though. The "log" >> part is significant. > > Not sure I get your point. Both new names include "change-log". As do the > older names that we have that are related to ChangeLog's. > >> But if you have better suggestions for the names, please do tell. > > quick-log, fast-log, log-auto, neo-log. > > None sounds great exactly, but that's the direction I would be looking to. What I had in mind was how the buffer that is generated has the name "*vc-change-log*". I wanted to avoid using valuable names, that we might want to use for other things in the future, because these are interactive-only variants. So for now my preference would be not to change them. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 23 Jan 2026 13:40:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 23 08:40:35 2026 Received: from localhost ([127.0.0.1]:34436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vjHOs-0003iz-L5 for submit <at> debbugs.gnu.org; Fri, 23 Jan 2026 08:40:35 -0500 Received: from fout-b8-smtp.messagingengine.com ([202.12.124.151]:49005) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1vjHOn-0003iX-6M for 80037 <at> debbugs.gnu.org; Fri, 23 Jan 2026 08:40:32 -0500 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id 0069B1D00027; Fri, 23 Jan 2026 08:40:22 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Fri, 23 Jan 2026 08:40:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1769175622; x=1769262022; bh=jtmDVaU7ufC7JmT6/QyX+0qayYqA1eQFDRDGGUlhaP4=; b= oDqbYy9Fbee/BwE/h6LQabt3mrhKaAkFxF8hTiVsQWGncnkd6v33KpxJaSB7Oacg U/PdKSzD2gsk3GD4VT74YlL2niL8CN1wFf0TBwxA1yBFXYsziYfh2ckGxiVsxNoK yoRf+s+vbrCDpNWzQj8WZ2g4YKHii7uEVwuGOBzQcNgUaN3W+OrBAcg99a29lBo8 18sR8QYDozv0+Wq5WEFM/35q8G4CiG+hmPHmkiXkpyPVvHkyQTNbGQzHo41W1HHA BgfshQOGv65tuh371uXwN4IL9rYMswA5Fx01VQZcvx7RL34qoirogbdiFiBzaBcS nMWnWsjw0nFYIG2pxcXvkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1769175622; x= 1769262022; bh=jtmDVaU7ufC7JmT6/QyX+0qayYqA1eQFDRDGGUlhaP4=; b=w 0vzPt3hpGM+nxM277zk1VWxzPWj+/ckhAwzhmGpZvjrVoV44JjwKPJAYBKtSXO/a vnDyRN5mhpysEY+HD6YOKuFGZrAArnQaJ6ZhrlmYV0S/vV7mxDYD4uwhDyxe5/vG NGojrn1FjaSdQ2KMacE+bqgrACh00JgwG0UiWWeI29Efp63fNFM63RQgCtVwktQd 9VaFkubqRg/sy7gzUbES/SZzAkoJ8FleDWMR1tijW5JLGXSfabUIFjg2Ckw0yqvj Rx7+tNQh48gXdFPF5dcBrH8qmRNhfXqfZ8ZOQad8alU5Qxmi5jjqRc36ltypEKKq 0XN/yYbu6NREFHITARdOQ== X-ME-Sender: <xms:RnpzaeD0Xy6HXUvgP5XdqjBSJpQu4LuLPVrBjd_JmS-j4yqwyBHd2w> <xme:RnpzafZpiQ6NPYo-cutKqOXV1RwUO3R6BemuPwnO-CFwawB6svFGi51tYkQ6xhShK fElYqdhkmZShVbs7CrgaNDgsgz7zK_uEvEja2mTGlNreIWU8C1TspE> X-ME-Received: <xmr:RnpzaZ60j0tpKaRCCQnbRVh3fazk1M-bmVr4AEVa3pptVFCrJU4DRsURjQl3AnxLiSHk> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddugeeludekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeeh necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmih htrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehsphifhh hithhtohhnsehsphifhhhithhtohhnrdhnrghmvgdprhgtphhtthhopeektddtfeejsegu vggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepjhhurhhisehlihhnkhhovhdrnh gvthdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhm X-ME-Proxy: <xmx:RnpzaYYFv1N-GCfp8FbF1a0Fkut-WH6O70grYihQF2-AW0u01lLCFQ> <xmx:RnpzaQh76ce7YN_iifwr04oQxFwnhMPmrnI-OW7ogkoJkpSg6_mOXA> <xmx:RnpzaR_sTkIQoPkhG0pOY08ldydphXfosedM8YbWTCm0azpLUb2xvQ> <xmx:RnpzaTqriwjt0FfLag4Xc9-BX0qBfhE7mV2NzSCRm2yzjCx4mkPcDg> <xmx:RnpzaTpLg8xr9eXanFNSBX-m6FuWznxc6oxhZvugwOwcGmfB8ygABBr6> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 23 Jan 2026 08:40:20 -0500 (EST) Message-ID: <c2afd251-4803-4473-8837-88f8d0ef3675@HIDDEN> Date: Fri, 23 Jan 2026 15:40:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' To: Eli Zaretskii <eliz@HIDDEN> References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <62465385-b020-4322-8bd9-cf9cc9072095@HIDDEN> <86ms24iyau.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86ms24iyau.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80037 Cc: 80037 <at> debbugs.gnu.org, juri@HIDDEN, sbaugh@HIDDEN, spwhitton@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) On 23/01/2026 09:27, Eli Zaretskii wrote: >> Personally, it's difficult to imagine a scenario where I would use >> limit: because it's non-trivial to determine the number of commits it >> would take to print a specific one. One would possibly filter by date >> (in the terminal), or not at all, relying on paging. > > To my mind, LIMIT is a device intended to limit the time until the > command presents its full output. It is a very rare situation, in my > workflows, when I need to see the entire history of the tree. > Currently, the default LIMIT is 2000, which IMO is too large. What I meant of course, is situations where I would specify the value of LIMIT interactively, rather than having the command use the current default. A smaller default sounds fine to me too - especially if we give the users a more accessible way to specify it using the button. >> So I'm pretty sure the vast majority of our users use the "Show 2X >> entries" button instead, perhaps multiple times. > > I'm surprised to hear that many people need to see many thousands of > revisions of log. Or are we talking about different things? To elaborate: I'm pretty sure that on the rare occasions that they need to see many thousands of revisions at all, our users choose to click the "Show 2X entries" button, rather than pass LIMIT to the command interactively. And repeat clicking on the button until the revision they are looking for appears in the log. This is something I _have_ done, many times, when digging into old history. > It's > hard to have a conversation about complex technical issues with > month-long gaps between messages. Sorry.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 23 Jan 2026 13:35:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 23 08:35:06 2026 Received: from localhost ([127.0.0.1]:34328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vjHJa-0003Dq-6U for submit <at> debbugs.gnu.org; Fri, 23 Jan 2026 08:35:06 -0500 Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]:58763) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1vjHJU-0003Cf-Pc for 80037 <at> debbugs.gnu.org; Fri, 23 Jan 2026 08:35:04 -0500 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id A57217A001D; Fri, 23 Jan 2026 08:34:54 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Fri, 23 Jan 2026 08:34:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1769175294; x=1769261694; bh=RGC2g7pbj3HhLaY+ZI22FLGU+OTiyjUqS7P9bclWZm4=; b= PFyHOLOIWRppQ9AbYDiUuQkUNfR62rgP2BwMqK3YIRkkxNb+bDUWdwvU0/t6gSw8 9cxa0+In578LM9vyrPIoqI7viGY+4rFJyNugKojG0jz7yqtS7QmIGAFud8Kcvgw1 wjmPhkuQ+EQlmfpNhenhFh0pxH/w3HfBIsH1mcKCJmofqtyLPeJINdCx8vggtcI5 NUyyGtccuyajKtKeSZV3Q1nEoFSPoQ+3uNjzufN9LcReGLDp6VKttkM/R47+SKZf oSfI7FIYfp/LKC6fITEJwCv9b+/Y4zHISNFEsERNaQrtXWOrlwMRq3fU1Gd57sNE FHfR5O7g3GjQuNSCbdq2Iw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1769175294; x= 1769261694; bh=RGC2g7pbj3HhLaY+ZI22FLGU+OTiyjUqS7P9bclWZm4=; b=A 7zpbzVSLdcJ/EEbatYk22j6h6hBmKjhAZBUWaGhnKgOKuNlAccQi5FtpnkKGYa7E Gu4IjgqoSlk1BuL2iEFM1l+IBZoXYXVz6pePDOlbR0VncG91l2BMY6qoONE+vhDX Q3S1Wsq8Ryt4/04AuAbNSc+gRTDNWn7ts7jEK49wKoyo8ViLgbFX8QrUbktbLKD8 eHQ0+0TcQy7sIO0f+SYwILM4Z9UfjjFpLYeyWjSyt7yvzPA4VIYJ+IIxluIeudLu VLvsCFW9npiPR5a1vqLT9SMsC5XUZoUXm1yPeKR7wGG+n3ArlXKKjc5lVJ2tFgNO npusNuShNQnV9tjncw+OQ== X-ME-Sender: <xms:_XhzafWxrUKqJKC93-de0pRvnUkwf8IeQcjCMnO4lpofxTAmSd_xWQ> <xme:_XhzafDahKdm-Q2qZG3NPWis7xOcjSqtwHgZkvKDlJHZRrwr6_s7dzxXGcxrvek0e _h1bP9siN9BNWVBLthpBdjDun0cuaZF9Eosde2QFF4Nr_XkUKuXOHHi> X-ME-Received: <xmr:_XhzaYzgAtowjtpuY0lD-numy6wAIcd_aO6fEaJHj5WY_mCfvE-FAwshOlhrrJzZ-9T9> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddugeeludejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeeh necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmih htrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopeektddtfe ejseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepshhpfihhihhtthhonhes shhpfihhihhtthhonhdrnhgrmhgv X-ME-Proxy: <xmx:_XhzaUDn0boeuF030Zt3LD2ZtvK5C4GYsN_fH-S6k8LhU9BieY8fig> <xmx:_XhzadZxhDqPHxUVFAHrzGaWEOfT0On9tuS_Cv6xWs39M2u9Zf2lkw> <xmx:_XhzaUg9hHg4nxG50wahiNs4us1YfvONBvTubdJmKz4yZriD6H5yWg> <xmx:_XhzaX7Rj3uIhbPHuro818iUjaNzsgdtjvTVgHmlR6NZxG0H3dzLaQ> <xmx:_nhzaSfZnqv831P91LTNXQB60ylP3acrfIUHEr5cgU1xk2n_jgXXmQNW> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 23 Jan 2026 08:34:52 -0500 (EST) Message-ID: <a7fe96cd-fb11-48fa-8eeb-c051d0602245@HIDDEN> Date: Fri, 23 Jan 2026 15:34:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' To: Eli Zaretskii <eliz@HIDDEN> References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <87y0mxgwie.fsf@HIDDEN> <867buhyzir.fsf@HIDDEN> <87wm2hfa97.fsf@HIDDEN> <87344tgvc1.fsf@HIDDEN> <8426fa71-2e9b-4679-9628-c75c10998c6e@HIDDEN> <86jyx8ixkh.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86jyx8ixkh.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80037 Cc: 80037 <at> debbugs.gnu.org, spwhitton@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) On 23/01/2026 09:43, Eli Zaretskii wrote: >> They both don't seem distinct enough from the existing commands, so it's >> difficult to grasp at a glance why we have both (ideally, names would >> hint at the difference in behavior). But it can be okay if we intend to >> replace the default bindings someday, deprecating the originals. > > They are deliberately similar, because they do the same jobs, just > with a slightly different UI. > > And the difference is explained close to the beginning of the doc > string, so I don't think users will be confused. Fair enough. >> But also they are called too similarly to another thing we have, and >> that's ChangeLog files: in the same file we define vc-update-change-log >> (operating on them), and we also have change-log-mode, >> add-change-log-entry, etc. So maybe we could choose a different word. > > "Change log" and "change" are not the same thing, though. The "log" > part is significant. Not sure I get your point. Both new names include "change-log". As do the older names that we have that are related to ChangeLog's. > But if you have better suggestions for the names, please do tell. quick-log, fast-log, log-auto, neo-log. None sounds great exactly, but that's the direction I would be looking to. >> Long story short - if it was determined by the limitations of >> backends which we don't use anymore, it would make sense to change. > > As long as those "older backends" are still in use, I don't think we > should make any such changes in long-time established UIs. CVS might be the only one such still in use. Worst case, we could do a fallback for it specifically to the current behavior.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 23 Jan 2026 07:43:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 23 02:43:20 2026 Received: from localhost ([127.0.0.1]:57425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vjBpA-0008OU-3i for submit <at> debbugs.gnu.org; Fri, 23 Jan 2026 02:43:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59380) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vjBp7-0008O6-P2 for 80037 <at> debbugs.gnu.org; Fri, 23 Jan 2026 02:43:18 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vjBp1-0000zK-TO; Fri, 23 Jan 2026 02:43:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TbH/vmVCAlmLEB9R5vGtKZjZw2VXIlwKG1MhkOD4RKQ=; b=WJDgWOYSkVJW z5+CNhZ6sOZJluP42G94kANkgTaa93VnKYhmaGQ01BjgHdm9MZ4E+nrJ/h+MCRZaOsZo1lz2CtL7g MblurMAHxy0bCJ08M7DRFdpuME57IdvpRjSc0a4n9C1+R7WDpL7N+20xDEctTNRVqFG+jAcK7gZJX 6YHDGLPLHH4ej7M1sJN94mz1YvZuDjfSYYAjuHaJagW4VEAGVhqTV0I1PDWL1iosIzSBRAvsbC0Z+ fgOwFtdQT978eXIuEseRaO1rY+8xPkvUp2iTMRhOB3MKuF0fYefZQ+peGoXZDtlF2+uS+Nc1FMfVz kiIVmaO/jNfHBsMTAJZVVA==; Date: Fri, 23 Jan 2026 09:43:10 +0200 Message-Id: <86jyx8ixkh.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <8426fa71-2e9b-4679-9628-c75c10998c6e@HIDDEN> (message from Dmitry Gutov on Fri, 23 Jan 2026 06:26:56 +0200) Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <87y0mxgwie.fsf@HIDDEN> <867buhyzir.fsf@HIDDEN> <87wm2hfa97.fsf@HIDDEN> <87344tgvc1.fsf@HIDDEN> <8426fa71-2e9b-4679-9628-c75c10998c6e@HIDDEN> X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 80037 Cc: 80037 <at> debbugs.gnu.org, spwhitton@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) > Date: Fri, 23 Jan 2026 06:26:56 +0200 > From: Dmitry Gutov <dmitry@HIDDEN> > > Regarding the chosen name for the new commands: > > vc-print-root-change-log > vc-print-change-log > > They both don't seem distinct enough from the existing commands, so it's > difficult to grasp at a glance why we have both (ideally, names would > hint at the difference in behavior). But it can be okay if we intend to > replace the default bindings someday, deprecating the originals. They are deliberately similar, because they do the same jobs, just with a slightly different UI. And the difference is explained close to the beginning of the doc string, so I don't think users will be confused. > But also they are called too similarly to another thing we have, and > that's ChangeLog files: in the same file we define vc-update-change-log > (operating on them), and we also have change-log-mode, > add-change-log-entry, etc. So maybe we could choose a different word. "Change log" and "change" are not the same thing, though. The "log" part is significant. But if you have better suggestions for the names, please do tell. > Long story short - if it was determined by the limitations of > backends which we don't use anymore, it would make sense to change. As long as those "older backends" are still in use, I don't think we should make any such changes in long-time established UIs.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 23 Jan 2026 07:27:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 23 02:27:33 2026 Received: from localhost ([127.0.0.1]:57196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vjBZt-0007GP-7P for submit <at> debbugs.gnu.org; Fri, 23 Jan 2026 02:27:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40682) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vjBZp-0007Ff-Qh for 80037 <at> debbugs.gnu.org; Fri, 23 Jan 2026 02:27:31 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vjBZj-00065W-Bx; Fri, 23 Jan 2026 02:27:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=v+cP5Few+ko6RIzHrZMc4CmbatYoVXIHOBPl5NLTw4c=; b=IEbw3OEJoLuR R+RZaxZcI1Wkv/zPX4hlL2SVnslKymrqUO2DTbJwtYYSAeeMlXf5WVELUMfGLq9fvKnVfnFp25j7H dkpEwu0Wa9KYP1KVGDSEOQIzFqvz5tPXvgNzUIx8t3QCQr39WGH0UzUNnb8KVjVIqcpgIkx+U3X/e Xulbf+QLtcCnU00o1+x0sWNGxY+fGbi6NdqUe1b/++FmeMix2MBoFCgsTzwE4FrZss3di67UGkSaP lVNLHpyJy3QKEkQUhVISZRPDH2FdUAEr1Cu8GKtvBhw+ldBZIXNys1qhKsMdS4gojqOMrpfYyE/ZW TB3MNvsuka6kkxzILBOd+g==; Date: Fri, 23 Jan 2026 09:27:21 +0200 Message-Id: <86ms24iyau.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <62465385-b020-4322-8bd9-cf9cc9072095@HIDDEN> (message from Dmitry Gutov on Fri, 23 Jan 2026 05:25:59 +0200) Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <62465385-b020-4322-8bd9-cf9cc9072095@HIDDEN> X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 80037 Cc: 80037 <at> debbugs.gnu.org, juri@HIDDEN, sbaugh@HIDDEN, spwhitton@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) > Date: Fri, 23 Jan 2026 05:25:59 +0200 > Cc: 80037 <at> debbugs.gnu.org, juri@HIDDEN, sbaugh@HIDDEN > From: Dmitry Gutov <dmitry@HIDDEN> > > Sorry, a little late to the discussion, but: > > On 20/12/2025 14:00, Eli Zaretskii wrote: > >> In particular, it is very interesting to hear that you regularly specify > >> the LIMIT > > No, I said that I_sometimes_ use LIMIT. However, in most cases, I'm > > only interested in the latest part of the log, starting from HEAD, so > > some default value of LIMIT that is not too large should be okay for > > my uses. > > Personally, it's difficult to imagine a scenario where I would use > limit: because it's non-trivial to determine the number of commits it > would take to print a specific one. One would possibly filter by date > (in the terminal), or not at all, relying on paging. To my mind, LIMIT is a device intended to limit the time until the command presents its full output. It is a very rare situation, in my workflows, when I need to see the entire history of the tree. Currently, the default LIMIT is 2000, which IMO is too large. > So I'm pretty sure the vast majority of our users use the "Show 2X > entries" button instead, perhaps multiple times. I'm surprised to hear that many people need to see many thousands of revisions of log. Or are we talking about different things? It's hard to have a conversation about complex technical issues with month-long gaps between messages.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 23 Jan 2026 04:27:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 22 23:27:08 2026 Received: from localhost ([127.0.0.1]:54938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vj8lI-0001XQ-Fu for submit <at> debbugs.gnu.org; Thu, 22 Jan 2026 23:27:08 -0500 Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:33429) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1vj8lF-0001Wq-D3 for 80037 <at> debbugs.gnu.org; Thu, 22 Jan 2026 23:27:06 -0500 Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id 8D59D1400248; Thu, 22 Jan 2026 23:26:59 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Thu, 22 Jan 2026 23:26:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1769142419; x=1769228819; bh=8vNoza8ELkLF01e3QagdnlVwxO8cBiuBgi8e0ezShn4=; b= mBVKBKNWlTGGTuLOMtk/PuzEzFH3p2cQl/Z5xhuv6kmkedO8NzYDMaqsWcpKzrJD ZYX6dXwSF2IGxpnn4bJYO2ZwnuG1YaH6YKQqwTmO8u14DqxSsHyB4ebytnzngoBW haRJSooxtGLHF2Q3o3X+BKWK2IytuLIkXtRpy9xj15bmYhyH8R/P8EyLLbbvdY7E BYZRw3K0xDe2Lljx24wgUZrh6NwiiETyQfb09YdMwa+dkWM0RQOvm1Wfw1Th5s8i ULhuolFV1uGc0FQM4XKI8LcDdGYBfzN1QU1PS+7zzSyZOzmjEfKPmXASBOoVRK1V ebxOHuzl3wxED6x7qwaWZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1769142419; x=1769228819; bh=8 vNoza8ELkLF01e3QagdnlVwxO8cBiuBgi8e0ezShn4=; b=LTziSA4gXL4SWNq1j kxnCIch4niEE0IRnD26yGWRmGnAg45/eQ0GjUIgAf8df1bnoG4n9Y3mZ9hDinaWJ IXnAdDOwYXAhWWIQiHXjM1vnLtCw2cRmBLHdjhRPx2Hm9+btenxxJUj6og4KUpmt vdqcbsZR/kRnnG0aRvNiX3qwbxn+ApXuArt0cgB8ZjR6NEmJBbDUziAKsgsB0sqm n0mfiSI0YhIie9icqB7bzuTKdoyc+Su1Jmjx4PUy9hHlNBX9ps6KKVxyKd0dXhJy ypGaSVLmsf0xuK3RDvtl94pOal2EgnWY0uWeYYHXNS8yyj9Lyvfgayc1FYbsC/iU dK1Bg== X-ME-Sender: <xms:k_hyae2hf_YKjjoINcypVizJuY8aJWmOyW5iikfFInSF8if95CrjIA> <xme:k_hyaXF_4kRMdfEPFaMHIVHxP2xyf8kmShlUHcMNetFylNEk5LDkSo--7KGSJRGMY zGrNZQhJLdM3yRsFR8gLOwuPHM20R73TB1DdC1VD1Gsvu48sj7WrQ> X-ME-Received: <xmr:k_hyaUi_ZIFayrTpwnnUxYfiyvgYGxAQ1biRY4zGNnEVg1GH06ZlkNZ68F3KHoMz1IVC> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddugeektdekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertd dtvdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthho vhdruggvvheqnecuggftrfgrthhtvghrnheptdfhuedvtdevleegueelvedvjeevheffve evhedvuefftdefhfdvueeggfetgfdtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtph htthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeektddtfeejseguvggs sghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepshhpfihhihhtthhonhesshhpfihhih htthhonhdrnhgrmhgv X-ME-Proxy: <xmx:k_hyaa9q-omUuz0Lu6jQPG6RCHsDMZBF9shU0E1bzDGRSQOXJUIAzQ> <xmx:k_hyaTokk8CQdgi1u9Uu3bK7Ew5wphbyDb-yTDpEzTSjpohaTud4UQ> <xmx:k_hyaR90QoCbNL3PvfnprVy5dzxt1EGTtM2RQl5EbPlrMOJ5WrWsZA> <xmx:k_hyafX9xxqRYFmKJ7KmCnRjxLuUjzEoAm75EdrVhowsoyT7osq4eg> <xmx:k_hyaZIx0u-XJEC-6UD3JF9yrO7GVVqBs_q8FWVgC_W9joq-6KfEPgQo> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 Jan 2026 23:26:58 -0500 (EST) Message-ID: <8426fa71-2e9b-4679-9628-c75c10998c6e@HIDDEN> Date: Fri, 23 Jan 2026 06:26:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' To: 80037 <at> debbugs.gnu.org, spwhitton@HIDDEN References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <87y0mxgwie.fsf@HIDDEN> <867buhyzir.fsf@HIDDEN> <87wm2hfa97.fsf@HIDDEN> <87344tgvc1.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <87344tgvc1.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80037 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) Hi Sean, On 29/12/2025 17:29, Sean Whitton wrote: > Everything remaining from this bug is now implemented. Regarding the chosen name for the new commands: vc-print-root-change-log vc-print-change-log They both don't seem distinct enough from the existing commands, so it's difficult to grasp at a glance why we have both (ideally, names would hint at the difference in behavior). But it can be okay if we intend to replace the default bindings someday, deprecating the originals. But also they are called too similarly to another thing we have, and that's ChangeLog files: in the same file we define vc-update-change-log (operating on them), and we also have change-log-mode, add-change-log-entry, etc. So maybe we could choose a different word. Or else - I recall the idea to use a new option to decide whether 'C-u' will prompt you for LIMIT or for REVISION. But then we are against two weird established behaviors: a) '... L' and '... l' reacting differently to C-u, b) that the latter scrolls to REVISION rather than starts the log with it. The latter might make sense in theory: could help observe the revision in the context of surrounding history, but I've also only ever used C-s for that. The UI choice seems to originate from some older backends not being able to print the log for a different branch, or a specific revision. Commit 662c5698fb07b4e2 (from 2009) and its description imply that. Likewise there is a reference to it in the docstring of vc-annotate-show-log-revision-at-line. Long story short - if it was determined by the limitations of backends which we don't use anymore, it would make sense to change.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 23 Jan 2026 03:26:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 22 22:26:13 2026 Received: from localhost ([127.0.0.1]:54051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vj7oL-00067q-BJ for submit <at> debbugs.gnu.org; Thu, 22 Jan 2026 22:26:13 -0500 Received: from fout-a4-smtp.messagingengine.com ([103.168.172.147]:46799) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1vj7oG-00067M-Ug for 80037 <at> debbugs.gnu.org; Thu, 22 Jan 2026 22:26:10 -0500 Received: from phl-compute-07.internal (phl-compute-07.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id BF98EEC00DF; Thu, 22 Jan 2026 22:26:03 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Thu, 22 Jan 2026 22:26:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1769138763; x=1769225163; bh=qE53OOaRKrEOICwUF66DJ0GjorzfJoYmnRB3G0jL9Ak=; b= BkQotsHEvfc4Vgdx2bpqP81HFLDsGYvfsnp/1y7OaCQVfqoHC8RJsvJUBzCZDf6t 612QI6F8tV8Z1ZSptJ2MyI4lu+ooOcIdBzNvBeNoGYXk6mkV4jAI7YmMuW6WFp0A 0M/yNW5//+IV6lDxVGG3Fumlsn81HzbEJ7QR09PD6DRnh3HMJa77MfX/HgQgMvGf xNYG9sZHj2IO/sr/j7EffxZzFzHdc6K5ZmvvqzTKdv14SmPvNj9gjUVCsG/sI/6X keMeLs/XosP8QIx/O1fj7i9PcydLK49mpEoGeeKeTHkin3hIQIH0TmfrWAqyCMuK BROXKOsQJshXof2uZxfoog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1769138763; x= 1769225163; bh=qE53OOaRKrEOICwUF66DJ0GjorzfJoYmnRB3G0jL9Ak=; b=t ZXNdfbqndc2ixAqSJ/0sT+7xhAE1NS/kBqkOsHz6LCkn8eLc4Ew8nNW17Ks8jW6Q DbBVYJI00BpUCe9buE4mHy2A0atilRB7hFLaKyoej6uOu/tZEWZdLV3rT2XTJe92 NK/ncB++o83463ITaHzOLZM4RcEzglOka3eETb27WiffefcaczpqlgUpPH5VnFhc f/Vs7jvjn8gzbOAH3wzIO80qlWeaEFY4jYaNtX6uiLDpvGXwdT9HlO31M+gH9UMN xPtITc5Wz8AV4QgVnJrTtyHLfR7oaoeqSW74+PT20b7LVe03VrI67kECMGtO2+qs BCeZkVZDjTBTCjH0t3A8A== X-ME-Sender: <xms:S-pyaRXT_nN4ppdp4e0qxNpR5gwx9i6ziZ_1JlVSK48lDQUKIUp6CA> <xme:S-pyaYekrT3VeFq1IJDMtL-Ar3xrdGPF5ntdljIogzrp8rU37opcPkrk8QwNyTx1k 3pC7hj8flL9TsxnJM9dD5PtQKdacNfGBfcILo9Z4L9X1tduf1j6pQ> X-ME-Received: <xmr:S-pyaVvqRqYZhjU4wgvtpOf2hWq_nv4vN0QIL9-xFvJrOfaECRMgXaFcKEHmQNNGmiqs> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddugeejleeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeeh necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmih htrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehsphifhh hithhtohhnsehsphifhhhithhtohhnrdhnrghmvgdprhgtphhtthhopeektddtfeejsegu vggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepjhhurhhisehlihhnkhhovhdrnh gvthdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhm X-ME-Proxy: <xmx:S-pyaf-0RP7whpCFTNLrQYI2MqbQrdat8zBgT8dzoR1kjT9vTmoUKg> <xmx:S-pyaY3nBzDEgGHRedw8aWPij2vzMeRn-vnArXlEqkE3v1ztgYHZWg> <xmx:S-pyacCeXk0Aa64Rr6PXhYp2KkpiTKjKM77tKloXotIeH_Jn6pLP5A> <xmx:S-pyacdfIyNPQDmVdqL4w3vjTsDLBo_AjFGazFqkkpvcytF7Lm4wMQ> <xmx:S-pyafOrGAhYuHDwLQFwVS7I1TN9PGOGVKvgRZGeJ2wTVSoxfFxx1wXM> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 Jan 2026 22:26:01 -0500 (EST) Message-ID: <62465385-b020-4322-8bd9-cf9cc9072095@HIDDEN> Date: Fri, 23 Jan 2026 05:25:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' To: Eli Zaretskii <eliz@HIDDEN>, Sean Whitton <spwhitton@HIDDEN> References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86tsxlz7kt.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80037 Cc: 80037 <at> debbugs.gnu.org, sbaugh@HIDDEN, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) Sorry, a little late to the discussion, but: On 20/12/2025 14:00, Eli Zaretskii wrote: >> In particular, it is very interesting to hear that you regularly specify >> the LIMIT > No, I said that I_sometimes_ use LIMIT. However, in most cases, I'm > only interested in the latest part of the log, starting from HEAD, so > some default value of LIMIT that is not too large should be okay for > my uses. Personally, it's difficult to imagine a scenario where I would use limit: because it's non-trivial to determine the number of commits it would take to print a specific one. One would possibly filter by date (in the terminal), or not at all, relying on paging. So I'm pretty sure the vast majority of our users use the "Show 2X entries" button instead, perhaps multiple times. BTW, we could consider adding a "Show X entries" button there which reads the exact number specifically (or replace one of the existing ones, e.g. the first one, offering 2X the current as default). That should reduce the demand for the interactive LIMIT argument even further.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037-done) by debbugs.gnu.org; 29 Dec 2025 15:29:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 29 10:29:44 2025 Received: from localhost ([127.0.0.1]:38229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vaFBo-0001tV-BQ for submit <at> debbugs.gnu.org; Mon, 29 Dec 2025 10:29:44 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:57272) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vaFBk-0001sx-RT for 80037-done <at> debbugs.gnu.org; Mon, 29 Dec 2025 10:29:42 -0500 DKIM-Signature: a=rsa-sha256; b=SaXHKweYJQzlApBk0/JomD8Qm91urzylSA/7vHvgYwrCdwDdWTsMwGPQfsz6Zc256fsFOvxQ6lMM5esxKoV0jWxBqyAP/oJvr8GfdGQwKL+pjN2QW8Q6o+5/1mcBrw7HMuFG42Fjjt1vAGVsUZvbgJUFGujG2GbmnWgoGvMnfIo7YkVsnU81xwJ6CNsHfJ6T+8WcxUz3epObYzq33SQ9pbgbrOk5ITXsE/D/X7mjxkLwR4g1ML+NjpH7ixZWEVH0PFOMrL8BDbE3PK6qFVDyxCDDcbgCKqzDVTNTlGHRykAYp5tMmuyQ01rbUYG6KJ/Hn72lPFyfQiQm0n7d0XSRVg==; s=purelymail3; d=spwhitton.name; v=1; bh=jBanBQwZTFqRkGSqe4+SjvDe8I+ReSyyby2tlnI+ZuE=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=L2hicJ+rlFPGctBFPdc3RPN3JtpGFI867OB0k55l2eXjwZt4OheGMn8rtG8W8XvM6odu/4TVwPt4usyMa95z//zmTvOw4AstdOM2skh/6nqcOCWCRNXwYkXNtMPJg6VaA5uCePyyj9jkkz1zkvBgoD7ZrHARVqEXsvw1PPEsSbd80in5LUmDt6hMHAw8iS2LkNzqxEh/XRIG73qogqFZkiE5hVlrwlUkVNNTLQh0AC3ZPLxYfXd9d9D/I85JoLoLuB2axgR5eeuoC8eGBvw5s5UAS57KPWUvY4yrtL/UjiABegAcfsfvnei2/rYcZhkNd5w35LMd2AxqSarlWmz5aQ==; s=purelymail3; d=purelymail.com; v=1; bh=jBanBQwZTFqRkGSqe4+SjvDe8I+ReSyyby2tlnI+ZuE=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80037-done <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1073994499 for <80037-done <at> debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 29 Dec 2025 15:29:34 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 36EE4940791; Mon, 29 Dec 2025 15:29:34 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: 80037-done <at> debbugs.gnu.org Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' In-Reply-To: <87wm2hfa97.fsf@HIDDEN> References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <87y0mxgwie.fsf@HIDDEN> <867buhyzir.fsf@HIDDEN> <87wm2hfa97.fsf@HIDDEN> Date: Mon, 29 Dec 2025 15:29:34 +0000 Message-ID: <87344tgvc1.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 80037-done X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) Version: 31.1 Hello, Everything remaining from this bug is now implemented. -- Sean Whitton
Sean Whitton <spwhitton@HIDDEN>:Sean Whitton <spwhitton@HIDDEN>:Received: (at 80037) by debbugs.gnu.org; 21 Dec 2025 17:58:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 21 12:58:23 2025 Received: from localhost ([127.0.0.1]:38458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vXNhG-0000kp-Id for submit <at> debbugs.gnu.org; Sun, 21 Dec 2025 12:58:23 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:37162) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vXNhD-0000kG-Rg for 80037 <at> debbugs.gnu.org; Sun, 21 Dec 2025 12:58:20 -0500 DKIM-Signature: a=rsa-sha256; b=TDD3eutQp2FZSDFKXxZkLlsR/m+3hRMrpZJLRzzxLhzI/O26d3brpwuwq3T//YVD0/UvyaYboo6DRBiQw/01inVlfnS1RlmUwEfPtTG/5BICeARfb8R7sA3fnvs+noFrwkdT1zJed7Y48Ts3H/3i52Ui6T57h/cHgNmWJZLeTFvD94XmlN9bHYK5bDAXRUEzC1P2TrbAV1p2+W/vV+kMS7e5XVGgJaFuTxiTkh0X6YfUEfoH9XyCg5SGxsAIOprVePOvzNKrxZprlKbTdeqTmnSBtfZr8ZdYZkSqBBTQHej5jSIfQ01xQ6Dy3jO/A2AbMcZoqck/khrOdylEd87AHw==; s=purelymail2; d=spwhitton.name; v=1; bh=zLlTZvxZbtg6Sp1N+OXObV5wsMNTE9Cy+YLLlMQk1Fo=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=FSrRzRHFeUpqBRFJI/N+ihwJNZNn6vuZ7AwW/QGz5hk3rqNpo5R+pXU57ogxKb5nGD0AwNO8FXYW8QC7p3zcBrK9QFcUONJ8iRf6hXh3baJ3LyAsDyMoQFQEiSkpiJWEsk1jjxox9QTLUdLsxMfDWshny466fbwQmAjGXFkUNp8j+02xfUCxsN0W+giwCW/rMS4RKWBTRyLA/iLiAub+vDB5kUxkm8DyDHOHEFOxD35jZHR7GXdlmbqBhM76pm6bJKegyA2EFS+Ys7l1KHYTsikVXeqeKAc4WCJh8lLVDkgSG/tasV0fOGQTwn+FhigbEoAkE2UjQAE/iaFRPC32Gg==; s=purelymail2; d=purelymail.com; v=1; bh=zLlTZvxZbtg6Sp1N+OXObV5wsMNTE9Cy+YLLlMQk1Fo=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80037 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1209567535; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sun, 21 Dec 2025 17:58:14 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 800C3940453; Sun, 21 Dec 2025 17:58:13 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' In-Reply-To: <864iplyx1u.fsf@HIDDEN> References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <87y0mxgwie.fsf@HIDDEN> <867buhyzir.fsf@HIDDEN> <87wm2hfa97.fsf@HIDDEN> <864iplyx1u.fsf@HIDDEN> Date: Sun, 21 Dec 2025 17:58:13 +0000 Message-ID: <87y0mvbtu2.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 80037 Cc: dmitry@HIDDEN, 80037 <at> debbugs.gnu.org, sbaugh@HIDDEN, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) Hello, On Sat 20 Dec 2025 at 05:47pm +02, Eli Zaretskii wrote: >> From: Sean Whitton <spwhitton@HIDDEN> >> Cc: dmitry@HIDDEN, 80037 <at> debbugs.gnu.org, sbaugh@HIDDEN, >> juri@HIDDEN >> Date: Sat, 20 Dec 2025 15:23:00 +0000 >> >> > With my suggestions above, you'd need to know the branch, yes, but >> > otherwise it's not fiddly IMO. And one needs to know the branch >> > anyway, when working with changes from another branch. >> >> No, you don't need to. You can cherry-pick them by revision ID. > > Sure, but in practice, how many times did you do that without knowing > the name of the branch? > >> > Once you did a "git fetch", the stuff is already in your clone, so >> > what do you mean by "don't want to create a local branch"? >> >> I don't want to create a local branch tracking the remote branch because >> I don't in general care about that remote branch. It may be one of tens >> of branches that upstream have hanging around, that are irrelevant to >> me. > > Once again, if we are talking about Git, doing "git fetch" already > brings the branch down to your clone, doesn't it? A branch is just a > pointer in Git, as you well know, so "creating a remote branch" is > basically a no-op, once the objects are in your clone. My experience with this has been that while the remote branch name is accessible to me if I want to hunt through the web interface, and as you say a 'git fetch' is enough to create it, revision IDs are much more immediately available. Therefore, I am glad that we have vc-print-branch-log and that it works for revision IDs, too. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 20 Dec 2025 15:48:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 10:48:09 2025 Received: from localhost ([127.0.0.1]:51164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vWzBh-0006Q6-0U for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 10:48:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46046) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vWzBd-0006PY-Q6 for 80037 <at> debbugs.gnu.org; Sat, 20 Dec 2025 10:48:06 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vWzBX-0002Lx-T3; Sat, 20 Dec 2025 10:47:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Qz7QK5WEqgsqtrdYVkT4L3VqCyxX8A0V5sHHswFQBcE=; b=R+T0+LN3pjal AP2eWcRpS8yIfXAreLVumyv6S4ncFOzQU4XoXAdnGQsC1YWt/FMkvEjyfw9RCX4gQJItAqGWCuCZs /WmwKh4A7WjOetucyCsUSCDvKYn8z8Or+nd1u0LB/svDEU2i5zCHtezf7WE5UzFSLkg76B+AWoAX7 XJvqaYr4kTw7AqaPYoWJw2oVCBb2F4gh5BLgu9rjW3n+KNemfe4CwB/4rYR8Y8i1DxHx6WXy6hLcm sA0cirZ/nIptGd7CsjGO5P/KDpDXWu7ujRdYPT2XVQ6qbIzHetut2swFEHxD6GMOunnlEgpv5QXla dJ6+/yNdbJCU/6890I7ePg==; Date: Sat, 20 Dec 2025 17:47:57 +0200 Message-Id: <864iplyx1u.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Sean Whitton <spwhitton@HIDDEN> In-Reply-To: <87wm2hfa97.fsf@HIDDEN> (message from Sean Whitton on Sat, 20 Dec 2025 15:23:00 +0000) Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <87y0mxgwie.fsf@HIDDEN> <867buhyzir.fsf@HIDDEN> <87wm2hfa97.fsf@HIDDEN> X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 80037 Cc: dmitry@HIDDEN, juri@HIDDEN, sbaugh@HIDDEN, 80037 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) > From: Sean Whitton <spwhitton@HIDDEN> > Cc: dmitry@HIDDEN, 80037 <at> debbugs.gnu.org, sbaugh@HIDDEN, > juri@HIDDEN > Date: Sat, 20 Dec 2025 15:23:00 +0000 > > > With my suggestions above, you'd need to know the branch, yes, but > > otherwise it's not fiddly IMO. And one needs to know the branch > > anyway, when working with changes from another branch. > > No, you don't need to. You can cherry-pick them by revision ID. Sure, but in practice, how many times did you do that without knowing the name of the branch? > > Once you did a "git fetch", the stuff is already in your clone, so > > what do you mean by "don't want to create a local branch"? > > I don't want to create a local branch tracking the remote branch because > I don't in general care about that remote branch. It may be one of tens > of branches that upstream have hanging around, that are irrelevant to > me. Once again, if we are talking about Git, doing "git fetch" already brings the branch down to your clone, doesn't it? A branch is just a pointer in Git, as you well know, so "creating a remote branch" is basically a no-op, once the objects are in your clone.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.
Received: (at 80037) by debbugs.gnu.org; 20 Dec 2025 15:23:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 10:23:11 2025
Received: from localhost ([127.0.0.1]:50852 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vWynW-0004oU-TH
for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 10:23:11 -0500
Received: from sendmail.purelymail.com ([34.202.193.197]:55126)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>)
id 1vWynU-0004o2-6c
for 80037 <at> debbugs.gnu.org; Sat, 20 Dec 2025 10:23:09 -0500
DKIM-Signature: a=rsa-sha256;
b=HWVYbB9FTnD9m3jfFfn5aPYlWiX9+4KK5nBBF+AYlOS74Bk2HWoBDgxAS50WEBCyPKFT+A3mjGAoLOKZJS8vDKOeXlyS1PZVWJziJvOE3atB3I/MH3JpQ+5WyphtYlPJlaN8EmXkOWDK5/kW3YCTNTjcMiOqz5bKXDKsjjPcbvBy4PFfGx7YMqH8OKmA7smHlXUiY7oAUQKkeBYCnnI1JcDDIMsJ4xkVXf6pec+VbWkX+Uee0f9EHe1Ysag0pBJHKBqckmLEQOBJhy8f33UeWlRpKNVAljdme//M6MVietzm9EYIRNaUT7CbPfJ5QRRWCfFQo0/HQcHSSueYocYA4w==;
s=purelymail2; d=spwhitton.name; v=1;
bh=ven61I+qSmcCAVX24+K1k3iR7QmT00V9LyaUEKPt6dw=;
h=Received:Received:From:To:Subject:Date;
DKIM-Signature: a=rsa-sha256;
b=YsvHjQncaCRbhT85H+kuiSDU83WKhOJTyl09/59FEjw5Qlht9oh/jixsx+xqqfXAjw8XpctflF+ga8c8wdhKlbN4B+m4Z3ipAb8brTY0AmfGz3uk+H/kvU6A6UiikBdNd8r/TJJCGwRDWYhgU75UNmm6+6axFvKfm3ynvAj/oDWBnQniV+gddbmAMlukvYje2IZwRwhdYLWu37cP6uBKcpPdGb9e6W5Dd43TPdA3t8T9VnDlMQTFZpBTC9TiL2LkqHZcI8T3GIb912zFRpJvHXcNUQCBe3dcCMdRq5XlX/ZTgFa3ulC6CU/0LzdFeaO8msSn+wo+zzzebJR3zcOOJQ==;
s=purelymail2; d=purelymail.com; v=1;
bh=ven61I+qSmcCAVX24+K1k3iR7QmT00V9LyaUEKPt6dw=;
h=Feedback-ID:Received:Received:From:To:Subject:Date;
Feedback-ID: 20115:3760:null:purelymail
X-Pm-Original-To: 80037 <at> debbugs.gnu.org
Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -156172121;
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
Sat, 20 Dec 2025 15:23:00 +0000 (UTC)
Received: by zephyr.silentflame.com (Postfix, from userid 1000)
id 11E329407A0; Sat, 20 Dec 2025 15:23:00 +0000 (GMT)
From: Sean Whitton <spwhitton@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x
v B' into 'C-x v b'
In-Reply-To: <867buhyzir.fsf@HIDDEN>
References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN>
<87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN>
<87y0mxgwie.fsf@HIDDEN> <867buhyzir.fsf@HIDDEN>
Date: Sat, 20 Dec 2025 15:23:00 +0000
Message-ID: <87wm2hfa97.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.1 (/)
X-Debbugs-Envelope-To: 80037
Cc: dmitry@HIDDEN, juri@HIDDEN, sbaugh@HIDDEN,
80037 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)
Hello,
On Sat 20 Dec 2025 at 04:54pm +02, Eli Zaretskii wrote:
> And those commits are not at or near HEAD of that branch?
Often they are not, because I'm trying to extract them to backport them
to an older release.
> How about making "C-x v b l" allow a prefix argument, which will let
> you specify a revision?
> [...]
> We could also modify "C-x v L" such that if the prefix is -1, it will
> ask for REVISION, but display the log _starting_ at that REVISION, not
> just of that REVISION. And the prefix argument of "C-x v b l" could
> behave the same. Or maybe we could have "C-x v b L" doing that.
>
> So there's more than one way of satisfying that need without breaking
> any previous behavior.
Thanks for reminding me that we could use a negative prefix argument to
have one of these special meanings.
I believe, though, that if we are going to retain a global binding for
the current behavior of vc-print-branch-log ('C-x v b L', in accordance
with the other thread), then there is no need to add anything else,
because vc-print-branch-log already satisfies the need of logging
branches or printing logs starting at arbitrary revisions.
> With my suggestions above, you'd need to know the branch, yes, but
> otherwise it's not fiddly IMO. And one needs to know the branch
> anyway, when working with changes from another branch.
No, you don't need to. You can cherry-pick them by revision ID.
>> That's much more fiddly, because Git doesn't
>> make working with remote branches easy (and I don't want to create a
>> local branch just for this read-only operation).
>
> Once you did a "git fetch", the stuff is already in your clone, so
> what do you mean by "don't want to create a local branch"?
I don't want to create a local branch tracking the remote branch because
I don't in general care about that remote branch. It may be one of tens
of branches that upstream have hanging around, that are irrelevant to
me.
I only create local branches where I intend to make and push new commits
on that branch. I think that's the usual way to use Git branches.
For example, I assume you don't have a local branch right now tracking
remotes/origin/scratch/tzz/auth-source-reveal-mode that we have on
Savannah (to pick a random example).
You only have a remote-tracking branch for that.
> We trust people not to mix "C-x v l" with "C-x v L", so why not trust
> them not tro confuse "o" with "O"?
Hmm, yes, good point. So that should be okay.
So if we don't see any counterarguments, I'll plan to move the existing
'C-x v B' commands under 'C-x v o'. Thanks again for the idea.
> A pointer should be enough, IMO.
Thanks, done that.
--
Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 20 Dec 2025 14:55:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 09:55:25 2025 Received: from localhost ([127.0.0.1]:50091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vWyMd-0003Dr-Mf for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 09:55:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53320) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vWyMa-0003Aq-NB for 80037 <at> debbugs.gnu.org; Sat, 20 Dec 2025 09:55:22 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vWyMM-0005bD-Gg; Sat, 20 Dec 2025 09:55:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bYvQ65NaYkdV864W3m0zWAmIoUDQEN76ZmpdV7u6EhQ=; b=q0q5Poi/D/18 4EGj7OdvQTsAkwckOdEksB9dkpqexMpnlcHj+F6gdLYO8ab7RbtQosKaHqiYLWe1rt324dvHhndUc sy0KhBMa17mIF3sCdhozrDhPCDfU+MCYfwU//WaQZNHTucAZ1dNpsgO4YO8uCJPgpmtSh6SNBTxbN 7OVXX6v/xVXb8BK2DS6Q9a2Ql/DFfvjzsc+6h6mdpIv5XJw3OPgS3Ow9JgV1j82AVCk9AUMdo3AKL cmIlHK+6YpFRSIBZENNFznQQeQq4jFFFhcs2zbehY5qicNYs+IgsyYNe8eTT8/pwQXsuZtE42d3jh B0WHa99SIeDnP0fLkW2mLw==; Date: Sat, 20 Dec 2025 16:54:36 +0200 Message-Id: <867buhyzir.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Sean Whitton <spwhitton@HIDDEN> In-Reply-To: <87y0mxgwie.fsf@HIDDEN> (message from Sean Whitton on Sat, 20 Dec 2025 12:36:57 +0000) Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> <87y0mxgwie.fsf@HIDDEN> X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 80037 Cc: dmitry@HIDDEN, 80037 <at> debbugs.gnu.org, sbaugh@HIDDEN, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) > From: Sean Whitton <spwhitton@HIDDEN> > Cc: dmitry@HIDDEN, juri@HIDDEN, sbaugh@HIDDEN, > 80037 <at> debbugs.gnu.org > Date: Sat, 20 Dec 2025 12:36:57 +0000 > > On Sat 20 Dec 2025 at 02:00pm +02, Eli Zaretskii wrote: > > > When/why do you need to see a log that starts from some non-HEAD > > revision? > > This happen for me with Git repositories where there are commits on some > remote branch but not on any of my local branches. Someone in an e-mail > or web forum discussion posts the commit IDs of a series of commits > fixing a bug on some branch somewhere. And those commits are not at or near HEAD of that branch? If so, this is quite a specialized situation, and I cannot imagine it to happen frequently. How about making "C-x v b l" allow a prefix argument, which will let you specify a revision? Then the command could work similar to "C-x v L". We could also modify "C-x v L" such that if the prefix is -1, it will ask for REVISION, but display the log _starting_ at that REVISION, not just of that REVISION. And the prefix argument of "C-x v b l" could behave the same. Or maybe we could have "C-x v b L" doing that. So there's more than one way of satisfying that need without breaking any previous behavior. > I do a git fetch, copy the > commit ID of the last revision in the series from the mail or web page, > and yank it to vc-git-branch-log's prompt. That will immediately show > me all the commits the person was talking about, with easy access to > view both the diffs and the log messages. The alternative is to figure > out the remote branch the commits are on, log that, and then find the > commits somewhere down it. With my suggestions above, you'd need to know the branch, yes, but otherwise it's not fiddly IMO. And one needs to know the branch anyway, when working with changes from another branch. > That's much more fiddly, because Git doesn't > make working with remote branches easy (and I don't want to create a > local branch just for this read-only operation). Once you did a "git fetch", the stuff is already in your clone, so what do you mean by "don't want to create a local branch"? > >> - Do the changes to 'C-x v b' discussed in the other thread. > > > > Please point to the thread, as I don't have a clear idea what changes > > do you allude to here. > > Yes, I should have linked to it again: > <https://lists.gnu.org/archive/html/emacs-devel/2025-12/msg00394.html> If you mean moving "C-x v b l" to "C-x v b L", then I think it's okay. > >> - Bind all the new outstanding change commands under 'C-x v B'. > > > > Why not "C-x v o"? > > The "B" was meant to be mnemonic for "base" because the outstanding > changes are determined by comparison with a base commit which is often a > merge base. > > Using "o" for "outstanding" instead is worth considering. > > My first thought would be that the notions of outstanding and outgoing > changes are similar but not the same, and so someone might easily mix up > 'C-x v o' and 'C-x v O'. > > But maybe most people will use only one of these two sets of commands > most of the time, so it would be okay? WDYT? We trust people not to mix "C-x v l" with "C-x v L", so why not trust them not tro confuse "o" with "O"? > > I'd prefer to have all of this discussion on emacs-devel, as I expect > > us to have some difficulty to distinguish between parts of this that > > are simple enough to be kept on the bug tracker. People who read and > > participate in the emacs-devel discussion should have the full picture > > at their disposal. > > Okay. How do you think it would be best to move the discussion? > I could post a summary, or just a pointer back to this bug. A pointer should be enough, IMO. Thanks.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 20 Dec 2025 12:37:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 07:37:15 2025 Received: from localhost ([127.0.0.1]:48501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vWwCw-0002Ay-Ci for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 07:37:14 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:37344) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vWwCt-0002Ac-Pq for 80037 <at> debbugs.gnu.org; Sat, 20 Dec 2025 07:37:13 -0500 DKIM-Signature: a=rsa-sha256; b=LktIHUVYLo/kwiW8SHlCTYf5URfe1yOs3mXOnpRVsFmzLTWj/jky8C+trlh7QCIJe/Y5wUyroXvyVQddOlcWAkei45RUP071nENDeWyW/jVHqQyhyCwf80q46jQngT3bx/VoIqt1PamRf/DgXapXHb3VUR5RKNCAAJRWCiu3A3tzB4G5XXOcZxM4HHxl/BK83KuRoy/K4SMsIoZyod+w73BE0fTQefwasWvirJBl1GVpw84gVLr9rp4ZAOPZj2+CjvKq8tMb6ZsdSB5Mv5Kdqaby/D4v9OZV7bWoEaXJ1iWJsP5FxvL75sLQEBRnKYdXZ/uMNfnP98nPfvIjDbcoRw==; s=purelymail2; d=spwhitton.name; v=1; bh=PXoj0CU6xXiMGUmPd0cwu/8csHQ0unhK+mgcRZjKMwI=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=R9ZkOWeP/qIRJtKOelxAlYVj7Qx3NpmD02owNFflmrlZWFh+6A8TEa2ddnKUv3rLOhMnE1Y8fZoc62Ui8EOU8TQ5NnCm05mIMRUUPFsql85fOzzw3zcaedqVqPToOTgV7HTACR8adAXkeRLhREE6KDNYWwxKW+nkDOB2y6vfWx8JXchxC6zWVsKBAzwfGchdkIR0nmKILWSXuG9Ei8bcDptMVLRqoQqeqDwwmTOlGhWrE6mVCJr1v6Q8jonZ2GJXJ7MwwpUyDzzcmvJrhDUOPdZXeFTcze7M7Yhl+wRfpSc7kxFn5WvZ7LMw5TdsRoZBo09BOl6+t6kS6++5EpMQYw==; s=purelymail2; d=purelymail.com; v=1; bh=PXoj0CU6xXiMGUmPd0cwu/8csHQ0unhK+mgcRZjKMwI=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80037 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1462393653; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 20 Dec 2025 12:36:58 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 7BD139407A0; Sat, 20 Dec 2025 12:36:57 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' In-Reply-To: <86tsxlz7kt.fsf@HIDDEN> References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> <86tsxlz7kt.fsf@HIDDEN> Date: Sat, 20 Dec 2025 12:36:57 +0000 Message-ID: <87y0mxgwie.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 80037 Cc: dmitry@HIDDEN, 80037 <at> debbugs.gnu.org, sbaugh@HIDDEN, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) Hello, On Sat 20 Dec 2025 at 02:00pm +02, Eli Zaretskii wrote: >> and don't ever start a log from a particular revision. > > What is the purpose of doing such a strange thing? If I'm interested > in specific portions of VC history, I use "C-x v h" and sometimes > "C-x v g" (the latter usually when the backend can't follow renames or > significant/complex changes which break vc-region-history). > >> That is the opposite of my own experience -- I don't believe I have ever >> specified a LIMIT (instead I use the "Show 2x more" button) but I often >> use C-x v b l to start a log at a particular revision. > > When/why do you need to see a log that starts from some non-HEAD > revision? This happen for me with Git repositories where there are commits on some remote branch but not on any of my local branches. Someone in an e-mail or web forum discussion posts the commit IDs of a series of commits fixing a bug on some branch somewhere. I do a git fetch, copy the commit ID of the last revision in the series from the mail or web page, and yank it to vc-git-branch-log's prompt. That will immediately show me all the commits the person was talking about, with easy access to view both the diffs and the log messages. The alternative is to figure out the remote branch the commits are on, log that, and then find the commits somewhere down it. That's much more fiddly, because Git doesn't make working with remote branches easy (and I don't want to create a local branch just for this read-only operation). >> This is the most important point. The idea is that the outstanding >> changes on a feature branch can be thought of as "the feature branch >> diff" or "the feature branch log". So if you use those commands a lot, >> the 'b L' and 'b D' have "branch log" and "branch diff" as mnemonics. > > But outstanding changes happen on non-feature branches as well. It is > IMO confusing to treat feature branches differently in this regard. > Whether the current branch is a feature branch or anything else > (including master) is entirely in my head; VC commands apply to any > kind of branch, and the backend has no idea what will be the use of > the branch I'm on. E.g., I could be working on master implementing > some feature, and during that work treat master as a kind-of feature > branch, delaying updating from upstream until I'm done. Yes, that's right, and indeed over in #80006 one of the goals is to make sure the commands work well on non-feature branches too. >> - Do the changes to 'C-x v b' discussed in the other thread. > > Please point to the thread, as I don't have a clear idea what changes > do you allude to here. Yes, I should have linked to it again: <https://lists.gnu.org/archive/html/emacs-devel/2025-12/msg00394.html> >> - Add a feature to 'C-u C-x v l' where if the revision ID specified does >> not appear in the log (because it's on another branch), try to print a >> log of a branch containing that revision ID, or fall back to printing >> a log starting at that revision ID. > > This is problematic, IMO. A revision could be absent because the user > simply mistyped it. Also, if there are many branches in the > repository, looking for the right branch could be slow. Finally, and > most importantly, you assume that revision IDs are absolute, i.e. not > local to the branch. This is false for Bazaar at least, and might be > wrong in other cases as well. Hrm, all good points. I'll leave this aside until I can think of a better design for it, then. >> - Bind all the new outstanding change commands under 'C-x v B'. > > Why not "C-x v o"? The "B" was meant to be mnemonic for "base" because the outstanding changes are determined by comparison with a base commit which is often a merge base. Using "o" for "outstanding" instead is worth considering. My first thought would be that the notions of outstanding and outgoing changes are similar but not the same, and so someone might easily mix up 'C-x v o' and 'C-x v O'. But maybe most people will use only one of these two sets of commands most of the time, so it would be okay? WDYT? > I'd prefer to have all of this discussion on emacs-devel, as I expect > us to have some difficulty to distinguish between parts of this that > are simple enough to be kept on the bug tracker. People who read and > participate in the emacs-devel discussion should have the full picture > at their disposal. Okay. How do you think it would be best to move the discussion? I could post a summary, or just a pointer back to this bug. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 20 Dec 2025 12:00:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 07:00:49 2025 Received: from localhost ([127.0.0.1]:48079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vWvdg-0005N4-RX for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 07:00:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48304) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vWvdc-0005Mg-Ix for 80037 <at> debbugs.gnu.org; Sat, 20 Dec 2025 07:00:47 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vWvdV-00088Z-4t; Sat, 20 Dec 2025 07:00:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zQQvcs/iafKWsVa4eMDOMIkage0iGCG3CPyo+KhXjVU=; b=cD36YJsByjxH TaP9MNp3cHX9sUucPduRXth+AVaLqiSN7VyDNEY0mlMik71Jqj3TYkddA+Ukz0b/J35ikYNdQjlNe MwJfFTr2ineG2yELe3HVdNgKj0Yz3hhYuxGr2G8nPZmQ8yt7UusVZxJTTiEq0N5/ak4BbMWpU9BQF jo9pIMTNt9952p+CaIqnAsPiB/2zw7oog8oPdg+RVco4qJtcr1Ts9N0cI5FR42mHVjM3RUyM3TwXq J9Tn16/JuTdiy2iznnm/9BcUeu2R2j83U/QY0Br5Q4upG0LXnbJGDyA0y3IUYhXBT/6tkDtKBefNN gc2YpAGEJ+j0RYbgcSA/eg==; Date: Sat, 20 Dec 2025 14:00:34 +0200 Message-Id: <86tsxlz7kt.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Sean Whitton <spwhitton@HIDDEN> In-Reply-To: <87ldixidwv.fsf@HIDDEN> (message from Sean Whitton on Sat, 20 Dec 2025 11:35:44 +0000) Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> <87ldixidwv.fsf@HIDDEN> X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 80037 Cc: dmitry@HIDDEN, juri@HIDDEN, sbaugh@HIDDEN, 80037 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) > From: Sean Whitton <spwhitton@HIDDEN> > Cc: dmitry@HIDDEN, 80037 <at> debbugs.gnu.org, juri@HIDDEN, > sbaugh@HIDDEN > Date: Sat, 20 Dec 2025 11:35:44 +0000 > > In particular, it is very interesting to hear that you regularly specify > the LIMIT No, I said that I _sometimes_ use LIMIT. However, in most cases, I'm only interested in the latest part of the log, starting from HEAD, so some default value of LIMIT that is not too large should be okay for my uses. > and don't ever start a log from a particular revision. What is the purpose of doing such a strange thing? If I'm interested in specific portions of VC history, I use "C-x v h" and sometimes "C-x v g" (the latter usually when the backend can't follow renames or significant/complex changes which break vc-region-history). > That is the opposite of my own experience -- I don't believe I have ever > specified a LIMIT (instead I use the "Show 2x more" button) but I often > use C-x v b l to start a log at a particular revision. When/why do you need to see a log that starts from some non-HEAD revision? > > "C-x v b" was previously a prefix for commands that took a branch as > > an argument and/or prompted for a branch. This was easy to remember > > and was mnemonically a good UI. The above bindings break this > > mnemonics, and I don't think I see why it was deemed a good idea to > > use "C-x v b" for them -- what is the "b" part about? > > This is the most important point. The idea is that the outstanding > changes on a feature branch can be thought of as "the feature branch > diff" or "the feature branch log". So if you use those commands a lot, > the 'b L' and 'b D' have "branch log" and "branch diff" as mnemonics. But outstanding changes happen on non-feature branches as well. It is IMO confusing to treat feature branches differently in this regard. Whether the current branch is a feature branch or anything else (including master) is entirely in my head; VC commands apply to any kind of branch, and the backend has no idea what will be the use of the branch I'm on. E.g., I could be working on master implementing some feature, and during that work treat master as a kind-of feature branch, delaying updating from upstream until I'm done. > But if you mostly use the commands under 'C-x v b' which take a branch > as an argument, then we have clashing mnemonics, indeed. > > As the idea of 'C-x v b' for commands which take a branch as an argument > is fundamentally simpler, and is already in place, probably it should > take precedence. > > So here is an alternative set of changes, incorporating various > suggestions you made: > > - Do the changes to 'C-x v b' discussed in the other thread. Please point to the thread, as I don't have a clear idea what changes do you allude to here. > - Add a feature to 'C-u C-x v l' where if the revision ID specified does > not appear in the log (because it's on another branch), try to print a > log of a branch containing that revision ID, or fall back to printing > a log starting at that revision ID. This is problematic, IMO. A revision could be absent because the user simply mistyped it. Also, if there are many branches in the repository, looking for the right branch could be slow. Finally, and most importantly, you assume that revision IDs are absolute, i.e. not local to the branch. This is false for Bazaar at least, and might be wrong in other cases as well. > - Define new commands to replace 'C-x v l' and 'C-x v L' which have a > prefix argument to prompt for a revision to start the log at, *and* a > limit. Don't bind these anywhere, but suggest binding them to > 'C-x v l' and 'C-x v L' in NEWS, for those users who don't find the > existing prefix arguments to 'C-x v l' and 'C-x v L' useful. > (Discard the 'C-u 999 C-u' idea.) This is okay, and we could also find some suitable bindings for these commands if that makes sense. > - Bind all the new outstanding change commands under 'C-x v B'. Why not "C-x v o"? > > P.S. Such a significant change should have been discussed on > > emacs-devel, not in a bug report. > > Ah, good point. I think the smaller set of changes I've proposed in > this message probably doesn't need to go to -devel but let me know if > you disagree. I'd prefer to have all of this discussion on emacs-devel, as I expect us to have some difficulty to distinguish between parts of this that are simple enough to be kept on the bug tracker. People who read and participate in the emacs-devel discussion should have the full picture at their disposal.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 20 Dec 2025 11:35:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 06:35:58 2025 Received: from localhost ([127.0.0.1]:47858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vWvFd-0003lI-Rf for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 06:35:58 -0500 Received: from sendmail.purelymail.com ([34.202.193.197]:43248) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1vWvFZ-0003l1-3J for 80037 <at> debbugs.gnu.org; Sat, 20 Dec 2025 06:35:56 -0500 DKIM-Signature: a=rsa-sha256; b=biG9fzuoTsIky2ZknfAUDKBh3UVfKl25UVRBCSEWukSmD/gpsFOv3diqGUhvUku/H5vEVEYnzYKvd+YvqOzrpda21f/h/97V3THGELrlQ+2uZm0zbDRIp3+085FGNw9aKXniUnlqA02bzllCGbIwqI1ArqNtIKoRYi9pxsSii134X2SVoFhHgSFovHlfWEXujJ1Wc/aeQ3byTyHLHE68clI9z0t16z86KHfhUg4JoopMTPDSHUehiLfU2WytncZ9zvw6T+guYw1sIWiKnGCT+czFdEX8VgCEf7JfmOLAb4kSLjWBMJjLd04sS1EWULPpdZSzmGKdbkPnjXC7+nA/jQ==; s=purelymail2; d=spwhitton.name; v=1; bh=swIDnXS24CbhkjkdqmbL/i2YOKtiwjDdqBbo4stOvrA=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=SJvpd+yTOnouw0uDIagAhh41FRVmL8GVXO9rdRuduroit3pmwdkDH1V7THPrT7sqEgFLGm49Fg/Bz+fmNGRtN7isekHwbcYxZ6WTjbcgA1XTvbxYx9Ag6VsFVLHrdOmucsQ3BLfQPRVrbVbUW5bE19pcBubHyi+misQegYz4EZglz9aIsO8IDFvFxEDtXL4AlkW7pExKV4jCJ3oKVWtGabNV+FbKB/s44tvdgW5JG32w4DHFKb0JTMwrj7rWKSbzVHWY9/yTqbZzN6a76wdo8bs7uQ2Y2Gz6nuT8VF10pCBpFmzUnaFA0taoFBX1m2Ebub/Tt3nSV9tg/l79gakaOg==; s=purelymail2; d=purelymail.com; v=1; bh=swIDnXS24CbhkjkdqmbL/i2YOKtiwjDdqBbo4stOvrA=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 80037 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 1821410135; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 20 Dec 2025 11:35:46 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 3BDDD9407A0; Sat, 20 Dec 2025 11:35:44 +0000 (GMT) From: Sean Whitton <spwhitton@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' In-Reply-To: <867buh1qwp.fsf@HIDDEN> References: <87zf7ejuri.fsf@HIDDEN> <867buh1qwp.fsf@HIDDEN> Date: Sat, 20 Dec 2025 11:35:44 +0000 Message-ID: <87ldixidwv.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 80037 Cc: dmitry@HIDDEN, juri@HIDDEN, sbaugh@HIDDEN, 80037 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) Hello Eli, Thank you for reviewing. What I presented was the most thoroughgoing possible set of breaking changes in this area, and I would be happy if we can find a subset of them that will appear to be improvements from the perspectives of all (or almost all) users. In particular, it is very interesting to hear that you regularly specify the LIMIT and don't ever start a log from a particular revision. That is the opposite of my own experience -- I don't believe I have ever specified a LIMIT (instead I use the "Show 2x more" button) but I often use C-x v b l to start a log at a particular revision. I don't doubt that your usage matches plenty of other people's, so this is important input. I want to do right by both these sets of users. > "C-x v b" was previously a prefix for commands that took a branch as > an argument and/or prompted for a branch. This was easy to remember > and was mnemonically a good UI. The above bindings break this > mnemonics, and I don't think I see why it was deemed a good idea to > use "C-x v b" for them -- what is the "b" part about? This is the most important point. The idea is that the outstanding changes on a feature branch can be thought of as "the feature branch diff" or "the feature branch log". So if you use those commands a lot, the 'b L' and 'b D' have "branch log" and "branch diff" as mnemonics. But if you mostly use the commands under 'C-x v b' which take a branch as an argument, then we have clashing mnemonics, indeed. As the idea of 'C-x v b' for commands which take a branch as an argument is fundamentally simpler, and is already in place, probably it should take precedence. So here is an alternative set of changes, incorporating various suggestions you made: - Do the changes to 'C-x v b' discussed in the other thread. - Add a feature to 'C-u C-x v l' where if the revision ID specified does not appear in the log (because it's on another branch), try to print a log of a branch containing that revision ID, or fall back to printing a log starting at that revision ID. The UI is slightly tricky because populating the log buffer is async. Therefore we can't do a y/n prompt only after discovering that the specified revision ID does not appear in the log, because the user might be typing in another buffer. (Making the log printing non-async for the sake of this feature would be too much of a UI snappiness regression.) So we could have it on by default with an option to disable. I.e., Emacs would automatically replace the contents of *vc-change-log* with another branch's log or a log starting at the revision ID the user specified if, after the original log of the current branch has finished printing, that revision does not appear in it. If someone really doesn't want this they can toggle a defcustom to get back the behaviour of only printing a log once. - Define new commands to replace 'C-x v l' and 'C-x v L' which have a prefix argument to prompt for a revision to start the log at, *and* a limit. Don't bind these anywhere, but suggest binding them to 'C-x v l' and 'C-x v L' in NEWS, for those users who don't find the existing prefix arguments to 'C-x v l' and 'C-x v L' useful. (Discard the 'C-u 999 C-u' idea.) - Bind all the new outstanding change commands under 'C-x v B'. > Why couldn't this have been done without breaking existing UIs? The > outstanding-changes commands are new, so we could do anything we like > for them, including find good bindings. I don't understand why these > new commands required breaking changes, and you have never explained > that. If there were some alternatives that were considered and > rejected, how about showing those alternatives and explaining why you > rejected them? To be clear, the breaking changes definitely aren't necessary, as we can just put the new commands under 'C-x v B'. My idea was not to outright reject that option, but just the thought that there may be more mnemonic options, and it might combine well with improving the old prefix arguments. > P.S. Such a significant change should have been discussed on > emacs-devel, not in a bug report. Ah, good point. I think the smaller set of changes I've proposed in this message probably doesn't need to go to -devel but let me know if you disagree. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 20 Dec 2025 08:47:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 03:47:15 2025 Received: from localhost ([127.0.0.1]:46362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vWscM-0000s0-FF for submit <at> debbugs.gnu.org; Sat, 20 Dec 2025 03:47:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34230) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vWscJ-0000rg-95 for 80037 <at> debbugs.gnu.org; Sat, 20 Dec 2025 03:47:12 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vWscC-00034q-B3; Sat, 20 Dec 2025 03:47:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mLGBXlVCqGnDKEfwDJyhcMPKHWruDgUKILKnT8PMkd0=; b=cCCHzxvH3F3G 5vxRBMfs0Aq0aIGQbh/5COqH2F2GdhArSJfVh1pWLurINJrCwHJGvmQcbBjfcStBWGIpenZINGiUb 3MU1S0ZQEZ3TD6PzNo5K6+lsl4OT9pTvZXmJheP+O5Pk8IH+6EraYLOVtP6oCs2H3dfRHEcmmjpAd yZ7vY8X5yx/IMvaXlJ4ndRsE2eJeZSeR8vFY4AgrZLSto0AIDQq4Dy+KXYsQHmcZSU3EhyOYvgTyv FUxhuJHE04qFVseKRPab8kQjbyWF5bG3Djc6mIM+wYoP1F1AztImSRvhhRfiOHmETrTnlX+/3Mcj4 IKBDL0U/NBjhYXJHBoLzKQ==; Date: Sat, 20 Dec 2025 10:47:02 +0200 Message-Id: <867buh1qwp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Sean Whitton <spwhitton@HIDDEN> In-Reply-To: <87zf7ejuri.fsf@HIDDEN> (message from Sean Whitton on Fri, 19 Dec 2025 16:34:09 +0000) Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' References: <87zf7ejuri.fsf@HIDDEN> X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 80037 Cc: dmitry@HIDDEN, 80037 <at> debbugs.gnu.org, juri@HIDDEN, sbaugh@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) > Cc: sbaugh@HIDDEN, dmitry@HIDDEN, juri@HIDDEN > From: Sean Whitton <spwhitton@HIDDEN> > Date: Fri, 19 Dec 2025 16:34:09 +0000 > > *** 'C-u C-x v l' now prompts for a revision or branch to log. > Previously, 'C-u C-x v l' prompted for a revision ID that was used only > to position point in the log buffer, and also a number specifying the > maximum number of revisions to show. > > The old prefix argument was not very useful because it would only work > if the revision ID specified was on the current branch. Now, so long as > the revision ID is present in the repository, 'C-u C-x v l' will print a > log containing that revision ID. Why cannot this change be combined with the ability to specify the maximum number of revisions to show? That would make this proposed breaking change to be almost 100% compatible with previous behavior. > You can still specify the maximum number of revisions to show using a > numeric prefix argument, e.g. 'C-u 999 C-x v l'. What will this mean/do in VCS where revisions are specified by numbers? > You can specify a > numeric limit and also be prompted for a revision ID with an additional > 'C-u' after your numeric prefix, like this: 'C-u 999 C-u C-x v l'. This is IMO extremely complicated and clumsy. It is also without precedent in Emacs, AFAIK. > You > can position point in the log by doing a plain 'C-x v l' and then using > 'C-s' to search forward for the revision ID. Yes, but then you are basically saying that the previous capability of specifying a revision was not needed and can be removed. I cannot agree, given how old this feature is. > *** 'C-u C-x v L' now prompts for a revision or branch to log. > Previously, 'C-u C-x v L' prompted for a number specifying the maximum > number of revisions to show. Now it prompts for a revision or branch > from which to start the log. Another breaking change. And why is it so important to start the global log from a specific revision, let alone specify a branch, with modern VCSes? IME, specifying how many revisions to show is much more frequently needed. > Emacs has some new commands to display summaries of outstanding changes > on the current branch: > > - 'C-x v b l': Show a log of outstanding changes to the current fileset. > - 'C-x v b L': Show a log of all outstanding changes. > - 'C-x v b =': Show a diff of outstanding changes to the current fileset. > - 'C-x v b D': Show a diff of all outstanding changes. > - 'C-x v b +': Pull from this branch's outgoing base. "C-x v b" was previously a prefix for commands that took a branch as an argument and/or prompted for a branch. This was easy to remember and was mnemonically a good UI. The above bindings break this mnemonics, and I don't think I see why it was deemed a good idea to use "C-x v b" for them -- what is the "b" part about? So, another breaking change in the UI, which from where I stand is a Bad Thing. > Here are why this seems like an acceptable breaking change: Sorry, I'm not convinced, see below. > - It's easy for users to switch back to the old commands, and any Lisp > calling the commands programmatically is entirely unaffected. This can be said about almost every breaking change we make: we always strive to provide a way to revert to old behavior. But that doesn't change the fact that a change is breaking, and that we should avoid doing that if possible. > - The change to 'C-u C-x v l' wrt revision IDs is a usability > improvement to existing functionality, not truly new functionality. > It still prompts for a revision ID, and still leaves point positioned > on the log entry for that revision. And indeed it will do so > successfully more often. This could be done in backward-compatible fashion, I think, see above. > - Regarding the LIMIT changes to 'C-x v l' and 'C-x v L', prompting for > the numeric limit is strange for an Emacs command. Normally such > limits have to be specified with a numeric prefix argument. So it's > only a small step to say that this now has to be done here too. > (And the existing commands already accept a LIMIT supplied this way.) There's nothing wrong with a command that asks for a numeric input if the prefix arg is already taken. And the proposed "C-u NNN C-u" prefix is actually more outlandish, at least IME. > - In the thread on the previous proposal,[1] we thought that it is okay > to move 'C-x v b l' somewhere else because it was the wrong key > sequence to begin with (because it is a root log, the last key should > be uppercase), and the binding has only been around for a couple of > releases. This could have been done without all the other breakage, couldn't it? > - For all logging commands, a C-u prefix argument will now consistently > mean "log something other than the current branch". This covers > C-x v l, C-x v L, C-x v O l, C-x v O L, C-x v I l, C-x v I L, and all > the new outstanding changes commands. That's much easier to remember > than the strange prefix arguments to C-x v l and C-x v L. I think this is a wrong aspect of a command to look for consistency. What the prefix argument means is inherently specific to the command (with the sole exception of when the prefix specifies the repetition count). In particular, I see no reason to make the "l" and "L" commands interpret the argument in the same way, since these are fundamentally different commands with today's VCSes. So this justification doesn't convince me; on the contrary, it sounds like you tried to achieve consistency in the wrong place. > - The old vc-print-branch-log was actually "print a log starting at this > branch *or* this revision ID". For modern VCS you often want to print > logs starting at arbitrary revision IDs. So moving that functionality > away from a command and sub-keymap that only referred to "branches" is > more mnemonic. This looks like someone's personal preferences forced upon all Emacs users. I almost _never_ need to print a log starting from some arbitrary revision ID. I do sometimes need to print a log of a non-current branch, and I definitely almost always want to show the log of the current branch from its HEAD. So, for me at least, the above is a change for the worse, because it goes against my workflows. I dare to assume that there are other Emacs users like me. In addition, this convention was there for ages. So it seems like we are breaking a very useful and veteran UI principle in favor of someone's personal preferences. Our way of handling different preferences is by either providing user options or by providing alternative commands. Why couldn't this have been done here, instead of so many breaking changes? > - The new outstanding changes commands gain more mnemonic bindings. The > thought is, if you're on a shorter-lived branch that will later be > merged into a trunk (very common with modern forge workflows, and also > the feature/foo branches we use in emacs.git) then it makes sense to > ask for "the branch diff" which is just, what effects on the trunk > will merging this branch into it have? And that's precisely C-x v b = > and C-x v b D on this new scheme. Why couldn't this have been done without breaking existing UIs? The outstanding-changes commands are new, so we could do anything we like for them, including find good bindings. I don't understand why these new commands required breaking changes, and you have never explained that. If there were some alternatives that were considered and rejected, how about showing those alternatives and explaining why you rejected them? > - One point in the other direction is that currently commands under > 'C-x v b' always operate on a branch other than the current branch, > but that wouldn't be the case with the new outstanding changes > commands. I think this is okay. I don't, sorry. I find no justification for breaking the "branch" mnemonics of "C-x v b" prefix. In sum, I urge you to try to find a better solution that doesn't break so many long-time UI assumptions and conventions. P.S. Such a significant change should have been discussed on emacs-devel, not in a bug report.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.Received: (at 80037) by debbugs.gnu.org; 19 Dec 2025 16:46:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 19 11:46:12 2025 Received: from localhost ([127.0.0.1]:40519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vWdcK-0003TL-4A for submit <at> debbugs.gnu.org; Fri, 19 Dec 2025 11:46:12 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:44251) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vWdcG-0003Ss-7r for 80037 <at> debbugs.gnu.org; Fri, 19 Dec 2025 11:46:10 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: Sean Whitton <spwhitton@HIDDEN> Subject: Re: bug#80037: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x v b' In-Reply-To: <87zf7ejuri.fsf@HIDDEN> (Sean Whitton's message of "Fri, 19 Dec 2025 16:34:09 +0000") References: <87zf7ejuri.fsf@HIDDEN> Date: Fri, 19 Dec 2025 11:46:00 -0500 Message-ID: <ierpl8axvw7.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1766162761; bh=f0G361jOEVbNy+sAI0Dqnc2p0IEWGZShXfVbNT2dZb4=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=3ik8+dVM2Ys/E+sifMwAXDeufKPaWXIdAGvn2q5+S8xuj8UytWSGnn+cPXwstclIU th6HFngi3gjt78VDArvxFlK8509Lx4GotpNafP7/bB6oR+tUdZQGyJ9lJjz1/qCxR0 cse8+ctgPIossRSFcAfqFJxypgLBKR59C5OEwnlP1Qa1sr7psu7MK1CpMpot+rVz5S 0qUkK6k1ym+vIAI3p/Sodw1FtLdtZsmxPEFpa33OaqC6sB7s8/tp9bLNl8DcE02hTA oP3KwY0dNN5lloXORJ2BoznWYu9xjIxSHqnlcbA1m/cX9PXbKdzyjlxuTICjpYuhSw yKxdnEQqNsp6w== X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80037 Cc: 80037 <at> debbugs.gnu.org, juri@HIDDEN, dmitry@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) I agree with all this, it seems like it would be a great improvement. One more point in favor of C-u C-x v l/L prompting for a revision: that would be more consistent with the behavior of C-u C-x v =/D, which also prompt for a revision.
bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 19 Dec 2025 16:34:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 19 11:34:25 2025
Received: from localhost ([127.0.0.1]:40440 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vWdQu-0002mi-By
for submit <at> debbugs.gnu.org; Fri, 19 Dec 2025 11:34:25 -0500
Received: from lists.gnu.org ([2001:470:142::17]:41026)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>)
id 1vWdQr-0002mP-S1
for submit <at> debbugs.gnu.org; Fri, 19 Dec 2025 11:34:22 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <spwhitton@HIDDEN>)
id 1vWdQl-00030R-M2
for bug-gnu-emacs@HIDDEN; Fri, 19 Dec 2025 11:34:16 -0500
Received: from sendmail.purelymail.com ([34.202.193.197])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <spwhitton@HIDDEN>)
id 1vWdQj-0008KK-G2
for bug-gnu-emacs@HIDDEN; Fri, 19 Dec 2025 11:34:15 -0500
DKIM-Signature: a=rsa-sha256;
b=dkOoRD761zOg/XfjmHD+NHBdCsexJ25QrZOuN9ZALXfwV6JEitSDXn142AJE0CsGYgswIrLZdEkiz4t60WNOy5ejhySTdv9K0zRrZIGwdhpTsIUsL0rhSipd++1xFM63gPrkoakKZP31ygkmZNky/f1eQ8+mReccKxrebeKPqNTSqCA4jKACVomdAaq6bvueRAUjKE1mQczPX6Sw9HhLOTnrArpLSwTfDHfSNFxkHJEa2TWUZr7OEp6kDni4sN0rnXjuQBRCenTpBumggungy9Jo4SPv54jasqSRDYMt337PxluGgHXNlnveoHoBWudiRL07d1hIneyIaeRPvlPN8A==;
s=purelymail2; d=spwhitton.name; v=1;
bh=yOmo9hsWb/5FWFS4VPpU+SsswYbGaHyebfHv2Gv39tE=;
h=Received:Received:From:To:Subject:Date;
DKIM-Signature: a=rsa-sha256;
b=k8kS0CoP71SNpAyz4sBsJ3fKVPz0ErFlYBL54XwJ87C9G6w4StokAwhiJ1L7qqZyHHZWDXlOJl8MROg71mmbbXHRfsy4si6FMb45aVX7uayAu8QBkfYHy0Tcu5pyfiWj8c4vfe+WO7y/U1XU4p9jSqTloViMqq0v48UrI83+QpPDtq9GDgVk+x+s+QvCwlRyDW+Vi9DLjZEazA0c9b2rF7DsGD8/7fKQpe2tryy4ChVIxiTcau2tzaLHRN6YnY1jYLDccLZF45rU2iI2DKCiLA5az+1IvADdwJjVlOC44JQ6Twr/R7+Ef1daQ6RrXhFzc0UyHxTO/L9ZJ7fSdT+F7w==;
s=purelymail2; d=purelymail.com; v=1;
bh=yOmo9hsWb/5FWFS4VPpU+SsswYbGaHyebfHv2Gv39tE=;
h=Feedback-ID:Received:Received:From:To:Subject:Date;
Feedback-ID: 20115:3760:null:purelymail
X-Pm-Original-To: bug-gnu-emacs@HIDDEN
Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1153004191
for <bug-gnu-emacs@HIDDEN>
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
Fri, 19 Dec 2025 16:34:09 +0000 (UTC)
Received: by zephyr.silentflame.com (Postfix, from userid 1000)
id 0FDDB940373; Fri, 19 Dec 2025 16:34:09 +0000 (GMT)
From: Sean Whitton <spwhitton@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; Improving 'C-u C-x v l/L' and merging 'C-x v B' into 'C-x
v b'
Date: Fri, 19 Dec 2025 16:34:09 +0000
Message-ID: <87zf7ejuri.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=34.202.193.197;
envelope-from=spwhitton@HIDDEN; helo=sendmail.purelymail.com
X-Spam_score_int: -19
X-Spam_score: -2.0
X-Spam_bar: --
X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GAPPY_SUBJECT=0.1,
RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: X-debbugs-cc: sbaugh@HIDDEN, dmitry@HIDDEN,
juri@HIDDEN
Spencer suggested to me off-list that the new 'C-x v B' keymap could be merged
into 'C-x v b',
and we have been hashing out a proposal. This is a more involved
alternative to the proposal I made on em [...]
Content analysis details: (1.1 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.1 GAPPY_SUBJECT Subject: contains G.a.p.p.y-T.e.x.t
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.1 (/)
X-debbugs-cc: sbaugh@HIDDEN, dmitry@HIDDEN, juri@HIDDEN
Spencer suggested to me off-list that the new 'C-x v B' keymap could be
merged into 'C-x v b', and we have been hashing out a proposal. This is
a more involved alternative to the proposal I made on emacs-devel a few
days ago.[1]
The new 'C-x v B' keymap contains commands to show the outstanding work
on a branch. On a trunk branch, such as 'master', that means work you
haven't yet committed plus work you haven't yet pushed. On a feature
branch, such as 'feature/igc', that means all work that hasn't yet been
merged into the relevant trunk branch (in this case, again, 'master').
See bug#80006 regarding the implementation of these new commands.
In this bug I want to focus on the user interface at the highest level,
in order to make an assessment of the breaking change proposal.
Let's set aside, initially, the renaming and obsoleting of functions.
Here is what the NEWS entries for this change would be. I'll follow
them up with some further justification for why I think this is an
acceptable breaking change.
--8<---------------cut here---------------start------------->8---
*** 'C-u C-x v l' now prompts for a revision or branch to log.
Previously, 'C-u C-x v l' prompted for a revision ID that was used only
to position point in the log buffer, and also a number specifying the
maximum number of revisions to show.
The old prefix argument was not very useful because it would only work
if the revision ID specified was on the current branch. Now, so long as
the revision ID is present in the repository, 'C-u C-x v l' will print a
log containing that revision ID.
You can still specify the maximum number of revisions to show using a
numeric prefix argument, e.g. 'C-u 999 C-x v l'. You can specify a
numeric limit and also be prompted for a revision ID with an additional
'C-u' after your numeric prefix, like this: 'C-u 999 C-u C-x v l'. You
can position point in the log by doing a plain 'C-x v l' and then using
'C-s' to search forward for the revision ID.
We have implemented this change by changing the default binding of
'C-x v l' to a new command. Therefore, if you prefer, you can undo this
change like this:
(keymap-global-set "C-x v l" #'vc-print-log)
*** 'C-u C-x v L' now prompts for a revision or branch to log.
Previously, 'C-u C-x v L' prompted for a number specifying the maximum
number of revisions to show. Now it prompts for a revision or branch
from which to start the log.
You can still specify a limit with a numeric prefix argument, e.g.
'C-u 999 C-x v L'. You can specify a numeric limit and also be prompted
for a revision ID to log with an additional 'C-u' after your numeric
prefix, like this: 'C-u 999 C-u C-x v L'.
We have implemented this change by changing the default binding of
'C-x v L' to a new command. Therefore, if you prefer, you can undo this
change like this:
(keymap-global-set "C-x v l" #'vc-print-root-log)
*** 'C-x v b l' is no longer bound to 'vc-print-branch-log'.
The new 'C-u C-x v L', described in the previous entry, is equivalent to
'vc-print-branch-log', and therefore the 'C-x v b l' key sequence has
been freed up for another use (described below).
If you prefer, you can undo this change like this:
(keymap-global-set "C-x v b l" #'vc-print-branch-log)
*** New commands to show information about outstanding changes.
Outstanding changes on a branch are ...
Emacs has some new commands to display summaries of outstanding changes
on the current branch:
- 'C-x v b l': Show a log of outstanding changes to the current fileset.
- 'C-x v b L': Show a log of all outstanding changes.
- 'C-x v b =': Show a diff of outstanding changes to the current fileset.
- 'C-x v b D': Show a diff of all outstanding changes.
- 'C-x v b +': Pull from this branch's outgoing base.
The outgoing base means ...
What counts as outstanding changes is controlled by ...
--8<---------------cut here---------------end--------------->8---
Here are why this seems like an acceptable breaking change:
- It's easy for users to switch back to the old commands, and any Lisp
calling the commands programmatically is entirely unaffected.
- The change to 'C-u C-x v l' wrt revision IDs is a usability
improvement to existing functionality, not truly new functionality.
It still prompts for a revision ID, and still leaves point positioned
on the log entry for that revision. And indeed it will do so
successfully more often.
- Regarding the LIMIT changes to 'C-x v l' and 'C-x v L', prompting for
the numeric limit is strange for an Emacs command. Normally such
limits have to be specified with a numeric prefix argument. So it's
only a small step to say that this now has to be done here too.
(And the existing commands already accept a LIMIT supplied this way.)
- In the thread on the previous proposal,[1] we thought that it is okay
to move 'C-x v b l' somewhere else because it was the wrong key
sequence to begin with (because it is a root log, the last key should
be uppercase), and the binding has only been around for a couple of
releases.
- For all logging commands, a C-u prefix argument will now consistently
mean "log something other than the current branch". This covers
C-x v l, C-x v L, C-x v O l, C-x v O L, C-x v I l, C-x v I L, and all
the new outstanding changes commands. That's much easier to remember
than the strange prefix arguments to C-x v l and C-x v L.
- The old vc-print-branch-log was actually "print a log starting at this
branch *or* this revision ID". For modern VCS you often want to print
logs starting at arbitrary revision IDs. So moving that functionality
away from a command and sub-keymap that only referred to "branches" is
more mnemonic.
- We are able to get rid of a whole sub-keymap, 'C-x v B'.
- The new outstanding changes commands gain more mnemonic bindings. The
thought is, if you're on a shorter-lived branch that will later be
merged into a trunk (very common with modern forge workflows, and also
the feature/foo branches we use in emacs.git) then it makes sense to
ask for "the branch diff" which is just, what effects on the trunk
will merging this branch into it have? And that's precisely C-x v b =
and C-x v b D on this new scheme.
- One point in the other direction is that currently commands under
'C-x v b' always operate on a branch other than the current branch,
but that wouldn't be the case with the new outstanding changes
commands. I think this is okay.
[1] https://lists.gnu.org/archive/html/emacs-devel/2025-12/msg00394.html
--
Sean Whitton
Sean Whitton <spwhitton@HIDDEN>:sbaugh@HIDDEN, dmitry@HIDDEN, juri@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.sbaugh@HIDDEN, dmitry@HIDDEN, juri@HIDDEN, bug-gnu-emacs@HIDDEN:bug#80037; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.