GNU bug report logs - #9908
24.0.90; Improve mode-line's "flags" section

Previous Next

Package: emacs;

Reported by: Dani Moncayo <dmoncayo <at> gmail.com>

Date: Sun, 30 Oct 2011 09:51:02 UTC

Severity: wishlist

Tags: wontfix

Found in version 24.0.90

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9908 in the body.
You can then email your comments to 9908 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#9908; Package emacs. (Sun, 30 Oct 2011 09:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dani Moncayo <dmoncayo <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 30 Oct 2011 09:51:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.90; Improve mode-line's "flags" section
Date: Sun, 30 Oct 2011 10:48:41 +0100
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9908; Package emacs. (Sun, 30 Oct 2011 10:46:02 GMT) Full text and rfc822 format available.

Message #8 received at 9908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 9908 <at> debbugs.gnu.org
Subject: Re: bug#9908: 24.0.90; Improve mode-line's "flags" section
Date: Sun, 30 Oct 2011 06:42:55 -0400
> Date: Sun, 30 Oct 2011 10:48:41 +0100
> From: Dani Moncayo <dmoncayo <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9908; Package emacs. (Sun, 30 Oct 2011 11:29:01 GMT) Full text and rfc822 format available.

Message #11 received at 9908 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9908 <at> debbugs.gnu.org
Subject: Re: bug#9908: 24.0.90; Improve mode-line's "flags" section
Date: Sun, 30 Oct 2011 12:26:20 +0100
>> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9908; Package emacs. (Mon, 31 Oct 2011 09:32:01 GMT) Full text and rfc822 format available.

Message #14 received at 9908 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 9908 <at> debbugs.gnu.org
Subject: Re: bug#9908: 24.0.90; Improve mode-line's "flags" section
Date: Mon, 31 Oct 2011 05:29:45 -0400
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/




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9908; Package emacs. (Wed, 25 Aug 2021 12:27:01 GMT) Full text and rfc822 format available.

Message #17 received at 9908 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9908 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#9908: 24.0.90; Improve mode-line's "flags" section
Date: Wed, 25 Aug 2021 14:26:01 +0200
Eli Zaretskii <eliz <at> 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




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 25 Aug 2021 12:27:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 9908 <at> debbugs.gnu.org and Dani Moncayo <dmoncayo <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 25 Aug 2021 12:27:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 23 Sep 2021 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 209 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.