Re: How to test if the current line contains only white-spache?

[Emanuel Berg <embe8573@student.uu.se>]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2015-11-19, at 14:54, Rolf Ade
> <rolf@pointsman.de>
> wrote:
>
>> Yes, this is, what my instinct also telling me.
>> But this instinct was trained by other programming
>> languages and environments. I'm aware, that it may
>> be not applicable to emacs lisp / emacs.
>
> And you're right: it's not.
>
>> Discussing programming concepts at such 'meta level'
>> is difficult. But maybe some may express their
>> thinking about this. Is this 'moving point around'
>> in emacs lisp programming code the "right thing" to
>> do [...]
>
> Yes it is.

I don't think you can be categorical about it.

`save-excursion' and `save-window-excursion' are there
because they are useful. But just because they are
useful doesn't mean they should always be used.

As for "side-effects" that is the phantom menace the
Haskell buffs came up with, when actually side effects
are the reason we use computers.

Rather, in this case it is clear which is preferable
of

    (save-excursion (beginning-of-line) (point))

and

    (line-beginning-position)

The code is easier and faster to write, read,
and understand.

This is even more true when the example isn't as basic
as that, but when everything appears in nested forms
and loops and what have you. If you rely on moving
point around, this will demand of you to be a better
programmer than you would have to be, less it will get
out of hands pretty quickly.

That is one aspect. The other aspect is that often
moving point to the correct place to extract some data
seems straightforward in the lab. In the field all
sorts of unexpected situations appear and suddenly
point doesn't land where it should (or remotely so!).
Now the code once again can quickly get out of hands
if you try to compensate if `looking-at' something
`forward-char' else - and so on: not good!

Note that save-excursion isn't only used to get data
but perhaps most often to seemingly reset the state
after something is done so tho the user is aware it
happened (because he struck the command) he won't be
bothered with the buffer flicking by in the process.

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