Modernize frame-title-format: "%b - GNU Emacs"

Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

Lars Ljung proposed to change frame-title-format to something more
modern and similar to Firefox, gvim, Gimp, LibreOffice, etc.:
https://debbugs.gnu.org/41147

We currently have:

    (setq frame-title-format
          '(multiple-frames "%b"
                            ("" invocation-name "@" system-name)))

The suggestion is to change it to:

    (setq frame-title-format "%b - GNU Emacs")

Alternatively, I think one could also reasonably choose:

    (setq frame-title-format
          '(multiple-frames "%b"
                            ("%b - GNU Emacs")))

I personally think it makes sense to just do what other modern software
does here, but Eli felt that we need more opinions before making any
changes.  So please let us know if you have any thoughts.

Best regards,
Stefan Kangas

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Monnier]

> The suggestion is to change it to:
>
>     (setq frame-title-format "%b - GNU Emacs")
>
> Alternatively, I think one could also reasonably choose:
>
>     (setq frame-title-format
>           '(multiple-frames "%b"
>                             ("%b - GNU Emacs")))

Either is fine by me and better than what we have IMO.


        Stefan

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> >     (setq frame-title-format "%b - GNU Emacs")
> >
> > Alternatively, I think one could also reasonably choose:
> >
> >     (setq frame-title-format
> >           '(multiple-frames "%b"
> >                             ("%b - GNU Emacs")))
> 
> Either is fine by me and better than what we have IMO.

Off the top of my head, in order of diminishing
strength of opinion:

1. Either is better than what we have now.

2. I prefer the second one, as it's more specific.

3. Generally, the more specific and informative, the
better.  If more than one bit of info is conveyed,
it's good to put the most important or most specific
bits leftmost, since narrowing the frame truncates
from the right.  To avoid: "GNU Emacs" _followed by_
more specific info.

4. Showing whatever is most important from the mode
line might be good.  At a minimum, that's %b.

If there's room, maybe after %b show the modes part
(and recursive-edit brackets).

Setting `frame-title-format' to `mode-line-format'
works, of course, but the order might not be the
most useful in general.  (But try it, just to get
the idea.)

