unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Modernize frame-title-format: "%b - GNU Emacs"
@ 2020-08-26 22:09 Stefan Kangas
  2020-08-26 22:37 ` Stefan Monnier
                   ` (8 more replies)
  0 siblings, 9 replies; 95+ messages in thread
From: Stefan Kangas @ 2020-08-26 22:09 UTC (permalink / raw)
  To: Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:09 Stefan Kangas
@ 2020-08-26 22:37 ` Stefan Monnier
  2020-08-26 23:12   ` Drew Adams
  2020-08-27  5:28 ` Yuri Khan
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 95+ messages in thread
From: Stefan Monnier @ 2020-08-26 22:37 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs developers

> 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




^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:37 ` Stefan Monnier
@ 2020-08-26 23:12   ` Drew Adams
  0 siblings, 0 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-26 23:12 UTC (permalink / raw)
  To: Stefan Monnier, Stefan Kangas; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:09 Stefan Kangas
  2020-08-26 22:37 ` Stefan Monnier
@ 2020-08-27  5:28 ` Yuri Khan
  2020-08-27  5:55   ` Stefan Kangas
  2020-08-27  6:32 ` Alfred M. Szmidt
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 95+ messages in thread
From: Yuri Khan @ 2020-08-27  5:28 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  5:28 ` Yuri Khan
@ 2020-08-27  5:55   ` Stefan Kangas
  2020-08-27  6:56     ` Yuri Khan
  0 siblings, 1 reply; 95+ messages in thread
From: Stefan Kangas @ 2020-08-27  5:55 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Emacs developers

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:09 Stefan Kangas
  2020-08-26 22:37 ` Stefan Monnier
  2020-08-27  5:28 ` Yuri Khan
@ 2020-08-27  6:32 ` Alfred M. Szmidt
  2020-08-27  7:20   ` Stefan Kangas
  2020-08-27  6:52 ` tomas
                   ` (5 subsequent siblings)
  8 siblings, 1 reply; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-27  6:32 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

   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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:09 Stefan Kangas
                   ` (2 preceding siblings ...)
  2020-08-27  6:32 ` Alfred M. Szmidt
@ 2020-08-27  6:52 ` tomas
  2020-08-27  9:07 ` Gregory Heytings via Emacs development discussions.
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 95+ messages in thread
From: tomas @ 2020-08-27  6:52 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  5:55   ` Stefan Kangas
@ 2020-08-27  6:56     ` Yuri Khan
  2020-08-27 14:52       ` Stefan Monnier
                         ` (2 more replies)
  0 siblings, 3 replies; 95+ messages in thread
From: Yuri Khan @ 2020-08-27  6:56 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs developers

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  6:32 ` Alfred M. Szmidt
@ 2020-08-27  7:20   ` Stefan Kangas
  2020-08-27  8:00     ` Alfred M. Szmidt
  2020-08-28  1:04     ` James Cloos
  0 siblings, 2 replies; 95+ messages in thread
From: Stefan Kangas @ 2020-08-27  7:20 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  7:20   ` Stefan Kangas
@ 2020-08-27  8:00     ` Alfred M. Szmidt
  2020-08-27  8:03       ` Alfred M. Szmidt
                         ` (2 more replies)
  2020-08-28  1:04     ` James Cloos
  1 sibling, 3 replies; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-27  8:00 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  8:00     ` Alfred M. Szmidt
@ 2020-08-27  8:03       ` Alfred M. Szmidt
  2020-08-27 14:35       ` Colin Baxter
  2020-08-27 14:59       ` Stefan Kangas
  2 siblings, 0 replies; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-27  8:03 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: stefan, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:09 Stefan Kangas
                   ` (3 preceding siblings ...)
  2020-08-27  6:52 ` tomas
@ 2020-08-27  9:07 ` Gregory Heytings via Emacs development discussions.
  2020-08-27  9:14 ` Eli Zaretskii
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 95+ messages in thread
From: Gregory Heytings via Emacs development discussions. @ 2020-08-27  9:07 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs developers


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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:09 Stefan Kangas
                   ` (4 preceding siblings ...)
  2020-08-27  9:07 ` Gregory Heytings via Emacs development discussions.
@ 2020-08-27  9:14 ` Eli Zaretskii
  2020-08-27 17:06   ` Pip Cet
  2020-08-27 17:27 ` Ulrich Mueller
                   ` (2 subsequent siblings)
  8 siblings, 1 reply; 95+ messages in thread
From: Eli Zaretskii @ 2020-08-27  9:14 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  8:00     ` Alfred M. Szmidt
  2020-08-27  8:03       ` Alfred M. Szmidt
@ 2020-08-27 14:35       ` Colin Baxter
  2020-08-27 14:59       ` Stefan Kangas
  2 siblings, 0 replies; 95+ messages in thread
From: Colin Baxter @ 2020-08-27 14:35 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: Stefan Kangas, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  6:56     ` Yuri Khan
@ 2020-08-27 14:52       ` Stefan Monnier
  2020-08-27 15:04         ` tomas
  2020-08-27 16:18       ` Stefan Kangas
  2020-08-28  0:17       ` Wayne Harris via Emacs development discussions.
  2 siblings, 1 reply; 95+ messages in thread
From: Stefan Monnier @ 2020-08-27 14:52 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Stefan Kangas, Emacs developers

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




