[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: separate name uniquification from `generate-new-buffer-name'
From: |
Drew Adams |
Subject: |
RE: separate name uniquification from `generate-new-buffer-name' |
Date: |
Tue, 28 Dec 2021 03:05:39 +0000 |
> Sent: Tuesday, May 25, 2010 12:53 PM
>
> > > Something I would like to see is separation of
> > > <N>-suffix name uniquifying from
> > > `generate-new-buffer-name'. The latter could
> > > just use the more general unique-naming function
> > > (unless C optimization is important in that
> > > particular case).
> >
> > Mostly agreed. As you noticed, uniquify uses advices and
> > that should be fixed. A good way to fix it is to come up
> > with a good name-buffer-function variable that holds a
> > function that's run whenever a buffer name is chosen or
> > modified. This variable's default would be a function
> > that implements the usual <N> stuff and it could be
> > replaced by uniquify to do something more clever.
>
> I agree. Not sure what disagreement there is (why "mostly"?).
> Everything you say sounds OK to me.
>
> The kind of uniquifying I proposed, and the kind that
> generate-new-buffer-name' does, seem to be quite
> different from the uniquifying that uniquify.el does.
>
> That does not mean that the logical place for a
> function such as I proposed would not be uniquify.el.
> uniquify.el could either be broadened (e.g. more than
> one uniquifying method) or keep to the kind of naming
> it does now.
ping.
Bugs 1338 and 6259 have finally been closed.
But this is still undone, I believe. It would be
good if Someone(TM) were to make progress here.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- RE: separate name uniquification from `generate-new-buffer-name',
Drew Adams <=