Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> (One other case I like keyboard macros is
> rearranging things, e.g., paragraphs, in a buffer;
> I open two windows with the same buffer, but with
> the point in different places, and record a macro
> which kills something in one window and yanks in the
> other one. Very handy.)

(defun kill-and-yank-other-window (beg end)
  (interactive "r")
  (kill-region beg end)
  (save-window-excursion
    (other-window 1)
    (yank) ))

> If you edit text, which is somehow “graphical”, why
> shouldn’t the code reflect the problem? Not that it
> has to, but IMHO there’s nothing wrong if it does.

It is good that the code is "graphical" (perhaps
"visual" is a better word) in terms of simple but
life-important features like font lock (syntax
highlighting) and indentation, as well as the
programmer's expert touch and personality to arrange
code his way. This makes it easier to *see* the code,
rather than having to *read* it all the time.
For example, when I look at Lisp, I don't read the
code, I only see blondes and brunettes and...

No, those are nice little things (I mean, the font
locks etc.) to make it pleasant and productive, and
because of that, they are very important despite
their littleness.

However, it is not good if structure and purpose is
expressed and controlled like that in a deeper sense.
The code - the functions and keywords - should
do that.

When you want to change something, you shouldn't
"rearrange" the code into some new pattern in the
fourth dimension of Nirvana, you should change
typically but a few function invocations or
variable settings.

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