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

[Stefan Monnier]

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

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

We're just replacing "ChangeLog" files with "*ChangeLog*" buffers.

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.

>>> In practice, I find the "|<uniqueness>" much harder to read,
>> Harder then what?
> Harder than reading a short, plain-english phrase using the "for"
> preposition: "*ChangeLog for project-path*".

Maybe you'd like

    (setq uniquify-separator " for ")

better?

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

> Can I make it so that the suffix is inside the *EarMuffs*?

No.

>> Yes, but it's not as nice for the user.
> The problem is that I don't understand the niceness being advocated
> here?  And zero niceness versus non-zero complexity always loses.

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 because I find such long buffer
names insuperable.

>> 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
that buffer to the directory (and you can add the new
`add-log--buffer-file-name` to those two).

The file names introduced by `C-x 4 a` more informally do as well.

> If there's a part of it that is so common as to be distracting, we
> should use `abbreviate-file-name' (which you can probably customize to
> abbreviate extremely using directory-abbrev-alist).

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


        Stefan