difficulty creating unique frame names

difficulty creating unique frame names

[Damon Permezel]

The default naming scheme for certain emacs implementations is to use
the string in the frame-title-format which defaults to "%b".  It is
thus quite easy to create many frames with the same name.  Just start
emacs and hit ^x-5-2 repeatedly.

The Buffers>Frames menu thus presents a list of buffers many with the
same names.  Also, any command for manipulating frames by frame names
really cannot use the name to distinguish between the frames.  Note that
the Buffers>Frames cannot be used to select all the frames with the same
name when there are more than 2 with the same name.  This is a bug!

In order to avoid this bug, one has to have unique frame names.

I wish to retain the "%b" functionality in the frame-title-format, so
I have attempted to construct a FORM that will be evaluated when the
frame title is desired to provide some unique element --- in this case
a F%d where the %d is the index of the frame within the (frame-list),  
say.

I find that it is not possible to calculate this correctly, as I have
no means, from elisp, at the time the FORM is being evaluated, to
obtain the frame in question.

I have also tried setting a :zz-count property on the frames to
uniquely identify them, however there is no means I know of to
retrieve this property again as the frame in question is not available
to me.

I do not want to set the 'name property for the frame, as I wish to
retain the "%b" functionality, and I note that this does not work.
IE: I could arrange to set each frame's 'name to "<unique> %b" readily
enough, but then the %b is not expanded.  Also, cannot set name to
anything by a string.

I have tried setting the 'frame-title-format property in a frame,
given that this is rumoured to create frame-local-variables, but this
does not seem to influence the global frame-title-format.

(setq zz-frame-count 0)

;;
;; this will put a unique :zz-count in each frame's properties
;;
(add-hook 'after-make-frame-functions
	  '(lambda (frame)
	     (progn
	       (modify-frame-parameters frame (list (cons :zz-count (setq zz- 
frame-count (1+ zz-frame-count)))))
	       (message "%S" (frame-parameters frame)))))

;;
;; this attempts to set F%d to the index of the frame in the
;; frame-list, but it just does so for the current frame.
;;

(setq frame-title-format
       (cons :eval
	    '((let ((f (next-frame (previous-frame)))
		    (x nil))
		(format "F%d:%%b - %%F"
			(apply '+ (mapcar
				   (lambda (_)
				     (if x 0
				       (setq x (eq _ f))
				       1))
				   (frame-list))))))

;; try the above, and then a a slew of ^x-5-2 and then cycle thru the  
frames and look at the names.


I would either like to be able to have (current-frame) return the
frame for which the frame-title-format is being expanded, or I would
like to have a '%Z[pname]' (or something less revolting) expand out to  
a named property for
the implicit frame, just as '%F' expands the implicit frame's name.

(setq frame-title-format "F%Z[:zz-count]:%b")

would give me "F1:*scratch*", "F2:*scratch*", ... for example.

Another solution would be to use the per-frame frame-title-format.


In GNU Emacs 22.1.50.1 (i386-apple-darwin8.11.1, Carbon Version 1.6.0)
  of 2008-01-18 on seijiz.local
Windowing system distributor `Apple Inc.', version 10.5.2
configured using `configure  '--prefix=/Applications/Emacs.app/ 
Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/ 
Volumes/Emacs/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-Os -arch i386  
-arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI - 
DUSE_MAC_TSM''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
   shell-dirtrack-mode: t
   encoded-kbd-mode: t
   show-paren-mode: t
   mac-key-mode: t
   display-time-mode: t
   mac-print-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