^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  8:00     ` Alfred M. Szmidt
  2020-08-27  8:03       ` Alfred M. Szmidt
  2020-08-27 14:35       ` Colin Baxter
@ 2020-08-27 14:59       ` Stefan Kangas
  2020-08-27 15:39         ` Alfred M. Szmidt
  2 siblings, 1 reply; 95+ messages in thread
From: Stefan Kangas @ 2020-08-27 14:59 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 14:52       ` Stefan Monnier
@ 2020-08-27 15:04         ` tomas
  2020-08-27 15:17           ` Stefan Monnier
  0 siblings, 1 reply; 95+ messages in thread
From: tomas @ 2020-08-27 15:04 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
       [not found]       ` <<E1kBCsX-00049o-5Z@fencepost.gnu.org>
@ 2020-08-27 15:05         ` Drew Adams
  0 siblings, 0 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-27 15:05 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: stefan, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
       [not found] ` <<83y2m01me0.fsf@gnu.org>
@ 2020-08-27 15:10   ` Drew Adams
  2020-08-27 15:14     ` tomas
  0 siblings, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-27 15:10 UTC (permalink / raw)
  To: Eli Zaretskii, Stefan Kangas; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 15:10   ` Drew Adams
@ 2020-08-27 15:14     ` tomas
  2020-08-27 15:24       ` Drew Adams
  0 siblings, 1 reply; 95+ messages in thread
From: tomas @ 2020-08-27 15:14 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 15:04         ` tomas
@ 2020-08-27 15:17           ` Stefan Monnier
  0 siblings, 0 replies; 95+ messages in thread
From: Stefan Monnier @ 2020-08-27 15:17 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 15:14     ` tomas
@ 2020-08-27 15:24       ` Drew Adams
  2020-08-27 16:00         ` tomas
  0 siblings, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-27 15:24 UTC (permalink / raw)
  To: tomas, emacs-devel

> > [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. ;-)



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 14:59       ` Stefan Kangas
@ 2020-08-27 15:39         ` Alfred M. Szmidt
  0 siblings, 0 replies; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-27 15:39 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

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?



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
       [not found]         ` <<E1kBJzg-0001FK-Eb@fencepost.gnu.org>
@ 2020-08-27 15:51           ` Drew Adams
  2020-08-27 15:59             ` Alfred M. Szmidt
                               ` (3 more replies)
  0 siblings, 4 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-27 15:51 UTC (permalink / raw)
  To: Alfred M. Szmidt, Stefan Kangas; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 15:51           ` Drew Adams
@ 2020-08-27 15:59             ` Alfred M. Szmidt
  2020-08-27 16:42               ` Thibaut Verron
  2020-08-27 17:49             ` Michael Albinus
                               ` (2 subsequent siblings)
  3 siblings, 1 reply; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-27 15:59 UTC (permalink / raw)
  To: Drew Adams; +Cc: stefan, emacs-devel

   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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 15:24       ` Drew Adams
@ 2020-08-27 16:00         ` tomas
  0 siblings, 0 replies; 95+ messages in thread
From: tomas @ 2020-08-27 16:00 UTC (permalink / raw)
  To: Drew Adams; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  6:56     ` Yuri Khan
  2020-08-27 14:52       ` Stefan Monnier
@ 2020-08-27 16:18       ` Stefan Kangas
  2020-08-27 17:02         ` Yuri Khan
  2020-08-27 17:28         ` Colin Baxter
  2020-08-28  0:17       ` Wayne Harris via Emacs development discussions.
  2 siblings, 2 replies; 95+ messages in thread
From: Stefan Kangas @ 2020-08-27 16:18 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Emacs developers

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?



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 15:59             ` Alfred M. Szmidt
@ 2020-08-27 16:42               ` Thibaut Verron
  2020-08-27 17:23                 ` Alfred M. Szmidt
  0 siblings, 1 reply; 95+ messages in thread
From: Thibaut Verron @ 2020-08-27 16:42 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: stefan, Drew Adams, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 16:18       ` Stefan Kangas
@ 2020-08-27 17:02         ` Yuri Khan
  2020-08-27 17:28         ` Colin Baxter
  1 sibling, 0 replies; 95+ messages in thread
From: Yuri Khan @ 2020-08-27 17:02 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs developers

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  9:14 ` Eli Zaretskii
@ 2020-08-27 17:06   ` Pip Cet
  2020-08-27 17:11     ` Eli Zaretskii
  0 siblings, 1 reply; 95+ messages in thread
From: Pip Cet @ 2020-08-27 17:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Kangas, emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 17:06   ` Pip Cet
@ 2020-08-27 17:11     ` Eli Zaretskii
  2020-08-27 17:36       ` Robert Pluim
  0 siblings, 1 reply; 95+ messages in thread
From: Eli Zaretskii @ 2020-08-27 17:11 UTC (permalink / raw)
  To: Pip Cet; +Cc: stefan, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 16:42               ` Thibaut Verron
@ 2020-08-27 17:23                 ` Alfred M. Szmidt
  2020-08-27 17:50                   ` Thibaut Verron
  0 siblings, 1 reply; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-27 17:23 UTC (permalink / raw)
  To: thibaut.verron; +Cc: stefan, drew.adams, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:09 Stefan Kangas
                   ` (5 preceding siblings ...)
  2020-08-27  9:14 ` Eli Zaretskii
@ 2020-08-27 17:27 ` Ulrich Mueller
  2020-08-27 17:52   ` Drew Adams
  2020-08-28 22:06 ` Drew Adams
  2020-08-30 23:59 ` Stefan Kangas
  8 siblings, 1 reply; 95+ messages in thread
From: Ulrich Mueller @ 2020-08-27 17:27 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 16:18       ` Stefan Kangas
  2020-08-27 17:02         ` Yuri Khan
@ 2020-08-27 17:28         ` Colin Baxter
  1 sibling, 0 replies; 95+ messages in thread
