use-package

use-package

[Uwe Brauer]

Hello

Using GNU emacs 25.1.50, emacs need some 20sec to start up, «thanks» to my
complicated init file.


Now I have heard that use-package could considerable shorten the startup
time.


My init file is structured in the following way

(defvar running-xemacs (string-match "XEmacs\\|Lucid" emacs-version))
(cond (running-xemacs
  	   (load-file "~/xemacs/init/xemacs_init.el")
   	   (setq custom-file "/home/oub/xemacs/init/custom-init.el")))

(cond ((and (not running-xemacs)
       (setq inhibit-x-resources t)
       (package-initialize)
       (setq custom-file "/home/oub/emacs/init/custom-init.el")
       (let ((gc-cons-threshold most-positive-fixnum))
	 (load-file "~/emacs/init/emacs_init.el")
	 (load-file "/home/oub/emacs/init/custom-init.el")))))

Now my real init file, emacs_init.el

contains calls to many official packages such as auctex, orgmode, gnus
to name a few. These calls I presume I am able to transfer to the
use-package syntax.

But I have also private files, with some hacks, one file with my global
keybindings etc

How do I treat those files?

Maybe somebody with experience in use-package could give me an advice?

thanks

Uwe Brauer 

Re: use-package

[Kaushal Modi]

>
> Now my real init file, emacs_init.el
>
> contains calls to many official packages such as auctex, orgmode, gnus
> to name a few. These calls I presume I am able to transfer to the
> use-package syntax.
>
> But I have also private files, with some hacks, one file with my global
> keybindings etc
>
> How do I treat those files?
>
> Maybe somebody with experience in use-package could give me an advice?
>

This probably has nothing to do with use-package. You can have a mix of
(use-package ..) and (require ..) forms.

