emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Run hook when variable is set


From: Stefan Monnier
Subject: Re: [PATCH] Run hook when variable is set
Date: Mon, 02 Feb 2015 10:57:39 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

OK, let's drop this whole idea.  Too much arguing for a negligible
feature already available via other packages.


        Stefan


>>>>> "Kelly" == Kelly Dean <address@hidden> writes:

> Stefan Monnier wrote:
>>> Without it, code which would be simply:
>>> (let-with-hook ((hooked-var foo))
>>> (body))
>> 
>>> would have to become:
>>> (setq tmp hooked-var)
>>> (setq-with-hook hooked-var foo)
>>> (body)
>>> (setq-with-hook hooked-var tmp)
>> 
>>> That's cumbersome.
>> 
>> No, if you really need it, it's a simple (cl-letf (((get-var) foo)) ...).

> I'm lost.

>> I think I'd rather have something yet a bit simpler:
>> - extend the `constant' bit to allow a "hooked" value, for efficiency.
>> Provide a function to set/unset this "hooked" annotation.
>> - when setting a hooked var, call a global Elisp function

> IIUC, you mean you want a centralized handler for all hooked vars, rather
> than enabling use of separate functions for different symbols like
> varhook does.

>>> That would fail in this case:
>>> (setq-default cursor-type 'bar)
>>> Later in the same Emacs session...
>>> (dynamic-cursor-mode)
>> 
>> As I already said, enabling dynamic-cursor-mode should set cursor-type to t.

> Come on. I acknowledged that just two lines later in my message. Please
> don't imply that I ignored it.

>>> then it won't work. If you instead do:
>>> (make-local-variable 'dynamic-cursor-mode)
>>> (dynamic-cursor-mode)
>>> then DCM is enabled only locally,
>> 
>> Not really.  Such usage is unsupported.  Users who do that get what they
>> deserve.

> Even though in the very next paragraph I showed a simple way to handle it
> properly even using your preferred way of implementing DCM?

> IOW, you would intentionally omit that proper handling just for the sake of
> aggravating users who want to control DCM buffer-locally?

>>> This has the edge case that if the mark happens to be active when you set
>>> cursor-type to 'bar, then the setting doesn't stick;
>> 
>> That's right.  I'm not worried about that either.

> Well yeah, I guess you can just declare it to not be a bug.

> This reminds me of the joke: How many Microsoft programmers does it take to 
> change a lightbulb?
> Answer: none. They just change the standard to darkness.


> And what about the fact that your way of implementing DCM shows the mode as 
> enabled, even though it effectively isn't, if the user set a non-standard 
> cursor-type in his init file? I guess you think that's user-friendly too.

> Splitting «technically enabled» from «actually in effect» results in a bad 
> API too. For any other mode foo, if you want to know whether the mode is in 
> effect, there's a variable to tell you, so the only expression you need is 
> simply:
> foo

> But for your version of DCM, there's no such variable, so you would require 
> the special-case expression:
> (and dynamic-cursor-mode
>      (or (eq cursor-type t)
>        (and dynamic-cursor-mode--set (eq cursor-type 'bar))))



reply via email to

[Prev in Thread] Current Thread [Next in Thread]