From: Colin Baxter @ 2020-08-27 17:28 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs developers, Yuri Khan

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 17:11     ` Eli Zaretskii
@ 2020-08-27 17:36       ` Robert Pluim
  2020-08-27 18:08         ` Drew Adams
  0 siblings, 1 reply; 95+ messages in thread
From: Robert Pluim @ 2020-08-27 17:36 UTC (permalink / raw)
  To: Pip Cet; +Cc: Eli Zaretskii, stefan, emacs-devel

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



^ permalink raw reply related	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 15:51           ` Drew Adams
  2020-08-27 15:59             ` Alfred M. Szmidt
@ 2020-08-27 17:49             ` Michael Albinus
  2020-08-27 18:10               ` Alfred M. Szmidt
  2020-08-27 18:10               ` Drew Adams
       [not found]             ` <<87a6yg9dyq.fsf@gmx.de>
       [not found]             ` <<<87a6yg9dyq.fsf@gmx.de>
  3 siblings, 2 replies; 95+ messages in thread
From: Michael Albinus @ 2020-08-27 17:49 UTC (permalink / raw)
  To: Drew Adams; +Cc: Alfred M. Szmidt, Stefan Kangas, emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 17:23                 ` Alfred M. Szmidt
@ 2020-08-27 17:50                   ` Thibaut Verron
  2020-08-27 18:15                     ` Alfred M. Szmidt
  0 siblings, 1 reply; 95+ messages in thread
From: Thibaut Verron @ 2020-08-27 17:50 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: stefan, drew.adams, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 17:27 ` Ulrich Mueller
@ 2020-08-27 17:52   ` Drew Adams
  0 siblings, 0 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-27 17:52 UTC (permalink / raw)
  To: Ulrich Mueller, Stefan Kangas; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 17:36       ` Robert Pluim
@ 2020-08-27 18:08         ` Drew Adams
  0 siblings, 0 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-27 18:08 UTC (permalink / raw)
  To: Robert Pluim, Pip Cet; +Cc: Eli Zaretskii, stefan, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 17:49             ` Michael Albinus
@ 2020-08-27 18:10               ` Alfred M. Szmidt
  2020-08-27 18:19                 ` Michael Albinus
  2020-08-27 18:10               ` Drew Adams
  1 sibling, 1 reply; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-27 18:10 UTC (permalink / raw)
  To: Michael Albinus; +Cc: stefan, drew.adams, emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 17:49             ` Michael Albinus
  2020-08-27 18:10               ` Alfred M. Szmidt
@ 2020-08-27 18:10               ` Drew Adams
  2020-08-27 18:22                 ` Michael Albinus
  1 sibling, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-27 18:10 UTC (permalink / raw)
  To: Michael Albinus; +Cc: Alfred M. Szmidt, Stefan Kangas, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
       [not found]               ` <<E1kBMLt-00033R-SA@fencepost.gnu.org>
@ 2020-08-27 18:14                 ` Drew Adams
  2020-08-27 18:19                   ` Alfred M. Szmidt
  0 siblings, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-27 18:14 UTC (permalink / raw)
  To: Alfred M. Szmidt, Michael Albinus; +Cc: stefan, drew.adams, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 17:50                   ` Thibaut Verron
@ 2020-08-27 18:15                     ` Alfred M. Szmidt
  2020-08-27 19:13                       ` Thibaut Verron
  0 siblings, 1 reply; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-27 18:15 UTC (permalink / raw)
  To: thibaut.verron; +Cc: stefan, drew.adams, emacs-devel

    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?



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 18:14                 ` Drew Adams
@ 2020-08-27 18:19                   ` Alfred M. Szmidt
  2020-08-27 18:30                     ` Michael Albinus
  0 siblings, 1 reply; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-27 18:19 UTC (permalink / raw)
  To: Drew Adams; +Cc: stefan, michael.albinus, drew.adams, emacs-devel


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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 18:10               ` Alfred M. Szmidt
@ 2020-08-27 18:19                 ` Michael Albinus
  0 siblings, 0 replies; 95+ messages in thread
From: Michael Albinus @ 2020-08-27 18:19 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: stefan, drew.adams, emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 18:10               ` Drew Adams
@ 2020-08-27 18:22                 ` Michael Albinus
  0 siblings, 0 replies; 95+ messages in thread
From: Michael Albinus @ 2020-08-27 18:22 UTC (permalink / raw)
  To: Drew Adams; +Cc: Alfred M. Szmidt, Stefan Kangas, emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 18:19                   ` Alfred M. Szmidt
@ 2020-08-27 18:30                     ` Michael Albinus
  0 siblings, 0 replies; 95+ messages in thread
