From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= 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 19:00:50 +0100 Message-ID: <87sh4jcb71.fsf@gmail.com> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1531763948 22414 195.159.176.226 (16 Jul 2018 17:59:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Jul 2018 17:59:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier , eliz@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 16 19:59:04 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 1ff7m2-0005ih-Sm for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 19:59:03 +0200 Original-Received: from localhost ([::1]:53075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff7o9-0006dR-NL for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 14:01:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff7nu-0006bb-I8 for emacs-devel@gnu.org; Mon, 16 Jul 2018 14:00:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ff7nr-0004If-FB for emacs-devel@gnu.org; Mon, 16 Jul 2018 14:00:58 -0400 Original-Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:55232) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ff7nr-0004IQ-4x; Mon, 16 Jul 2018 14:00:55 -0400 Original-Received: by mail-wm0-x242.google.com with SMTP id c14-v6so5703690wmb.4; Mon, 16 Jul 2018 11:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Kg3VCrFu5GauaEw4qeMselLT4jZbZU+2tb3Q8TKYqfk=; b=B3IWYf9oQqjRRBJY14/SmKbsQsPjp+UCZHJvsn25MRvY/fIoQKK1DqtqAfSVrWMPT+ DNmuVOrdO8qvu/W/VhtQKNdXY0QGd38yDJEafJ6DQjpr3cn7ADmecCG5jEbsOaci01Zn eZUPQSJbaUbiGIuhxsC7HQiP51y3Ev7Tm747QDvBJEo4YdmNqh356J65RlJ6QzEqsnor za5+YvbtVj7yDQt6GErHBqF0N9eVMCvTQT5ozfOxZ9CfjRi34VCmKXemMRN2AHqowQm7 FU2Mo7imzt8wAws0TMpaX3h2S/qwjxVas+E+LT23VwnsGWSDLKz1w037xelMRHH3kdt6 SDfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Kg3VCrFu5GauaEw4qeMselLT4jZbZU+2tb3Q8TKYqfk=; b=ZO62VXMZKqKqgcUVCqh+eeRVhCdKce0RoO1ftMPhTkiNJHGTYj1EWx1Os9v0wXuwd6 dNCYzcGlMOaT5ZANT/HiXqrT2ZWbOJ4Mr9RHe56/c71MsybZOOwfy+Sv/ICGlKkcl6Hy gYaAk/VVSYFV4F5AvW/3nvTWEMdMq6DLWjHp54Je9Yt2AGcJ9spVzmi1xz97JA+KUgDC z78PzHCH1p/2WrfV6RfJTXKyw6aALcOqeoOOX5sHg/yDxcjd0ePOd6RmLJjIaerX/Y/0 sZZX0gqyBC6aPqZNx2WzfMoiw7uOoGykH3ENh7wzMZyuJWUNZo4idPsRKV/ARKgCsUPL Wu3w== X-Gm-Message-State: AOUpUlHD5Um48MCF+B3XPv1JNPvlQskRSk92RfLO6ZRAhRkm83M72X9U KOcuw7Z3+JMjdUob0SWzkEi1k3Ls X-Google-Smtp-Source: AAOMgpd0S+iGfl7+2WmjIMOtJJUXEKQ1TASEeyg9YkqCpz/d+RrOcUxev8WZxdRrr2dY3GKHduHakw== X-Received: by 2002:a1c:b609:: with SMTP id g9-v6mr9715239wmf.73.1531764053542; Mon, 16 Jul 2018 11:00:53 -0700 (PDT) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id j3-v6sm20059772wrt.70.2018.07.16.11.00.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 16 Jul 2018 11:00:52 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Mon, 16 Jul 2018 11:44:45 -0400") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::242 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:227473 Archived-At: Stefan Monnier writes: >> * This isn't a file, it's a file-less buffer. I haven't seen uniquify >> ever used for those, > > That's because you don't use vc-dir and haven't use PCL-CVS before that. > > [ IIUC it can only be made to work for *shell* buffers, but I don't use > them enough to know for sure, and it doesn't work that way out of the > box anyway, from what I know. ] > >> so it would probably confuse users into thinking >> there's a funnily named file after all; > > I haven't seen any sign of users being confused by it back in the > PCL-CVS days, nor now with vc-dir. Probabaly because vc-dir wasn't ever a notable file-name. > >> * Uniquify is designed to have a very shortest possible distinguishing >> string because the file's name is foremost in importance. It's quite >> different here. The file's name doesn't exist. The buffer's name does >> exist, but is quite irrelevant. The path to the directory, on the >> contrary, isn't. And I want that bit to show even if I have only one >> *ChangeLog* buffer. >p > We're just replacing "ChangeLog" files with "*ChangeLog*" buffers. Yes.=20 > > Currently, if you have a single ChangeLog file opened, it just says > "ChangeLog", so I don't see a strong reason to impose that the sole > "*ChangeLog*" buffer you have opened states in its buffer name which > directory it's associated to. I don't see what's wrong in being able seeing in the buffer name, at a glance, what the buffer is for. This was actually in the original suggestion by Eli, and I think it's a good idea. And it goes for *vc-dir* too, where arguably it's a little silly: its a "dir" but what dir? I have to go in the buffer and read down the second line to know. 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'd start with an option to make uniquify always show the suffix. > 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). >> Can I make add-log.el set this buffer-locally by default in the >> *ChangeLog* buffer, so that the suffix always appears even if I have >> only one? > > I don't think so, no. But as a user I'd personally not want that "at > least 1 dir element" behavior. OK, let's make this optional. > You don't have to it, indeed. It's just a suggestion. I'll probably > sooner or later apply such a patch either into `master` or into my own > local branch Well if you say you're going to turn the suggestion into a commit sooner or later, we might as well coordinate first :-) > I find such long buffer names insuperable. I don't see why. Don't you use gnus? This buffer's name reads "*unsent wide reply to Stefan Monnier*". 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*". If you want your mode-line to diet, we could cut down on the major-mode's name, which uselessly parrots "ChangeLog", or make slightly smaller as "*changes to *". Or I'll cut you a simpler deal: let's first do this very simple change and then do the single ChangeLog file/buffer that you proposed earlier, that way you won't be bothered by long buffer names. >>> These are awfully long, with a lot of redundancy in the middle, making >>> it harder to find the relevant information. >> Really, I don't think it's redundant: it's the only thing semantically >> (and formally) tying that buffer to the directory whose (vc-)project >> it's representing. > > Formally, clearly not: default-directory and list-buffers-directory tye Indirectly yes, but by that reasoning so does the mark ring, or view-lossage, or the user's memory. > 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? Jo=C3=A3o