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]

> 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