From: Michael Albinus @ 2020-08-27 18:30 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: stefan, Drew Adams, emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
       [not found]                   ` <<E1kBMUM-0003xd-MI@fencepost.gnu.org>
@ 2020-08-27 18:34                     ` Drew Adams
  2020-08-27 18:51                       ` Michael Albinus
  0 siblings, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-27 18:34 UTC (permalink / raw)
  To: Alfred M. Szmidt, Drew Adams
  Cc: stefan, michael.albinus, drew.adams, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 18:34                     ` Drew Adams
@ 2020-08-27 18:51                       ` Michael Albinus
  2020-08-27 20:01                         ` Drew Adams
  0 siblings, 1 reply; 95+ messages in thread
From: Michael Albinus @ 2020-08-27 18:51 UTC (permalink / raw)
  To: Drew Adams; +Cc: Alfred M. Szmidt, stefan, emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 18:15                     ` Alfred M. Szmidt
@ 2020-08-27 19:13                       ` Thibaut Verron
  2020-08-27 19:20                         ` Yuri Khan
  0 siblings, 1 reply; 95+ messages in thread
From: Thibaut Verron @ 2020-08-27 19:13 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: stefan, drew.adams, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 19:13                       ` Thibaut Verron
@ 2020-08-27 19:20                         ` Yuri Khan
  0 siblings, 0 replies; 95+ messages in thread
From: Yuri Khan @ 2020-08-27 19:20 UTC (permalink / raw)
  To: thibaut.verron; +Cc: Alfred M. Szmidt, Stefan Kangas, Drew Adams, emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27 18:51                       ` Michael Albinus
@ 2020-08-27 20:01                         ` Drew Adams
  0 siblings, 0 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-27 20:01 UTC (permalink / raw)
  To: Michael Albinus; +Cc: Alfred M. Szmidt, stefan, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  6:56     ` Yuri Khan
  2020-08-27 14:52       ` Stefan Monnier
  2020-08-27 16:18       ` Stefan Kangas
@ 2020-08-28  0:17       ` Wayne Harris via Emacs development discussions.
  2020-08-28  4:44         ` Yuri Khan
  2 siblings, 1 reply; 95+ messages in thread
From: Wayne Harris via Emacs development discussions. @ 2020-08-28  0:17 UTC (permalink / raw)
  To: emacs-devel

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.




^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-27  7:20   ` Stefan Kangas
  2020-08-27  8:00     ` Alfred M. Szmidt
@ 2020-08-28  1:04     ` James Cloos
  2020-08-28  4:46       ` Yuri Khan
                         ` (2 more replies)
  1 sibling, 3 replies; 95+ messages in thread
From: James Cloos @ 2020-08-28  1:04 UTC (permalink / raw)
  To: emacs-devel; +Cc: Alfred M. Szmidt, Stefan Kangas

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28  0:17       ` Wayne Harris via Emacs development discussions.
@ 2020-08-28  4:44         ` Yuri Khan
  2020-08-28  8:56           ` Ulrich Mueller
  2020-08-28 19:03           ` Drew Adams
  0 siblings, 2 replies; 95+ messages in thread
From: Yuri Khan @ 2020-08-28  4:44 UTC (permalink / raw)
  To: Wayne Harris; +Cc: Emacs developers

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28  1:04     ` James Cloos
@ 2020-08-28  4:46       ` Yuri Khan
  2020-08-28 19:09         ` Drew Adams
  2020-08-28  9:18       ` Stefan Kangas
  2020-08-28 19:29       ` Tassilo Horn
  2 siblings, 1 reply; 95+ messages in thread
From: Yuri Khan @ 2020-08-28  4:46 UTC (permalink / raw)
  To: James Cloos; +Cc: Alfred M. Szmidt, Stefan Kangas, Emacs developers

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28  4:44         ` Yuri Khan
@ 2020-08-28  8:56           ` Ulrich Mueller
  2020-08-28 19:03           ` Drew Adams
  1 sibling, 0 replies; 95+ messages in thread
From: Ulrich Mueller @ 2020-08-28  8:56 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Wayne Harris, Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28  1:04     ` James Cloos
  2020-08-28  4:46       ` Yuri Khan
@ 2020-08-28  9:18       ` Stefan Kangas
  2020-08-28 13:00         ` Alfred M. Szmidt
  2020-08-29 23:08         ` James Cloos
  2020-08-28 19:29       ` Tassilo Horn
  2 siblings, 2 replies; 95+ messages in thread
From: Stefan Kangas @ 2020-08-28  9:18 UTC (permalink / raw)
  To: James Cloos, emacs-devel; +Cc: Alfred M. Szmidt

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28  9:18       ` Stefan Kangas
@ 2020-08-28 13:00         ` Alfred M. Szmidt
  2020-08-29 23:08         ` James Cloos
  1 sibling, 0 replies; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-28 13:00 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: cloos, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28  4:44         ` Yuri Khan
  2020-08-28  8:56           ` Ulrich Mueller
@ 2020-08-28 19:03           ` Drew Adams
  2020-08-28 19:55             ` Yuri Khan
  1 sibling, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-28 19:03 UTC (permalink / raw)
  To: Yuri Khan, Wayne Harris; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28  4:46       ` Yuri Khan
@ 2020-08-28 19:09         ` Drew Adams
  2020-08-28 19:22           ` Colin Baxter
  0 siblings, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-28 19:09 UTC (permalink / raw)
  To: Yuri Khan, James Cloos; +Cc: Alfred M. Szmidt, Stefan Kangas, Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
       [not found]         ` <<E1kBdzV-0006sF-Ha@fencepost.gnu.org>