c o u n t ) C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b
C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b
C-b C-b c o n s SPC C-e C-x C-e C-] C-p C-p C-p C-p
C-p C-p C-x C-e C-n C-n C-n C-n C-n C-n C-e C-x C-e
) C-n C-n C-b C-b C-x C-e C-] C-e C-x C-e C-x C-e C-x
5 2 <switch-frame> <down-mouse-1> <mouse-movement>
<mouse-1> C-h f <return> <help-echo> C-x 1 C-x C-b
C-n SPC <down-mouse-1> <mouse-1> ( l i s t SPC C-e
) b x C-e <backspace> <backspace> C-x C-e C-] C-b C-x
C-e C-n C-n C-x C-e C-p C-p C-p C-p C-p C-p C-a C-k
C-k C-y C-y C-p C-p C-d C-d C-d C-d C-d C-d C-d C-d
C-d C-d C-d ( s e t q SPC C-e SPC n i l ) C-a ; C-e
C-x C-e C-n C-n C-n C-n C-n C-n C-n C-n C-p C-x C-e
C-x 5 2 <switch-frame> <switch-frame> <help-echo> <down-mouse-1>
<mouse-movement> <mouse-1> C-b C-b C-b C-b C-b C-b
C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b
C-b C-b C-b C-b C-b C-b C-b C-b ( s r t q <backspace>
<backspace> <backspace> e t q SPC <backspace> <backspace>
<backspace> <backspace> <backspace> C-f C-f C-f C-f
C-f C-f C-f C-f C-f C-f ( s e t q SPC C-k C-y <backspace>
<backspace> <backspace> SPC ( 1 + SPC C-y <backspace>
<backspace> C-x C-e ) ) ) ) C-x C-e <down-mouse-1>
<mouse-1> <backspace> C-e C-b C-x C-e C-x C-e C-n C-n
C-p C-p C-p C-p C-p C-p C-p C-x C-e C-n C-n C-n C-n
C-n C-n C-n C-x C-e C-n C-n C-n C-n C-n C-n C-] <down-mouse-1>
<mouse-movement> <mouse-movement> <drag-mouse-1> C-x
C-x A-c <menu-bar> <help-menu> <send-emacs-bug-rep
ort>

Recent messages:
1
Entering debugger...
((:zz-count . 1))
((:zz-count . 2))
nil
((lambda (frame) (progn (select-frame-set-input-focus frame) (modify- 
frame-parameters frame (list (cons :zz-count (setq zz-frame-count (1+  
zz-frame-count))))) (message "%S" (frame-parameters frame)) (mwm))))
Auto-saving...done
Quit
Auto-saving...
Loading emacsbug...done

should frame names be unique? [was: difficulty creating unique frame names]

[Drew Adams]

It is not the best design to have multiple frames with the
same name. When you choose a frame by its name via the
minibuffer or a menu, it's possible to see duplicate names
that represent different frames - there is then no way to
know which name corresponds to which frame.

Frames are uniquely identified internally, but the `name'
frame parameter does not reflect this uniqueness. It might
be better to treat frame names similarly to how we treat
buffer names (foo, foo<2>, foo<3>...). But because the frame
name is often based on a buffer name (via frame-title-format
"%b"), angle brackets are perhaps not the best choice for
making frame names unique.

In my code, I provide unique names for choosing frames,
without actually renaming the frames. The unique names use
brackets ([]) with a counter: foo, foo[2], bar<3>,
bar<3>[2], and so on - the bracketed counter is appended to
the existing frame name (existing frame name bar<3> comes
from buffer bar<3>).

My code doesn't change frame-parameter `name' in this way;
it just gives users a way to refer to frames using unique
names.

I think it would be good, however, if Emacs actually named
frames in this way. When a frame is named, if a frame with
the same name already exists, then the new name would get a
bracketed counter id.

WDOT?

For reference, here is the code I use to map existing frame
names to unique names (again, without renaming the frames
themselves):

