Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> A macro is a program, too, and it's editable as you
> know, but written in a different language.
> When I record a macro I get some code in the end,
> yet it's not elisp.

A macro is a program but is it in another language?
If the inputs are commands, and the commands are
Elisp, isn't the language actually a subset of Elisp?

And this is what I've said since day one, macros is
poor man's programming.

Or do you mean how that language is perceived
and/or displayed?

> That's what I meant by saying that macros help write
> code _using interactive editor facilities_ - that
> is, not directly typing language syntactic
> constructs. It's quicker and simpler to record
> a macro, but the cost of it is the lack of
> general usefulness.

It may be quicker if you do not make any mistakes and
if you can envision what to do from start to finish.
In Elisp you don't have to worry about the interactive
distinction and instead you are able to use the full
power of the tool Emacs. But yes, I'm sure some people
who did lots of it compared to the amount of Elisp
they did, it makes sense it is quicker for them.

> This is obvious, and I'm writing it because you time
> after time refuse to admit that sometimes macros are
> better than elisp. I suppose you have reasons to say
> that, that's why this discussion can be interesting
> to me.

The reason I have for saying that is that it is
logical: you can do everything with Elisp that you can
do with macros, but not remotely so the other
way around.

I also say that because I haven't seen any good
examples where a macro saves the day.

I also say that because of a more bigger view.
Nother else works like that. Say that ten guys are
digging a hole with shovels. That sounds pretty fun,
ey? Unfortunately, some guy thought that to be
inefficient so he constructed the excavator. Now, that
machinery does the job as well as the ten guys but it
doesn't look or work like the ten guys at all. This is
the Elisp approach. The macro approach would be to
construct ten robots that look exactly like the guys
and have them to the exact same thing to produce the
exact same result.

If A solves problem B, and I want to solve B in
another way, I don't think "how can I replicate A?",
instead I examine B to think how I can solve it in
terms of the problem itself. If I can't find
a solution, I might examine A to learn how to do it,
but not in order to exactly replicate it!

> Yes, thanks, that was a rhetorical question :-)

*nod* (note then smiley)

> Meant to underline that programs written in
> a language not general enough to handle all and
> everything also can be useful sometimes, and awk is
> a good example, I think.

Yeah, but are macros more specific than Elisp just
because they are less general?

No, I think this is rather something on the human side
of the equation. I want to type the actual commands
and see them appear in front of me. You, perhaps do
not care about that and have it all in your fingertips
and muscle memory. And that is interesting because I'm
all into fingertips and muscle memory (finger habits)
as well...

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