RE: should frame names be unique?

[Drew Adams]

> > > > Yes, both. Though select-frame-by-name apparently removes
> > > > duplicates, so AFAICT it doesn't even let you select some of
> > > > the frames (a bug?).
> 
> I don't see duplicate removal in select-frame-by-name; can you point
> me to what I'm missing here?

Dunno. ;-)

I used emacs -Q, then C-x 5 2 a few times on a couple buffers.

Then M-x select-frame-by-name TAB shows me only, say, two names, for the two
buffers that are shown in, say, 6 frames altogether. Duplicate frame names are
removed from *Completions*. 

That's normal Emacs completion behavior, AFAIK, so I shouldn't have suggested
that it's a select-frame-by-name bug. What might be considered a bug (more
precisely, a limitation of the current design) is just the fact that frame names
are not distinct.

> > > Not a bug: a fundamental limitation of the command: you can't 
> > > select by name and at the same time distinguish between two
> > > objects that have the same name.
> 
> Yes, select-frame-by-name assumes the frame names are unique.

We know they are not. The question is whether they should be - whether that
would be more useful.

> > That's just describing the bug/limitation (the status quo)! 
> > That's exactly the point.
> 
> select-frame-by-name was written for use primarily on text terminals,
> where the default Fn names (where n is a number) are not helpful when
> you have several frames.  To remedy that, I modified set-frame-name
> and its subroutines to allow setting the frame name on a tty to a
> meaningful name.  My thoughts were that, since a human is expected to
> give frames their names, which should be meaningful (or else they will
> not be helpful), she (the said human) will take care of naming them
> uniquely.  The only problem I had to deal with was the potential
> clashes with the default Fn naming scheme.  Which is why
> frame.c:set_term_name refuses to let you give a frame a name such as
> F42.
> 
> select-frame-by-name works for GUI frames as well, but IMO it doesn't
> make much sense there, since (a) several frames can be seen at once,
> and (b) better ways of selecting the right frame by GUI features, such
> as the mouse or task bar, are available.

I don't think anyone is criticizing select-frame-by-name. Stefan raised that as
an example of how someone might be using multiple frames with the same name. He
asked if that was such a scenario, and I replied that it could be.

I disagree about the senselessness of `select-frame-by-name' for GUI frames. It
can be a very useful way to select a GUI frame, when frames have unique names
(which you say was its design assumption). Completion is very helpful in this
regard. It is more flexible and quicker than using the mouse, in many contexts.
(Completion could even be used to raise and select invisible frames.)

> Now, if the above assumptions are somehow wrong, there should be no
> problem to force unique frame names inside x_set_name, similar to what
> set_term_frame_name does for tty frames, either by uniquifying them
> like we do with buffers (but I personally dislike the resulting foo<2>
> names), or by requesting that the caller provides another name.

I know nothing about the C implementation, so I won't comment on how to do it.

The advantage of the foo<2> buffer uniquifying regime is that it is
recognizable, systematic, and understandable. It might not win a beauty contest,
but I don't know another naming system that would, in this context. 

My approach is to use [3], not <3> after the base frame name, since that is
often a buffer name and a buffer might already be named foo<3>. Using just
foo<3> would be ambiguous - is it the third frame whose base name is foo or a
frame showing buffer foo<3>?

As to the suggestion that Emacs drop everything and ask the user what frame to
use - no, please. Can you imagine if Emacs did that for buffer names, instead of
silently giving you buffer foo<3>? Users would be manning the barricades. Think
of what we do for buffers, and why - a similar approach makes sense for frames,
IMO.