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))

["João Távora" <joaotavora@gmail.com>]

Stefan Monnier <monnier@IRO.UMontreal.CA> 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. 

>
> 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 <project>*".

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ão