[Top][All Lists]

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

Re: replacing a function with another one

From: Michael Heerdegen
Subject: Re: replacing a function with another one
Date: Sun, 09 Mar 2014 23:02:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

lee <address@hidden> writes:

> So I guess should use advice-add instead --- and I can´t figure out how
> to get that to work.  I need to access the argument passed to the
> function the advice is for, too.  I tried to find examples, without
> success.

IMHO the best description how the advice types work is in C-h f

> What I have is:
> (defadvice hi-lock-set-file-patterns (after
> lsl-hi-lock-set-file-patterns-advice activate)
>   (setq hi-lock-interactive-patterns (ad-get-arg 0)))

> How would I do the same with add-advice (or whatever is appropriate)?

 'hi-lock-set-file-patterns :after
 (lambda (patterns)
   (setq hi-lock-interactive-patterns patterns)))

You can also give the piece of advice a name like in defadvice:

 'hi-lock-set-file-patterns :after
 (lambda (patterns)
   (setq hi-lock-interactive-patterns patterns))
 '((name . lsl-hi-lock-set-file-patterns-advice)))

But you can instead just name the function instead of using an anonymous

(defun my-hi-lock-set-file-patterns-after-ad (patterns)
  (setq hi-lock-interactive-patterns patterns))

(advice-add 'hi-lock-set-file-patterns
            :after 'my-hi-lock-set-file-patterns-after-ad)

The advantage is that advices are functions with the new implementation,
so referring to arguments and return values works transparently, instead
of the need of using obscure pseudo variables.

See C-h f add-function to learn how the other advice types work.

> Yes, that´s exactly what I´m trying to avoid.  There is no way to detect
> when something changes in hi-lock.el in such a way that what I´m doing
> doesn´t work anymore, or is there?

No, not direct way.

> Suddenly finding out that what I´m trying to do doesn´t work anymore
> won´t be so great.

Indeed.  But if you only rely on documented behavior (docstring), the
risk is low, since changes are backwards compatible most of the time.

> One change I´m thinking about is keeping the highlighting-patterns in a
> separate buffer and applying them to several buffers.  That way, you can
> have several files that all use the same highlighting-patterns which
> were generated on the fly, centralised for the whole project (or some
> files of it).  That´ll probably require quite a few modifications.

Don't hesitate to ask when you've questions, but I think you're on a
good way.



reply via email to

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