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:

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

Those are files.  I'm just proposing that we use the advantage of
file-less buffers, which is non-persistently naming them after a
specific location or context

You can't do with a with a file name, and, on a tangent, I think this is
what many people like the "project drawer" for: to know whence a file
comes by looking at their screen.

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

Oh so it does exist.  Can it be set buffer-locally?

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

But don't you find it useful in a buffer list (C-x b, C-x C-b, etc) to
know _whom_ that *mail* is for? Or what project that *vc-dir* is
editing?

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

OK, good idea: then I'll update the patch to be

  (defun add-log--pseudo-changelog-buffer-name (changelog-file-name)
  "Compute suitable name for a pseudo-ChangeLog buffer."
  (format "*changes to %s*"
          (abbreviate-file-name
           (file-name-directory changelog-file-name))))

and wait for Eli's comments.

Then we can plug uniquify in there somehow later.  I'll be happy just to
rid myself of ChangeLog files tbh...

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

Even better, then!

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

Did you mean a file named *changes*? If you did, it's like opening some
"*grep*" file today (I've just checked: it's uniquified, correctly).  If
you didn't I don't understand the problem.  To be clear, I was talking
about always having a (potentially short) suffix.

               João (who would like it known that he used "whom" and
                    "whence" having no idea if he botched it)