From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] New option to make C-x 4 a use file-less ChangeLog buffers (was Re: git history tracking across renames (and emacs support)) Date: Mon, 16 Jul 2018 14:22:46 -0400 Message-ID: References: <838t6jgl1k.fsf@gnu.org> <601m6cc6.fsf@lifelogs.com> <83o9fefnv9.fsf@gnu.org> <83in5lg4ol.fsf@gnu.org> <83efg9fxnj.fsf@gnu.org> <838t6hfa4h.fsf@gnu.org> <87h8l4lt9q.fsf@gmail.com> <831sc8fttu.fsf@gnu.org> <87sh4lwwg6.fsf_-_@gmail.com> <87wotvebk6.fsf@gmail.com> <871sc3e0s8.fsf@gmail.com> <87sh4jcb71.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1531765314 19570 195.159.176.226 (16 Jul 2018 18:21:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Jul 2018 18:21:54 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: eliz@gnu.org, emacs-devel@gnu.org To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 16 20:21:50 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ff885-0004z2-Qy for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 20:21:49 +0200 Original-Received: from localhost ([::1]:53189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff8AC-0007X3-Ud for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 14:24:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff897-00072Q-Bm for emacs-devel@gnu.org; Mon, 16 Jul 2018 14:22:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ff894-0005Ul-7X for emacs-devel@gnu.org; Mon, 16 Jul 2018 14:22:53 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:40805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff894-0005UX-13; Mon, 16 Jul 2018 14:22:50 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w6GINSeE032193; Mon, 16 Jul 2018 14:23:29 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 8CF3E660E5; Mon, 16 Jul 2018 14:22:46 -0400 (EDT) In-Reply-To: <87sh4jcb71.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Mon, 16 Jul 2018 19:00:50 +0100") X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 3 Rules triggered LNG_SB_1=0.2, EDT_SA_DN_PASS=0, RV6330=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6330> : inlines <6751> : streams <1792733> : uri <2674565> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:227477 Archived-At: > I don't see what's wrong in being able seeing in the buffer name, at a > glance, what the buffer is for. It's a tradeoff w.r.t buffer name length. Part of the benefit of uniquify is that it lets the user choose which side of the tradeoff he wants to favor. > And it goes for *vc-dir* too, where arguably it's a little silly: its a > "dir" but what dir? We've had the same for ChangeLog buffers for years (and README buffers, and `src` dired buffers, and ...). > If anything I'd go all out on (a modified version of) uniquify: use it > for *grep*, *Find*, *Occur* and the like, so I can distinguish by > reading from the buffer list what these buffers apply to. I could go along with that (and indeed the *cvs-commit* buffer in PCL-CVS (in which to write the commit message) followed this idea). The other tradeoff at play here (beside the buffer name) is reuse of existing buffers. > I'd start with an option to make uniquify always show the suffix. It's called uniquify-min-dir-content. >> Maybe you'd like >> (setq uniquify-separator " for ") >> better? > I probably would, a little. But it didn't do anything (for vc dir at > least). Hmm... apparently it only kicks for some of the style options. Try: (setq uniquify-separator " for ") (setq uniquify-buffer-name-style 'post-forward) >> I find such long buffer names insuperable. > I don't see why. To each his own. > Don't you use gnus? This buffer's name reads "*unsent > wide reply to Stefan Monnier*". I hate those (and there's no uniquify to save me there). Luckily I rarely need to look at those buffers's modeline. > Using ido, i can just C-x b stefan and see every file I have on you > (kidding, I only have one right now). I wouldn't like to see "*unsent > wide reply*". I'd be quite happy with "*mail*". > Or I'll cut you a simpler deal: let's first do this very simple change In any case, let's leave this uniquify beside on the side, because I don't want it to hold us back. > and then do the single ChangeLog file/buffer that you proposed earlier, > that way you won't be bothered by long buffer names. The way I imagine it, this "single file" is completely internal: the user would never view/edit it directly. >> abbreviate-file-name is supposed to return a valid file name. And it >> can't abbreviate in a context-sensitive manner (e.g. if I have two >> ChangeLog buffers opened, one for .../src/emacs/master and another for >> .../src/typer/master, it can't shorten things to "ChangeLog | emacs" >> and "ChangeLog | typer" like uniquify does). > > Maybe uniquify could provide that bit of functionality as an utility > function that other modes can use irrespective of "requiring" > uniquification. > > If it did, would you be happy with "*changes for emacs*", "*changes for > typer*" and the like? It needs to be dynamic: what if I later open some "changes" for .../src/emacs/work? Stefan