Re: point-min and 1

[martin rudalics]

> 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))?

No.  The doc-string is incomplete in this regard.  But a similar thing
happens when I want to go to a marker and that marker's position is not
within the accessible portion of the buffer.  (And no, I see no need to
enhance the doc-string.  It's all in the Elisp manual.)

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

I hope you don't expect me to dispute anything you say here ;-)

But all these arguments apply as well when you call (goto-char 1) in a
widened buffer.  One case against I could come up with is, that in a
narrowed buffer referential transparency is lost because

(goto-char (+ 1 1))

is not equivalent to

(goto-char (+ (point-min) 1))

but I've been told once that referential transparency does not have very
high priority within the development of Emacs.

martin