I use use-package for all my packages. But I also `require' files like
setup-personal.el (which have a (provide 'setup-personal)), which I do not
commit to github.

https://github.com/kaushalmodi/.emacs.d/blob/d51b8bb267fd18978eed28e59a28006b235f75aa/init.el#L310-L311

Example use:

(require 'setup-personal nil :noerror)

If a setup-personal.el (with the right provide) is found in the load-path,
it will be required, else nothing will happen (no errors).

Then, within the setup-personal.el, I would be having use-package forms if
any.

Hope this helps.
-- 

-- 
Kaushal Modi

Re: use-package

[Uwe Brauer]

    > This probably has nothing to do with use-package. You can have a
    > mix of (use-package ..) and (require ..) forms.

    > I use use-package for all my packages. But I also `require' files
    > like setup-personal.el (which have a (provide 'setup-personal)),
    > which I do not commit to github.

    > https://github.com/kaushalmodi/.emacs.d/blob/d51b8bb267fd18978eed28e59a28006b235f75aa/init.el#L310-L311

    > Example use:

    > (require 'setup-personal nil :noerror)

    > If a setup-personal.el (with the right provide) is found in the
    > load-path, it will be required, else nothing will happen (no
    > errors).

    > Then, within the setup-personal.el, I would be having use-package
    > forms if any.

Thanks. Just one question, for example my emacs_keys file contains stuff
like

(defun some-funny functions ()
)
(global-set-key [(f1)] 'save-buffer)
(global-set-key [(f2)] 'some-funny-function)

(provide 'emacs_keys)

So using 

    -  use-package is possible?

    -  and if so: would it shorten startup?

thanks

Uwe Brauer 

Re: use-package

[Kaushal Modi]

>
> Thanks. Just one question, for example my emacs_keys file contains stuff
> like
>
> (defun some-funny functions ()
> )
> (global-set-key [(f1)] 'save-buffer)
> (global-set-key [(f2)] 'some-funny-function)
>
> (provide 'emacs_keys)
>
> So using
>
>     -  use-package is possible?
>

Yes. Assuming that your emacs_keys.el is already in the load-path (i.e. you
are able to successfully do (require 'emacs_keys), you can do instead

    (use-package emacs_keys)

    -  and if so: would it shorten startup?
>

Most likely, not.

use-package speeds up startup times by delaying the loading the packages
that you can afford to.. for example, you do not need to load org-mode
until you are in a buffer with org-mode major mode or you call one of the
commands like org-agenda that autoloads org-mode. So if you load org-mode
using use-package and its ":defer t" or ":commands (...)" or similar
load-deferring options, you will see an improvement in the startup time.

use-package, very broadly put, is syntax sugar, a very elaborate macro, in
a good way.

To understand what it does, type the below, place cursor after the closing
parenthesis and do M-x pp-macroexpand-last-sexp.

    (use-package org-mode)

Now do the same with

    (use-package org-mode
      :defer t)

And once again do it with

    (use-package org-mode
      :mode ("\\.org\\'" . org-mode))

Study the raw elisp that all of the 3 macros above expand to and understand
them. That, in conjunction with reading the documentation on
https://github.com/jwiegley/use-package will make you understand what
use-package exactly does and how it saves you startup time.

If it helps, you can also go through few of my setup-*.el files here (
https://github.com/kaushalmodi/.emacs.d/tree/master/setup-files ) and see
how I use use-package for various packages. You can ignore the :config and
:init blocks in my use-package blocks and focus only on blocks like :defer,
:mode, :commands, :bind, etc which help me speedup my emacs startup.


-- 

-- 
Kaushal Modi

Re: use-package

[Stefan Monnier]

> (defvar running-xemacs (string-match "XEmacs\\|Lucid" emacs-version))
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                         (featurep 'xemacs)

> contains calls to many official packages such as auctex, orgmode, gnus
> to name a few.  These calls I presume I am able to transfer to the
> use-package syntax.

What do you mean by "calls"?

In a normal setup, your config should not need to load either of Gnus,
Org, or AUCTeX, but only set things up so that they are configured (and
that they get loaded when needed, tho that should already be the case
without any local configuration anyway).


        Stefan

Re: use-package

[Stefan Monnier]

> use-package speeds up startup times by delaying the loading the packages
> that you can afford to..

In my point of view, the job that use-package does is only useful when
the corresponding package is poorly setup to start with.

IOW, if use-package is helpful, usually it indicates a shortcoming in
the package or in the way the package is installed.

> for example, you do not need to load org-mode until you are in
> a buffer with org-mode major mode or you call one of the commands like
> org-agenda that autoloads org-mode.

That's right.  But that's already the case without doing any config at
all (because org-mode is setup properly to start with), so you shouldn't
need use-package for that.

I see use-package as having 2 benefits:
- work around package shortcomings as described above.
- help the user structure his .emacs configuration.
I'd like to see those two parts separated, FWIW.


        Stefan

Re: use-package

[Kaushal Modi]

>
> In my point of view, the job that use-package does is only useful when
> the corresponding package is poorly setup to start with.


> IOW, if use-package is helpful, usually it indicates a shortcoming in
> the package or in the way the package is installed.
>

That, or the user installing the package is just not completely aware of
implications of during (require 'PKG-NAME) for all the installed packages.

I can talk of myself that when I began using emacs, I simply did (require
'PKG-NAME) for any new package I installed, because sometimes I got errors
like undefined variable blah at emacs startup. And using the require
magically solved the problem.

For instance, we cannot do (add-to-list 'package-archives '("org" . "
http://orgmode.org/elpa/") t) before doing (require 'package). Well, this
is a valid case where we need to do require first as package-archives does
not autoload package.

At one point, it became a "style" to require all the installed packages. I
had never head of eval-after-load at that time. Even if I had heard, I
would have thought that that's probably for "advanced" emacs user and I as
a newbie probably doesn't need to learn or use that.

use-package adds a simply syntactic sugar that does that "advanced stuff"
under the hood.

Another useful function that use-package uses is run-with-idle-timer using
which you can lazy load a package which you typically don't care about
loading immediately at startup.. like yasnippet; by using the :defer
keyword in use-package.

I am not qualified enough to judge if yasnippet could have been coded
better so that I didn't need to lazy load it. But delaying loading this
package made a significant difference to my emacs startup, especially
because I save and load desktop with about 50-60 files open. I do not need
yasnippet to load the snippets for all the major modes in those 50-60 files
immediately at startup.

That's right.  But that's already the case without doing any config at
> all (because org-mode is setup properly to start with), so you shouldn't
> need use-package for that.
>

That's correct. The syntactic sugar for eval-after-load applies here too.

(Also, it's easy to simply prevent loading of a package you suspect to be
misbehaving by adding :disabled keyword for that package's use-package
form. With that you prevent loading that package and also evaluating your
config for that package like keybindings, advices, overrides, wrapper
defuns, etc).


> I see use-package as having 2 benefits:
> - work around package shortcomings as described above.
> - help the user structure his .emacs configuration.
>

And also, get a new user acquaint themself to different ways by which a
package loading can be delayed using various use-package keywords like
:commands, :bind, :defer, :mode.


> I'd like to see those two parts separated, FWIW.
>

I don't understand why that is important.
-- 

-- 
Kaushal Modi

Re: use-package

[Stefan Monnier]

> For instance, we cannot do (add-to-list 'package-archives '("org" . "
> http://orgmode.org/elpa/") t) before doing (require 'package).  Well, this
> is a valid case where we need to do require first as package-archives does
> not autoload package.

I'm not saying there aren't valid cases.
I'm saying that when it's needed, we should treat it as a bug.
IOW I consider this specific case as a shortcoming of package.el.

Kind of like advice: if you need to use it, it's usually an indication
that the package lacks some customization hooks.

> I am not qualified enough to judge if yasnippet could have been coded
> better so that I didn't need to lazy load it.  But delaying loading this

yasnippet.el could probably easily be split into two files so only
a "smallish" file is loaded when you activate yasnippet, and the second
larger one is loaded only once you do trigger a snippet-expansion.

> package made a significant difference to my emacs startup, especially
> because I save and load desktop with about 50-60 files open.  I do not need
> yasnippet to load the snippets for all the major modes in those 50-60 files
> immediately at startup.

desktop.el is indeed a source of significant slowdown "by nature".
It's be worthwhile to try and improve desktop.el so that it can do the
loading more lazily.

E.g. we could add some kind of "virtual buffer" functionality, such that
list-buffers displays the buffer and C-x b lets you select it, even
though the buffer doesn't really exist yet, and only once you really
select it is the buffer created.

> (Also, it's easy to simply prevent loading of a package you suspect to be
> misbehaving by adding :disabled keyword for that package's use-package
> form. With that you prevent loading that package and also evaluating your
> config for that package like keybindings, advices, overrides, wrapper
> defuns, etc).

Yes, use-package helps you structure your config, indeed, and that's good.

> I don't understand why that is important.

Because as it stands, use-package encourages users to work around
packages's shortcomings rather than to report those.  It encourages the
perception that it's the user's responsability to setup autoloads and to
avoid all kinds of pitfalls.


        Stefan

Re: use-package

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> use-package speeds up startup times by delaying the loading the packages
>> that you can afford to..
>
> In my point of view, the job that use-package does is only useful when
> the corresponding package is poorly setup to start with.
>
> IOW, if use-package is helpful, usually it indicates a shortcoming in
> the package or in the way the package is installed.

I was curious about that "usually". So I had a quick look at my own
.emacs (I use use-package everywhere in it).

You are just about right -- it's about 50% of my cases that a
use-package form contains what is essentially a fix.

My main use for use-package that I think is good are:

- auto-install from ELPA
- using defer to idle loading.
- switching global modes on as well as loading them
- diminishing these global modes
- configuration -- for example, I have global bindings for org-mode
- lots of hooks
- setting load paths for my own packages which are *not* package
  installed


There are some issue here that could do with long term fixes.

For example, diminishing minor modes -- I think we have overloaded the
functionality of minor modes; many (company say, or eldoc) you either
want on or off. Do I really need mode-line space to be taken up telling
me that company is one? And is the mode-line the only place we can
display this information?

Global binding -- key-binding space is precious in Emacs, but perhaps
with tools like hydra, could allow better use of longer bindings.

Lots of hooks -- I regularly hear new users of Emacs complain "well, it
doesn't go X" where X are things like, for example, info on function
arguments or completion. Emacs does do both of these, but you have to
turn them on; perhaps, core Emacs should be more adventurous with its
defaults.

load-path for my own packages: I develop without installing and eval as
I go, but this means I develop source in one way and users get another.
Perhaps, we need better support given some lisp package source, for
rapidly generating a package and installing it, directly in
Emacs-lisp-mode.

Just some thoughts.

Phil

RE: use-package

[Drew Adams]

> For example, diminishing minor modes -- I think we have overloaded the
> functionality of minor modes; many (company say, or eldoc) you either
> want on or off. Do I really need mode-line space to be taken up telling
> me that company is one? And is the mode-line the only place we can
> display this information?

There are of course ways (e.g. packages) to reduce the mode-line
indications.  But I think it might be good if vanilla Emacs provided
a simple way for a user to not display particular lighters (mode
indications in the mode-line).

Re: use-package

[Uwe Brauer]

   > Yes. Assuming that your emacs_keys.el is already in the load-path
   > (i.e. you are able to successfully do (require 'emacs_keys), you
   > can do instead

   >     (use-package emacs_keys)

   >     -  and if so: would it shorten startup?

   > Most likely, not.

   > use-package speeds up startup times by delaying the loading the
   > packages that you can afford to.. for example, you do not need to
   > load org-mode until you are in a buffer with org-mode major mode or
   > you call one of the commands like org-agenda that autoloads
   > org-mode. So if you load org-mode using use-package and its ":defer
   > t" or ":commands (...)" or similar load-deferring options, you will
   > see an improvement in the startup time.

That sounds a bit like autoloads.

So the time you gain at startup you might loose on run time, do I
understand that correctly? Ok makes sense,
there is no such thing as a free lunch...

Re: use-package

[Uwe Brauer]

>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

   >> (defvar running-xemacs (string-match "XEmacs\\|Lucid" emacs-version))
   >                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >                          (featurep 'xemacs)


right, ancient stuff from Lucid times :'(

   >> contains calls to many official packages such as auctex, orgmode, gnus
   >> to name a few.  These calls I presume I am able to transfer to the
   >> use-package syntax.

   > What do you mean by "calls"?

Oh sorry I meant requires, variables setting and hooks.

   > In a normal setup, your config should not need to load either of Gnus,
   > Org, or AUCTeX, but only set things up so that they are configured (and
   > that they get loaded when needed, tho that should already be the case
   > without any local configuration anyway).

You mean autoload instead of require, or do you mean require instead of
explicate load-file? (I don't think I use load-file at all). My startup
time is around 22 sec (vs 2 sec for emacs Q). I just saw that I had a
lot of complains that the source files were newer than the elc files, so
I recompiled those files, did not help much now I have 19 sec. I think I
will try

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


See whether that helps.

Re: use-package

[Phillip Lord]

Drew Adams <drew.adams@oracle.com> writes:

>> For example, diminishing minor modes -- I think we have overloaded the
>> functionality of minor modes; many (company say, or eldoc) you either
>> want on or off. Do I really need mode-line space to be taken up telling
>> me that company is one? And is the mode-line the only place we can
>> display this information?
>
> There are of course ways (e.g. packages) to reduce the mode-line
> indications.  But I think it might be good if vanilla Emacs provided
> a simple way for a user to not display particular lighters (mode
> indications in the mode-line).

I don't think this is the right solution. Asking the user to choose
which lighters to hide is just passing the buck.

Currently my mode lighter is

Message pab MML yas Helm Abbrev Fill Narrow

pab == pabbrev is my own abbrev mode, but diminished
MML == is attachement
yas == yasnippet diminished
Helm == Completion
Abbrev == Another abbrev expansion
Fill == auto fill.
Narrow == is narrowing

Of these, pab is global, so why show it? MML is only and always on with
message, so why show it (right click functionality is in the main menu)?
yas is always on, so why show it? Helm is always on. Abbrev, not sure
why it is on. Narrow, actually I don't know what is being hidden in
message -- it's certainly not user functionality.

Only "Fill" tells me anything useful, since I turn this on and off in
the same buffer, and "Message", since knowing the mode is good.

Phil

Re: use-package

[Phillip Lord]

Uwe Brauer <oub@mat.ucm.es> writes:
>    > use-package speeds up startup times by delaying the loading the
>    > packages that you can afford to.. for example, you do not need to
>    > load org-mode until you are in a buffer with org-mode major mode or
>    > you call one of the commands like org-agenda that autoloads
>    > org-mode. So if you load org-mode using use-package and its ":defer
>    > t" or ":commands (...)" or similar load-deferring options, you will
>    > see an improvement in the startup time.
>
> That sounds a bit like autoloads.

It's similar but different. With autoloads, when you first use a
function in a package, the package loads, Emacs stalls. With defer, it
loads in the idle cycle.

I also use it for global minor-modes like Helm. Normally, it's loaded by
the time you want it.

> So the time you gain at startup you might loose on run time, do I
> understand that correctly? Ok makes sense, there is no such thing as a
> free lunch...

idle time, rather than run time. It's a good compromise.

Phil

RE: use-package

[Drew Adams]

> >> For example, diminishing minor modes -- I think we have overloaded the
> >> functionality of minor modes; many (company say, or eldoc) you either
> >> want on or off. Do I really need mode-line space to be taken up telling
> >> me that company is one? And is the mode-line the only place we can
> >> display this information?
> >
> > There are of course ways (e.g. packages) to reduce the mode-line
> > indications.  But I think it might be good if vanilla Emacs provided
> > a simple way for a user to not display particular lighters (mode
> > indications in the mode-line).
> 
> I don't think this is the right solution. Asking the user to choose
> which lighters to hide is just passing the buck.

Of course I did not mean obligating the user to manage lighters.
I do advocate making it easier for users to manage them, if they
want to.

> Currently my mode lighter is
> 
> Message pab MML yas Helm Abbrev Fill Narrow
> 
> pab == pabbrev is my own abbrev mode, but diminished
> MML == is attachement
> yas == yasnippet diminished
> Helm == Completion
> Abbrev == Another abbrev expansion
> Fill == auto fill.
> Narrow == is narrowing
> 
> Of these, pab is global, so why show it?

Why might a user want to show the lighter for a global minor
mode?  Some minor modes you will turn on and off, perhaps
even frequently.  For some of those you might well want to
know whether it is on or off.

This is no different than for a local minor mode, such as
overwrite mode.  You might well want to know whether a
particular mode is on.

It can depend on the mode and on the user.  There is no
one-size-fits-all, IMHO.  And that is true of global modes
as well as local ones.

> Only "Fill" tells me anything useful, since I turn this on and off in
> the same buffer, and "Message", since knowing the mode is good.

What's useful to see depends on the user and on the context.
That's really the point, IMO.

A library can of course choose not to have a lighter for some
mode (local or global).  But in the end, users too need to be
able to easily adjust things to suit their tastes and needs.

Re: use-package

[Kaushal Modi]

>
> > >> For example, diminishing minor modes -- I think we have overloaded the
> > >> functionality of minor modes; many (company say, or eldoc) you either
> > >> want on or off. Do I really need mode-line space to be taken up
> telling
> > >> me that company is one? And is the mode-line the only place we can
> > >> display this information?
> > >
> > > There are of course ways (e.g. packages) to reduce the mode-line
> > > indications.  But I think it might be good if vanilla Emacs provided
> > > a simple way for a user to not display particular lighters (mode
> > > indications in the mode-line).
> >
> > I don't think this is the right solution. Asking the user to choose
> > which lighters to hide is just passing the buck.
>

I also have a same opinion as Drew. Hiding minor mode lighters is very
subjective. You might find a particular mode lighter as useless but someone
else might be wanting that. So I would also leave it up to the users on
which lighters they want to hide.

Why might a user want to show the lighter for a global minor
> mode?  Some minor modes you will turn on and off, perhaps
> even frequently.  For some of those you might well want to
> know whether it is on or off.
>
> This is no different than for a local minor mode, such as
> overwrite mode.  You might well want to know whether a
> particular mode is on.
>
> It can depend on the mode and on the user.  There is no
> one-size-fits-all, IMHO.  And that is true of global modes
> as well as local ones.
>

+1

A library can of course choose not to have a lighter for some
> mode (local or global).  But in the end, users too need to be
> able to easily adjust things to suit their tastes and needs.
>

The rich-minority package in GNU Elpa (
https://elpa.gnu.org/packages/rich-minority.html ) is basically this:
Allows the user to hide the lighters they want AND also modify them to
their liking.

I do not like the extra spacing between the lighters and I choose each
lighter to be just one character (regular or unicode) (or 2 at max).

So I have this ( http://i.imgur.com/bHmMU1N.png ) using rich-minority.

(use-package rich-minority
  :config
  (progn
    (setq rm-blacklist
          '(" WK"        ; which-key
            " hc"        ; hardcore mode
            " AC"        ; auto-complete
            " vl"        ; global visual line mode enabled
            " Wrap"      ; shows up if visual-line-mode is enabled for that
buffer
            " Omit"      ; omit mode in dired
            " yas"       ; yasnippet
            " drag"      ; drag-stuff-mode
            " VHl"       ; volatile highlights
            " ctagsU"    ; ctags update
            " Undo-Tree" ; undo tree
            " wr"        ; Wrap Region
            " SliNav"    ; elisp-slime-nav
            " Fly"       ; Flycheck
            " PgLn"      ; page-line-break
            " ElDoc"     ; eldoc
            " GG"        ; ggtags
            " hs"        ; hideshow
            " hs+"       ;
            " ez-esc"    ; easy-escape
            " ivy"       ; ivy
            " h"         ; hungry-delete-mode
            ))
    (setq rm-text-properties '(("\\` Ovwrt\\'" 'face
'font-lock-warning-face))) ; default
    (add-to-list 'rm-text-properties '("\\` Abbrev\\'" 'display "​@")) ;
Abbrev
    (add-to-list 'rm-text-properties '("\\` Ind\\'"    'display "​*>")) ;
org indent
    (add-to-list 'rm-text-properties '("\\` Outl\\'"   'display "​ø")) ;
outline
    (add-to-list 'rm-text-properties '("\\` Server\\'" 'display "​Σ")) ;
Server
    (add-to-list 'rm-text-properties '("\\` μ\\'"      'display "​μ")) ;
modi-mode
    (add-to-list 'rm-text-properties '("\\` Wg\\'"     'display "​w")) ;
writegood
    (add-to-list 'rm-text-properties '("\\` =>\\'"     'display "​a")) ;
aggressive indent
    (add-to-list 'rm-text-properties '("\\` Vis\\'"    'display "​V")) ;
visible-mode
    (with-eval-after-load 'setup-symbola
      (if font-symbola-p
          (progn
            (add-to-list 'rm-text-properties '("\\` Tail\\'" 'display
"​🢛")) ; auto revert tail
            (add-to-list 'rm-text-properties '("\\` Temp\\'" 'display
"​𝘵")) ; temp
            (add-to-list 'rm-text-properties '("\\` rk\\'"   'display
"​▯")) ; region bindings
            (add-to-list 'rm-text-properties '("\\` (\\*)\\'" 'display
"​💡")) ; beacon
            (add-to-list 'rm-text-properties '("\\` Hi\\'"   'display
"​🞵"))) ; Hi-Lock
        (progn
          (add-to-list 'rm-text-properties '("\\` Tail\\'" 'display
"​Tail|"))
          (add-to-list 'rm-text-properties '("\\` Temp\\'" 'display "​t"))
          (add-to-list 'rm-text-properties '("\\` rk\\'"   'display "​r"))
          (add-to-list 'rm-text-properties '("\\` (\\*)\\'" 'display "​*"))
          (add-to-list 'rm-text-properties '("\\` Hi\\'"   'display
"​H")))))))

-- 

-- 
Kaushal Modi

RE: use-package

[Drew Adams]

> The rich-minority package in GNU Elpa ( 
> https://elpa.gnu.org/packages/rich-minority.html ) is basically this: 
> Allows the user to hide the lighters they want AND also modify them to
> their liking.

That is an example of what I meant by this, in my original msg here:

   There are of course ways (e.g. packages) to reduce the mode-line
   indications.

But vanilla Emacs should, I think, at least provide some easy way for
users to not display particular lighters.  (Better would be for it to
provide the flexibility that such packages offer.)

Re: use-package

[Stefan Monnier]

> You mean autoload instead of require,

Pretty much, yes.  Using `require' in your .emacs should generally not
be necessary (except for things like (require 'seq) or (require 'cl-lib)
which you may want in order to use cl-lib functions in your .emacs) and
is a significant source of slowness.

But for all those packages you mention, you shouldn't need to setup any
autoloads, because they should already be setup for you.


        Stefan

Re: use-package

[Phillip Lord]

Drew Adams <drew.adams@oracle.com> writes:

>> Currently my mode lighter is
>> 
>> Message pab MML yas Helm Abbrev Fill Narrow
>> 
>> pab == pabbrev is my own abbrev mode, but diminished
>> MML == is attachement
>> yas == yasnippet diminished
>> Helm == Completion
>> Abbrev == Another abbrev expansion
>> Fill == auto fill.
>> Narrow == is narrowing
>> 
>> Of these, pab is global, so why show it?
>
> Why might a user want to show the lighter for a global minor
> mode?  Some minor modes you will turn on and off, perhaps
> even frequently.  For some of those you might well want to
> know whether it is on or off.
>
> This is no different than for a local minor mode, such as
> overwrite mode.  You might well want to know whether a
> particular mode is on.
>
> It can depend on the mode and on the user.  There is no
> one-size-fits-all, IMHO.  And that is true of global modes
> as well as local ones.
>
>> Only "Fill" tells me anything useful, since I turn this on and off in
>> the same buffer, and "Message", since knowing the mode is good.
>
> What's useful to see depends on the user and on the context.
> That's really the point, IMO.
>
> A library can of course choose not to have a lighter for some
> mode (local or global).  But in the end, users too need to be
> able to easily adjust things to suit their tastes and needs.

At the moment, though, I think developers add a lighter because it's
just the way that things are done. Perhaps the default advice should be
"do not add a lighter to your mode, unless it's useful".

Phil

Re: use-package

[Phillip Lord]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> I also have a same opinion as Drew. Hiding minor mode lighters is very
> subjective. You might find a particular mode lighter as useless but someone
> else might be wanting that. So I would also leave it up to the users on
> which lighters they want to hide.

The question is, though, which is the most sensible default.



> So I have this ( http://i.imgur.com/bHmMU1N.png ) using rich-minority.
>
> (use-package rich-minority
>   :config
>   (progn
>     (setq rm-blacklist
>           '(" WK"        ; which-key
>             " hc"        ; hardcore mode

=== SNIP LOTS ===

>             " ivy"       ; ivy
>             " h"         ; hungry-delete-mode
>             ))
>     (setq rm-text-properties '(("\\` Ovwrt\\'" 'face
> 'font-lock-warning-face))) ; default
>     (add-to-list 'rm-text-properties '("\\` Abbrev\\'" 'display "​@")) ;
> Abbrev

=== SNIP LOTS ===

>           (add-to-list 'rm-text-properties '("\\` Hi\\'"   'display
> "​H")))))))


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

Phil

Re: use-package

[Phillip Lord]

Drew Adams <drew.adams@oracle.com> writes:

>> The rich-minority package in GNU Elpa ( 
>> https://elpa.gnu.org/packages/rich-minority.html ) is basically this: 
>> Allows the user to hide the lighters they want AND also modify them to
>> their liking.
>
> That is an example of what I meant by this, in my original msg here:
>
>    There are of course ways (e.g. packages) to reduce the mode-line
>    indications.
>
> But vanilla Emacs should, I think, at least provide some easy way for
> users to not display particular lighters.  (Better would be for it to
> provide the flexibility that such packages offer.)

I shall think about adding something!

Phil

Re: use-package

[Kaushal Modi]

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.

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.

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.

> --

-- 
Kaushal Modi

Re: use-package

[Phillip Lord]

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

Re: use-package

[Stefan Monnier]

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

If by "this" you mean change the doc, then it's possible.


        Stefan

RE: use-package

[Drew Adams]

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

Re: use-package

[Rusi]

On Friday, May 13, 2016 at 9:09:09 PM UTC+5:30, Drew Adams wrote:
> Making a blanket, one-size-fits-all judgment for everyone
> takes choice away from users. 

:
:

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


etc
Just consider me in the opposite camp.
Everything else being equal too much choice is a bad thing:

https://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice

One could go further and DEFINE freedom as choicelessness.
While I wont do that I will say that emacs is progressing from the
best software category to suxware category by offering too much bogus choices

- .emacs.d/init.el or .emacs 
- custom-file or let customize mess your init
- setq or customize
- half a dozen options to specify keybindings
- eval-after-load or add-hook or simple-setq (+prayer that the mode author 
followed norms)

I could go on
But I think you get the idea -- Choice is undesirable if there is any choice 
about making the choice

Most recent example of bogus choices
haskell mode has been upgraded to some new fancy beyond-comint stuff
But the old comint is still there -- if you like -- Choice after all is wonderful.
Result: What used to work OTB now needs to have explicit define-keys to make 
sure user chooses old or new interface

Re: use-package

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Think we can get this done in time for Emacs-25.1?
>
> If by "this" you mean change the doc, then it's possible.


No, I meant write the entire mode lighter presentation scheme; I was
kind of joking.

The doc, though, yes, I think that would be good to update, to at least
say "you don't have to have a lighter" and "here are some reasons why
you might not want one".

Phil

Re: use-package

[Stefan Monnier]

> The doc, though, yes, I think that would be good to update, to at least
> say "you don't have to have a lighter" and "here are some reasons why
> you might not want one".

On a related note: the INIT-VALUE LIGHTER KEYMAP optional args should
really be deprecated in favor of the use of keyword arguments.
Also, we should emphasize that in 99.9% of the cases, :init-value
and :keymap args should not be used.

Of course, we have the problem currently that if no keyword arg is
provided, we can't easily distinguish the BODY from the (potential)
INIT-VALUE, LIGHTER, and KEYMAP args.


        Stefan

Re: use-package

[Phillip Lord]

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

RE: use-package

[Drew Adams]

[-- 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 --]