(defun icicle-make-frame-alist ()
  "Return an alist of entries (FNAME . FRAME), where FNAME
names FRAME.
Frame parameter `name' is used as FNAME, unless there is
more than one
frame with the same name.  In that case, FNAME includes a
suffix
\[NUMBER], to make it a unique name.  The NUMBER order among
frame
names that differ only by their [NUMBER] is arbitrary."
  (let ((fr-alist ())
        (count 2)
        fname new-name)
    (dolist (fr (frame-list))
      (setq fname (frame-parameter fr 'name))
      (if (not (assoc fname fr-alist))
          (push (cons fname fr) fr-alist)
        (setq new-name fname)
        (while (assoc new-name fr-alist)
          (setq new-name (format "%s[%d]" fname count)
                count (1+ count)))
        (push (cons new-name fr) fr-alist))
      (setq count 2))
    fr-alist))

Trying that gives you an idea of the kinds of names I'm
talking about, but what's needed is to actually name frames
from the outset using some such convention.

See also Damon's remarks and code, below.

> From: Damon Permezel Sent: Monday, March 10, 2008 8:42 PM
> To: emacs-pretest-bug@gnu.org
> Subject: difficulty creating unique frame names
> 
> The default naming scheme for certain emacs
implementations is to use
> the string in the frame-title-format which defaults to
"%b".  It is
> thus quite easy to create many frames with the same name.
Just start
> emacs and hit ^x-5-2 repeatedly.
> 
> The Buffers>Frames menu thus presents a list of buffers
many with the
> same names.  Also, any command for manipulating frames by
frame names
> really cannot use the name to distinguish between the
frames. 
>  Note that
> the Buffers>Frames cannot be used to select all the frames

> with the same
> name when there are more than 2 with the same name.  This
is a bug!
> 
> In order to avoid this bug, one has to have unique frame
names.
> 
> I wish to retain the "%b" functionality in the
frame-title-format, so
> I have attempted to construct a FORM that will be
evaluated when the
> frame title is desired to provide some unique element ---
in this case
> a F%d where the %d is the index of the frame within the 
> (frame-list),  
> say.
> 
> I find that it is not possible to calculate this
correctly, as I have
> no means, from elisp, at the time the FORM is being
evaluated, to
> obtain the frame in question.
> 
> I have also tried setting a :zz-count property on the
frames to
> uniquely identify them, however there is no means I know
of to
> retrieve this property again as the frame in question is
not available
> to me.
> 
> I do not want to set the 'name property for the frame, as
I wish to
> retain the "%b" functionality, and I note that this does
not work.
> IE: I could arrange to set each frame's 'name to "<unique>
%b" readily
> enough, but then the %b is not expanded.  Also, cannot set
name to
> anything by a string.
> 
> I have tried setting the 'frame-title-format property in a
frame,
> given that this is rumoured to create
frame-local-variables, but this
> does not seem to influence the global frame-title-format.
> 
> (setq zz-frame-count 0)
> 
> ;;
> ;; this will put a unique :zz-count in each frame's
properties
> ;;
> (add-hook 'after-make-frame-functions
> 	  '(lambda (frame)
> 	     (progn
> 	       (modify-frame-parameters frame (list (cons 
> :zz-count (setq zz- 
> frame-count (1+ zz-frame-count)))))
> 	       (message "%S" (frame-parameters frame)))))
> 
> ;;
> ;; this attempts to set F%d to the index of the frame in
the
> ;; frame-list, but it just does so for the current frame.
> ;;
> 
> (setq frame-title-format
>        (cons :eval
> 	    '((let ((f (next-frame (previous-frame)))
> 		    (x nil))
> 		(format "F%d:%%b - %%F"
> 			(apply '+ (mapcar
> 				   (lambda (_)
> 				     (if x 0
> 				       (setq x (eq _ f))
> 				       1))
> 				   (frame-list))))))
> 
> ;; try the above, and then a a slew of ^x-5-2 and then
cycle 
> thru the  
> frames and look at the names.
> 
> 
> I would either like to be able to have (current-frame)
return the
> frame for which the frame-title-format is being expanded,
or I would
> like to have a '%Z[pname]' (or something less revolting) 
> expand out to  
> a named property for
> the implicit frame, just as '%F' expands the implicit
frame's name.
> 
> (setq frame-title-format "F%Z[:zz-count]:%b")
> 
> would give me "F1:*scratch*", "F2:*scratch*", ... for
example.
> 
> Another solution would be to use the per-frame
frame-title-format.

Re: should frame names be unique?

[Stefan Monnier]

>>>>> "Drew" == Drew Adams <drew.adams@Oracle.com> writes:

> It is not the best design to have multiple frames with the
> same name. When you choose a frame by its name via the
> minibuffer or a menu, it's possible to see duplicate names
> that represent different frames - there is then no way to
> know which name corresponds to which frame.

Try

  (setq frame-title-format
        '(multiple-frames ("F"
                           (:eval (number-to-string
                                   (length (memq (selected-frame)
                                                 (frame-list)))))
                           " %b")
                          ("" invocation-name "@" system-name)))

I'm not opposed to making frame names unique, but first, I'd like to
hear about the use-cases where it matters.

I.e. what uses of frame-names are we talking about
(select-frame-by-name?  The Frames menu?)?
What is the difference between those frames showing the same buffer
(is it just to display two different parts of a buffer, if so do the
various frames play different roles?  Are they on different screens?
Can you see their names in the title bar? ...)


        Stefan

RE: should frame names be unique?

[Drew Adams]

> > It is not the best design to have multiple frames with
the
> > same name. When you choose a frame by its name via the
> > minibuffer or a menu, it's possible to see duplicate
names
> > that represent different frames - there is then no way
to
> > know which name corresponds to which frame.
> 
> Try
> 
>   (setq frame-title-format
>         '(multiple-frames ("F"
>                            (:eval (number-to-string
>                                    (length (memq
(selected-frame)
>
(frame-list)))))
>                            " %b")
>                           ("" invocation-name "@"
system-name)))

This is about commands that interact with user frames. It's
not appropriate to ask users to name their frames in some
particular way. But perhaps I misunderstand you.

> I'm not opposed to making frame names unique, but first,
I'd like to
> hear about the use-cases where it matters.

Think of the Frames menu. If you have multiple frames
showing the same buffer, then you will have multiple
identical entries in the Frames menu. No way to know which
is which, which makes them pretty useless.

> I.e. what uses of frame-names are we talking about
> (select-frame-by-name?  The Frames menu?)?

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

(The example that brought this up was an Icicles
multi-command version of select-frame-by-name.)

> What is the difference between those frames showing the
same buffer
> (is it just to display two different parts of a buffer, if
so do the
> various frames play different roles?  Are they on
different screens?
> Can you see their names in the title bar? ...)

I can't answer any of those questions. Perhaps Damon can. He
is the one who reported the problem using multiple frames
with the same name.

Re: should frame names be unique?

[Stefan Monnier]

>> Try
>> 
>> (setq frame-title-format
>> '(multiple-frames ("F"
>> (:eval (number-to-string
>> (length (memq
> (selected-frame)
>> 
> (frame-list)))))
>> " %b")
>> ("" invocation-name "@"
> system-name)))

> This is about commands that interact with user frames.  It's
> not appropriate to ask users to name their frames in some
> particular way. But perhaps I misunderstand you.

I was just proposing a way that gives a unique name to each frame.
Those people who suffer from the problems you cite may like to use it.
I'm not suggesting it as a general solution, which is obvious since I'm
not sure what is the problem.

>> I'm not opposed to making frame names unique, but first, I'd like to
>> hear about the use-cases where it matters.

> Think of the Frames menu.  If you have multiple frames
> showing the same buffer, then you will have multiple
> identical entries in the Frames menu.  No way to know which
> is which, which makes them pretty useless.

Yup, pretty useless.  So if it hurts, don't do that.

>> I.e. what uses of frame-names are we talking about
>> (select-frame-by-name?  The Frames menu?)?

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

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.

> (The example that brought this up was an Icicles
> multi-command version of select-frame-by-name.)

Yes, but I don't know where it fits: if it just creates different names
in the names-list without actually changing the frame names, then the
problem is the same as the Frames menu: you can select any frame, but
you have no way to know beforehand which name corresponds to which frame
(among those that have the same name).

>> What is the difference between those frames showing the same buffer
>> (is it just to display two different parts of a buffer, if so do the
>> various frames play different roles?  Are they on different screens?
>> Can you see their names in the title bar? ...)

> I can't answer any of those questions.

So you're not faced with this problem in practice.  It's just
a hypothetical issue?


        Stefan

Re: should frame names be unique?

[Damon Permezel]

Certain emacs commands (menu-bar buffer frames, for example) did not
work well with the default frame naming mechanism.  Attempts to use
the frame naming mechanism to address this, whilst keeping the "%b"
feature, did not work.  I believe that this problem has been
addressed, altough I have not had occasion to confirm this.

Whether the default frame naming mechanism results in unique names is
another issue.

I do believe that any command that produces a list of frames must
assign unique identifiers to the frames so that when a user selects a
frame to be acted upon, using a name so presented, precisely the frame
the user intends is the target of the command.

Should emacs itself enforce unique frame names?  I am not sure,
however, the default behavior could be changed so that frame names do
default to unique, user-friendly ones.

Frame names can be (are currently) dynamic.  Default xdisp.c platforms
have "%b" which is dynamic, and can result in duplicate name confusion.

What I desired was to be able to enforce a static portion, unique for
each frame, plus a dynamic portion, and with the fix I believe to be
in emacs 23, I believe I have that, although it takes me more work.

It might be sufficient for most users to have the default
frame-title-format, which is currently, on many platforms, "%b" when
multiple frames are present, be something else, such as "%@ %b" where
"%@" (select something more appropriate than @) will be expanded to
some user-friendly, static and unique frame identifier.

(multiple-frames "%@ - %b" ("" invocation-name "@" system-name))

where %@ expands into the static frame unique portion of the name, and  
"%b"
the dynamic (in this example).

Simply add the '%@' expansion and change the icon-title-format string  
in xdisp.c.

Have not looked at any non-xdisp.c platforms.

Cheers,
Damon Permezel
permezel@mac.com

-----
"Those who preserve integrity remain unshaken by the storms of daily  
life ." -- Eliot Spitzer

Re: should frame names be unique?

[Damon Permezel]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]


On 2008-Mar-22, at 11:12 AM, Stefan Monnier wrote:
>>>
>>>
>>> What is the difference between those frames showing the same buffer
>>> (is it just to display two different parts of a buffer, if so do the
>>> various frames play different roles?  Are they on different screens?
>>> Can you see their names in the title bar? ...)
>
>> I can't answer any of those questions.
>
> So you're not faced with this problem in practice.  It's just
> a hypothetical issue?
>
>


[-- Attachment #2: pastedGraphic.tiff --]
[-- Type: image/tiff, Size: 211160 bytes --]

[-- Attachment #3: Type: text/plain, Size: 501 bytes --]




Here is an example I tend to run into.  I have a large frame where I  
am doing most of my work.  I have popped up two smaller frames to  
provide reference to different parts of the same file.  I wish to use  
the buffers>frames> menu to select one of the three frames displaying  
portions of the file.  One, I am editing in, the other two, I have for  
reference.


Not at all hypothetical, although I am more inclined to use a keyboard  
command, rather than the mouse, so somewhat contrived.

RE: should frame names be unique?

[Drew Adams]

> >> I'm not opposed to making frame names unique, but first, 
> >> I'd like to hear about the use-cases where it matters.
> 
> > Think of the Frames menu.  If you have multiple frames
> > showing the same buffer, then you will have multiple
> > identical entries in the Frames menu.  No way to know which
> > is which, which makes them pretty useless.
> 
> Yup, pretty useless.  So if it hurts, don't do that.

That was my reaction at first, also. But I now think it makes more sense to give
frames unique names - just as we do with buffers.

> >> I.e. what uses of frame-names are we talking about
> >> (select-frame-by-name?  The Frames menu?)?
> 
> > 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?).
> 
> 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.

That's just describing the bug/limitation (the status quo)! That's exactly the
point.

The frame objects are individual, unique, and it is appropriate that they have
unique names, so that you can select a given object by name.

> > (The example that brought this up was an Icicles
> > multi-command version of select-frame-by-name.)
> 
> Yes, but I don't know where it fits: if it just creates 
> different names
> in the names-list without actually changing the frame names, then the
> problem is the same as the Frames menu: you can select any frame, but
> you have no way to know beforehand which name corresponds to 
> which frame (among those that have the same name).

No, each frame has a unique way of referring to it, this way. This is no
different from buffer names. If you have three buffers visiting files named foo,
then you have three buffer names, foo, foo<2>, and foo<3>. It doesn't take you
long to get used to which is which, that is, which buffer name corresponds to
which file foo.

But yes, it would be preferable for the frames themselves to have these unique
names. Then you would not only refer to them by name via some
select-frame-by-name command, but you would also see the name in the frame title
bar, and the name would be the actual frame parameter. That is the point of my
suggestion, not to implement another stop-gap like what the Icicles command
provides.

> >> What is the difference between those frames showing the same buffer
> >> (is it just to display two different parts of a buffer, if 
> >> so do the various frames play different roles?  Are they on 
> >> different screens? Can you see their names in the title bar? ...)
> 
> > I can't answer any of those questions.
> 
> So you're not faced with this problem in practice.  It's just
> a hypothetical issue?

You're asking me what the difference was between Damon's frames in practice and
how he was using them differently. How can I answer that? 

But I didn't just say I couldn't answer it - I referred the question to Damon,
who can, presumably.

However, I don't think the user-specific practical difference is important. For
whatever reason, Mr X or Ms Y has multiple frames with the same name, but wants
to use them differently. Whether each shows the same buffer with a different
view, or they show different buffers but have the same frame name for some other
reason (e.g. machine name, date, whatever), or for any other reason. _If_ you
have multiple frames with the same name, it is likely that you have multiple
frames for a reason - they have _different uses for you_, whatever those uses
might be.

Damon has multiple frames, each named after the same buffer. The frames are
different _to him_ in some way - perhaps one of the ways you asked about. But
the frame names do not distinguish the frames in any way. That's too bad.

Even a unique name with no meaning (e.g., 1, 2, 3,...) would at least let you
distinguish the frames. Better would be to combine the existing frame name with
this, to give a unique name that is not totally meaningless.

That's all. Some way to distinguish is better than no way to distinguish. The
rationale is the same as for buffer names, as I see it.

Re: should frame names be unique?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 21 Mar 2008 19:34:28 -0700
> Cc: emacs-pretest-bug@gnu.org, 'Damon Permezel' <permezel@mac.com>,
> 	'Emacs-Devel' <emacs-devel@gnu.org>
> 
> > > 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?

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

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

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.

Re: should frame names be unique?

[Eli Zaretskii]

> From: Damon Permezel <permezel@mac.com>
> Date: Sat, 22 Mar 2008 11:43:29 +1000
> Cc: emacs-pretest-bug@gnu.org, 'Stefan Monnier' <monnier@iro.umontreal.ca>,
> 	'Emacs-Devel' <emacs-devel@gnu.org>
> 
> Have not looked at any non-xdisp.c platforms.

I don't think there are platforms that don't use xdisp.c.

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.

Re: should frame names be unique?

[Stefan Monnier]

>>>> What is the difference between those frames showing the same buffer
>>>> (is it just to display two different parts of a buffer, if so do the
>>>> various frames play different roles?  Are they on different screens?
>>>> Can you see their names in the title bar? ...)
>> 
>>> I can't answer any of those questions.
>> 
>> So you're not faced with this problem in practice.  It's just
>> a hypothetical issue?

> Here is an example I tend to run into.  I have a large frame where I am
> doing most of my work.  I have popped up two smaller frames to  provide
> reference to different parts of the same file.  I wish to use  the
> buffers>frames> menu to select one of the three frames displaying portions
> of the file.  One, I am editing in, the other two, I have for reference.

So you want to change frame-title-format so that the "same-name-frames"
don't have the same name.  A simple way to do that is the setting
I suggested (which adds "F<nn>" to every frame name).

> Not at all hypothetical,

Your case didn't sound hypothetical indeed.  Drew's does, tho.

> although I am more inclined to use a keyboard
> command, rather than the mouse, so somewhat contrived.

What keyboard command would you use?  One thing you may want to use
is a variant of windmove.el that allows the same kind of movement but
between frames.  But that's typically better provided by the
window-manager than by Emacs.

Basically, frame names in GUIs are currently assumed to be pretty much
"display only", so they don't matter and having them unique or not is of
fairly low importance.

This said, I wouldn't reject a patch that makes them unique, although
I'd rather such a patch to only make them unique on a particular
terminal, since I often access a single Emacs process from different
terminals and would rather have most of my frames suddenly get all named
"foo<2>" just because there's already a "foo" on some other terminal.


        Stefan

Re: should frame names be unique?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@Oracle.com>
> Cc: <monnier@iro.umontreal.ca>, <emacs-pretest-bug@gnu.org>,
>         <permezel@mac.com>, <emacs-devel@gnu.org>
> Date: Sat, 22 Mar 2008 08:38:06 -0700
> 
> > > > > 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

Yes, I think duplicates, if they exist, are removed by completion
subroutines.

> I don't think anyone is criticizing select-frame-by-name.

And I wasn't defending it, just explaining the design decisions I made
when I wrote it, in the hope that it will be useful to whoever
undertakes to change it now.

RE: should frame names be unique?

[Drew Adams]

> Your case didn't sound hypothetical indeed.  Drew's does, tho.

Uh, I was reporting Damon's case, AFAIK.

The original context for this was Damon's use of `icicle-select-frame', which
used `select-frame-by-name' at that time. (In Icicles, `C-0 C-x o' lets you
select frames by name, with completion. It now uses unique frame names.) 

