From: phillip.lord@russet.org.uk (Phillip Lord)
To: Kaushal Modi <kaushal.modi@gmail.com>
Cc: help-gnu-emacs@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: use-package
Date: Thu, 12 May 2016 22:04:58 +0100 [thread overview]
Message-ID: <87y47f7zt1.fsf@russet.org.uk> (raw)
In-Reply-To: <CAFyQvY2HzRTK0QDsZe5A5CaOajusmOhF3-o7TidTtMQuX1MiGg@mail.gmail.com> (Kaushal Modi's message of "Wed, 11 May 2016 11:42:34 +0000")
Kaushal Modi <kaushal.modi@gmail.com> writes:
> On Wed, May 11, 2016, 6:59 AM Phillip Lord
>
>> The question is, though, which is the most sensible default.
>>
>> Which kind of illustrates my point, I think. Most of your work is
>> switching things off!
>>
>> I think we can do a better job of the defaults, by simply moving to "no
>> lighter by default".
>>
>
> I would still say that the default would be to keep the lighters on. It is
> useful especially when people have installed some minor mode and have
> enabled that globally or locally without understanding the full
> implications. Then by simply glancing at the minor mode lighter list, they
> can get a hint as to what's different in the environment between when
> things are behaving as they expect vs the things they do not.
Maybe this is true, although if there are 5 lighters in the list, then
"glancing" doesn't really cover it.
> Also you saw just the list of minor mode lighters that I like to hide. It's
> very possible that someone else likes to hide the lighters I choose to show
> and show some of those that I am hiding. Overall when you overlay the
> choice of all emacs users (do an OR condition of everyone's choices), I
> would not be surprised if that result leaned towards showing almost all
> the lighters.
>
> We cannot set the defaults based on the preferences of just you and me. I
> think that it is more important to have those to help people debug stuff
> and avoid frustration.
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. Many applications have
something equivalent for "insert/overwrite", perhaps "caps lock" even
thought this normally changes the keyboard.
I agree that setting defaults is difficult, but "show everything in case
it is useful", is to my mind not sensible. 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.
I'm guilty of this. In my own pabbrev mode I add "pabbrev". Why? Because
I thought you were supposed to. What's the point? I mean, I know if it
is one because it offers expansions!
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.
> The list of minor mode lighters that I hide has grown over time. For few I
> was often confused on which ones I want to be shown vs which I do not. Also
> as my experience with elisp grew, I relied less on the lighters and more on
> C-h v minor-mode-name. But that does not justify turning the lighters off
> for everyone by default, even for people who may be just started using
> emacs. If the lighters are on, then they would at least know what question
> to ask.. Like "Hey, things are funny only when I have XYZ in the thing at
> the bottom".
>
> Here's the initial thinking:
> 1. Leave the defaults as they are now.
> 2. Add a customizable option to hide all lighters.
> 3. Allow user to customize a white list or black list of minor modes. So
> you might choose to show all lighters except a few in black list. Or you
> might choose to hide all except a few in white list.
>
> Thinking of that, may be rich-minority should be integrated into the core.
> But then, why do that when it is already included in GNU Elpa. We are
> anyways trying to keep only the very essential code in the core and put the
> useful, nice to have feature packages in Elpa. It's pretty straight forward
> to install that package today and configure as you need.
>
> So the final proposal would be to not hide the lighter by default and use
> the available packages like rich-minority to set user-specific lighters.
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. So
(Message pab MML yas Helm Abbrev Fill Narrow)
would change to:
(Message options[7])
Clicking on options[7] would give a menu
pabbrev --> Turn off
Turn on (for globalized only)
Help
MML --> Turn off
Help
(the current menu)
and so on.
Toggling (say) pabbrev on would give:
(Message Options[7: pabbrev on])
for a few seconds then back to
(Message Options[7])
Finally, some minor-modes would be "permanent lighters", which would
appear permanently visible (like now). So
(Message Options[7] Ovwrt)
My current list for these would be "Ovwrt", "Narrow" "Fill". Advice in
the manual would be: "Don't do this, unless you have a very good
reason".
Rich-minority and diminish are papering over the cracks. Too much is
happening in mode line. Adding configuration options is, I feel, dumping
the responsibility onto the user.
Think we can get this done in time for Emacs-25.1?
Phil
next prev parent reply other threads:[~2016-05-12 21:04 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 ` Phillip Lord [this message]
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 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y47f7zt1.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--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.
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.