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]

Stefan Monnier <address@hidden> writes:
>> To tell you the truth, I was hoping to *avoid* uniquify here.  IMO, it
> I don't follow.  `uniquify` is designed specifically for those cases
> where the same file name can occur in multiple projects and lets you see
> "foo|bar" and "foo|baz" instead of "foo" and "foo<1>".

Evidently, having opened two Makefile's more than once in my life, I
know that.  However:

* This isn't a file, it's a file-less buffer.  I haven't seen uniquify
  ever used for those, so it would probably confuse users into thinking
  there's a funnily named file after all;

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

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

> In any case, you should be able to get pretty much the same as what
> your patch currently does by setting uniquify-buffer-name-style and
> uniquify-min-dir-content appropriately.
>> This would also avoid the added complexity that you foresee.

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?  Can I make it so that the suffix is inside the *EarMuffs*?

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

>> Right, that is clearer.  But will it fit in the miniscule column limit? 
>
> We can split it into two sentences if needed ;-)

Rephrase away!

>> As I said, I was hoping to avoid this.  "*ChangeLog for
>> <full-project-path>*" seems acceptable to me, but we could shorten it to
> [ We call those things "filenames" rather than "path" in the GNU
> project.  ]

In code and doc, yes.  In this list, I think everybody gets me.

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

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

João