5. Being able to, with a user option, filter out
bits of the mode-line (depending on what?) would
help.  E.g., for an Info buffer, the encoding,
read-only, mode, and `Narrow' indications aren't
needed/helpful.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Yuri Khan]

On Thu, 27 Aug 2020 at 05:09, Stefan Kangas <stefan@marxist.se> wrote:
>
> Lars Ljung proposed to change frame-title-format to something more
> modern and similar to Firefox, gvim, Gimp, LibreOffice, etc.:
> https://debbugs.gnu.org/41147
>
> The suggestion is to change it to:
>
>     (setq frame-title-format "%b - GNU Emacs")

I do that in my config, except that I use an en dash as the separator:
"%b – Emacs"; and I also display a • if the buffer is modified and
visiting a file.

One thing that slightly bothers me is that when the minibuffer is
active the title changes to " *Minibuf-1* – Emacs". Which is
technically true and perfectly logical but I think it would be more
useful for me to display the name of the last active buffer. (I’m sure
I could get to that if I spent some time at it; it just doesn’t bother
me enough.)

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

Yuri Khan <yuri.v.khan@gmail.com> writes:

>>     (setq frame-title-format "%b - GNU Emacs")
>
> I do that in my config, except that I use an en dash as the separator:
> "%b – Emacs"; and I also display a • if the buffer is modified and
> visiting a file.

Why do you use en dash?  Does Firefox, etc. use en dash, or is it simply
your own local customization?

Regarding the "•" for modified files, I have seen some programs add such
a marker (more often "*", IME).  But I checked LibreOffice and it does
not do that.  I think it would be useful to check if there are any other
text editors that use such a marker.

> One thing that slightly bothers me is that when the minibuffer is
> active the title changes to " *Minibuf-1* – Emacs". Which is
> technically true and perfectly logical but I think it would be more
> useful for me to display the name of the last active buffer. (I’m sure
> I could get to that if I spent some time at it; it just doesn’t bother
> me enough.)

Indeed, I see the same behavior in "emacs -Q" when I have two frames.

Maybe this could warrant a wishlist level bug report.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

   We currently have:

       (setq frame-title-format
	     '(multiple-frames "%b"
			       ("" invocation-name "@" system-name)))

   The suggestion is to change it to:

       (setq frame-title-format "%b - GNU Emacs")

   Alternatively, I think one could also reasonably choose:

       (setq frame-title-format
	     '(multiple-frames "%b"
			       ("%b - GNU Emacs")))

Those loose information about where you are running Emacs; which is a
useful thing when you have multiple Emacsen open on several hosts.

Please keep at least the system-name in the title bar.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[tomas]

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

On Wed, Aug 26, 2020 at 03:09:08PM -0700, Stefan Kangas wrote:
> Lars Ljung proposed to change frame-title-format to something more
> modern and similar to Firefox, gvim, Gimp, LibreOffice, etc.:
> https://debbugs.gnu.org/41147
> 
> We currently have:
> 
>     (setq frame-title-format
>           '(multiple-frames "%b"
>                             ("" invocation-name "@" system-name)))

Personally, I'm perfectly happy with this one. But then, I know how
to customize it.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Yuri Khan]

On Thu, 27 Aug 2020 at 12:55, Stefan Kangas <stefan@marxist.se> wrote:
>
> >>     (setq frame-title-format "%b - GNU Emacs")
> >
> > I do that in my config, except that I use an en dash as the separator:
> > "%b – Emacs"; and I also display a • if the buffer is modified and
> > visiting a file.
>
> Why do you use en dash?  Does Firefox, etc. use en dash, or is it simply
> your own local customization?

I do that because that is typographically correct. Other programs use
a hyphen for historical reasons and if they all nod at each other for
consistency then we will not have any way forward.

> Regarding the "•" for modified files, I have seen some programs add such
> a marker (more often "*", IME).  But I checked LibreOffice and it does
> not do that.  I think it would be useful to check if there are any other
> text editors that use such a marker.

Yes, asterisk is often used as an unsaved file marker. Mousepad
(default text editor for XFCE) does display it, and so does GIMP.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

ams@gnu.org (Alfred M. Szmidt) writes:

> Those loose information about where you are running Emacs; which is a
> useful thing when you have multiple Emacsen open on several hosts.

OTOH, you will still be able to easily customize frame-title-format
yourself.  You could also use:

    alias emacs="emacs --title emacs@`hostname`"

The question here is what is a reasonable default for most users.
I suspect that most users only ever run Emacs on one machine.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

   > Those loose information about where you are running Emacs; which is a
   > useful thing when you have multiple Emacsen open on several hosts.

   OTOH, you will still be able to easily customize frame-title-format
   yourself.  You could also use:

       alias emacs="emacs --title emacs@`hostname`"

That assumes that you put this alias on every single host you might
want to ever connect to.

   The question here is what is a reasonable default for most users.
   I suspect that most users only ever run Emacs on one machine.

My experience says otherwise.

The title bar should give useful information, not just be "pretty".
There is enough space in the title bar to keep the system-name.  E.g,

   "buffer-name - GNU Emacs (system-name)"

The hyphen, en dash, could maybe be an asterix if the buffer is
modified.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

      "buffer-name - GNU Emacs (system-name)"

   The hyphen, en dash, could maybe be an asterix if the buffer is
   modified.

Or maybe:

  "GNU Emacs (system-name) - buffer-name"

Since the first part is mostly static, and this could keep the buffer
name visually in the same spot in the title bar.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Gregory Heytings via Emacs development discussions.]

>
> Lars Ljung proposed to change frame-title-format to something more 
> modern and similar to Firefox, gvim, Gimp, LibreOffice, etc.: 
> https://debbugs.gnu.org/41147
>

FWIW, on Debian GNU/Linux, this is what some other programs do:

"<title of the page displayed in the current tab> - Mozilla Firefox"

"<title of the page displayed in the current tab> - Google Chrome"

"<file name being played> - VLC media player" (with a playlist with two or more items)

"VLC media player" (with an empty playlist or one with a single file)

"MPlayer"

"<file name> - LibreOffice {Calc|Writer|...}"

"<modification status>[<file name without extension>] <detailed information about the file> - GIMP", where <modification status> is "" or "*"

In short, there is no clear convention.

On macOS, title bars have mostly disappeared, but a few apps still use it, 
for example:

"<file name>" (LibreOffice or TextEdit)

"<buffer name>" (GNU Emacs, the default value for frame-title-format is t)

I would personally vote for something like:

(setq frame-title-format '("%* %b - " (:eval (format "GNU Emacs %d on %s" emacs-major-version system-name))))

Gregory

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 26 Aug 2020 15:09:08 -0700
> 
> The suggestion is to change it to:
> 
>     (setq frame-title-format "%b - GNU Emacs")
> 
> Alternatively, I think one could also reasonably choose:
> 
>     (setq frame-title-format
>           '(multiple-frames "%b"
>                             ("%b - GNU Emacs")))
> 
> I personally think it makes sense to just do what other modern software
> does here, but Eli felt that we need more opinions before making any
> changes.

I'd actually encourage people to think what would be useful to show
there, not necessarily how to follow others' suit.  What does this
addition add to the information displayed on the GUI terminal, and how
will it be useful -- that's the kind of arguments that I hoped to see.

But feel free to ignore me if "doing like others" sounds like a good
enough reason.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Colin Baxter]

Dear Alfred,

>>>>> Alfred M Szmidt <ams@gnu.org> writes:

I am pleased you have raised concerns about the proposed change in the
title-bar. I very much agree with you. 

We already have a functioning title bar, without the need for further
configuring, which gives not useful information but essential
information. I suggest that is the purpose of the tile bar - it is not
to look pretty.

If it's thought that "most users" only use emacs on a single host then
tramp ought to be moved from emacs core and made an optional package!


Colin Baxter
URL: http://www.Colin-Baxter.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Monnier]

>> Regarding the "•" for modified files, I have seen some programs add such
>> a marker (more often "*", IME).  But I checked LibreOffice and it does
>> not do that.  I think it would be useful to check if there are any other
>> text editors that use such a marker.
>
> Yes, asterisk is often used as an unsaved file marker. Mousepad
> (default text editor for XFCE) does display it, and so does GIMP.

And xterm adds a `*** ` in front of its title when output arrived but
the window is iconified (maybe it's a feature I had to enable, can't
remember, but at least the feature exists and uses a `*** ` prefix).


        Stefan

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

ams@gnu.org (Alfred M. Szmidt) writes:

>        alias emacs="emacs --title emacs@`hostname`"
>
> That assumes that you put this alias on every single host you might
> want to ever connect to.

You could just type "emacs --title `hostname`".

>    The question here is what is a reasonable default for most users.
>    I suspect that most users only ever run Emacs on one machine.
>
> My experience says otherwise.

What experience is that?

Best regards,
Stefan Kangas

Re: Modernize frame-title-format: "%b - GNU Emacs"

[tomas]

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

On Thu, Aug 27, 2020 at 10:52:59AM -0400, Stefan Monnier wrote:
> >> Regarding the "•" for modified files, I have seen some programs add such
> >> a marker (more often "*", IME).  But I checked LibreOffice and it does
> >> not do that.  I think it would be useful to check if there are any other
> >> text editors that use such a marker.
> >
> > Yes, asterisk is often used as an unsaved file marker. Mousepad
> > (default text editor for XFCE) does display it, and so does GIMP.
> 
> And xterm adds a `*** ` in front of its title when output arrived but
> the window is iconified (maybe it's a feature I had to enable, can't
> remember, but at least the feature exists and uses a `*** ` prefix).

This sounds a bit like the zIconBeep resource (start option -ziconbeep).
Does it beep also when output arrives?

It is off by default, AFAIK.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

>   "buffer-name - GNU Emacs (system-name)"
> Or maybe:
>   "GNU Emacs (system-name) - buffer-name"
> 
> Since the first part is mostly static, and this could keep
> the buffer name visually in the same spot in the title bar.

Interesting and reasonable reason.

My argument is just the opposite: put specific info
to the left, and more common, less specific info to
the right.

I hate it when some application or website insists
on putting the app/site name at the left of every
browser window, with the real info - about the
specific page or whatever, relegated to the right.

Why? Because narrowing the window, or seeing the
title in a tab, cuts off the pertinent part: the
part that makes a difference.

Good to see different arguments.  Picking a default
behavior is, like other things, about trade-offs.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> > I personally think it makes sense to just do what other modern software
> > does here, but Eli felt that we need more opinions before making any
> > changes.
> 
> I'd actually encourage people to think what would
> be useful to show there, not necessarily how to
> follow others' suit.

100% agreement.

> What does this addition add to the information
> displayed on the GUI terminal, and how will it
> be useful -- that's the kind of arguments that
> I hoped to see.

+1.

[I even object to the Subject line: "Modernize...".
It's fine to raise the question about changing the
default behavior.  Spinning this or that change as
more "modern" is not helpful, IMO, and it slants
the poll question.  (I almost said "ridiculous"
instead of "not helpful", but I expect that someone
will complain.)]

Re: Modernize frame-title-format: "%b - GNU Emacs"

[tomas]

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

On Thu, Aug 27, 2020 at 08:10:03AM -0700, Drew Adams wrote:

[...]

> [I even object to the Subject line: "Modernize...".

This is called "Dark Pattern" and is, in itself, pretty modern these
days :-)

(I'm not implying that the OP is aware of this -- on the contrary).

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Monnier]

>> And xterm adds a `*** ` in front of its title when output arrived but
>> the window is iconified (maybe it's a feature I had to enable, can't
>> remember, but at least the feature exists and uses a `*** ` prefix).
>
> This sounds a bit like the zIconBeep resource (start option -ziconbeep).

Could be.

> Does it beep also when output arrives?

I wouldn't know, because I've been pretty careful to make sure you
computers are generally as silent as possible (tho they're not all
fanless yet, sadly).


        Stefan

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> > [I even object to the Subject line: "Modernize...".
> 
> This is called "Dark Pattern" and is, in itself, pretty modern these
> days :-)

;-)

But the term is recent (if 2010 is recent), not "modern".

> (I'm not implying that the OP is aware of this -- on the contrary).

Yes, in this case, so dark that OP was no doubt
unaware.  Subliminal advertising hits even the
advertiser sometimes. ;-)

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

You're not providing any arguments as to why your suggestion is
better, only trying to suggest that it can be solved differently.

That isn't the point -- you wish to change a sensible default to
something that provides less information to the user for absolutley no
benefit.

As for what my experience, I've used Emacs for over or close too 30
years, where I currently work we have a quite heavy group of Emacs
users and the normal work flow is to connect to many hosts over X11
with one Emacs window for each host.  Should I ask what your
experience is?

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> we have a quite heavy group of Emacs users and the
> normal work flow is to connect to many hosts over X11
> with one Emacs window for each host.

FWIW, I agree that showing the remote host is important.

That fits in with my call for privileging specific info
over general info.  For someone who never connects to
a remote host, the system name is typically general info,
common to all frames.  For someone who connects remotely
it's specific info.

I'd suggest that remote host be shown by default, but
if not remote then the system not be shown by default.
___

A general guide, I think, could be the info that is in
the mode line by default.  That's specific info about a
the current state of what's in the window - the buffer,
whether read-only, the mode, etc.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

   I'd suggest that remote host be shown by default, but
   if not remote then the system not be shown by default.

Is it possible to detect between remote and non-remote?

   A general guide, I think, could be the info that is in
   the mode line by default.  That's specific info about a
   the current state of what's in the window - the buffer,
   whether read-only, the mode, etc.

I think that is a sound general guideline.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[tomas]

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

On Thu, Aug 27, 2020 at 08:24:59AM -0700, Drew Adams wrote:
> > > [I even object to the Subject line: "Modernize...".
> > 
> > This is called "Dark Pattern" and is, in itself, pretty modern these
> > days :-)
> 
> ;-)
> 
> But the term is recent (if 2010 is recent), not "modern".

My language mastery is too humble to dare a choice here.

> > (I'm not implying that the OP is aware of this -- on the contrary).
> 
> Yes, in this case, so dark that OP was no doubt
> unaware.  Subliminal advertising hits even the
> advertiser sometimes. ;-)

Viral, so to speak.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

Yuri Khan <yuri.v.khan@gmail.com> writes:

>> Why do you use en dash?  Does Firefox, etc. use en dash, or is it simply
>> your own local customization?
>
> I do that because that is typographically correct. Other programs use
> a hyphen for historical reasons and if they all nod at each other for
> consistency then we will not have any way forward.

I agree with the typographical point.

But I worry that all fonts won't support en dash.  Could that be the
reason why others avoid it as well?

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Thibaut Verron]

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

Le jeu. 27 août 2020 à 18:02, Alfred M. Szmidt <ams@gnu.org> a écrit :

> Is it possible to detect between remote and non-remote?
>

For buffers associated to files, there is file-remote-p.
For others, stackoverflow suggests using (file-remote-p default-directory).

I don't know how those behave if you use tramp to connect to a server which
then connects to the local host, or whether one using such connections would
not want that information to be as clearly visible as a remote host.

[-- Attachment #2: Type: text/html, Size: 845 bytes --]

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Yuri Khan]

On Thu, 27 Aug 2020 at 23:18, Stefan Kangas <stefan@marxist.se> wrote:

> >> Why do you use en dash?  Does Firefox, etc. use en dash, or is it simply
> >> your own local customization?
> >
> > I do that because that is typographically correct. Other programs use
> > a hyphen for historical reasons and if they all nod at each other for
> > consistency then we will not have any way forward.
>
> I agree with the typographical point.
>
> But I worry that all fonts won't support en dash.  Could that be the
> reason why others avoid it as well?

I include considerations like “my window manager uses a font that does
not have coverage for General Punctuation block” and “I’m running with
a locale that uses an encoding where En Dash is unrepresentable” in
the “historical reasons” bin.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Pip Cet]

On Thu, Aug 27, 2020 at 9:19 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > I personally think it makes sense to just do what other modern software
> > does here, but Eli felt that we need more opinions before making any
> > change

I strongly disagree with that argument, and weakly disagree with the conclusion.

GNU software is very different from most software in that it is not
attentionware: It is provided in the hope that it will be useful.

Other software, apart from some but by no means all of the software
you pay for, is distributed in exchange for human attention.  (In
fact, with so much of it being hosted on Cloudflare servers, you're
expected to "prove that you are human" to even access it.) You can
often configure it not to bombard you with what is essentially
advertising, but it is correctly assumed that most people don't have
the time to do that, and it is not made easy to do so.

We're already exposing users to a lot of "branding": if you type
"emacs" and hit enter, there's the logo, the start-up message, and the
splash screen, to list only those things that are impossible for
normal users to avoid. "Branding" the frame title, even if we know the
name of the file being edited, would certainly be another entry in
that list.

The right fix for this is for Emacs, along with all other
applications, to obey system/session/user policy about how much
"branding" the user wants. By the time a user learns enough about
Emacs to configure the frame title, they'll already have logged many
hours of using it. I propose we make Emacs obey an environment
variable, or whatever mechanism is appropriate, informing us about the
user choice in that matter, and to err distinctly on the side of not
displaying "Emacs" all over the place.

> I'd actually encourage people to think what would be useful to show
> there, not necessarily how to follow others' suit.  What does this
> addition add to the information displayed on the GUI terminal, and how
> will it be useful -- that's the kind of arguments that I hoped to see.

I don't think that question can be answered categorically for all
users. I don't even think it would be acceptable to go with a default
setting if it were easy to customize this, and it's not (M-x customize
RET frame title RET doesn't work). This really is a question that the
user wants to answer once, for all applications, just like they're not
expected to choose a new keyboard layout for each application: how
many unilateral messages containing nothing but a reminder of which
software you're using and who made it do you want to receive?

This really isn't for us to decide, it should be up to the X window
manager or desktop environment, or whatever equivalent Wayland has. In
the absence of a good working mechanism to learn about the user
choice, let's go with an environment variable. I'd certainly welcome
the ability to type "export BRANDING=none" and have GNU software (I
wouldn't expect other software authors to follow suit) respect it.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Thu, 27 Aug 2020 17:06:26 +0000
> Cc: Stefan Kangas <stefan@marxist.se>, emacs-devel@gnu.org
> 
> I don't even think it would be acceptable to go with a default
> setting if it were easy to customize this, and it's not (M-x customize
> RET frame title RET doesn't work).

Though not via Customize, you _can_ customize the title: see the
variable frame-title-format.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

    Is it possible to detect between remote and non-remote?

   For buffers associated to files, there is file-remote-p. 
   For others, stackoverflow suggests using (file-remote-p default-directory).

   I don't know how those behave if you use tramp to connect to a server which 
   then connects to the local host, or whether one using such connections would
   not want that information to be as clearly visible as a remote host.

That assumes running emacs locally, what is being discussed is if you
are running Emacs remotley, i.e. over a remote X11 connection (e.g,
ssh -X).

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Ulrich Mueller]

>>>>> On Thu, 27 Aug 2020, Stefan Kangas wrote:

> Lars Ljung proposed to change frame-title-format to something more
> modern and similar to Firefox, gvim, Gimp, LibreOffice, etc.:
> https://debbugs.gnu.org/41147

> We currently have:

>     (setq frame-title-format
>           '(multiple-frames "%b"
>                             ("" invocation-name "@" system-name)))

> The suggestion is to change it to:

>     (setq frame-title-format "%b - GNU Emacs")

> Alternatively, I think one could also reasonably choose:

>     (setq frame-title-format
>           '(multiple-frames "%b"
>                             ("%b - GNU Emacs")))

> I personally think it makes sense to just do what other modern software
> does here, but Eli felt that we need more opinions before making any
> changes.  So please let us know if you have any thoughts.

One point about %b which I think hasn't been raised yet. When selecting
another window (even if in the same frame), the frame title will change.
In addition, when using a desktop environment's panel (for example,
xfce4-panel) with "window buttons", there will be some visual activity
outside of the Emacs frame as well. Not sure if that could be
distracting.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Colin Baxter]

>>>>> Stefan Kangas <stefan@marxist.se> writes:

    > Yuri Khan <yuri.v.khan@gmail.com> writes:
    >>> Why do you use en dash?  Does Firefox, etc. use en dash, or is
    >>> it simply your own local customization?
    >> 
    >> I do that because that is typographically correct. Other programs
    >> use a hyphen for historical reasons and if they all nod at each
    >> other for consistency then we will not have any way forward.

    > I agree with the typographical point.

    > But I worry that all fonts won't support en dash.  Could that be
    > the reason why others avoid it as well?

I am sorry to be monotonous, but could someone please tell me why
the frame title needs modernising, and the improvements that would be
expected to follow?

I often maintain identically named files for users with the same
login name. The only difference is the host name. This works at present
well by splitting my emacs into several windows. As I move the point
between windows, the title bar tells me which host I'm in. Of course,
there are other ways of getting the same information, but none as
convenient. I'm told I could change my init file to get back the
same effect in the newly proposed frame-title. But why? We already have
the effect.

Best wishes,


-- 
Colin Baxter
URL: http://www.Colin-Baxter.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Robert Pluim]

>>>>> On Thu, 27 Aug 2020 20:11:06 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Pip Cet <pipcet@gmail.com>
    >> Date: Thu, 27 Aug 2020 17:06:26 +0000
    >> Cc: Stefan Kangas <stefan@marxist.se>, emacs-devel@gnu.org
    >> 
    >> I don't even think it would be acceptable to go with a default
    >> setting if it were easy to customize this, and it's not (M-x customize
    >> RET frame title RET doesn't work).

Well, fixing that is a one-liner:

diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index f5b70e082a..9da8bdc93a 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -90,6 +90,7 @@ minibuffer-prompt-properties--setter
 	     ;; buffer.c
 	     (cursor-type display ,cursor-type-types)
 	     (mode-line-format mode-line sexp) ;Hard to do right.
+	     (frame-title-format frames sexp) ;Hard to do right.
 	     (major-mode internal function)
 	     (case-fold-search matching boolean)
 	     (fill-column fill integer)

    Eli> Though not via Customize, you _can_ customize the title: see the
    Eli> variable frame-title-format.

(is there a better custom type than 'sexp here?)

Robert

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

>> we have a quite heavy group of Emacs users and the
>> normal work flow is to connect to many hosts over X11
>> with one Emacs window for each host.
>
> FWIW, I agree that showing the remote host is important.
>
> That fits in with my call for privileging specific info
> over general info.  For someone who never connects to
> a remote host, the system name is typically general info,
> common to all frames.  For someone who connects remotely
> it's specific info.
>
> I'd suggest that remote host be shown by default, but
> if not remote then the system not be shown by default.

There is the package tramp-theme in GNU ELPA. With its default values,
it decorates modelines depending on whether the buffer is remote or not,
it shows the remote hostname, and alike. Other customizations (buffer
colors, fringe colors, etc) are possible. Could be easily extended for
frame titles.

(Advertisement alert: I'm the author of that package.)

Best regards, Michael.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Thibaut Verron]

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

>
> That assumes running emacs locally, what is being discussed is if you
> are running Emacs remotley, i.e. over a remote X11 connection (e.g,
> ssh -X).
>

Oh, sorry, my bad. I'm surprised to discover that it's apparently the remote
application's job to ensure that it has a proper title when run remotely...

For ssh connections at least, I guess that emacs could check if a ssh
variable
such as SSH_CONNECTION is set in the environment. But I'm not sure how
robust it would be.

[-- Attachment #2: Type: text/html, Size: 769 bytes --]

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> One point about %b which I think hasn't been raised yet. When selecting
> another window (even if in the same frame), the frame title will change.
> In addition, when using a desktop environment's panel (for example,
> xfce4-panel) with "window buttons", there will be some visual activity
> outside of the Emacs frame as well. Not sure if that could be
> distracting.

It could be distracting.  Anything decided on
could be noise, or distracting, to some.

What you describe for window-switching could also
be considered a feature, not a problem: the title
tells you the selected window's buffer etc.

Choosing default behavior is always a trade-off.

What's most important is that it be easy for users
to customize the behavior.
___

That's kind of the case, and kind of not the case.
`frame-title-format' is like `mode-line-format':
in the general case it's not so simple to configure.

