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

Previous Next

Full log

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

Previous Next

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