unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Chong Yidong" <cyd@gnu.org>,
	"João Távora" <joaotavora@gmail.com>,
	emacs-devel@gnu.org
Subject: Re: Redundant (harmful) duplication of run-hooks in define-globalized-minor-mode [patch]
Date: Fri, 18 Jan 2013 17:09:24 +0000	[thread overview]
Message-ID: <20130118170924.GA4719@acm.acm> (raw)
In-Reply-To: <jwv4nifbrol.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Thu, Jan 17, 2013 at 01:31:32PM -0500, Stefan Monnier wrote:
> > I'm still trying to come up with a reason somebody might want to turn on
> > the minor mode _before_ the major mode's hook has been run.

> The issue is how to locally turn off the globalized minor mode from
> a major-mode hook.  If the globalized mode is enabled after the
> major-mode hook, you basically can't do it without resorting to
> ugly gymnastics.

Ah, OK.

> I'm not completely sure what happens (and what should happen instead) in
> your scenario, but for the case described by João, where you don't just
> want to disable it in some modes, but you want to prevent it from ever
> being enabled in such modes, obviously the current approach
> fails similarly.

> A simple solution is to activate the minor mode late, and provide
> a `disable-foo-mode' variable, that can be set in the major mode hook.
> But it's kind of ugly because it requires another var and the user needs
> to know about that magic var.

Not enabling a globally-enabled mode in particular buffers is essentially
ugly, so whatever solution we come up with will be ugly too.

> Maybe we could do it this way:

> for a globalized minor mode `foo', before running the major-mode hook, a magic
> `disable-foo-mode' is set to nil.  A function is added to `foo-mode-hook'
> which sets this var to t when foo-mode is disabled.  And after running
> the major-mode hook, the globalized minor mode code checks the magic var
> to decide whether to enable the minor mode.

!!!!!!!!!!!!!!!

> This way, the user doesn't need to know about the extra magic var; she
> can just call (foo-mode -1) in her major-mode hook as she can now, but
> the minor-mode is really only activated late.

> It's also kind of ugly because of all the magic, but it's the best I can
> come up with so far.

I can't come up with anything better at the moment, either, but I can't
help feeling that there's something more fundamental about global minor
modes that we're missing.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



  parent reply	other threads:[~2013-01-18 17:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-13 19:28 Redundant (harmful) duplication of run-hooks in define-globalized-minor-mode Alan Mackenzie
2013-01-13 20:48 ` Dmitry Gutov
2013-01-14 16:30 ` Redundant (harmful) duplication of run-hooks in define-globalized-minor-mode [patch] Alan Mackenzie
2013-01-14 16:52   ` emacs24/auctex bug Camm Maguire
2013-01-14 23:58     ` Xue Fuqiao
2013-01-15  2:12   ` Redundant (harmful) duplication of run-hooks in define-globalized-minor-mode [patch] Stefan Monnier
2013-01-15 14:08     ` Alan Mackenzie
2013-01-17 13:17       ` João Távora
2013-01-17 17:51         ` Alan Mackenzie
2013-01-17 18:31           ` Stefan Monnier
2013-01-18 12:07             ` João Távora
2013-01-18 17:09             ` Alan Mackenzie [this message]
2013-01-31 11:04             ` Redundant (harmful) duplication of run-hooks in define-globalized-minor-mode [patch-2] Alan Mackenzie
2013-01-31 14:38               ` Stefan Monnier
2013-02-01 15:44                 ` Alan Mackenzie
2013-02-01 16:28                   ` Stefan Monnier
2013-02-01 19:53                     ` Alan Mackenzie
2013-02-01 20:09                       ` Achim Gratz
2013-02-01 20:15                         ` Alan Mackenzie
2013-02-01 23:17                         ` Stefan Monnier
2013-02-01 23:16                       ` Stefan Monnier
2013-02-03 22:14                         ` Alan Mackenzie

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=20130118170924.GA4719@acm.acm \
    --to=acm@muc.de \
    --cc=cyd@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@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 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).