It would be great if Someone (TM) came up with easy
ways to configure the format.  Yes, I know we have
mode-line variables etc.  But a simple way to get
a fair amount of configuration without being a Lisp
pro would be helpful, IMO.

That said, I wouldn't want to see any of the existing
mode-line config features disappear, just in some
attempt to "dumb things down".  Adding some simple
ways to configure should be a plus, not a replacement.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

>>> I don't even think it would be acceptable to go with a default
>>> setting if it were easy to customize this, and it's not (M-x customize
>>> RET frame title RET doesn't work).
> 
> Well, fixing that is a one-liner:
>     Eli> Though not via Customize, you _can_ customize the title: see the
>     Eli> variable frame-title-format.
> (is there a better custom type than 'sexp here?)

I at first had the same reflex.  But I think it's
probably misguided.  The format in question, which
is that of `mode-line-format', is pretty complex
for Customize.

Certainly, it should _not_ just be :type `sexp'.
If Customize is to be helpful then the :type
should be as specific/accurate as possible,
while still covering all possibilities.

I don't think Customize is the immediate answer
here, at least not by just applying it to vars
such as `mode-line-format' and `frame-title-format'.

Instead, we should come up with some simpler ways
to customize such formats - not just toss these
complex variables over to Customize as is.  (That
would be a mistake, I think.)

I, like others, have provided mode-line features.
(See `modeline-posn.el', `modeline-char.el', and
`modeline-win.el' - on Emacs Wiki.)

But I can't imagine any of what those libraries
offer as being things that most users could do
easily (e.g., via Customize).  And I imagine
that the same thing holds for what others have
done with the mode-line.

I think the ease-of-use needs to be brainstormed.

We should probably come up with a "simple" layer
on top of `mode-line-format'.  Something that at
least lets you do some common, simple things.
Something beyond just the existing mode-line
variables.

I have nothing particular in mind - just the
question and the feeling that something could
be done.  `mode-line-format' is a bear.  It's
great, but not simple.

Just a thought.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

When you use tramp, you're not running Emacs remotely; remotely means
that Emacs is run/executed on a different host (e.g., X11 forwarding)
not that you access buffers on a different remote host.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> There is the package tramp-theme in GNU ELPA. With its default values,
> it decorates modelines depending on whether the buffer is remote or not,
> it shows the remote hostname, and alike. Other customizations (buffer
> colors, fringe colors, etc) are possible. Could be easily extended for
> frame titles.
> 
> (Advertisement alert: I'm the author of that package.)

Sounds great.  Would it work to move some of that
to the default behavior?  Does it do nothing (i.e.,
not interfere) when you don't have Tramp buffers?

If so, let's really consider that.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> When you use tramp, you're not running Emacs remotely; remotely means
> that Emacs is run/executed on a different host (e.g., X11 forwarding)
> not that you access buffers on a different remote host.

True.  But I in fact was thinking of the other case:
locally running Emacs accessing remote resources
(files).  We can at least handle that use case well.

If we can _also_ somehow handle the case you're
talking about, so much the better.
___

(I wouldn't consider that your case is the only one
where the word "remote" applies.  You're talking
about a remote Emacs session.  Others are talking
about a local session accessing remote resources.
Both involve "remote".)

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

    That assumes running emacs locally, what is being discussed is if you
    are running Emacs remotley, i.e. over a remote X11 connection (e.g,
    ssh -X).

   Oh, sorry, my bad. I'm surprised to discover that it's apparently the remote
   application's job to ensure that it has a proper title when run remotely... 

Not sure how it could work other wise, who would be setting the title
if not the program it self?  If it is remote or not isn't really
important here.

   For ssh connections at least, I guess that emacs could check if a ssh variable
   such as SSH_CONNECTION is set in the environment. But I'm not sure how
   robust it would be.

That would only work for SSH I think e.g., does GNU lsh set
SSH_CONNECTION?  What about telnet and Kerberos?  Are there other
ways, or protocols to do X11 forwarding?

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

   > When you use tramp, you're not running Emacs remotely; remotely means
   > that Emacs is run/executed on a different host (e.g., X11 forwarding)
   > not that you access buffers on a different remote host.

   True.  But I in fact was thinking of the other case:
   locally running Emacs accessing remote resources
   (files).  We can at least handle that use case well.

   If we can _also_ somehow handle the case you're
   talking about, so much the better.

INCF, but should that then also show if e.g., you are accessing a file
using sudo/su/...?  What if you do multi-hop using tramp?

It might quickly become quite alot of information in the title, that
we don't even show in the mode-line today.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Michael Albinus]

ams@gnu.org (Alfred M. Szmidt) writes:

Hi Alfred,

> When you use tramp, you're not running Emacs remotely; remotely means
> that Emacs is run/executed on a different host (e.g., X11 forwarding)
> not that you access buffers on a different remote host.

In that case, you don't need tramp-theme. I was rather replying to Drew,
who wanted an indication for remote buffers or frames with remote buffers.

Best regards, Michael.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

>> There is the package tramp-theme in GNU ELPA. With its default values,
>> it decorates modelines depending on whether the buffer is remote or not,
>> it shows the remote hostname, and alike. Other customizations (buffer
>> colors, fringe colors, etc) are possible. Could be easily extended for
>> frame titles.
>>
>> (Advertisement alert: I'm the author of that package.)
>
> Sounds great.  Would it work to move some of that
> to the default behavior?

Don't know. In order to avoid this discussion, I've created an ELPA
package :-)

> Does it do nothing (i.e., not interfere) when you don't have Tramp
> buffers?

Yes. In fact, although it's name is tramp-theme, it even doesn't know
about the Tramp library :-) IOW, it doesn't (require 'tramp)

> If so, let's really consider that.

Best regards, Michael.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Michael Albinus]

ams@gnu.org (Alfred M. Szmidt) writes:

>    > When you use tramp, you're not running Emacs remotely; remotely means
>    > that Emacs is run/executed on a different host (e.g., X11 forwarding)
>    > not that you access buffers on a different remote host.
>
>    True.  But I in fact was thinking of the other case:
>    locally running Emacs accessing remote resources
>    (files).  We can at least handle that use case well.
>
>    If we can _also_ somehow handle the case you're
>    talking about, so much the better.
>
> INCF, but should that then also show if e.g., you are accessing a file
> using sudo/su/...?

tramp-theme shows that. If you're paranoid, you could even get a red
fringe in case the user name of current-buffer is "root", as
alert. Configurable.

> What if you do multi-hop using tramp?

tramp-theme shows you just the last hop (at least it should, not tested
ATM). This is what counts.

> It might quickly become quite alot of information in the title, that
> we don't even show in the mode-line today.

That's why I'm also in favor of making it optional and configurable.

Best regards, Michael.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

>    True.  But I in fact was thinking of the other case:
>    locally running Emacs accessing remote resources
>    (files).  We can at least handle that use case well.
> 
>    If we can _also_ somehow handle the case you're
>    talking about, so much the better.
> 
> INCF, but should that then also show if e.g., you are accessing a file
> using sudo/su/...?  What if you do multi-hop using tramp?
> 
> It might quickly become quite alot of information in the title, that
> we don't even show in the mode-line today.

Right, it's a trade-off.  All choices of default
behavior are trade-offs.

The question is: Which specific info is most
important to show in the frame title, for most users,
most of the time?

In general, I think that the info in the `mode-line'
is also good for the frame title.

Not that we would necessarily show all such info,
or show it in the same way (e.g. same left-to-right
order).  But such info is generally important and
serves to identify what the frame is about (the
current state of its content).

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

> The question is: Which specific info is most
> important to show in the frame title, for most users,
> most of the time?
>
> In general, I think that the info in the `mode-line'
> is also good for the frame title.
>
> Not that we would necessarily show all such info,
> or show it in the same way (e.g. same left-to-right
> order).  But such info is generally important and
> serves to identify what the frame is about (the
> current state of its content).

The modeline is for the buffer it belongs to. The frame title shall show
more general information. This could be the host name the current buffer
is remote on, but not more.

And it might change, if you're switching between buffers. There isn't
such a thing like "the" remote host Emacs is connected to via Tramp.

Best regards, Michael.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Thibaut Verron]

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

>
>     That assumes running emacs locally, what is being discussed is if you
>     are running Emacs remotley, i.e. over a remote X11 connection (e.g,
>     ssh -X).
>
>    Oh, sorry, my bad. I'm surprised to discover that it's apparently the
> remote
>    application's job to ensure that it has a proper title when run
> remotely...
>
> Not sure how it could work other wise, who would be setting the title
> if not the program it self?  If it is remote or not isn't really
> important here.
>

I'd assume that the program could give a frame name regardless, and someone
on the local host (maybe ssh?) would use it to make a valid window name on
the
local host, e.g. transform "title" into "title on host".

But I'm obviously not very familiar with how display servers work, so I
trust that if it
works this way, then there is good reason for it.


>
>    For ssh connections at least, I guess that emacs could check if a ssh
> variable
>    such as SSH_CONNECTION is set in the environment. But I'm not sure how
>    robust it would be.
>
> That would only work for SSH I think e.g., does GNU lsh set
> SSH_CONNECTION?  What about telnet and Kerberos?  Are there other
> ways, or protocols to do X11 forwarding?
>

I'd expect that most other protocols would be identifiable through such a
setting,
and that emacs would have to loop through all known such tests.

As a bonus, it would also allow to make titles like "title on host [ssh]".

[-- Attachment #2: Type: text/html, Size: 2063 bytes --]

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Yuri Khan]

On Fri, 28 Aug 2020 at 02:13, Thibaut Verron <thibaut.verron@gmail.com> wrote:

> I'd assume that the program could give a frame name regardless, and someone
> on the local host (maybe ssh?) would use it to make a valid window name on the
> local host, e.g. transform "title" into "title on host".

That would make much more sense than each application having to
include the hostname in its title. As a bonus, you’d get “Emacs on
remote on hop2 on hop1” if you were adventurous enough to tunnel X11
over a multi-hop connection.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> > The question is: Which specific info is most
> > important to show in the frame title, for most
> > users, most of the time?
> >
> > In general, I think that the info in the `mode-line'
> > is also good for the frame title.
> >
> > Not that we would necessarily show all such info,
> > or show it in the same way (e.g. same left-to-right
> > order).  But such info is generally important and
> > serves to identify what the frame is about (the
> > current state of its content).
> 
> The modeline is for the buffer it belongs to. The frame title shall show
> more general information. This could be the host name the current buffer
> is remote on, but not more.

Why not more?  We already show the buffer name in the
frame title.  That's more than just the host name.

> And it might change, if you're switching between buffers. 

That can be viewed as a plus, not a minus.  The frame
title tells you what you're currently doing/using.

And that's what we already do by default: the name
of the buffer of the selected frame is in the frame
title, by default, when you have more than one frame.

> There isn't such a thing like "the" remote host
> Emacs is connected to via Tramp.

Right.  And?  A given frame would tell you which
remote host was used for the buffer in the selected
window, if that info's included in the frame title.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Wayne Harris via Emacs development discussions.]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Thu, 27 Aug 2020 at 12:55, Stefan Kangas <stefan@marxist.se> wrote:
>>
>> >>     (setq frame-title-format "%b - GNU Emacs")
>> >
>> > I do that in my config, except that I use an en dash as the separator:
>> > "%b – Emacs"; and I also display a • if the buffer is modified and
>> > visiting a file.
>>
>> Why do you use en dash?  Does Firefox, etc. use en dash, or is it simply
>> your own local customization?
>
> I do that because that is typographically correct. 

IMHO and FWIW, two thumbs up for typographically correct.  However, I
think `` – Emacs'' is kind of useless.  I like useful information.  The
name of the buffer is definitely useful and, guess what, the name of the
machine too.  The directory where the buffer would be written to could
be an interesting addition --- as a right-side-filling.

When I want to know to which directory a buffer would be written, I say
C-x C-w to discover.  Then I C-g and continue my work.  For some reason
it's not a very rare operation that I do.  When I look at my frames I
see a lot of space on the right side.  But seeing ``– Emacs'' would
definitely make wish I knew I had memorized the name frame-title-format.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[James Cloos]

>>>>> "SK" == Stefan Kangas <stefan@marxist.se> writes:

SK> The question here is what is a reasonable default for most users.
SK> I suspect that most users only ever run Emacs on one machine.

the icon that the wm outs before the text already shows that it is
gnu emacs.

more words just make things longer.

and losing the invocation-name@system-name bit would be a significant
regression.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Yuri Khan]

On Fri, 28 Aug 2020 at 07:18, Wayne Harris via Emacs development
discussions. <emacs-devel@gnu.org> wrote:

> However, I
> think `` – Emacs'' is kind of useless.  I like useful information.

The name of the application in the title is useful. It helps you pick
the Emacs window out of multiple applications operating on the same
file. For example, a Dired buffer showing a directory and Thunar
showing the same directory.

This is important in contexts where the window contents are not
visible, e.g. a taskbar showing minimized windows, or a
tiling/tabbing/stacking window manager such as i3 showing a single
window in the stack and the titles of all other windows in the same
stack.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Yuri Khan]

