From: John Mastro <john.b.mastro@gmail.com>
To: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: Re: Help setting nadvice for indent-region
Date: Mon, 8 Feb 2016 12:03:12 -0800 [thread overview]
Message-ID: <CAOj2CQTunApn3jmwL1y-qujTt-BAvRyiGSOk_n8cSayH9FEOPg@mail.gmail.com> (raw)
In-Reply-To: <87si145aru.fsf@debian.uxu>
Emanuel Berg <embe8573@student.uu.se> wrote:
> Macros and advices are absolutely at the next level
> compared to stapling defuns as another bricklayer, but
> just because it is more advanced doesn't make it
> better - it depends.
>
>> (defvar modi/region-or-whole-fns '(indent-region eval-region))
>>
>> (defun modi/region-or-whole-advice (orig &rest _)
>> (interactive)
>> (if (use-region-p)
>> (funcall orig (region-beginning) (region-end))
>> (funcall orig (point-min) (point-max))))
>>
>> (dolist (fn modi/region-or-whole-fns)
>> (advice-add fn :around #'modi/region-or-whole-advice))
>
> OK, if this is "simpler", I'd say my DWIM groyne is
> simpler still:
>
> (defun indent-region-dwim ()
> (interactive)
> (if mark-active
> (indent-region (mark) (point))
> (indent-region (point-min) (point-max) )))
I don't have strong feelings about this one way or the other, but the
points I would make in defense of advice are:
- It's "just" function composition, nothing scary
- Your solution requires you to define a new `dwim' function every
time you want overload a function like this, whereas with advice you
can simply add it to the list of functions to be adviced (assuming
it will be adviced in the same way).
> It it also more natural and "human-ish" to read
> without all the computer lingo (`funcall' etc.).
Avoid funcall because it has a fun-y (haha) name? This part I can't get
behind at all.
--
john
next prev parent reply other threads:[~2016-02-08 20:03 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 23:49 Help setting nadvice for indent-region Kaushal Modi
2016-02-05 23:58 ` Kaushal Modi
2016-02-06 0:00 ` Kaushal Modi
2016-02-06 0:30 ` Emanuel Berg
2016-02-06 3:31 ` Kaushal Modi
2016-02-06 10:43 ` Michael Heerdegen
2016-02-07 3:12 ` Kaushal Modi
2016-02-07 17:46 ` Kaushal Modi
2016-02-07 18:51 ` John Mastro
2016-02-08 0:03 ` Emanuel Berg
2016-02-08 4:22 ` Kaushal Modi
2016-02-08 17:05 ` Eli Zaretskii
2016-02-08 17:27 ` Kaushal Modi
2016-02-09 3:07 ` Emanuel Berg
2016-02-08 20:03 ` John Mastro [this message]
2016-02-08 23:13 ` Emanuel Berg
2016-02-11 14:02 ` Stefan Monnier
2016-02-11 17:36 ` Kaushal Modi
2016-02-11 18:10 ` Michael Heerdegen
2016-02-11 18:47 ` Kaushal Modi
2016-02-11 18:56 ` Kaushal Modi
2016-02-11 19:14 ` Michael Heerdegen
2016-02-11 20:15 ` Kaushal Modi
2016-02-11 20:38 ` Kaushal Modi
2016-02-12 14:09 ` Michael Heerdegen
2016-02-12 14:21 ` Michael Heerdegen
2016-02-12 16:02 ` Kaushal Modi
2016-02-12 19:04 ` Michael Heerdegen
2016-02-12 13:57 ` Michael Heerdegen
2016-02-11 19:03 ` Michael Heerdegen
2016-02-07 23:48 ` Emanuel Berg
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=CAOj2CQTunApn3jmwL1y-qujTt-BAvRyiGSOk_n8cSayH9FEOPg@mail.gmail.com \
--to=john.b.mastro@gmail.com \
--cc=help-gnu-emacs@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.
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).