all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Boruch Baum <boruch_baum@gmx.com>, Eli Zaretskii <eliz@gnu.org>
Cc: 36839@debbugs.gnu.org
Subject: bug#36839: 26.1: unique frame names
Date: Wed, 31 Jul 2019 11:13:40 +0200	[thread overview]
Message-ID: <ddf2e498-10cc-7e92-4c5a-38f3d95fe61d@gmx.at> (raw)
In-Reply-To: <20190729174933.jkov4mji5uovxlm6@E15-2016.optimum.net>

 > I'm using C-x 5 b (M-x select-frame-by-name) to switch between frames
 > and in my case, I would like the names to be more informative than just
 > Fnn. In a more general sense, if emacs is offering the NAME parameter,
 > it should assume the parameter will be used, and currently emacs isn't
 > handling its use well.

I think the current behavior (using the name of the buffer of the
selected window of each frame) works reasonably well as long as the
same buffer doesn't appear in more than one selected window.  It
simply delegates your problem to the buffer naming mechanism.

What you probably want is a mechanism that automatically assigns each
frame an explicit, unique name at creation time.  We could do that
(optionally, because otherwise we would interfere with the default
approach) but would have to invent a suitable naming scheme first.
This is non-trivial because a naive numbering scheme where a user
creates and subsequently deletes many frames might get out of hand
soon.  Such users need a mechanism for recycling the numbers of dead
frames which might confuse other users who rarely create new frames.

You could try putting a function that produces such names in your
early init file, assign the values it produces to each newly created
frame in a lambda you put on 'after-make-frame-functions' and tell us
your experiences.

martin





  parent reply	other threads:[~2019-07-31  9:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-29 16:16 bug#36839: 26.1: unique frame names Boruch Baum
2019-07-29 17:00 ` Eli Zaretskii
2019-07-29 17:49   ` Boruch Baum
2019-07-29 18:00     ` Eli Zaretskii
2019-07-29 18:54       ` Boruch Baum
2019-07-29 19:28         ` Eli Zaretskii
2019-07-29 19:43           ` Boruch Baum
2019-07-30 15:11             ` Eli Zaretskii
2022-03-23 13:38               ` Lars Ingebrigtsen
2019-07-31  9:13     ` martin rudalics [this message]
2019-07-31 14:10       ` Eli Zaretskii
2019-08-01  8:54         ` martin rudalics
2019-08-02  8:57           ` Eli Zaretskii
2019-08-02 12:50             ` martin rudalics
2019-07-29 17:43 ` Andreas Schwab
2019-07-29 18:00   ` Boruch Baum
2019-07-29 20:42     ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ddf2e498-10cc-7e92-4c5a-38f3d95fe61d@gmx.at \
    --to=rudalics@gmx.at \
    --cc=36839@debbugs.gnu.org \
    --cc=boruch_baum@gmx.com \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.