On Fri, 28 Aug 2020 at 08:05, James Cloos <cloos@jhcloos.com> wrote:

> the icon that the wm outs before the text already shows that it is
> gnu emacs.

Not all wms display an icon. Also, I’m not sure if screen readers for
visually impaired users do anything useful with the icon; in contrast,
I’m pretty sure the application name in the title will get read.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Ulrich Mueller]

>>>>> On Fri, 28 Aug 2020, Yuri Khan wrote:

>> However, I
>> think `` – Emacs'' is kind of useless.  I like useful information.

> The name of the application in the title is useful. It helps you pick
> the Emacs window out of multiple applications operating on the same
> file. For example, a Dired buffer showing a directory and Thunar
> showing the same directory.

> This is important in contexts where the window contents are not
> visible, e.g. a taskbar showing minimized windows, or a
> tiling/tabbing/stacking window manager such as i3 showing a single
> window in the stack and the titles of all other windows in the same
> stack.

An early historic data point: Emacs 18.59 used to display
"emacs: Emacs @ <hostname>" in the window title (and yes, they called
it "window" rather than "frame" at the time).

Maybe one should find out what led to the decision to change that?
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

James Cloos <cloos@jhcloos.com> writes:

> and losing the invocation-name@system-name bit would be a significant
> regression.

You are the first person to say that `invocation-name' is important to
keep.  Would like to expand on the use-case you have in mind, and why
you think it is important to keep as the default?

Best regards,
Stefan Kangas

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

   > and losing the invocation-name@system-name bit would be a significant
   > regression.

   You are the first person to say that `invocation-name' is important to
   keep.  Would like to expand on the use-case you have in mind, and why
   you think it is important to keep as the default?

I can think of one situation, when running multiple emacs:en of
different version.  E.g, development versions or when you wish to run
an older or newer version.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> > However, I think `` – Emacs'' is kind of useless.
> > I like useful information.
> 
> The name of the application in the title is useful. It helps you pick
> the Emacs window out of multiple applications operating on the same
> file. For example, a Dired buffer showing a directory and Thunar
> showing the same directory.
> 
> This is important in contexts where the window contents are not
> visible, e.g. a taskbar showing minimized windows, or a
> tiling/tabbing/stacking window manager such as i3 showing a single
> window in the stack and the titles of all other windows in the same
> stack.

The discussion is about the _default_ frame title.
Users can define their own title formatting.

How common is the use of multiple applications
(in separate window-mgr windows) for the same
file or directory (or other argument)?

(Not a rhetorical question - that's never been my
experience.)

Wrt your examples of a file or dir, showing the
buffer name should be even more specific, and
even better distinguish from some other app
window for the same file or dir, no?  Especially
if the other app puts its app name first in the
title.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> > the icon that the wm outs before the text already shows that it is
> > gnu emacs.
> 
> Not all wms display an icon. Also, I’m not sure if screen readers for
> visually impaired users do anything useful with the icon; in contrast,
> I’m pretty sure the application name in the title will get read.

Those are two good points, neither of which occurred to me.

But I would expect those to be minority cases.  (I could
be wrong, especially about the icon case.)

The discussion is about the _default_ formatting.
Users can configure frame-title formatting as they like.