@ 2020-08-28 19:16           ` Drew Adams
  2020-08-31  5:26             ` Alfred M. Szmidt
  0 siblings, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-28 19:16 UTC (permalink / raw)
  To: Alfred M. Szmidt, Stefan Kangas; +Cc: cloos, emacs-devel

>    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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 19:09         ` Drew Adams
@ 2020-08-28 19:22           ` Colin Baxter
  2020-08-28 20:07             ` Drew Adams
  0 siblings, 1 reply; 95+ messages in thread
From: Colin Baxter @ 2020-08-28 19:22 UTC (permalink / raw)
  To: Drew Adams
  Cc: Stefan Kangas, Emacs developers, Alfred M. Szmidt, James Cloos,
	Yuri Khan

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




^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28  1:04     ` James Cloos
  2020-08-28  4:46       ` Yuri Khan
  2020-08-28  9:18       ` Stefan Kangas
@ 2020-08-28 19:29       ` Tassilo Horn
  2 siblings, 0 replies; 95+ messages in thread
From: Tassilo Horn @ 2020-08-28 19:29 UTC (permalink / raw)
  To: James Cloos; +Cc: Alfred M. Szmidt, Stefan Kangas, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 19:03           ` Drew Adams
@ 2020-08-28 19:55             ` Yuri Khan
  2020-08-28 20:36               ` Drew Adams
  0 siblings, 1 reply; 95+ messages in thread
From: Yuri Khan @ 2020-08-28 19:55 UTC (permalink / raw)
  To: Drew Adams; +Cc: Wayne Harris, Emacs developers

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 19:22           ` Colin Baxter
@ 2020-08-28 20:07             ` Drew Adams
  0 siblings, 0 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-28 20:07 UTC (permalink / raw)
  To: Colin Baxter
  Cc: Alfred M. Szmidt, Emacs developers, Stefan Kangas, James Cloos,
	Yuri Khan

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 19:55             ` Yuri Khan
@ 2020-08-28 20:36               ` Drew Adams
  2020-08-28 20:40                 ` Thibaut Verron
  2020-08-29  8:39                 ` Yuri Khan
  0 siblings, 2 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-28 20:36 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Wayne Harris, Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 20:36               ` Drew Adams
@ 2020-08-28 20:40                 ` Thibaut Verron
  2020-08-28 21:18                   ` Drew Adams
  2020-08-29  8:39                 ` Yuri Khan
  1 sibling, 1 reply; 95+ messages in thread
From: Thibaut Verron @ 2020-08-28 20:40 UTC (permalink / raw)
  To: Drew Adams; +Cc: Wayne Harris, Emacs developers, Yuri Khan

[-- 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 --]

^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 20:40                 ` Thibaut Verron
@ 2020-08-28 21:18                   ` Drew Adams
  0 siblings, 0 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-28 21:18 UTC (permalink / raw)
  To: thibaut.verron; +Cc: Wayne Harris, Emacs developers, Yuri Khan

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:09 Stefan Kangas
                   ` (6 preceding siblings ...)
  2020-08-27 17:27 ` Ulrich Mueller
@ 2020-08-28 22:06 ` Drew Adams
  2020-08-28 23:39   ` Gregory Heytings via Emacs development discussions.
  2020-08-30 23:59 ` Stefan Kangas
  8 siblings, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-28 22:06 UTC (permalink / raw)
  To: Stefan Kangas, Emacs developers

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"))



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 22:06 ` Drew Adams
@ 2020-08-28 23:39   ` Gregory Heytings via Emacs development discussions.
  2020-08-29  1:20     ` Stefan Kangas
  0 siblings, 1 reply; 95+ messages in thread
From: Gregory Heytings via Emacs development discussions. @ 2020-08-28 23:39 UTC (permalink / raw)
  To: emacs-devel


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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 23:39   ` Gregory Heytings via Emacs development discussions.
@ 2020-08-29  1:20     ` Stefan Kangas
  0 siblings, 0 replies; 95+ messages in thread
From: Stefan Kangas @ 2020-08-29  1:20 UTC (permalink / raw)
  To: Gregory Heytings, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 20:36               ` Drew Adams
  2020-08-28 20:40                 ` Thibaut Verron
@ 2020-08-29  8:39                 ` Yuri Khan
  2020-08-29 16:35                   ` Drew Adams
  1 sibling, 1 reply; 95+ messages in thread
From: Yuri Khan @ 2020-08-29  8:39 UTC (permalink / raw)
  To: Drew Adams; +Cc: Wayne Harris, Emacs developers

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-29  8:39                 ` Yuri Khan
@ 2020-08-29 16:35                   ` Drew Adams
  2020-08-29 17:01                     ` Thibaut Verron
  2020-08-29 18:25                     ` Yuri Khan
  0 siblings, 2 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-29 16:35 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Wayne Harris, Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-29 16:35                   ` Drew Adams
@ 2020-08-29 17:01                     ` Thibaut Verron
  2020-08-29 18:25                     ` Yuri Khan
  1 sibling, 0 replies; 95+ messages in thread
From: Thibaut Verron @ 2020-08-29 17:01 UTC (permalink / raw)
  To: Drew Adams; +Cc: Wayne Harris, Emacs developers, Yuri Khan

[-- 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 --]

^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-29 16:35                   ` Drew Adams
  2020-08-29 17:01                     ` Thibaut Verron
@ 2020-08-29 18:25                     ` Yuri Khan
  2020-08-29 20:19                       ` Drew Adams
  1 sibling, 1 reply; 95+ messages in thread
From: Yuri Khan @ 2020-08-29 18:25 UTC (permalink / raw)
  To: Drew Adams; +Cc: Wayne Harris, Emacs developers

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-29 18:25                     ` Yuri Khan
@ 2020-08-29 20:19                       ` Drew Adams
  0 siblings, 0 replies; 95+ messages in thread
From: Drew Adams @ 2020-08-29 20:19 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Wayne Harris, Emacs developers

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28  9:18       ` Stefan Kangas
  2020-08-28 13:00         ` Alfred M. Szmidt
@ 2020-08-29 23:08         ` James Cloos
  1 sibling, 0 replies; 95+ messages in thread
