unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Howard Melman <hmelman@gmail.com>
To: 30978@debbugs.gnu.org
Subject: bug#30978: 25.3; Suggestion: define-minor-mode should define mode-lighter variable
Date: Sun, 25 Jul 2021 12:43:25 -0400	[thread overview]
Message-ID: <lysg029weq.fsf@Lumet.home> (raw)
In-Reply-To: <C0EA6366-1848-4EF9-A963-9197E672B4E6@gmail.com>

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Phil Sainty <psainty@orcon.net.nz> writes:
>
>>> Does anybody else have an opinion here?  The suggestion is to make
>>> define-minor-mode define a `foo-mode-lighter' variable that users can
>>> then change to easily change the lighters.
>>
>> It sounds like a good change.
>
> I just can't make up my mind here.  On the one hand, a
> `foo-mode-lighter' variable would make things easy and regular.  On the
> other hand, it means creating a new user option for each minor mode
> (i.e., a defcustom), and it means having these in `minor-mode-alist',
> which means one additional variable lookup (per minor mode) when
> creating the mode line.

Thanks for considering this.  If the performance impact of
having these variables in minor-mode-alist is significant,
then fine.  Otherwise IMHO "easy and regular" clearly
outweighs having more defcustoms (which seems better to me
anyway, I could use completion to see all the lighter
strings). 

>>> Or do we have a separate mechanism for this somewhere?
>>
>> We do in GNU ELPA (see https://www.emacswiki.org/emacs/DelightedModes
>> regarding the one I wrote, delight.el), but that and similar libraries
>> mostly exist because there wasn't something as trivial as a variable
>> to set.
>>
>> Delight also takes care of synchronising the label in `mode-line-menu'
>> (down-mouse-3 on `mode-line-modes'), as well as allowing custom names
>> for major modes via the same UI -- but providing an easy way to set
>> minor mode lighters was the actual reason for writing it.
>
> It sounds like delight is the right solution here -- it's a more
> complete solution, and people who want this can just install your
> package...
>
> So...  on the whole...  I think we shouldn't add the -lighter
> variables.  So I'm closing this bug report.

I agree that packages like delight, dim and diminish (and I
just learned about blackout) mostly exist because there
wasn't a "trivial" or "easy and regular" way to do this and
don't see how they're "more complete" than the proposal.. 

If the packages are the way to go, maybe one could be
included in emacs?  They've been around for several years
(diminish since '98). 

As it stands now, a user that just wants to eliminate
something like " ElDoc" or " ws" from their modeline won't
find the answer in the documentation. If they look for a
package to do this even the package descriptions as they
appear in list-packages don't have a common keyword to
search for: 

  blackout           Better mode lighter overriding
  delight            A dimmer switch for your lighter text
  dim                Change mode-line names of major/minor modes
  diminish           Diminished modes are minor modes with no modeline display

So they will have to do an internet search and then evaluate
which of 3 or 4 packages they want to use.  It's certainly
not "easy or regular". 

-- 

Howard






  reply	other threads:[~2021-07-25 16:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 20:11 bug#30978: 25.3; Suggestion: define-minor-mode should define mode-lighter variable Howard Melman
2019-07-14 13:40 ` Lars Ingebrigtsen
     [not found]   ` <CADwFkmk-oFgHAwgcZ=-utkBU303x4vF9c9vkuUfpkPinL7Q0KQ@mail.gmail.com>
2020-08-23 12:22     ` Lars Ingebrigtsen
2021-06-25 14:27       ` Lars Ingebrigtsen
2021-06-25 22:57         ` Phil Sainty
2021-07-25  7:59           ` Lars Ingebrigtsen
2021-07-25 16:43             ` Howard Melman [this message]
2021-07-28 15:31               ` Lars Ingebrigtsen
2021-07-28 19:10                 ` Howard Melman
2021-07-29 12:11                   ` Lars Ingebrigtsen
2021-07-28 20:00                 ` Kévin Le Gouguec

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=lysg029weq.fsf@Lumet.home \
    --to=hmelman@gmail.com \
    --cc=30978@debbugs.gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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