unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: phillip.lord@russet.org.uk, Kaushal Modi <kaushal.modi@gmail.com>
Cc: help-gnu-emacs@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: RE: use-package
Date: Fri, 13 May 2016 08:38:52 -0700 (PDT)	[thread overview]
Message-ID: <6f3a39f9-216c-4cfd-9a26-b2fb12e8be8f@default> (raw)
In-Reply-To: <87y47f7zt1.fsf@russet.org.uk>

> It is certainly the case that the lighters are sometimes useful. But
> if by sometimes, we mean "occasionally" then it's an open question
> how sensible it is showing all of this information.

Sensible, here as elsewhere, is in the mind of the user.

Users should have an easy way to specify what behavior they want
for a given lighter.  Most modes etc. should _provide_ a lighter,
thus giving the user the possibility of choosing.  But again,
users do need an easy way to pick and choose.  It is typically
enough that a mode provide an option to show the lighter or not.
The mode designer decides on the default value of the option.
A user can override that default choice. 

> I agree that setting defaults is difficult, but "show everything
> in case it is useful", is to my mind not sensible.

Nothing is useful at that black-&-white level of oversimplification.

For most modes I think there probably is some use in providing a
lighter.  But yes, users need to be able to choose, for any given
lighter.  They can choose a lighter only if it exists to be chosen.

And yes, of course, developers of some modes will decide that a
lighter is not at all useful.

> Consider, the current information about lighters in the manual.
> "Minor Mode Conventions" says nothing; in fact, the only place
> I can find anything is in the documentation about
> `define-minor-mode' which says:
> 
>      The string LIGHTER says what to display in the mode line when the
>      mode is enabled; if it is ‘nil’, the mode is not displayed in the
>      mode line.
> 
> So no information about why should and should not appear.

What would you expect it to say?  Any consideration of whether to
provide a lighter requires some knowledge of the _particular_ mode.
It is up to the mode designer to judge whether it makes any sense
to provide a lighter.  It should be up to a user to decide whether
to show a provided lighter.

> One thing that would be nice would be some way of surveying Emacs users.
> Perhaps an ELPA package that we could update occasionally, and each
> update would be a new survey. Still, a separate issue.

A separate issue, yes.  But as it relates to this discussion, my
voice is against asking for some summary yes/no from users.  The
utility of a particular lighter is 100% dependent on the particular
mode.  And its utility to a particular user depends on that user
and possibly on different use contexts.

I would not want to see a rule established based on some survey.

> I would suggest something more radical.
> 
> We replace the current list of lighters with a single item, which
> when clicked on gives a menu of minor modes.

A lighter is meant to provide immediate information, directly and
continually, without having to ask for it (e.g. access a menu).
We already have menus that provide access to minor-mode info.

So I strongly disagree with your suggestion.  Among other things,
I have lighters that indicate more than two states (mode on/off).
And I would encourage this for other modes that might, in effect,
have multiple states.  It puts the lie to the idea that lighters
are not very useful in general.

For example, the Icicles the lighter, `Icy', changes to indicate
whether completion is available for the current minibuffer
reading and, if so, what kind of completion: lax/strict,
multi-command, multi-completion (those are not mutually exclusive).

Display of the lighter is optional, controlled by option
`icicle-highlight-lighter-flag’ (on by default).

During input reading without completion, the lighter is not
highlighted - it just tells you that Icicle mode is on.  It is
highlighted red (by default) during completion.

`+' is appended to it (`Icy+') during multi-command completion
(meaning you can act on multiple candidates)  `||' is appended
if completion candidates are multi-completions (meaning that
you can match parts of a multi-part candidate, separately or
together).

The lighter is boxed (overline+underline) for strict completion.
If the list of candidates shown in `*Completions*' is currently 
truncated then the lighter is suffixed by `...'.  The lighter
text is `Icy' for case-sensitive completion and `ICY' when
case-insensitive.

https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#CompletionStatusIndicators

This lighter thus communicates a fair amount of info using
only a few characters.  This is no doubt not common, but I'd
bet that some other modes also could usefully provide more
info in a lighter than just on/off.

