From: Drew Adams <drew.adams@oracle.com>
To: phillip.lord@russet.org.uk
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 09:49:08 -0700 (PDT) [thread overview]
Message-ID: <60508da2-0a78-485a-a749-6fe1a37ff457@default> (raw)
In-Reply-To: <87shxinici.fsf@russet.org.uk>
[-- Attachment #1: Type: text/plain, Size: 10957 bytes --]
> >> 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;
Yes, but... (1) I would think that might be obvious. But we could
consider saying that in the doc. (2) On the other hand, some users
might still want to use the lighter, instead of the menu-bar, to
access the mode menu. If the mode does not _provide_ a lighter then
those users are out of luck.
Even a simple suggestion such as this one becomes nuanced, once we
scratch the surface a little. How many users will want to use the
lighter menu? Dunno. But why not give them the possibility?
Getting rid of the lighter at mode design-time precludes the
possibility of a user using it.
Better, in general: late binding. User-time, not design-time binding.
That's pretty much what Emacs is all about. But of course, it helps
to give users easy ways to choose etc. That too is what Emacs is
about. You have correctly identified a problem for lots of users,
I'm sure. I don't, so far, agree with the solution you proposed.
> don't use a lighter if your mode provides immediate feedback that
> it is one (completion!).
I don't understand that. Can you elaborate?
> >> 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.
What would we do with such info about `rich-minority' mode use (for
example)?
(I can imagine that the _maintainer_ of `rich-minority' mode might
be able to benefit from such info.)
> > 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.
Giving users control does not imply that we cannot provide useful
default behavior and helpful information. It does not mean we
throw users under the bus and say, "You're on your own! You figure
it out."
> > 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.
Of course. "Evidence" can be lots of things. Even surveys can
sometimes be helpful - or meaningless or misleading or a hindrance.
> >> 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?
On the mode-line lighter, for one place. Attached are menus for
Icicle mode, a minor mode, and Dired, a major mode, (e.g. from Dired+).
A mode's lighter menu is typically the same as its menu-bar menu.
A user need not show the menu-bar to get access to the menu ... if
s?he has the lighter. (And at least for menu access, vice versa:
if s?he shows the menu-bar then s?he doesn't need the lighter menu.)
Some modes, such as Dired, have multiple menu-bar menus, and the
mode-line menu typically gives you access to all of them. Dired has
5 menu-bar menus, and the lighter menu has 5 submenus, as shown in the
attachment. (The complete Dired+ menus are shown here:
https://www.emacswiki.org/emacs/DiredPlus#SubdirMenu).
> > 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.
Discouraging the use of lighters does not go in the direction of
encouraging more useful lighters. (Same goes for menus and other
UI elements intended to be helpful.)
There are plenty of Emacs features that are "not often" used as
well as they could be.
`defcustom' :type is a good example. There are lots of lousy
(lazy-programmer) defcustom :type specs out there. But that's
not a reason to discourage the use of :type or encourage only
simplistic use of it (which is pretty much useless).
The fact that there are bad, lazy, or useless lighters or menus
or whatever is not a reason to discourage the use of lighters
or menus or whatever. It is a reason to encourage _better_
lighters etc.
If we add any further direction to the doc about mode-line
lighters it should be to mention _what they are good for_ and
_what you can do with them_. It is also fine to remind mode
designers that if such things just do not apply to their case
for some reason then they might consider not providing a lighter.
Doing that should make clear to anyone when it might not be so
useful to use a lighter. That's very different from a blanket
statement that discourages their use or tells mode designers
that they probably should not add a lighter.
> And clearly, in this case, it is useful. So the question is,
> can we make more space for useful things?
Yes, but again:
1. Not just make more space for useful things, but make things
that are there more useful.
2. The designer of a mode should be aware of what a lighter
is good for. And, as you say, s?he should realize that
a lighter that is not very useful can get in the way of
other mode-line info.
3. Users should have easy ways to control which lighters are
actually expressed (used), and when. Implementing that is
where we might want to put more effort. Today, such easy
ways do not really exist, AFAIK.
4. Users can choose whether a lighter gets used _only if it
exists_. No lighter => no user choice. Discouraging the
provision of a lighter is not the way to go. Most modes,
IMO, _should_ provide lighters. But that does not imply
that most users will want to show most modes most of the
time. What's missing is #3: easy control.
The problem is not the provision of lighters by mode designers.
The problem is insufficient, easy control of lighters by users.
> >> 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.
Allowing them to "unclutter" - allowing them to choose what to
show and when to show it, is not _expecting_ them to unclutter.
What is true is that today it is not so easy for a user to control
what lighters are shown, and when (in what contexts etc.). But to
have such a possibility (user choice) the lighters need to exist.
The thing that needs to be done is to work on providing easy ways
for users to control this. Not just to discourage the existence
of lighters.
> What neither of us knows is a) do many users find the mode-line
> cluttered
My guess is yes.
> b) do many users unclutter it for themselves
My guess is not most. See above - it is not so easy to do that.
You can use one of the packages that lets you turn off certain
lighters, but those are, so far, fairly large hammers, AFAIK.
And they are probably not as well known as they could be.
Most users (a) probably do not use a zillion modes at once,
(b) probably never look at the lighters, and (c) probably
have no clue (1) what lighters are good for or (2) how to
control which lighters are used. (I'd even guess that many,
if not most, Emacs users rarely, if ever, look at the
mode-line.)
> and c) do they always unclutter the same things.
My guess is yes and no. There are probably some lighters
that most users (who unclutter) turn off. There are probably
other lighters that different users treat in different ways.
> > 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.
Agreed. (But then, there are folks who live with and even
love clutter...)
Housekeeping by individual users should be kept possible and
made easy. Emacs users do not need an overriding housekeeper
cleaning up for them in ways they don't control or understand.
Providing users better, and easier control, and providing
mode designers info about what can make for a useful lighter,
would be helpful. Just telling the latter that they probably
should not provide a lighter for their mode is a step backward,
not forward, IMO.
Just one opinion.
[-- Attachment #2: throw-Dired-lighter-menu.png --]
[-- Type: image/png, Size: 2961 bytes --]
[-- Attachment #3: throw-Icy-lighter-menu.png --]
[-- Type: image/png, Size: 15296 bytes --]
next prev parent reply other threads:[~2016-05-16 16:49 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 ` use-package Phillip Lord
2016-05-16 16:49 ` Drew Adams [this message]
[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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60508da2-0a78-485a-a749-6fe1a37ff457@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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.