Perhaps Emacs could either (1) automatically check for
the app icon, and do something to mitigate its absence,
or (2) make it especially easy for users to do so (e.g.
by providing an alist variable with keys being
`system-type' symbols.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

>    You are the first person to say that `invocation-name' is important to
>    keep.  Would like to expand on the use-case you have in mind, and why
>    you think it is important to keep as the default?
> 
> I can think of one situation, when running multiple emacs:en of
> different version.  E.g, development versions or when you wish to run
> an older or newer version.

1. `invocation-name' doesn't tell you anything about
the Emacs version, AFAICT.

2. As Eli would presumably point out [*], users who
have installed multiple Emacs versions are uncommon,
and those of them who run more than one version at
the same time are even more uncommon.  (I'm one of
them, FWIW.)

3. The discussion is about defining the _default_
frame-title format.  Users can define the format
any way they want.  The default should work well
for most users most of the time in most contexts.

_____

[*]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42993#8

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Colin Baxter]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

    > The discussion is about the _default_ formatting.  Users can
    > configure frame-title formatting as they like.

This is exactly my point. Those  who want to "modernise" the frame
title can format as they like. Why do others who want the format to
remain as it is have to be the ones who do the work?  

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Tassilo Horn]

James Cloos <cloos@jhcloos.com> writes:

> SK> The question here is what is a reasonable default for most users.
> SK> I suspect that most users only ever run Emacs on one machine.
>
> the icon that the wm outs before the text already shows that it is gnu
> emacs.

There are tools for switching windows (frames) using keyboard input!
Even with stock GNOME, I'm accustomed to type "<Super> em <RET>" to get
emacs into the focus.

Bye,
Tassilo

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Yuri Khan]

On Sat, 29 Aug 2020 at 02:03, Drew Adams <drew.adams@oracle.com> wrote:

> > The name of the application in the title is useful. It helps you pick
> > the Emacs window out of multiple applications operating on the same
> > file. For example, a Dired buffer showing a directory and Thunar
> > showing the same directory.
> >
> > This is important in contexts where the window contents are not
> > visible, e.g. a taskbar showing minimized windows, or a
> > tiling/tabbing/stacking window manager such as i3 showing a single
> > window in the stack and the titles of all other windows in the same
> > stack.
>
> The discussion is about the _default_ frame title.
> Users can define their own title formatting.

Users should not have to customize the title for the common case.
Which I believe to be multiple applications on the desktop.

> How common is the use of multiple applications
> (in separate window-mgr windows) for the same
> file or directory (or other argument)?
>
> (Not a rhetorical question - that's never been my
> experience.)
>
> Wrt your examples of a file or dir, showing the
> buffer name should be even more specific, and
> even better distinguish from some other app
> window for the same file or dir, no?  Especially
> if the other app puts its app name first in the
> title.

All well-behaved applications in many desktops (Windows, XFCE, GNOME,
KDE) show the document name and their own application name in the
title bar. It’s a convention, and it’s useful because this way
application authors do not have to consider whether a document name
alone is enough for the user to distinguish the window. Somebody has
already thought this through and decided that both components are
useful.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

>> The discussion is about the _default_ formatting.  Users can
>> configure frame-title formatting as they like.
> 
> This is exactly my point. Those  who want to "modernise" the frame
> title can format as they like. Why do others who want the format to
> remain as it is have to be the ones who do the work?

You won't get a strong argument about that from me.

I do think we could probably come up with a more
useful default value.  I'm not sure the current one
is most helpful for most people most of the time.

But I take your point.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> > > The name of the application in the title is useful. It helps you pick
> > > the Emacs window out of multiple applications operating on the same
> > > file. For example, a Dired buffer showing a directory and Thunar
> > > showing the same directory.
> > >
> > > This is important in contexts where the window contents are not
> > > visible, e.g. a taskbar showing minimized windows, or a
> > > tiling/tabbing/stacking window manager such as i3 showing a single
> > > window in the stack and the titles of all other windows in the same
> > > stack.
> >
> > The discussion is about the _default_ frame title.
> > Users can define their own title formatting.
> 
> Users should not have to customize the title for the common case.

100% agreement.

> Which I believe to be multiple applications on the desktop.

Sure.  But see below (you quoted, but didn't address).
Even if someone agrees that the app name should be
present, should it really be leftmost?  And how often
is the app name really helpful?

> > How common is the use of multiple applications
> > (in separate window-mgr windows) for the same
> > file or directory (or other argument)?

? How often, for the same file?  If you see only the
file or dir name, is it hard to know that the app is
Emacs?  Most of the time?

> > (Not a rhetorical question - that's never been my
> > experience.)
> >
> > Wrt your examples of a file or dir, showing the
> > buffer name should be even more specific, and
> > even better distinguish from some other app
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > window for the same file or dir, no?  Especially
> > if the other app puts its app name first in the
> > title.
> 
> All well-behaved applications in many desktops (Windows, XFCE, GNOME,
> KDE) show the document name and their own application name in the
> title bar.

I haven't argued that the app name shouldn't be included.
(But see the discussion about whether the app icon might
sometimes suffice.)

I argued to put the more specific info first, i.e.,
leftmost.  The app name is less specific than the file
name etc.

Imagine if every one of your browser windows had "Google
Chrome" or "Firefox" or "Internet Explorer" or "Brave"
as its leftmost text.  Imagine how useful/useless that
would be for picking a window out of a task-bar list,
a set of tabs, or any other list.  Imagine if every
mail-client window had the client name at the far left:
"Outlook" or whatever.

And in fact, at least in my environment (MS Windows),
it is NOT the case that "all well-behaved apps show...
the app name in the title bar".  Not if web browsers and
mail clients (and lots more) count as well-behaved, at
least.

The app name is totally missing from such window-mgr
windows.  And thank goodness, as that's the least
interesting info to show, especially when the full info
might get truncated (which happens for tabs etc.).

I do pick out an app by its icon.  I don't know, but
I'm guessing, that someone with specific accessibility
needs has an alternative for this, other than a
requirement that the app names appear as text.

What I see in the title bar for a Chrome or Brave or
Firefox or IE browser is this, from the left:

1. A site icon.  E.g. fancy "T" for New York Times site.
2. A page title, possibly with a subtitle.  E.g.
   "Opinion | Kenosha Tells Us More About Where the Right
    Is Headed Than the R.N.C. Did".

That means I can easily pick out that web page by its
app icon and page title.  Would you really prefer that
the frame title be something like this?

"Google Chrome <NYT icon> Opinion | Kenosha Tells Us More
About Where the Right Is Headed Than the R.N.C. Did"

Maybe I'm just misunderstanding you.  I hope so.

> It’s a convention, 

Maybe some places, i.e., for some apps.  I don't see
it for most apps, including web browsers and mail
client, on MS Windows.  (And you did mention "Windows.)

I do see it for some apps, but typically for apps that
have only one window.

> and it’s useful because this way
> application authors do not have to consider whether a document name
> alone is enough for the user to distinguish the window. Somebody has
> already thought this through and decided that both components are
> useful.

I take your point.  I don't consider it to override
all other considerations, but I guess it's one thing
to consider when rethinking what the default behavior
might be.  I'm glad you brought it up.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Thibaut Verron]

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

>
> Sure.  But see below (you quoted, but didn't address).
> Even if someone agrees that the app name should be
> present, should it really be leftmost?  And how often
> is the app name really helpful?
>

For what it's worth, I usually don't have the same document or directory
opened
in different apps, but when switching apps I'm looking for a software, not
for a
document. Especially in the case of Emacs, regardless of whether my current
file
is main.tex or program.py, the place to go to for edition is Emacs and
that's what I
look for in the window switcher.

The buffer name is only useful whenever I have two emacs frames on the same
workspace.

And I guess I always felt a bit annoyed when switching to Emacs window,
without
being able to pin-point exactly why... but now I suspect that it is because
the default
frame name does not make it as easy to identify emacs as other software.

[-- Attachment #2: Type: text/html, Size: 1251 bytes --]

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> when switching apps I'm looking for a software, not for a 
> document. Especially in the case of Emacs...

I take it that in this context you mean that, for you,
switching apps amounts to switching window-mgr windows.

In general, an app can have more than one window.  I
mentioned a web browser (an app), for example, which can
have multiple windows and multiple tabs in a window.

> The buffer name is only useful whenever I have two emacs
> frames on the same workspace. ...
>
> the default frame name does not make it as easy to identify
> emacs as other software.

Fair enough.

When you window-switch, does the method you use to do that
show you app _icons_?  If so, and assuming you can
distinguish the icons OK, is that less helpful than having
text that says "Emacs"?

E.g., to switch windows do you use completion perhaps, so
you need to actually type part of the app name: `e TAB' or
some such?

Obviously, different users work differently and do different
things.  Maybe there is not one reasonable default frame
config for all.

Maybe a small set of such configs would make sense, letting
users at least choose among them (as opposed to digging into
detail to configure `frame-title-format', which users can of
course always do).  But then we'd have to choose which of
that small number of choices should be the overall default. ;-)

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

Just as something to try out, here's a slightly simplified
`mode-line-format' value.  I'm not proposing anything; just
tossing this out as food for thought.

(defcustom frame-title-app-name-show-Emacs nil
  "Non-nil means put `Emacs' at the beginning of the frame title."
  :type 'boolean :group 'frames)

(setq frame-title-format
      '(multiple-frames 
        ("%e"
	   (frame-title-app-name-show-Emacs "Emacs" "")
         mode-line-front-space 
         mode-line-client
         mode-line-modified
         mode-line-remote
         mode-line-frame-identification
         mode-line-buffer-identification
         " "
         mode-line-modes
         (which-function-mode ("" which-func-format "  "))
         global-mode-string)
        "%b"))

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Gregory Heytings via Emacs development discussions.]

This thread is perhaps already too long, but here are two proposals:

Proposal 1:

"~/.emacs - GNU Emacs 27 on foobar" (unmodified buffer)
"~/.emacs * GNU Emacs 27 on foobar" (modified buffer)

(setq frame-title-format
   '((:eval (if buffer-file-truename buffer-file-truename "%b"))
   " %& "
   (:eval (format "GNU Emacs %d on %s" emacs-major-version system-name))))

Proposal 2:

"~/.emacs - ELisp/d - GNU Emacs 27 on foobar" (unmodified buffer)
"~/.emacs * ELisp/d * GNU Emacs 27 on foobar" (modified buffer)

(setq frame-title-format
   '((:eval (if buffer-file-truename buffer-file-truename "%b"))
   " %& " mode-name " %& "
   (:eval (format "GNU Emacs %d on %s" emacs-major-version system-name))))

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

Gregory Heytings via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> This thread is perhaps already too long, but here are two proposals:
>
> Proposal 1:
>
> "~/.emacs - GNU Emacs 27 on foobar" (unmodified buffer)
> "~/.emacs * GNU Emacs 27 on foobar" (modified buffer)
>
> (setq frame-title-format
>    '((:eval (if buffer-file-truename buffer-file-truename "%b"))
>    " %& "
>    (:eval (format "GNU Emacs %d on %s" emacs-major-version system-name))))
>
> Proposal 2:
>
> "~/.emacs - ELisp/d - GNU Emacs 27 on foobar" (unmodified buffer)
> "~/.emacs * ELisp/d * GNU Emacs 27 on foobar" (modified buffer)
>
> (setq frame-title-format
>    '((:eval (if buffer-file-truename buffer-file-truename "%b"))
>    " %& " mode-name " %& "
>    (:eval (format "GNU Emacs %d on %s" emacs-major-version system-name))))

Thank you, this is useful.  I would like to retract my original proposal
in favor of your "Proposal 1", with or without a marker.

To sum up the thread so far, people have clearly been unhappy with the
idea to remove the host name.  I think we should listen.

There has also been discussions about proposals to add even more
information, which I have followed closely.  I think some of the ideas
have been interesting, but ultimately risks being a bit too opinionated
and/or verbose to be suitable for the default case.

Best regards,
Stefan Kangas

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Yuri Khan]

On Sat, 29 Aug 2020 at 03:36, Drew Adams <drew.adams@oracle.com> wrote:

> Sure.  But see below (you quoted, but didn't address).
> Even if someone agrees that the app name should be
> present, should it really be leftmost?

Not leftmost but righmost, by convention and by your own argument that
the most specific information should stay when the title is truncated.

> And how often
> is the app name really helpful?

This is a trick question. You’re challenging the convention here,
asking me to find an excuse to not follow it.

> > > How common is the use of multiple applications
> > > (in separate window-mgr windows) for the same
> > > file or directory (or other argument)?
>
> ? How often, for the same file?  If you see only the
> file or dir name, is it hard to know that the app is
> Emacs?  Most of the time?

I might have a Dired for the root directory of an application project
open in Emacs, and the actual application running in a second window.
Both will have the same title in your proposed scheme.

I might be editing an HTML file in Emacs and previewing it in Firefox,
and it might not have a <title> yet. You want me to look at titles and
mentally say “This one is ‘index.html - Mozilla Firefox’, so that one
‘index.html’ must be Emacs”?

Lastly, I invoke the “What If Two Applications Did This” Raymond Chen’s razor.

> I argued to put the more specific info first, i.e.,
> leftmost.  The app name is less specific than the file
> name etc.

The convention already does this.

> Imagine if every one of your browser windows had "Google
> Chrome" or "Firefox" or "Internet Explorer" or "Brave"
> as its leftmost text.  Imagine how useful/useless that
> would be for picking a window out of a task-bar list,
> a set of tabs, or any other list.  Imagine if every
> mail-client window had the client name at the far left:
> "Outlook" or whatever.

I don’t need to imagine it, I *remember* it. This is how Windows
worked before 95. (Except none of Chrome, Firefox, IE, Brave, Outlook,
taskbar, or tabs existed back then, so let’s substitute Word and File
Manager and, for the sake of argument, cascaded window titles.)

> What I see in the title bar for a Chrome or Brave or
> Firefox or IE browser is this, from the left:
>
> 1. A site icon.  E.g. fancy "T" for New York Times site.
> 2. A page title, possibly with a subtitle.  E.g.
>    "Opinion | Kenosha Tells Us More About Where the Right
>     Is Headed Than the R.N.C. Did".
>
> That means I can easily pick out that web page by its
> app icon and page title.  Would you really prefer that
> the frame title be something like this?
>
> "Google Chrome <NYT icon> Opinion | Kenosha Tells Us More
> About Where the Right Is Headed Than the R.N.C. Did"
>
> Maybe I'm just misunderstanding you.  I hope so.

Yes you are. Ideally:

<Chrome icon> Kenosha Tells Us More
About Where the Right Is Headed Than the R.N.C. Did | Opinion – Google Chrome

possibly abbreviated to:

<Chrome icon> Kenosha Tells…

(The web site icon totally does not belong in a browser title bar,
because then a web site could impersonate a locally installed
application, at least until the user activates the window and sees the
address bar.)

>> It’s a convention,

> Maybe some places, i.e., for some apps.  I don't see
> it for most apps, including web browsers and mail
> client, on MS Windows.  (And you did mention "Windows.)

I do not know which browsers and mail clients you use but Firefox and
Thunderbird do append “- Mozilla Firefox” and “- Thunderbird” to every
title, at least for me on GNU/Linux, and I remember it being that way
back when I was using Windows.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> > Sure.  But see below (you quoted, but didn't address).
> > Even if someone agrees that the app name should be
> > present, should it really be leftmost?
> 
> Not leftmost but righmost, by convention and by your own argument that
> the most specific information should stay when the title is truncated.

Thanks; I misunderstood you.  I have no problem
with appending that (or anything else).  I thought
you were suggesting prepending, as if that were the
most important info to see.

> > And how often is the app name really helpful?
> 
> This is a trick question. You’re challenging the convention here,
> asking me to find an excuse to not follow it.

It wasn't meant as a trick question.

Where is this convention defined?  Is it a real
"thing" - some standard or something, or is it
just that you've noticed that many apps use such
naming?  I'm not challenging you; just curious
about this.

> > > > How common is the use of multiple applications
> > > > (in separate window-mgr windows) for the same
> > > > file or directory (or other argument)?
> >
> > ? How often, for the same file?  If you see only the
> > file or dir name, is it hard to know that the app is
> > Emacs?  Most of the time?
> 
> I might have a Dired for the root directory of an application project
> open in Emacs, and the actual application running in a second window.
> Both will have the same title in your proposed scheme.
> 
> I might be editing an HTML file in Emacs and previewing it in Firefox,
> and it might not have a <title> yet. You want me to look at titles and
> mentally say “This one is ‘index.html - Mozilla Firefox’, so that one
> ‘index.html’ must be Emacs”?

OK.  If I were in your shoes in that context I'd
configure my frame titles to fit such use cases.
I don't see that as important for the default
case.  But I may well be mistaken wrt how common
your case is.

> > I argued to put the more specific info first, i.e.,
> > leftmost.  The app name is less specific than the file
> > name etc.
> 
> The convention already does this.

Good.  So we're in agreement about the only thing
I've really argued for.

> > Imagine if every one of your browser windows had "Google
> > Chrome" or "Firefox" or "Internet Explorer" or "Brave"
> > as its leftmost text.  Imagine how useful/useless that
> > would be for picking a window out of a task-bar list,
> > a set of tabs, or any other list.  Imagine if every
> > mail-client window had the client name at the far left:
> > "Outlook" or whatever.
> 
> I don’t need to imagine it, I *remember* it.

(Me too.  And I still see it here and there.  And
I don't like it.)

> > What I see in the title bar for a Chrome or Brave or
> > Firefox or IE browser is this, from the left:
> >
> > 1. A site icon.  E.g. fancy "T" for New York Times site.
> > 2. A page title, possibly with a subtitle.  E.g.
> >    "Opinion | Kenosha Tells Us More About Where the Right
> >     Is Headed Than the R.N.C. Did".
> >
> > That means I can easily pick out that web page by its
> > app icon and page title.  Would you really prefer that
> > the frame title be something like this?
> >
> > "Google Chrome <NYT icon> Opinion | Kenosha Tells Us More
> > About Where the Right Is Headed Than the R.N.C. Did"
> >
> > Maybe I'm just misunderstanding you.  I hope so.
> 
> Yes you are. Ideally:
> <Chrome icon> Kenosha Tells Us More
> About Where the Right Is Headed Than the R.N.C. Did | Opinion – Google Chrome
> 
> possibly abbreviated to:
> <Chrome icon> Kenosha Tells…
> 
> (The web site icon totally does not belong in a browser title bar,
> because then a web site could impersonate a locally installed
> application, at least until the user activates the window and sees the
> address bar.)

We'll have to disagree about that last part, I guess.

> >> It’s a convention,
> 
> > Maybe some places, i.e., for some apps.  I don't see
> > it for most apps, including web browsers and mail
> > client, on MS Windows.  (And you did mention "Windows.)
> 
> I do not know which browsers and mail clients you use but Firefox and
> Thunderbird do append “- Mozilla Firefox” and “- Thunderbird” to every
> title, at least for me on GNU/Linux, and I remember it being that way
> back when I was using Windows.

On Windows I don't see it in Firefox, Google Chrome,
IE, or Brave (chromium).

But I guess I'm not really seeing a frame (wm window)
title.  As those browsers all use tabs, it's the tab
title I guess I've been talking about, for a browser.
I don't see a separate window title.  And googling
for that suggests that you need to fiddle or use an
add-on to implement or fake a window title.  (Is that
correct?  It's my impression, so far.)

Interestingly, for Chrome, I see this when I mouseover
a tab:

 "The New York Times - Breaking News, World News &
 Multimedia"

 followed by the site URL: "nytimes.com"

Similarly, for other sites.  IOW, the (closest
equivalent I can find to a) window title includes
lots of info: page title plus the site URL.

(I don't see the site URL for Brave or Firefox.)

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Thibaut Verron]

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

>
> On Windows I don't see it in Firefox, Google Chrome,
> IE, or Brave (chromium).
>

Interesting.

Here, with Chrome on Windows 10, if I visit a website with a short title
and I press Alt-Tab or Win-Tab, the window title is

> Page title - Google Chrome

With Edge, it is

> Page title - Personnel [French for personal, no idea why] - Mic...[which
I suspect ends with ...rosoft Edge]

[-- Attachment #2: Type: text/html, Size: 738 bytes --]

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Yuri Khan]

On Sat, 29 Aug 2020 at 23:37, Drew Adams <drew.adams@oracle.com> wrote:

> Where is this convention defined?  Is it a real
> "thing" - some standard or something, or is it
> just that you've noticed that many apps use such
> naming?  I'm not challenging you; just curious
> about this.

Now that I started looking, it seems that only Windows actively
recommends putting the application name in the window title.


Windows:

https://docs.microsoft.com/en-us/windows/win32/uxguide/text-ui

| Choose the title bar text based on the type of window:
|
| *Top-level, document-centric program windows:*
| Use a "document name program name" format.
| Document names are displayed first to give a document-centric feel.


GNOME 2:

https://developer.gnome.org/hig-book/unstable/windows-properties.html.en

| Use Filename as the window title for document-based applications.
| Do not use the full pathname,
| as the filename alone is easier to distinguish
| amongst other open window titles,
| for example on the window list.
|
| When a document has pending changes,
| insert an asterisk (*) at the beginning of the window title.
| For example, *Unsaved Drawing, *AnnualReport.
|
| While document names are most pertinent to users,
| we understand that application developers may want
| to increase recognition of their application.
| If you plan to include your application's name
| in the title of a primary window,
| use the following format: Document Name - Application Name.
| This will ensure
| that the document name appears in limited space situations
| such as the system window list.
|
| Including the application name
| in the title of a document-based application is not recommended.


GNOME 3 HIG is still not fleshed out enough to talk about window titles.


macOS:

https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/window-anatomy/

| Most title bars display the filename,
| although this isn’t always the case.
:
| For document windows,
| the title is the name of the document
| or Untitled (for new documents).


> > I do not know which browsers and mail clients you use but Firefox and> > Thunderbird do append “- Mozilla Firefox” and “- Thunderbird” to every
> > title, at least for me on GNU/Linux, and I remember it being that way
> > back when I was using Windows.
>
> On Windows I don't see it in Firefox, Google Chrome,
> IE, or Brave (chromium).
>
> But I guess I'm not really seeing a frame (wm window)
> title.  As those browsers all use tabs, it's the tab
> title I guess I've been talking about, for a browser.
> I don't see a separate window title.  And googling
> for that suggests that you need to fiddle or use an
> add-on to implement or fake a window title.  (Is that
> correct?  It's my impression, so far.)

Hey, that’s a whole different kettle of fish. Yes, recently, many
applications go out of their way so as not to have a proper title bar
when running with a window manager that supports client-side
decorations (i.e. lets applications assume responsibility for drawing
a title bar).

Fortunately, i3 tacks a title bar on them anyway; also fortunately,
these applications still have usable title strings for the window
manager to display.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> > Where is this convention defined?  Is it a real
> > "thing" - some standard or something, or is it
> > just that you've noticed that many apps use such
> > naming?  I'm not challenging you; just curious
> > about this.
> 
> Now that I started looking, it seems that only Windows actively
> recommends putting the application name in the window title.
>
> ...<lots of interesting info>

Thanks for looking this up.  Sounds like all of it
also confirms what we've both been saying: specific
info first (to the left), to more easily distinguish.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[James Cloos]

>>>>> "SK" == Stefan Kangas <stefan@marxist.se> writes:

SK> You are the first person to say that `invocation-name' is important to
SK> keep.  Would like to expand on the use-case you have in mind, and why
SK> you think it is important to keep as the default?

partly inertia, i suppose.  although there have been times whe seeing
the version number in the window list helped quickly get to the emacs
i wanted.  back when my then laptop was only an x server, anyway.

(compile-from-srcdists make it trivial to have multiple versions
installed.  in fact removing old versions is a manual step and as a
result my workstation has five versions right now.  my likely ssh -Y
targets all have at least two.  but actually *running* two different
versions in parallel is less common, unless testing differences.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

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

Stefan Kangas <stefan@marxist.se> writes:

> Lars Ljung proposed to change frame-title-format to something more
> modern and similar to Firefox, gvim, Gimp, LibreOffice, etc.:
> https://debbugs.gnu.org/41147
>
> We currently have:
>
>     (setq frame-title-format
>           '(multiple-frames "%b"
>                             ("" invocation-name "@" system-name)))

First, thank you to everyone who has contributed to the discussion so far.
I have followed the discussion closely, and thought about this some more
to come up with a realistic proposal.

The discussion has revealed that it is important for some reasonably
common use-cases to keep `system-name', but that there is less need for
`invocation-name'.

I therefore suggest:

  (setq frame-title-format
        '(multiple-frames "%B"
                          ("" "%B - GNU Emacs at " system-name))

The main new feature is that we will show the current buffer or file
name in the frame title, even when there is only one frame.

The new "%B" specifier, added by me here, is equivalent to:

  (if buffer-file-name
      (abbreviate-file-name buffer-file-name)
    buffer-name))

The proposal is an incremental improvement, which could be the basis of
further work (such as adding "*" if the file is modified, etc.).

Please find attached a proposed patch; thanks in advance for any reviews
or comments.

Best regards,
Stefan Kangas

[-- Attachment #2: 0001-Improve-frame-title-format-and-icon-title-format.patch --]
[-- Type: text/x-diff, Size: 3778 bytes --]

From 60185c2fa667fdd8a3900936130895b8a783c127 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Mon, 24 Aug 2020 02:46:15 +0200
Subject: [PATCH] Improve frame-title-format and icon-title-format

* src/xdisp.c (decode_mode_spec): Support new '%B'-construct.
(syms_of_xdisp): Change 'Vframe_title_format' and 'Vicon_title_format'
to use the new '%B'-construct.  Replace 'invocation-name' with the
text "GNU Emacs".  (Bug#41147)
* doc/lispref/modes.texi (%-Constructs): Document new '%B'-construct.
* etc/NEWS: Announce the above changes.
---
 doc/lispref/modes.texi |  6 ++++++
 etc/NEWS               | 14 ++++++++++++++
 src/xdisp.c            | 12 +++++++++---
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi
index 33a07c9fb4..92c660617d 100644
--- a/doc/lispref/modes.texi
+++ b/doc/lispref/modes.texi
@@ -2245,6 +2245,12 @@ %-Constructs
 The current buffer name, obtained with the @code{buffer-name} function.
 @xref{Buffer Names}.
 
+@item %B
+The visited file name obtained with the @code{buffer-file-name}
+function, but shortened using @code{abbreviate-file-name}.  If the
+current buffer is not visiting a file, use the current buffer name
+obtained with the @code{buffer-name} function instead.
+
 @item %c
 The current column number of point, counting from zero starting at the
 left margin of the window.
diff --git a/etc/NEWS b/etc/NEWS
index ad63955f7b..9bbcc7896c 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -121,6 +121,15 @@ the mouse cursor is on the scroll bars, fringes, margins, header line,
 and mode line.  ('mwheel-mode' is enabled by default on most graphical
 displays.)
 
+---
+** The default 'frame-title-format' has been changed.
+It now includes the file or buffer name even when there is only a
+single frame, but no longer contains 'invocation-name'.  To get the
+old behavior back, add the following to your Init file:
+
+    (setq frame-title-format '(multiple-frames "%b"
+                              ("" invocation-name "@" system-name)))
+
 \f
 * Editing Changes in Emacs 28.1
 
@@ -1091,6 +1100,11 @@ It was used to allow loading Lisp libraries compiled by XEmacs, a
 modified version of Emacs which is no longer actively maintained.
 This is no longer supported, and setting this variable has no effect.
 
++++
+** The Mode Line Format has a new '%B'-construct.
+The new construct adds the abbreviated file name or name of the
+current buffer.  See the Emacs Lisp Reference Manual for more details.
+
 +++
 ** The macro 'with-displayed-buffer-window' is now obsolete.
 Use macro 'with-current-buffer-window' with action alist entry 'body-function'.
diff --git a/src/xdisp.c b/src/xdisp.c
index dd73758043..4920260406 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -26424,6 +26424,13 @@ decode_mode_spec (struct window *w, register int c, int field_width,
       obj = BVAR (b, name);
       break;
 
+    case 'B':
+      if (!NILP (BVAR (b, filename)))
+	obj = call1 (intern ("abbreviate-file-name"), BVAR (b, filename));
+      else
+	obj = BVAR (b, name);
+      break;
+
     case 'c':
     case 'C':
       /* %c, %C, and %l are ignored in `frame-title-format'.
@@ -34830,13 +34837,12 @@ syms_of_xdisp (void)
      Oracle Developer Studio 12.6.  */
   Lisp_Object icon_title_name_format
     = pure_list (empty_unibyte_string,
-		 intern_c_string ("invocation-name"),
-		 build_pure_c_string ("@"),
+		 build_pure_c_string ("%B - GNU Emacs at "),
 		 intern_c_string ("system-name"));
   Vicon_title_format
     = Vframe_title_format
     = pure_list (intern_c_string ("multiple-frames"),
-		 build_pure_c_string ("%b"),
+		 build_pure_c_string ("%B"),
 		 icon_title_name_format);
 
   DEFVAR_LISP ("message-log-max", Vmessage_log_max,
-- 
2.28.0

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

   >    You are the first person to say that `invocation-name' is important to
   >    keep.  Would like to expand on the use-case you have in mind, and why
   >    you think it is important to keep as the default?
   > 
   > I can think of one situation, when running multiple emacs:en of
   > different version.  E.g, development versions or when you wish to run
   > an older or newer version.

   1. `invocation-name' doesn't tell you anything about
   the Emacs version, AFAICT.

Since emacs is normally installed using a version name as well, it can
tell you that.

   2. As Eli would presumably point out [*], users who
   have installed multiple Emacs versions are uncommon,
   and those of them who run more than one version at
   the same time are even more uncommon.  (I'm one of
   them, FWIW.)

Debian installs Emacs as emacs-version, and often also emacs-snapshot
for a later one.  It is also common to have a X11, non-X11, GTK, etc
versions.

If installing multiple Emacs versions is uncommon, why is it the
default way that Emacs gets installed and has been installed since
time begun?

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Gregory Heytings via Emacs development discussions.]

>
> Debian installs Emacs as emacs-version, and often also emacs-snapshot 
> for a later one.
>

This is not true anymore (except for emacs and emacs-snapshot, but 
emacs-snapshot is not in official Debian repositories AFAIK).  Now the 
package is just "emacs", and it is not possible anymore to have multiple 
emacs version installed (except of course if you build them, or create 
their packages, yourself).

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Gregory Heytings via Emacs development discussions.]

>
> (setq frame-title-format
>       '(multiple-frames "%B"
>                         ("" "%B - GNU Emacs at " system-name)))
>

I personally do not like the idea of having the program information ("GNU 
Emacs at ...") disappear when a second frame is opened, and reappear when 
the next to last frame is closed.  I see no reason to do this.

>
> The new "%B" specifier, added by me here, is equivalent to:
>
>  (if buffer-file-name
>      (abbreviate-file-name buffer-file-name)
>    buffer-name))
>

You probably meant:

(if buffer-file-name
     (abbreviate-file-name buffer-file-name)
   (buffer-name)))

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Colin Baxter]

>>>>> Alfred M Szmidt <ams@gnu.org> writes:

    >> You are the first person to say that `invocation-name' is
    >> important to keep.  Would like to expand on the use-case you have
    >> in mind, and why you think it is important to keep as the
    >> default?
    >> 
    >> I can think of one situation, when running multiple emacs:en of
    >> different version.  E.g, development versions or when you wish to
    >> run an older or newer version.

    >    1. `invocation-name' doesn't tell you anything about the Emacs
    > version, AFAICT.

    > Since emacs is normally installed using a version name as well, it
    > can tell you that.

    >    2. As Eli would presumably point out [*], users who have
    > installed multiple Emacs versions are uncommon, and those of them
    > who run more than one version at the same time are even more
    > uncommon.  (I'm one of them, FWIW.)

Me too. I also run multiple emacs versions on multiples hosts
simultaneously, some in tmux sessions and some not.

Colin Baxter

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 30 Aug 2020 16:59:39 -0700
> 
> I therefore suggest:
> 
>   (setq frame-title-format
>         '(multiple-frames "%B"
>                           ("" "%B - GNU Emacs at " system-name))
> 
> The main new feature is that we will show the current buffer or file
> name in the frame title, even when there is only one frame.
> 
> The new "%B" specifier, added by me here, is equivalent to:
> 
>   (if buffer-file-name
>       (abbreviate-file-name buffer-file-name)
>     buffer-name))

The display engine calls the function which produces the frame's title
very frequently.  You have just made redisplay much slower due to this
call (abbreviate-file-name is a large and complex function, and you
call Lisp on top of that), and caused most redisplay cycles prfoduce
more garbage.  Is it really worth it?

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> The display engine calls the function which produces the frame's title
> very frequently.  You have just made redisplay much slower due to this
> call (abbreviate-file-name is a large and complex function, and you
> call Lisp on top of that), and caused most redisplay cycles prfoduce
> more garbage.  Is it really worth it?

Thanks, I didn't know it was called very frequently.  I think it's most
definitely not worth slowing down redisplay.  We should probably replace
it with the "%b" we had before.

BTW, I assume this caveat applies in equal measure to using `:eval' in
`frame-title-format'?  Do they apply also to `icon-title-format' and
`mode-line-format'?  If yes, should we warn users about it in
(info "(elisp) Mode Line Data") or (info "(elisp) Frame Titles")?

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Gregory Heytings via Emacs development discussions.]

>
>> The display engine calls the function which produces the frame's title 
>> very frequently.  You have just made redisplay much slower due to this 
>> call (abbreviate-file-name is a large and complex function, and you 
>> call Lisp on top of that), and caused most redisplay cycles prfoduce 
>> more garbage.  Is it really worth it?
>
> Thanks, I didn't know it was called very frequently.  I think it's most 
> definitely not worth slowing down redisplay.  We should probably replace 
> it with the "%b" we had before.
>

I'm not sure, but I think using `buffer-file-truename' (as I did in my 
proposal) would eliminate the problems Eli mentioned.  It is a 
(buffer-local) variable, and it is set only once when a buffer is created.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> > (abbreviate-file-name buffer-file-name)
>
> The display engine calls the function which produces the frame's title
> very frequently.  You have just made redisplay much slower due to this
> call (abbreviate-file-name is a large and complex function, and you
> call Lisp on top of that), and caused most redisplay cycles prfoduce
> more garbage.  Is it really worth it?

Aside from whether it's worth the performance hit,
what is it worth, in general?

I wouldn't object to someone adding the possibility
of a `%B' behavior, even if I might never use it.

But why would we put that into the default?

I can guess why someone might want to use 
`abbreviate-file-name', to get a file name in the
mode-line or frame title - to get info about the
directory.  But I doubt I ever would.

If there's a need for someone to see the directory
then fine, s?he can add it to the frame title.

But the NONdirectory part of `buffer-file-name' is
the most specific part.  And that part is used for
the buffer name, which we have with `%b'.  The
nondir part should come before (to the left of)
the dir part, at least for the default.

If there's ever a need to see some directory info,
then it would be better to use a uniquified buffer
name than `abbreviate-file-name'.  That is, use a
`uniquify-buffer-name-style' other than `forward'.
And `buffer-name' already gives us this behavior.

To be clear, what's the motivation for adding a
`%B' behavior?  (But a priori I have no objection.)

More importantly, what's the motivation for using
it for the default behavior?

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 31 Aug 2020 14:46:31 +0000
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The display engine calls the function which produces the frame's title
> > very frequently.  You have just made redisplay much slower due to this
> > call (abbreviate-file-name is a large and complex function, and you
> > call Lisp on top of that), and caused most redisplay cycles prfoduce
> > more garbage.  Is it really worth it?
> 
> Thanks, I didn't know it was called very frequently.  I think it's most
> definitely not worth slowing down redisplay.  We should probably replace
> it with the "%b" we had before.

We could display the base name of buffer-file-name, if we wanted,
producing that in C.  But %b already does most of that.

> BTW, I assume this caveat applies in equal measure to using `:eval' in
> `frame-title-format'?

Yes, it should be avoided.

> Do they apply also to `icon-title-format' and `mode-line-format'?

When Emacs is iconified, it bypasses redisplay, so icon-title-format
is mostly off the hook.  mode-line-format is indeed slowed down by
:eval and the likes, but there's a crucial difference: the mode line
is drawn by Emacs, and we have tricks up our sleeve to avoid redrawing
those parts that were not changed.  By contrast, the frame's title is
drawn by the window-manager, and we have no control on how it does
that, so we always provide it with the full title, even if some parts
of it haven't changed (and, for example, the "GNU Emacs" part never
will).

> If yes, should we warn users about it in (info "(elisp) Mode Line
> Data") or (info "(elisp) Frame Titles")?

I doubt this is efficient: people who want fancy decorations will do
it regardless, and explaining why it's a bad idea is not easy, because
it requires a detailed description of how redisplay works.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> We could display the base name of buffer-file-name, if we wanted,
> producing that in C.  But %b already does most of that.

It's probably best to just stick with "%b" here, which also respects
uniquify.

>> If yes, should we warn users about it in (info "(elisp) Mode Line
>> Data") or (info "(elisp) Frame Titles")?
>
> I doubt this is efficient: people who want fancy decorations will do
> it regardless, and explaining why it's a bad idea is not easy, because
> it requires a detailed description of how redisplay works.

Fine by me, thanks.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Gregory Heytings via Emacs development discussions.]

>
> But the NONdirectory part of `buffer-file-name' is the most specific 
> part.  And that part is used for the buffer name, which we have with 
> `%b'.  The nondir part should come before (to the left of) the dir part, 
> at least for the default.
>
> If there's ever a need to see some directory info, then it would be 
> better to use a uniquified buffer name than `abbreviate-file-name'. 
> That is, use a `uniquify-buffer-name-style' other than `forward'. And 
> `buffer-name' already gives us this behavior.
>
> To be clear, what's the motivation for adding a `%B' behavior?  (But a 
> priori I have no objection.)
>
> More importantly, what's the motivation for using it for the default 
> behavior?
>

FWIW, I do not agree that the non-directory part of a file name is the 
most specific part.  This is only partly true.  Where a file is located is 
most often as important as (and sometimes more important than) the file 
name to identify a file, at least of you are a programmer.

In Visual Studio and XCode, the path of the file is displayed just above 
the "buffer".  In Eclipse, it is displayed in the title bar.  And that 
information is displayed in its "natural" order, with the current filename 
on the right.

(Likewise, it is almost standard to display the current working directory 
in full in shell prompts.)

It seems to me that using `(abbreviate-file-name buffer-file-name)' or 
`buffer-file-truename' in Emacs's title bar makes perfect sense.

(An additional option that would also make sense (I think) is to have an 
option so that `abbreviate-file-name' keeps only the initial N letters of 
the directories, for example: "/u/i/stdio.h" or "~/gn/em/sr/dired.c", 
which is shorter, and often clear enough.)

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Monnier]

> FWIW, I do not agree that the non-directory part of a file name is the most
> specific part.

This same argument applies to buffer names, AFAIK.
For this reason I think it makes sense to just display buffer names and
then users can choose which is contained in buffer names, e.g. by
customize the `uniquify.el` variables like `uniquify-min-dir-content`
and friends.


        Stefan

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Drew Adams]

> >> In Visual Studio and XCode, the path of the file is displayed just
> >> above the "buffer".  In Eclipse, it is displayed in the title bar.
> >> And that information is displayed in its "natural" order, with the
> >> current filename on the right.
> >
> > Is that a good argument for the default Emacs
> > behavior?  What's a good argument for this order,
> > without recourse to whether others use it?
> 
> If many (if not all) of the most popular code editors do something, and
> Emacs wants to do (or in this case, to continue to do) something else, the
> onus of the proof is on Emacs to justify that its own default behavior is
> better.  (The bias of that sentence is that Emacs is primarily a code
> editor, which is true for me, but not necessarily for everyone.)

There's no need for Emacs to justify its behavior wrt
other editors or any other programs, to anyone.  Emacs
users and developers can decide what Emacs behavior
should be, including default behavior.

Again: What's a good argument on its own merits,
without recourse to an argument from authority?
("Everybody else does it!")

Everyone in Texas might have 42 guns and attend
church twice every Sunday.  That's not a reason
why everyone in Switzerland should act the same.

> The current default behavior (using only the file name for %b, and in case
> of conflict uniquifying the names with uniquify-buffer-name-style set to
> post-forward-angle-brackets) was introduced in Emacs 24.4.  It's already
> much better than the previous default behavior (uniquify-buffer-name-style
> set to nil, with which buffer names are uniquified with numbers), but IMO
> still far from optimal.

"Optimal" is perhaps in the eye of the beholder.
And it might not necessarily apply to _default_
behavior.

And popularity outside Emacs does not "optimal"
make.  You'll need a real argument, not just
popularity, as to why you think the behavior is
not "optimal" or, more appropriately, is not a
good default.

> (This discussion has now diverged from the original purpose of this
> thread, which was to "modernize frame-title-format".)

I don't think it has.  Except that now we're
talking about "optimal" behavior and comparing
Emacs with other code editors.

Yes, those things diverge from the question of
what to use for the `frame-title-format' default.
I agree that that's an unproductive route.

> >> (Likewise, it is almost standard to display the current working
> >> directory in full in shell prompts.)
> >
> > I don't see how that's relevant here.
> 
> The equivalent of the Emacs current default behavior would be to print, in
> the prompt, only the basename of the current working directory instead of
> the current working directory in full.

Such a prompt is not a frame title.  That's the
irrelevance.

Unless, as I mentioned, it's a frame whose
selected window has a `*shell*' buffer, or
similar.

There is likely no single `frame-title-format'
that is "optimal" for all uses of a frame.
The question is about the default format.

I don't think that most Emacs frames, for most
users most of the time, are like CLI windows.
Do you?

> > Isn't that what we'd want for default behavior: minimal text that
> > distinguishes and identifies the current set of frames?
> 
> You apparently assume that "minimal" is better, presumably because
> "minimal" means "less to read" and therefore "less mental charge".

Minimal for distinguishing.  And actually, I
suggested that we could reasonably include a
lot _more_ in the default frame title.

> I do not think this is the case.  Understanding a uniquified buffer name with
> only a part of the directory placed after the file name between angle
> brackets requires (at least for me) much more effort than understanding
> `buffer-file-truename'.  The former is, BTW, much less predictable, as it
> changes when you open and close files/buffers.

Yes, it can change when the editing context
changes, including the set of buffers you're
using.  Whether that's a feature or a problem
is arguable.  IMO, it's good, not bad, default
behavior.

> The fact that most code
> editors chose to use the latter is, at least for me,
> an indication that it is in general easier to understand,
> and it is indeed, at least for me, easier to understand.

Fortunately, you can easily change
`frame-title-format' to fit your preferences.
As can I.

> Say, you open /home/drew/.emacs and /home/drew/foo/bar/.emacs.  When you
> open the first one you have a buffer ".emacs".  When you open the second
> one you now have a buffer ".emacs<drew>" and another one ".emacs<bar>".
> If you now close the first one you have again a buffer ".emacs", but it's
> not the same one as the ".emacs" you initially opened!

See above.  You're repeating, out of order,
what you said earlier.

Whether the confusion you point to is generally
(i.e., for default behavior) worth the benefit
of not repeating the same long dirs in multiple
frames (which is the much more typical case -
see my previous mail), is an open question.
Clearly we disagree about the answer.

> Likewise when you open /home/drew/.emacs, then /ssh:drew@...:.emacs, then
> close the first one.  You have a buffer ".emacs", then two buffers
> ".emacs<>" and ".emacs</ssh:drew@...>" (what's this ".emacs<>"?), then
> again single a buffer ".emacs" (the remote one!).
> 
> And so forth.

Same point.  See above.

RE: Modernize frame-title-format: "%b - GNU Emacs"

[Gregory Heytings via Emacs development discussions.]

>
> There's no need for Emacs to justify its behavior wrt other editors or 
> any other programs, to anyone.  Emacs users and developers can decide 
> what Emacs behavior should be, including default behavior.
>

I'm an Emacs user, so please allow me to voice my opinions ;-)

>
> Again: What's a good argument on its own merits, without recourse to an 
> argument from authority? ("Everybody else does it!")
>
> Everyone in Texas might have 42 guns and attend church twice every 
> Sunday.  That's not a reason why everyone in Switzerland should act the 
> same.
>

That's not at all what I said.  Please don't ridicule what I said, it's 
not helpful.

I said: "Where a file is located is most often as important as (and 
sometimes more important than) the file name to identify a file, at least 
of you are a programmer."  And: "Understanding a uniquified buffer name 
with only a part of the directory placed after the file name between angle 
brackets requires (at least for me) much more effort than understanding 
`buffer-file-truename'.  The former is, BTW, much less predictable, as it 
changes when you open and close files/buffers.  The fact that most code 
editors chose to use the latter is, at least for me, an indication that it 
is in general easier to understand, and it is indeed, at least for me, 
easier to understand."

If you read this, you'll see that I give arguments that have nothing to do 
with arguments by authority: "where a file is located is often important" 
(independently of the fact that another file with the same name is 
currently opened in Emacs), and the current default behavior "requires 
more mental effort", because buffer names are "less predictable" and 
"change".  To this I added that my personal experience is indeed that 
`buffer-file-truename' is easier to understand than `(buffer-name)', and 
that the fact that the majority of other code editors use 
`buffer-file-truename' and not `(buffer-name)' is for me an indication 
that I'm not the only one to have that experience.  None of these 
arguments are arguments by authority.

Two more arguments, that are still not arguments by authority:

The current default behavior of Emacs (using only the filename as its 
buffer names) dates from a time when users did not have many files, or at 
least much less files than what we have today.  So having a buffer named 
"interp.lsp" or "comp.pas" was clear enough.  Nowadays it is often not.

Emacs has adopted many of the more modern mechanisms used in text/code 
editors (for example, mouse interaction, the menu bar, the tool bar).  It 
could have been argued that they were unnecessary and should have been 
disabled by default.  I believe Emacs could adopt this (minor) feature as 
well.

In short, my opinion is that:

1. it would be a good thing to introduce a %B construct for mode-line-format and frame-title-format, equivalent to `(or buffer-file-truename "%b")'

2. it would be a good thing if frame-title-format default value was `("%B - GNU Emacs at " system-name)'

3. it would be a good thing to have an option (perhaps a format option) to shorten directory names in %B (for example "%1B" to have "/u/i/stdio.h")

Now I stop arguing, and will not contribute further to this thread.

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Alfred M. Szmidt]

   > Debian installs Emacs as emacs-version, and often also emacs-snapshot 
   > for a later one.

   This is not true anymore (except for emacs and emacs-snapshot, but 
   emacs-snapshot is not in official Debian repositories AFAIK).  Now the 
   package is just "emacs", and it is not possible anymore to have multiple 
   emacs version installed (except of course if you build them, or create 
   their packages, yourself).

Thank you for the update!

Re: Modernize frame-title-format: "%b - GNU Emacs"

[Stefan Monnier]

> The current default behavior of Emacs (using only the filename as its buffer
> names) dates from a time when users did not have many files, or at least
> much less files than what we have today.  So having a buffer named
> "interp.lsp" or "comp.pas" was clear enough.  Nowadays it is often not.

That can be controlled by the uniquify-* variables, tho.

I understand that you prefer something like `buffer-file-truename` over
`file-name-nondirectory`, but what is less clear is whether this opinion
only applies to frame titles or also to buffer names.

If it also applies to buffer names, then frame titles can just use "%b"
and you/we just have to change the naming scheme for buffer names (and if
the existing uniquify-* vars aren't good enough for that, we can fix it).


        Stefan