* difficulty creating unique frame names @ 2008-03-11 3:41 Damon Permezel 2008-03-21 15:40 ` should frame names be unique? [was: difficulty creating unique frame names] Drew Adams 0 siblings, 1 reply; 15+ messages in thread From: Damon Permezel @ 2008-03-11 3:41 UTC (permalink / raw) To: emacs-pretest-bug 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* should frame names be unique? [was: difficulty creating unique frame names] 2008-03-11 3:41 difficulty creating unique frame names Damon Permezel @ 2008-03-21 15:40 ` Drew Adams 2008-03-21 18:23 ` should frame names be unique? Stefan Monnier 0 siblings, 1 reply; 15+ messages in thread From: Drew Adams @ 2008-03-21 15:40 UTC (permalink / raw) To: Emacs-Devel; +Cc: emacs-pretest-bug, 'Damon Permezel' 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: should frame names be unique? 2008-03-21 15:40 ` should frame names be unique? [was: difficulty creating unique frame names] Drew Adams @ 2008-03-21 18:23 ` Stefan Monnier 2008-03-21 20:28 ` Drew Adams 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2008-03-21 18:23 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-pretest-bug, 'Damon Permezel', Emacs-Devel >>>>> "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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: should frame names be unique? 2008-03-21 18:23 ` should frame names be unique? Stefan Monnier @ 2008-03-21 20:28 ` Drew Adams 2008-03-22 1:12 ` Stefan Monnier 2008-03-22 1:43 ` Damon Permezel 0 siblings, 2 replies; 15+ messages in thread From: Drew Adams @ 2008-03-21 20:28 UTC (permalink / raw) To: 'Stefan Monnier' Cc: emacs-pretest-bug, 'Damon Permezel', 'Emacs-Devel' > > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: should frame names be unique? 2008-03-21 20:28 ` Drew Adams @ 2008-03-22 1:12 ` Stefan Monnier 2008-03-22 1:58 ` Damon Permezel 2008-03-22 2:34 ` Drew Adams 2008-03-22 1:43 ` Damon Permezel 1 sibling, 2 replies; 15+ messages in thread From: Stefan Monnier @ 2008-03-22 1:12 UTC (permalink / raw) To: Drew Adams Cc: emacs-pretest-bug, 'Damon Permezel', 'Emacs-Devel' >> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: should frame names be unique? 2008-03-22 1:12 ` Stefan Monnier @ 2008-03-22 1:58 ` Damon Permezel 2008-03-22 16:55 ` Stefan Monnier 2008-03-22 2:34 ` Drew Adams 1 sibling, 1 reply; 15+ messages in thread From: Damon Permezel @ 2008-03-22 1:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-pretest-bug, Drew Adams, 'Emacs-Devel' [-- 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: should frame names be unique? 2008-03-22 1:58 ` Damon Permezel @ 2008-03-22 16:55 ` Stefan Monnier 2008-03-22 18:12 ` Drew Adams 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2008-03-22 16:55 UTC (permalink / raw) To: Damon Permezel; +Cc: emacs-pretest-bug, Drew Adams, 'Emacs-Devel' >>>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: should frame names be unique? 2008-03-22 16:55 ` Stefan Monnier @ 2008-03-22 18:12 ` Drew Adams 2008-03-23 0:47 ` Stefan Monnier 0 siblings, 1 reply; 15+ messages in thread From: Drew Adams @ 2008-03-22 18:12 UTC (permalink / raw) To: 'Stefan Monnier', 'Damon Permezel' Cc: emacs-pretest-bug, 'Emacs-Devel' > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: should frame names be unique? 2008-03-22 18:12 ` Drew Adams @ 2008-03-23 0:47 ` Stefan Monnier 0 siblings, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2008-03-23 0:47 UTC (permalink / raw) To: Drew Adams Cc: emacs-pretest-bug, 'Damon Permezel', 'Emacs-Devel' >> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: should frame names be unique? 2008-03-22 1:12 ` Stefan Monnier 2008-03-22 1:58 ` Damon Permezel @ 2008-03-22 2:34 ` Drew Adams 2008-03-22 9:50 ` Eli Zaretskii 1 sibling, 1 reply; 15+ messages in thread From: Drew Adams @ 2008-03-22 2:34 UTC (permalink / raw) To: 'Stefan Monnier' Cc: emacs-pretest-bug, 'Damon Permezel', 'Emacs-Devel' > >> 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: should frame names be unique? 2008-03-22 2:34 ` Drew Adams @ 2008-03-22 9:50 ` Eli Zaretskii 2008-03-22 15:38 ` Drew Adams 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2008-03-22 9:50 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-pretest-bug, permezel, monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: should frame names be unique? 2008-03-22 9:50 ` Eli Zaretskii @ 2008-03-22 15:38 ` Drew Adams 2008-03-22 17:29 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Drew Adams @ 2008-03-22 15:38 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: emacs-pretest-bug, permezel, monnier, emacs-devel > > > > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: should frame names be unique? 2008-03-22 15:38 ` Drew Adams @ 2008-03-22 17:29 ` Eli Zaretskii 0 siblings, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2008-03-22 17:29 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-pretest-bug, permezel, monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: should frame names be unique? 2008-03-21 20:28 ` Drew Adams 2008-03-22 1:12 ` Stefan Monnier @ 2008-03-22 1:43 ` Damon Permezel 2008-03-22 9:51 ` Eli Zaretskii 1 sibling, 1 reply; 15+ messages in thread From: Damon Permezel @ 2008-03-22 1:43 UTC (permalink / raw) To: Drew Adams Cc: emacs-pretest-bug, 'Stefan Monnier', 'Emacs-Devel' 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: should frame names be unique? 2008-03-22 1:43 ` Damon Permezel @ 2008-03-22 9:51 ` Eli Zaretskii 0 siblings, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2008-03-22 9:51 UTC (permalink / raw) To: Damon Permezel; +Cc: emacs-pretest-bug, monnier, drew.adams, emacs-devel > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2008-03-23 0:47 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-03-11 3:41 difficulty creating unique frame names Damon Permezel 2008-03-21 15:40 ` should frame names be unique? [was: difficulty creating unique frame names] Drew Adams 2008-03-21 18:23 ` should frame names be unique? Stefan Monnier 2008-03-21 20:28 ` Drew Adams 2008-03-22 1:12 ` Stefan Monnier 2008-03-22 1:58 ` Damon Permezel 2008-03-22 16:55 ` Stefan Monnier 2008-03-22 18:12 ` Drew Adams 2008-03-23 0:47 ` Stefan Monnier 2008-03-22 2:34 ` Drew Adams 2008-03-22 9:50 ` Eli Zaretskii 2008-03-22 15:38 ` Drew Adams 2008-03-22 17:29 ` Eli Zaretskii 2008-03-22 1:43 ` Damon Permezel 2008-03-22 9:51 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.