Re: Help setting nadvice for indent-region

[Emanuel Berg]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> I am sorry, I did not follow that. The link I pasted
> was to a particular commit in my config,
> highlighting only 46 lines pertaining to this
> advice definition.

One should never expect anyone to follow links.
They are provided to say "this piece of code exists in
a file, it is compiled or otherwise in effect on some
system somewhere on the planet, if you against all
odds would like to use it or study it on your terms
I'm making this as easy for you as possible..." It is
just like scientific papers that have hundreds of
references no one ever bothers to read up on. So you
should do it, but always yank the code into the
message as well.

> On a PC, clicking that link should show you that
> highlighted section of 46 lines in a browser like
> Chrome/Firefox.

OK, drop them GUI browsers for Emacs-w3m, and stop
clicking on stuff - instead hit RET!

But it is OK to use a PC :)

> I simply find it convenient to read code on github
> with monospace fonts and syntax highlighting.

Mails/posts should always be written/read in
a monospace font. Try Emacs Gnus. As for syntax
highlighting (we call int font-lock) it is possible to
have snippets like that inline - not really necessary
(for messages) IMHO.

> I like the message telling me exactly what happened
> i.e. I indented the whole buffer or I eval'ed the
> whole buffer. But I can understand that that does
> not give much value. My initial purpose to use macro
> here was to learn how to use a macro.

Probably better to wait for a sharp situation to
arrive and do other stuff meanwhile. Because, if you
make up a solution to a made-up problem chances are
something won't work or won't work as intended and you
will then not be able to tell if it is the solution,
the method or the "made-up"-ness that failed (or
a combination).

> Just one important thing I'd like to point out in my
> code is the necessity to modify the orig-fn args
> ONLY when args is nil. This is to protect from
> corrupting the args when the advised fn is called by
> a wrapper fn. E.g. we do not want to override all 4
> args to eval-region (set by eval-defun) with just 2
> args when eval-region is being called by eval-defun.

You shouldn't focus on the technology. If a problem
that is very straightforward ends up in a complicated
discussion where everything is about technology and
nothing is about the problem, then the problem has not
been solved in a good way.

During the stone-age there were problems-solvers that
could solve all problems in the caves and around the
fireplace and even between the women in the
cave-society.

You can carry out a thought experiment to assess your
solution. If you can explain it to such
a problem-solving cave-dweller, then it is a good
solution. If he doesn't understand because of all the
advices, macros, arguments, and funcalls, it is
a bad solution.

-- 
underground experts united
http://user.it.uu.se/~embe8573