From: James Cloos @ 2020-08-29 23:08 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Alfred M. Szmidt, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-26 22:09 Stefan Kangas
                   ` (7 preceding siblings ...)
  2020-08-28 22:06 ` Drew Adams
@ 2020-08-30 23:59 ` Stefan Kangas
  2020-08-31  7:58   ` Gregory Heytings via Emacs development discussions.
  2020-08-31 14:19   ` Eli Zaretskii
  8 siblings, 2 replies; 95+ messages in thread
From: Stefan Kangas @ 2020-08-30 23:59 UTC (permalink / raw)
  To: Emacs developers

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


^ permalink raw reply related	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-28 19:16           ` Drew Adams
@ 2020-08-31  5:26             ` Alfred M. Szmidt
  2020-08-31  7:34               ` Gregory Heytings via Emacs development discussions.
  2020-08-31 12:02               ` Colin Baxter
  0 siblings, 2 replies; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-08-31  5:26 UTC (permalink / raw)
  To: Drew Adams; +Cc: stefan, cloos, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-31  5:26             ` Alfred M. Szmidt
@ 2020-08-31  7:34               ` Gregory Heytings via Emacs development discussions.
  2020-09-01 18:23                 ` Alfred M. Szmidt
  2020-08-31 12:02               ` Colin Baxter
  1 sibling, 1 reply; 95+ messages in thread
From: Gregory Heytings via Emacs development discussions. @ 2020-08-31  7:34 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: Drew Adams, stefan, cloos, emacs-devel


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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-30 23:59 ` Stefan Kangas
@ 2020-08-31  7:58   ` Gregory Heytings via Emacs development discussions.
  2020-08-31 14:19   ` Eli Zaretskii
  1 sibling, 0 replies; 95+ messages in thread
From: Gregory Heytings via Emacs development discussions. @ 2020-08-31  7:58 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs developers


>
> (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)))



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-31  5:26             ` Alfred M. Szmidt
  2020-08-31  7:34               ` Gregory Heytings via Emacs development discussions.
@ 2020-08-31 12:02               ` Colin Baxter
  1 sibling, 0 replies; 95+ messages in thread
From: Colin Baxter @ 2020-08-31 12:02 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: stefan, cloos, Drew Adams, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-30 23:59 ` Stefan Kangas
  2020-08-31  7:58   ` Gregory Heytings via Emacs development discussions.
@ 2020-08-31 14:19   ` Eli Zaretskii
  2020-08-31 14:46     ` Stefan Kangas
  1 sibling, 1 reply; 95+ messages in thread
From: Eli Zaretskii @ 2020-08-31 14:19 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-31 14:19   ` Eli Zaretskii
@ 2020-08-31 14:46     ` Stefan Kangas
  2020-08-31 14:52       ` Gregory Heytings via Emacs development discussions.
  2020-08-31 15:17       ` Eli Zaretskii
  0 siblings, 2 replies; 95+ messages in thread
From: Stefan Kangas @ 2020-08-31 14:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-31 14:46     ` Stefan Kangas
@ 2020-08-31 14:52       ` Gregory Heytings via Emacs development discussions.
  2020-08-31 15:17       ` Eli Zaretskii
  1 sibling, 0 replies; 95+ messages in thread
From: Gregory Heytings via Emacs development discussions. @ 2020-08-31 14:52 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Eli Zaretskii, emacs-devel


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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
       [not found]   ` <<83y2lux5hm.fsf@gnu.org>
@ 2020-08-31 14:53     ` Drew Adams
  2020-08-31 20:00       ` Gregory Heytings via Emacs development discussions.
  0 siblings, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-08-31 14:53 UTC (permalink / raw)
  To: Eli Zaretskii, Stefan Kangas; +Cc: emacs-devel

> > (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?



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-31 14:46     ` Stefan Kangas
  2020-08-31 14:52       ` Gregory Heytings via Emacs development discussions.
@ 2020-08-31 15:17       ` Eli Zaretskii
  2020-08-31 15:48         ` Stefan Kangas
  1 sibling, 1 reply; 95+ messages in thread
From: Eli Zaretskii @ 2020-08-31 15:17 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-31 15:17       ` Eli Zaretskii
@ 2020-08-31 15:48         ` Stefan Kangas
  0 siblings, 0 replies; 95+ messages in thread
From: Stefan Kangas @ 2020-08-31 15:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-31 14:53     ` Drew Adams
@ 2020-08-31 20:00       ` Gregory Heytings via Emacs development discussions.
  2020-09-01  3:22         ` Stefan Monnier
       [not found]         ` <b4cc3f5f-ef29-4b2c-b7f3-0a2572cd5869@default>
  0 siblings, 2 replies; 95+ messages in thread
From: Gregory Heytings via Emacs development discussions. @ 2020-08-31 20:00 UTC (permalink / raw)
  To: Drew Adams; +Cc: Eli Zaretskii, Stefan Kangas, emacs-devel


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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-31 20:00       ` Gregory Heytings via Emacs development discussions.
@ 2020-09-01  3:22         ` Stefan Monnier
       [not found]         ` <b4cc3f5f-ef29-4b2c-b7f3-0a2572cd5869@default>
  1 sibling, 0 replies; 95+ messages in thread
