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

Drew Adams <drew.adams@oracle.com> writes:
>> 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.

Most things require some knowledge of the use case, but that doesn't
stop us from making statements or giving advice that may be relevant in
certain circumstances.

Things that might be useful to say: don't use a lighter if your mode is
likely to be always on for any user that uses it at all; don't use a
lighter if your mode provides immediate feedback that it is one
(completion!).



>> 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.

My thought was a something a bit richer; a cross-between "M-x
report-emacs-bug" and a survey. For this question, for example, it would
be good to know how many people are using rich-minority and for what
purpose.

> 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.

These are assertions. You might be right, you might not. But I would not
use "it all depends" as the basis for not making a decision. Always
leaving things to the users and saying "well, it's configurable" is not
a good way forward.

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

In the ideal world, we would establish practice on the basis of
evidence.

>
>> 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.

Do we? Where?


> 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.


Oh, I said "not often" not "in general". There are certainly examples.
Likewise, projectile has a dynamic lighter. viper-mode, interesting, has
a static lighter but changes the mode line in other ways.


> 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.

And clearly, in this case, it is useful. So the question is, can we make
more space for useful things?


>> 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.


I think you need to distinguish between "your judgement"-- in this case
that means mine, and "user judgement" as something that the user should
reasonably be expected to make a decision on. Expecting users to
unclutter the mode-line for themselves is not good.

What neither of us knows is a) do many users find the mode-line
cluttered b) do many users unclutter it for themselves and c) do they
always unclutter the same things.




>
> 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.


A mode-line with 100 lighters really would be cluttered.

Phil



  reply	other threads:[~2016-05-16 15:16 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                         ` use-package Drew Adams
2016-05-16 15:16                           ` Phillip Lord [this message]
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=87shxinici.fsf@russet.org.uk \
    --to=phillip.lord@russet.org.uk \
    --cc=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=kaushal.modi@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /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).