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

[Rolf Ade]

Emanuel Berg <embe8573@student.uu.se> writes:
> 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.

Nah, it's not that easy.

("I don't think you can be categorical about it." ;-)

> 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.

Yes. That are general principles and they are important judgement rules
for me. (I'd sort it understand, read, write, but anyway.)

> 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.

Well, yeah. If you start digging a bit more into emacs lisp programming,
as I do atm, a lot of details showing up. While I enjoy that emacs, the
editor, mostly do The Right Thing depending on the "context" (e.g mode
of the buffer) it makes me nervous that within emacs, the programming
enviroment, the effect of my elisp code often depends on settings and
circumstances that are not under my (the programmer) control. (And more
important I may not know about. The one I know about I'm able to
handle.)

In the current, very simple case ("How to test if the current line
contains only white-space?") I learned the difference between
looking-at and looking-at-p. At some stage I used beginning-of-line-text
and quickly realized that the result of that defun depends on
adaptive-fill-mode being on or off. And so on. 

> 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!

Yeah. See above.