From: Stefan Monnier @ 2020-09-01  3:22 UTC (permalink / raw)
  To: Gregory Heytings via Emacs development discussions.
  Cc: Gregory Heytings, Eli Zaretskii, Stefan Kangas, Drew Adams

> 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




^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
       [not found]           ` <alpine.NEB.2.22.394.2009011047360453.11413@sdf.lonestar.org>
@ 2020-09-01 14:54             ` Drew Adams
  2020-09-01 17:00               ` Gregory Heytings via Emacs development discussions.
  0 siblings, 1 reply; 95+ messages in thread
From: Drew Adams @ 2020-09-01 14:54 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: Eli Zaretskii, Stefan Kangas, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* RE: Modernize frame-title-format: "%b - GNU Emacs"
  2020-09-01 14:54             ` Drew Adams
@ 2020-09-01 17:00               ` Gregory Heytings via Emacs development discussions.
  2020-09-01 20:31                 ` Stefan Monnier
  0 siblings, 1 reply; 95+ messages in thread
From: Gregory Heytings via Emacs development discussions. @ 2020-09-01 17:00 UTC (permalink / raw)
  To: Drew Adams; +Cc: Eli Zaretskii, Stefan Kangas, emacs-devel


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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-08-31  7:34               ` Gregory Heytings via Emacs development discussions.
@ 2020-09-01 18:23                 ` Alfred M. Szmidt
  0 siblings, 0 replies; 95+ messages in thread
From: Alfred M. Szmidt @ 2020-09-01 18:23 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: stefan, cloos, drew.adams, emacs-devel

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



^ permalink raw reply	[flat|nested] 95+ messages in thread

* Re: Modernize frame-title-format: "%b - GNU Emacs"
  2020-09-01 17:00               ` Gregory Heytings via Emacs development discussions.
@ 2020-09-01 20:31                 ` Stefan Monnier
  0 siblings, 0 replies; 95+ messages in thread
From: Stefan Monnier @ 2020-09-01 20:31 UTC (permalink / raw)
  To: Gregory Heytings via Emacs development discussions.
  Cc: Gregory Heytings, Eli Zaretskii, Stefan Kangas, Drew Adams

> 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




^ permalink raw reply	[flat|nested] 95+ messages in thread

end of thread, other threads:[~2020-09-01 20:31 UTC | newest]

Thread overview: 95+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <<CADwFkmnhA7TNqVpgG3jvPL+_33gYRwSK0z2ddvDpYXUu9qw-EQ@mail.gmail.com>
     [not found] ` <<E1kBBSl-0007bb-1K@fencepost.gnu.org>
     [not found]   ` <<CADwFkmmP_CwHk48=v2YQVG3ODMQsBjcqqnGU_8H-pMsw_4irrw@mail.gmail.com>
     [not found]     ` <<E1kBCpo-0006ol-R1@fencepost.gnu.org>
     [not found]       ` <<E1kBCsX-00049o-5Z@fencepost.gnu.org>
2020-08-27 15:05         ` Modernize frame-title-format: "%b - GNU Emacs" Drew Adams
     [not found]       ` <<CADwFkmn2mJ2Mns3qyLUa-uWjOEB6zpSB=x3M9nK8q5gidn6iPg@mail.gmail.com>
     [not found]         ` <<E1kBJzg-0001FK-Eb@fencepost.gnu.org>
2020-08-27 15:51           ` Drew Adams
2020-08-27 15:59             ` Alfred M. Szmidt
2020-08-27 16:42               ` Thibaut Verron
2020-08-27 17:23                 ` Alfred M. Szmidt
2020-08-27 17:50                   ` Thibaut Verron
2020-08-27 18:15                     ` Alfred M. Szmidt
2020-08-27 19:13                       ` Thibaut Verron
2020-08-27 19:20                         ` Yuri Khan
2020-08-27 17:49             ` Michael Albinus
2020-08-27 18:10               ` Alfred M. Szmidt
2020-08-27 18:19                 ` Michael Albinus
2020-08-27 18:10               ` Drew Adams
2020-08-27 18:22                 ` Michael Albinus
     [not found]             ` <<87a6yg9dyq.fsf@gmx.de>
     [not found]               ` <<E1kBMLt-00033R-SA@fencepost.gnu.org>