I do the same thing for Isearch (not really a mode, but it
does use a lighter).  With Isearch+, the lighter is `Isearch'
for case-sensitive search and `ISEARCH' for case-insensitive.
The lighter also indicates, by using faces, whether search
has wrapped or overwrapped.  By default, for wrapped the
lighter has a blue overline, and for overwrapped it has a
deep-pink overline and wavy underline.

https://www.emacswiki.org/emacs/IsearchPlus

> Advice in the manual would be: "Don't do this, unless you
> have a very good reason".

I disagree.  Most modes probably should provide a lighter.

But whether the lighter for a given mode is very, slightly,
or not at all useful to a particular user in a particular
context is for that user to decide.  And context, including
how many modes/lighters are currently available, can be
important.

> Rich-minority and diminish are papering over the cracks.
> Too much is happening in mode line.

Again, a user judgment.  It sounds like too much, for you,
was happening in your mode line.  Emacs is rich in use
cases and users.  Your mode line might bother me too - or
it might not.

> Adding configuration options is, I feel, dumping
> the responsibility onto the user.

Making a blanket, one-size-fits-all judgment for everyone
takes choice away from users.  Advice from the manual that
most modes should not use a lighter ("Don't do this, unless
you have a very good reason") would mean that users would
generally not have a choice: no lighter => no choice.

> Think we can get this done in time for Emacs-25.1?

I hope we never "get this done".  Just one opinion.

It sounds like you and your mode line have not really
gotten along very well, and you've looked for a way to
master it.  That does not imply that mode developers
should in general not provide lighters or that users
generally find them useful and annoying.

You know, there are packages that give Emacs a spartan,
minimal look & feel - no title bar, menu bar, tool bar,
fringes, mode line,...  That's great - for those users
who want such a look & feel.

I'm all for such a possibility.  What I am not for is
Emacs imposing or recommending this or that look & feel
in some blanket way.

Let a hundred flowers bloom.  Vive the mode line.



  parent reply	other threads:[~2016-05-13 15:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-02 17:07 use-package Uwe Brauer
2016-05-02 18:47 ` use-package Kaushal Modi
2016-05-03 10:47   ` use-package Uwe Brauer
2016-05-03 14:01     ` use-package Kaushal Modi
2016-05-03 22:28       ` use-package Stefan Monnier
2016-05-04  3:33         ` use-package Kaushal Modi
2016-05-04 12:09           ` use-package Stefan Monnier
2016-05-04 16:22         ` use-package Phillip Lord
2016-05-04 16:44           ` use-package Drew Adams
2016-05-05 13:34             ` use-package Phillip Lord
2016-05-05 14:00               ` use-package Drew Adams
2016-05-05 15:56                 ` use-package Kaushal Modi
2016-05-05 16:12                   ` use-package Drew Adams
2016-05-10  9:20                     ` use-package Phillip Lord
2016-05-10  9:18                   ` use-package Phillip Lord
2016-05-11 11:42                     ` use-package Kaushal Modi
2016-05-12 21:04                       ` use-package Phillip Lord
2016-05-13 11:56                         ` use-package Stefan Monnier
2016-05-14 22:27                           ` use-package Phillip Lord
2016-05-15  3:22                             ` use-package Stefan Monnier
2016-05-13 15:38                         ` Drew Adams [this message]
2016-05-16 15:16                           ` use-package Phillip Lord
2016-05-16 16:49                             ` use-package Drew Adams
     [not found]                         ` <mailman.2761.1463153947.7477.help-gnu-emacs@gnu.org>
2016-05-14  7:37                           ` use-package Rusi
2016-05-10  9:13                 ` use-package Phillip Lord
2016-05-05  9:51       ` use-package Uwe Brauer
2016-05-05 13:38         ` use-package Phillip Lord
2016-05-03 22:21 ` use-package Stefan Monnier
2016-05-05 10:15   ` use-package Uwe Brauer
2016-05-05 23:41     ` use-package Stefan Monnier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=6f3a39f9-216c-4cfd-9a26-b2fb12e8be8f@default \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=kaushal.modi@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=phillip.lord@russet.org.uk \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).