all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Gregory Heytings <ghe@sdf.org>
Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefan@marxist.se>,
	emacs-devel@gnu.org
Subject: RE: Modernize frame-title-format: "%b - GNU Emacs"
Date: Tue, 1 Sep 2020 07:54:31 -0700 (PDT)	[thread overview]
Message-ID: <d0456adb-a0ef-441b-b83f-b321ccebb502@default> (raw)
In-Reply-To: <alpine.NEB.2.22.394.2009011047360453.11413@sdf.lonestar.org>

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



  parent reply	other threads:[~2020-09-01 14:54 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=d0456adb-a0ef-441b-b83f-b321ccebb502@default \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=ghe@sdf.org \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.