separate name uniquification from `generate-new-buffer-name'

separate name uniquification from `generate-new-buffer-name'

[Drew Adams]

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

I use such naming for windows and frames, and I'm sure there could be other use
cases - wherever you want a set of similar names with some simple way to
distinguish them.

Something like the function `unique-name' below, perhaps.  It can be used for
other things besides buffer names, and its naming is more general (see doc
string):

* The minimum <N> can be anything you like, not just <2> (optional arg MIN).

* You can optionally make the new name use a single <N>, instead of things like
a<2><1> and a<2><1><4> (arg USE-BASE-P).

* When using only a single <N> (non-nil USE-BASE-P), you can optionally have it
either fill in holes, picking the minimal <N> that is free (and >= MIN), or have
it always use a number greater than all those in use (arg MAXP).

* (You can even use negative indexes, such as a<-3>, though I don't foresee any
particular use case for that.)


(defun unique-name (name existing-names &optional min use-base-p maxp)
  "Return NAME or NAME<N>, a name that is not in EXISTING-NAMES.
Return NAME if NAME is not a member of EXISTING-NAMES.
Otherwise, return NAME or its base name, suffixed by `<N>', where N is
an integer.

The optional args are used only when NAME is in EXISTING-NAMES.

MIN is the minimum integer N to use in the new suffix.  Default: 1.

Non-nil USE-BASE-P means use only the base name of NAME.  The value
returned is of the form `BASENAME<N>' (only a single suffix).
BASENAME is NAME truncated at the right starting with the first suffix
`<M>'.  The base name of `a<2>' and `a<2><3>' is `a'.

For example, if NAME is `a<2>', then with nil USE-BASE-P we might
return `a<2><1>' (depending on MIN, MAX etc.).  With non-nil
USE-BASE-P we might return `a<3>', since the base name `a' gets
suffixed, not the full NAME `a<2>'.

Optional arg MAXP is used only if USE-BASE-P is non-nil.

If MAXP is nil then N is the smallest integer greater than or equal to
MIN such that `BASENAME<N>' is not in EXISTING-NAMES.

If MAXP is non-nil then N is the smallest integer greater than or
equal to MIN and greater than the largest integer M used in a suffix
`<M>' that immediately follows BASENAME in a name in EXISTING-NAMES.

As an example, `generate-new-buffer-name' could be defined this way:

 (defun generate-new-buffer-name (buf)
   (let ((buffs  (mapcar #'buffer-name (buffer-list))))
     (unique-name buf buffs 2)))"

  (unless min  (setq min  1))
  (if (and (not (member name existing-names)) (not maxp))
      name
    (let ((indx     min)
          (baselen  (string-match "\<\\(-?[0-9]+\\)\>" name))
          try)
      (when (and use-base-p baselen)
        (setq name  (substring name 0 baselen)))
      (if maxp
          (format
           "%s<%d>" name
           (1+ (apply
                #'max
                (mapcar (lambda (nn)
                          (if (string-match "\<\\(-?[0-9]+\\)\>" nn)
                              (string-to-number (match-string 1 nn))
                            min))
                        existing-names))))
        (catch 'unique-name
          (while t
            (unless (member (setq try  (concat name "<" indx ">"))
                            existing-names)
              (throw 'unique-name try))
            (setq indx  (max min (1+ indx)))))))))

Re: separate name uniquification from `generate-new-buffer-name'

[Stefan Monnier]

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


        Stefan

RE: separate name uniquification from `generate-new-buffer-name'

[Drew Adams]

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

Re: separate name uniquification from `generate-new-buffer-name'

[Juanma Barranquero]

On Tue, May 25, 2010 at 21:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

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

As the comment in uniquify.el explains, the trouble is that usually
the function to generate a new buffer name gets only the desired
(non-unique) buffer name, not the intended use of the buffer, whether
it is going to visit a file (and its name), etc. That somewhat limits
the kinds of "uniquifyings" that can be done at  buffer-creation time.

    Juanma

RE: separate name uniquification from `generate-new-buffer-name'

[Drew Adams]

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