Re: point-min and 1

[David Kastrup <dak@gnu.org>]

martin rudalics <rudalics@gmx.at> writes:

>> As a general rule, using 1 rather than (point-min) tends to also
>> introduce bugs where code only works when the buffer is widened,
>
> What sort of bugs?  I suppose for every buffer
>
> 1 <= (point-min)
>
> holds invariantly.  If the buffer is narrowed, clip_to_bounds asserts
> that (goto-char 1) goes to (goto-char (point-min)) so these two idioms
> are semantically equivalent regardless of whether a buffer is narrowed
> or not.  Or what am I missing?

We have

goto-char is an interactive built-in function in `C source code'.

It is bound to <menu-bar> <edit> <goto> <go-to-pos>.

(goto-char POSITION)

Set point to POSITION, a number or marker.
Beginning of buffer is position (point-min), end is (point-max).

The return value is POSITION.

[back]

Can you guess from that what is done and returned when the buffer is
narrowed and you call (cons (goto-char 1) (point))?

From the DOC string, you could get an error thrown, or point is put
outside of the narrowed region and a number of different things.  It is
not at all clear that you get no error, and something like (1 . 90) is
returned.

In order to find that out, you have not only to read the doc string, but
the actual source code.

Whether or not the actual result turns out what it is, it is a lousy
idea to have to dig through the source code and all intricacies before
being able to tell what some code does.

The less information and detail you need to access before figuring out
the function of some code, the better.

Not least of all because you don't have dozens of accidental
dependencies if at one point of time some of the incidental semantics
are chosen to change.

-- 
David Kastrup