Damon's original context was not the Frames menu. The general problem of
non-unique frame names exists for the Frames menu also, so I replied "both" to
your question. 

The point is the general limitation wrt frame names, not the particular by-name
access method. Frame names should be unique for the same reason that buffer
names should be unique.

> Basically, frame names in GUIs are currently assumed to be pretty much
> "display only", so they don't matter and having them unique 
> or not is of fairly low importance.

That's again just describing the status quo. It's not a justification: your "so"
doesn't follow. It's not _because_ the Emacs GUI or some other GUI currently
doesn't uniquify frame names that they should not be unique. The Emacs GUI
evolves, and it already has features that other GUIs do not have.

> This said, I wouldn't reject a patch that makes them unique,

I hope someone provides such a patch. If it were Lisp, not C, then I might.

> although I'd rather such a patch to only make them unique on a particular
> terminal, since I often access a single Emacs process from different
> terminals and would rather have most of my frames suddenly 
> get all named "foo<2>" just because there's already a "foo" on some
> other terminal.

I can't speak to the case for terminals. Everything I've said about this is for
the GUI case. If non-unique frames are inappropriate in some terminal contexts,
then exclude those contexts.

And if there is a good reason that some user might not want unique names in a
GUI context, then we could add an option for it. I can't imagine that, any more
than I can imagine a user wanting non-unique buffer names, but perhaps there is
such a reason.

Re: should frame names be unique?

[Stefan Monnier]

>> This said, I wouldn't reject a patch that makes them unique,
> I hope someone provides such a patch.  If it were Lisp, not C, then I might.

I already provided a solution that involves no C code.  Feel free to
improve it.  But, yes, maybe doing it well in Elisp is going to
be difficult.

>> although I'd rather such a patch to only make them unique on a particular
>> terminal, since I often access a single Emacs process from different
>> terminals and would rather have most of my frames suddenly 
>> get all named "foo<2>" just because there's already a "foo" on some
>> other terminal.

> I can't speak to the case for terminals.

I meant "terminal" in the technical sense used in Emacs.  In my case,
most of those "terminals" are X11 displays.


        Stefan