bug#9908: 24.0.90; Improve mode-line's "flags" section

bug#9908: 24.0.90; Improve mode-line's "flags" section

[Dani Moncayo]

Severity: wishlist

Hi,

I'd like to propose some changes to the mode-line's "flags" section,
to make it more clear and readable:

1. In text-mode, the very first character in the mode-line is always a
dash.  Since it is adjacent to the "flags" section, users could think
that it is part of such section, i.e., that conveys some information.
To avoid such confusion, I propose to write a space in that spot.

2. The EOL flag is not consistent across platforms[a], and I don't see
the point of such inconsistency.  So I propose to use always the same
convention: ":", "\" and "/" for Unix, DOS, and MAC-type EOL formats.

3. When the buffer's default directory is local, the corresponding
flag is a dash, which is very unfortunate, because there can be other
dashes at both sides of that flag.  So, I propose to substitute the
dash for a space (the "@" would remain the same, of course).

4. In text-mode, The frame name is always preceded by a dash, which is
also confusing, because one could think that it means something.  I
propose either remove it (shifting the frame name 1 position to left)
or write a space in that spot.



In GNU Emacs 24.0.90.1 (i386-mingw-nt6.1.7601)
 of 2011-10-27 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.5)'


---- Footnotes ----

[a] Quotation from (info "(emacs)Mode Line"):

     The character after CS is usually a colon.  If a different string is
  displayed, that indicates a nontrivial end-of-line convention for
  encoding a file.  Usually, lines of text are separated by "newline
  characters" in a file, but two other conventions are sometimes used.
  The MS-DOS convention uses a "carriage-return" character followed by a
  "linefeed" character; when editing such files, the colon changes to
  either a backslash (`\') or `(DOS)', depending on the operating system.
  Another convention, employed by older Macintosh systems, uses a
  "carriage-return" character instead of a newline; when editing such
  files, the colon changes to either a forward slash (`/') or `(Mac)'.
  On some systems, Emacs displays `(Unix)' instead of the colon for files
  that use newline as the line separator.


-- 
Dani Moncayo

bug#9908: 24.0.90; Improve mode-line's "flags" section

[Eli Zaretskii]

> Date: Sun, 30 Oct 2011 10:48:41 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> I'd like to propose some changes to the mode-line's "flags" section,
> to make it more clear and readable:

I'd like to express an objection.  We already made the mode line look
very differently in the GUI sessions.  It is only prudent to wait for
a while before proposing further changes.  Personally, I hate programs
that change their look and feel every release.  I would not like to
see Emacs catch that particular disease.

> 1. In text-mode, the very first character in the mode-line is always a
> dash.  Since it is adjacent to the "flags" section, users could think
> that it is part of such section, i.e., that conveys some information.
> To avoid such confusion, I propose to write a space in that spot.

See 

  http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00709.html

where the rationale for leaving the dashes in the TTY sessions was
explained.  FWIW, I don't remember any complaints about this, so the
alleged user confusion does not seem to be present in practice.

> 2. The EOL flag is not consistent across platforms[a], and I don't see
> the point of such inconsistency.

The point is to alert the user to the fact that the EOL format of the
buffer or file is not "native" for his or her platform.  At the time,
this was important enough for Richard to explicitly ask for a change
to that effect.  I don't know if the reasons are still valid.  In any
case, these strings are customizable.

> So I propose to use always the same
> convention: ":", "\" and "/" for Unix, DOS, and MAC-type EOL formats.

Actually, a more logical choice would be '/' for Posix platforms, '\'
for DOS and Windows, and ':' for the Mac.  But I guess it's too late
for such changes.

> 3. When the buffer's default directory is local, the corresponding
> flag is a dash, which is very unfortunate, because there can be other
> dashes at both sides of that flag.  So, I propose to substitute the
> dash for a space (the "@" would remain the same, of course).

I don't see why this is unfortunate.  A space doesn't carry more or
less information than a dash: both mean there's nothing to show.  What
is important is not to have the dash signify anything in particular.

> 4. In text-mode, The frame name is always preceded by a dash, which is
> also confusing, because one could think that it means something.  I
> propose either remove it (shifting the frame name 1 position to left)
> or write a space in that spot.

Again, on a TTY we use dashes as a filler.  Please do not lobby for
removing the dashes from a TTY mode line, as the rationale was
explained in the above-mentioned URL.

bug#9908: 24.0.90; Improve mode-line's "flags" section

[Dani Moncayo]

>> I'd like to propose some changes to the mode-line's "flags" section,
>> to make it more clear and readable:
>
> I'd like to express an objection.  We already made the mode line look
> very differently in the GUI sessions.  It is only prudent to wait for
> a while before proposing further changes.  Personally, I hate programs
> that change their look and feel every release.  I would not like to
> see Emacs catch that particular disease.

IMHO, the changes I propose are pretty small from a look-and-feel POV,
and they still improve the readability of the flags.  See below.

>> 1. In text-mode, the very first character in the mode-line is always a
>> dash.  Since it is adjacent to the "flags" section, users could think
>> that it is part of such section, i.e., that conveys some information.
>> To avoid such confusion, I propose to write a space in that spot.
>
> See
>
>  http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00709.html
>
> where the rationale for leaving the dashes in the TTY sessions was
> explained.  FWIW, I don't remember any complaints about this, so the
> alleged user confusion does not seem to be present in practice.

I don't propose to remove the dashes that fill the unused space: In
this point, I'm just proposing to change the fist one because, as I
said, it is adjacent to the flags section (and the CS flags can be
dashes too), thus camouflaging the left boundary such section.

>> 2. The EOL flag is not consistent across platforms[a], and I don't see
>> the point of such inconsistency.
>
> The point is to alert the user to the fact that the EOL format of the
> buffer or file is not "native" for his or her platform.  At the time,
> this was important enough for Richard to explicitly ask for a change
> to that effect.  I don't know if the reasons are still valid.  In any
> case, these strings are customizable.

I see.  Personally, I'd prefer a consistent and concise convention.

>> So I propose to use always the same
>> convention: ":", "\" and "/" for Unix, DOS, and MAC-type EOL formats.
>
> Actually, a more logical choice would be '/' for Posix platforms, '\'
> for DOS and Windows, and ':' for the Mac.  But I guess it's too late
> for such changes.

I don't care, as long as the convention is concise and consistent
across platforms.

>> 3. When the buffer's default directory is local, the corresponding
>> flag is a dash, which is very unfortunate, because there can be other
>> dashes at both sides of that flag.  So, I propose to substitute the
>> dash for a space (the "@" would remain the same, of course).
>
> I don't see why this is unfortunate.  A space doesn't carry more or
> less information than a dash: both mean there's nothing to show.  What
> is important is not to have the dash signify anything in particular.

This dash is unfortunate for a similar reason that explained in point
#1: there can be other dashes at every side, so that it is harder to
identify each flag's boundaries.

>> 4. In text-mode, The frame name is always preceded by a dash, which is
>> also confusing, because one could think that it means something.  I
>> propose either remove it (shifting the frame name 1 position to left)
>> or write a space in that spot.
>
> Again, on a TTY we use dashes as a filler.  Please do not lobby for
> removing the dashes from a TTY mode line, as the rationale was
> explained in the above-mentioned URL.

This question is already answered above (in point #1).


-- 
Dani Moncayo

bug#9908: 24.0.90; Improve mode-line's "flags" section

[Richard Stallman]

I think this is the sort of change for which it is a good idea to poll
the users.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9908: 24.0.90; Improve mode-line's "flags" section

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

[all other cases elided]

> I don't see why this is unfortunate.  A space doesn't carry more or
> less information than a dash: both mean there's nothing to show.  What
> is important is not to have the dash signify anything in particular.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I agree with Eli's point about dashes in the TTY, and with his points
about the other flags.  I think the conclusion here is that none of the
proposed changes are clearly better than what we have today, and any
changes here have to be a lot better to justify changing them -- because
any changes in this area leads to user confusion and annoyance.

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no