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

[Drew Adams]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Same point.  See above.