2020-08-27 18:14                 ` Drew Adams
2020-08-27 18:19                   ` Alfred M. Szmidt
2020-08-27 18:30                     ` Michael Albinus
     [not found]             ` <<<87a6yg9dyq.fsf@gmx.de>
     [not found]               ` <<<E1kBMLt-00033R-SA@fencepost.gnu.org>
     [not found]                 ` <<5f644f03-df12-4af0-8bd7-46152372df72@default>
     [not found]                   ` <<E1kBMUM-0003xd-MI@fencepost.gnu.org>
2020-08-27 18:34                     ` Drew Adams
2020-08-27 18:51                       ` Michael Albinus
2020-08-27 20:01                         ` Drew Adams
     [not found]     ` <<m3sgc7mvh8.fsf@carbon.jhcloos.org>
     [not found]       ` <<CADwFkmkOjpGh-=FKXkuX31Hcuzku3=QdHHXzRvtWs6gEkpAN1Q@mail.gmail.com>
     [not found]         ` <<E1kBdzV-0006sF-Ha@fencepost.gnu.org>
2020-08-28 19:16           ` Drew Adams
2020-08-31  5:26             ` Alfred M. Szmidt
2020-08-31  7:34               ` Gregory Heytings via Emacs development discussions.
2020-09-01 18:23                 ` Alfred M. Szmidt
2020-08-31 12:02               ` Colin Baxter
     [not found] ` <<83y2m01me0.fsf@gnu.org>
2020-08-27 15:10   ` Drew Adams
2020-08-27 15:14     ` tomas
2020-08-27 15:24       ` Drew Adams
2020-08-27 16:00         ` tomas
     [not found] ` <<CADwFkmk1dtqB8jjSgUHY0u0cetCUkhsDLTWF7JFT+8dxiAa3WA@mail.gmail.com>
     [not found]   ` <<83y2lux5hm.fsf@gnu.org>
2020-08-31 14:53     ` Drew Adams
2020-08-31 20:00       ` Gregory Heytings via Emacs development discussions.
2020-09-01  3:22         ` Stefan Monnier
     [not found]         ` <b4cc3f5f-ef29-4b2c-b7f3-0a2572cd5869@default>
     [not found]           ` <alpine.NEB.2.22.394.2009011047360453.11413@sdf.lonestar.org>
2020-09-01 14:54             ` Drew Adams
2020-09-01 17:00               ` Gregory Heytings via Emacs development discussions.
2020-09-01 20:31                 ` Stefan Monnier
2020-08-26 22:09 Stefan Kangas
2020-08-26 22:37 ` Stefan Monnier
2020-08-26 23:12   ` Drew Adams
2020-08-27  5:28 ` Yuri Khan
2020-08-27  5:55   ` Stefan Kangas
2020-08-27  6:56     ` Yuri Khan
2020-08-27 14:52       ` Stefan Monnier
2020-08-27 15:04         ` tomas
2020-08-27 15:17           ` Stefan Monnier
2020-08-27 16:18       ` Stefan Kangas
2020-08-27 17:02         ` Yuri Khan
2020-08-27 17:28         ` Colin Baxter
2020-08-28  0:17       ` Wayne Harris via Emacs development discussions.
2020-08-28  4:44         ` Yuri Khan
2020-08-28  8:56           ` Ulrich Mueller
2020-08-28 19:03           ` Drew Adams
2020-08-28 19:55             ` Yuri Khan
2020-08-28 20:36               ` Drew Adams
2020-08-28 20:40                 ` Thibaut Verron
2020-08-28 21:18                   ` Drew Adams
2020-08-29  8:39                 ` Yuri Khan
2020-08-29 16:35                   ` Drew Adams
2020-08-29 17:01                     ` Thibaut Verron
2020-08-29 18:25                     ` Yuri Khan
2020-08-29 20:19                       ` Drew Adams
2020-08-27  6:32 ` Alfred M. Szmidt
2020-08-27  7:20   ` Stefan Kangas
2020-08-27  8:00     ` Alfred M. Szmidt
2020-08-27  8:03       ` Alfred M. Szmidt
2020-08-27 14:35       ` Colin Baxter
2020-08-27 14:59       ` Stefan Kangas
2020-08-27 15:39         ` Alfred M. Szmidt
2020-08-28  1:04     ` James Cloos
2020-08-28  4:46       ` Yuri Khan
2020-08-28 19:09         ` Drew Adams
2020-08-28 19:22           ` Colin Baxter
2020-08-28 20:07             ` Drew Adams
2020-08-28  9:18       ` Stefan Kangas
2020-08-28 13:00         ` Alfred M. Szmidt
2020-08-29 23:08         ` James Cloos
2020-08-28 19:29       ` Tassilo Horn
2020-08-27  6:52 ` tomas
2020-08-27  9:07 ` Gregory Heytings via Emacs development discussions.
2020-08-27  9:14 ` Eli Zaretskii
2020-08-27 17:06   ` Pip Cet
2020-08-27 17:11     ` Eli Zaretskii
2020-08-27 17:36       ` Robert Pluim
2020-08-27 18:08         ` Drew Adams
2020-08-27 17:27 ` Ulrich Mueller
2020-08-27 17:52   ` Drew Adams
2020-08-28 22:06 ` Drew Adams
2020-08-28 23:39   ` Gregory Heytings via Emacs development discussions.
2020-08-29  1:20     ` Stefan Kangas
2020-08-30 23:59 ` Stefan Kangas
2020-08-31  7:58   ` Gregory Heytings via Emacs development discussions.
2020-08-31 14:19   ` Eli Zaretskii
2020-08-31 14:46     ` Stefan Kangas
2020-08-31 14:52       ` Gregory Heytings via Emacs development discussions.
2020-08-31 15:17       ` Eli Zaretskii
2020-08-31 15:48         ` Stefan Kangas

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).