point-min and 1

point-min and 1

[Eli Zaretskii]

> Date: Mon, 10 Aug 2009 17:42:50 -0400
> From: emacs-diffs-request@gnu.org
> 
>    ;; Move to the specified line number in that buffer.
>    (save-restriction
>      (widen)
> -    (goto-char 1)
> +    (goto-char (point-min))

Can `(goto-char (point-min))' be different from `(goto-char 1)' after
a call to `widen'?

Re: point-min and 1

[martin rudalics]

 > Can `(goto-char (point-min))' be different from `(goto-char 1)' after
 > a call to `widen'?

simple.el should not promote bad programming style ;-)

martin

Re: point-min and 1

[Eli Zaretskii]

> Date: Tue, 11 Aug 2009 11:18:44 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
>  > Can `(goto-char (point-min))' be different from `(goto-char 1)' after
>  > a call to `widen'?
> 
> simple.el should not promote bad programming style ;-)

What's bad about it?

Re: point-min and 1

[martin rudalics]

 >>  > Can `(goto-char (point-min))' be different from `(goto-char 1)' after
 >>  > a call to `widen'?
 >>
 >> simple.el should not promote bad programming style ;-)
 >
 > What's bad about it?

The call to `widen' is of no importance here.  As a matter of fact,
`(goto-char (point-min))' and `(goto-char 1)' are operationally
equivalent - they "always" move point to the same buffer position
regardless of whether the buffer was narrowed or not.

IMHO writing `(goto-char 1)' is bad style because it exhibits a low
level detail of Elisp implementation, namely that it sees buffer
positions as numbers counted from 1.  I think Elisp code - and in
particular code in simple.el which might be used as some kind of
reference code for people starting to speak Elisp - should hide such
details wherever it can.

martin

Re: point-min and 1

[Eli Zaretskii]

> Date: Wed, 12 Aug 2009 10:55:58 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> IMHO writing `(goto-char 1)' is bad style because it exhibits a low
> level detail of Elisp implementation, namely that it sees buffer
> positions as numbers counted from 1.

ELisp code is full of such exposure, and not only in buffer
positioning.  Trying to change this is tantamount to fighting Quixotic
wars, IMO.

OTOH, replacing a constant with a function call might make a
difference.

Re: point-min and 1

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> IMHO writing `(goto-char 1)' is bad style because it exhibits a low
>> level detail of Elisp implementation, namely that it sees buffer
>> positions as numbers counted from 1.
>
> OTOH, replacing a constant with a function call might make a
> difference.

(point-min) has its own byte-code, so it's essentially the same speed as
a constant.

-miles

-- 
Any man who is a triangle, has thee right, when in Cartesian Space,
to have angles, which when summed, come to know more, nor no less,
than nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: point-min and 1

[Daniel Colascione]

On Wednesday 12 August 2009, Eli Zaretskii wrote:
> > From: martin rudalics <rudalics@gmx.at>
> > IMHO writing `(goto-char 1)' is bad style because it exhibits a low
> OTOH, replacing a constant with a function call might make a
> difference.

point-min has its own bytecode instruction, so it's not quite that bad.

Re: point-min and 1

[martin rudalics]

 > ELisp code is full of such exposure, and not only in buffer
 > positioning.  Trying to change this is tantamount to fighting Quixotic
 > wars, IMO.

But we could try to not encourage people to introduce such exposure in
the future.

 > OTOH, replacing a constant with a function call might make a
 > difference.

We have some 1000 occurrences of `(goto-char (point-min))' in current
Emacs.  If this really made a difference, we should replace them.

martin

Re: point-min and 1

[Stefan Monnier]

> We have some 1000 occurrences of `(goto-char (point-min))' in current
> Emacs.  If this really made a difference, we should replace them.

I'd rather change the byte-compiler to change it for us if we really
find it to be necessary.


        Stefan

Re: point-min and 1

[martin rudalics]

 >> We have some 1000 occurrences of `(goto-char (point-min))' in current
 >> Emacs.  If this really made a difference, we should replace them.
 >
 > I'd rather change the byte-compiler to change it for us if we really
 > find it to be necessary.

I'd opt for two new primitives `goto-point-min' and `goto-point-max'.

martin

Re: point-min and 1

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>>> We have some 1000 occurrences of `(goto-char (point-min))' in current
>>> Emacs.  If this really made a difference, we should replace them.
>>
>> I'd rather change the byte-compiler to change it for us if we really
>> find it to be necessary.
>
> I'd opt for two new primitives `goto-point-min' and `goto-point-max'.

I seriously doubt that this forms any kind of performance bottleneck,
but if anyone would like to try and measure it, please go ahead.

Re: point-min and 1

[Juri Linkov]

>>> We have some 1000 occurrences of `(goto-char (point-min))' in current
>>> Emacs.  If this really made a difference, we should replace them.
>>
>> I'd rather change the byte-compiler to change it for us if we really
>> find it to be necessary.
>
> I'd opt for two new primitives `goto-point-min' and `goto-point-max'.

And `goto-line-noninteractively' ;)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: point-min and 1

[martin rudalics]

 >> I'd opt for two new primitives `goto-point-min' and `goto-point-max'.
 >
 > And `goto-line-noninteractively' ;)

Hmmm.... Every second use of `point-min' is within the idiom (goto-char
(point-min)).  So I think I have a point here.  `forward-line' is mostly
used for going to the next or previous line, IIUC.

martin

Re: point-min and 1

[David Kastrup]

martin rudalics <rudalics@gmx.at> writes:

>>> I'd opt for two new primitives `goto-point-min' and `goto-point-max'.
>>
>> And `goto-line-noninteractively' ;)
>
> Hmmm.... Every second use of `point-min' is within the idiom (goto-char
> (point-min)).  So I think I have a point here.

That's exactly why you don't have a point.  Every second use of "think"
is within the idiom "I think", and yet we don't use a separate word for
it.  Because we don't need a separate word for a common simple idiom
comprised of elementary parts.

-- 
David Kastrup

Re: point-min and 1

[martin rudalics]

 > That's exactly why you don't have a point.  Every second use of "think"
 > is within the idiom "I think", and yet we don't use a separate word for
 > it.  Because we don't need a separate word for a common simple idiom
 > comprised of elementary parts.

If every second use of "think" were within the idiom "I, David Kastrup,
think" we probably would have a spearate word for it ...

martin

Re: point-min and 1

[Miles Bader]

This thread ceased to have a point a long time ago...

-Miles

-- 
Idiot, n. A member of a large and powerful tribe whose influence in human
affairs has always been dominant and controlling.

Re: point-min and 1

[Stefan Monnier]

>>> We have some 1000 occurrences of `(goto-char (point-min))' in current
>>> Emacs.  If this really made a difference, we should replace them.
>> I'd rather change the byte-compiler to change it for us if we really
>> find it to be necessary.

> I'd opt for two new primitives `goto-point-min' and `goto-point-max'.

What for?


        Stefan

Re: point-min and 1

[martin rudalics]

 >> I'd opt for two new primitives `goto-point-min' and `goto-point-max'.
 >
 > What for?

To simplify typing.  And dicussions like the present one ;-)

martin

Re: point-min and 1

[David Kastrup]

martin rudalics <rudalics@gmx.at> writes:

>>> I'd opt for two new primitives `goto-point-min' and `goto-point-max'.
>>
>> What for?
>
> To simplify typing.  And dicussions like the present one ;-)

I don't see how this "discussion" would be implified, typing is
simplified only marginally, and understanding is usually affected
negatively when simple, logical language idioms are replaced by
functions with a separate name.

If performance were an issue, it would perfectly well be addressed by
the byte compiler.

-- 
David Kastrup

Re: point-min and 1

[martin rudalics]

 > I don't see how this "discussion" would be implified,

It wouldn't have taken place in the first place.

 > typing is
 > simplified only marginally,

Indeed.  `goto-bob' and `goto-eob' would simplify completion.

 > and understanding is usually affected
 > negatively when simple, logical language idioms are replaced by
 > functions with a separate name.

Not in this case: Instances of (goto-char 1) like those in reftex-* or
`edit-tab-stops-note-changes' could have been avoided so understanding
these would have been affected positively.

 > If performance were an issue, it would perfectly well be addressed by
 > the byte compiler.

Not in people's .emacs.

martin

Re: point-min and 1

[Stefan Monnier]

>> ;; Move to the specified line number in that buffer.
>> (save-restriction
>> (widen)
>> -    (goto-char 1)
>> +    (goto-char (point-min))

> Can `(goto-char (point-min))' be different from `(goto-char 1)' after
> a call to `widen'?

No, indeed it can't in Emacs, which is why the change is guaranteed to
be correct.


        Stefan

Re: point-min and 1

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Tue, 11 Aug 2009 11:13:55 -0400
> 
> >> ;; Move to the specified line number in that buffer.
> >> (save-restriction
> >> (widen)
> >> -    (goto-char 1)
> >> +    (goto-char (point-min))
> 
> > Can `(goto-char (point-min))' be different from `(goto-char 1)' after
> > a call to `widen'?
> 
> No, indeed it can't in Emacs, which is why the change is guaranteed to
> be correct.

I asked a serious question.  Would you please humor me with a serious
answer?

Re: point-min and 1

[Stefan Monnier]

> I asked a serious question.  Would you please humor me with a serious
> answer?

Just the same old general programming principle that says that you
should avoid using integer constants and prefer to give them names, so
the intention is clear.  In the case of "1", there might be many
different kinds of "1", it can be "1" the size of chars in a buffer, or
"1" the position of the second char in a string, or ...
As a general rule, using 1 rather than (point-min) tends to also
introduce bugs where code only works when the buffer is widened, so it's
good practice to prefer (point-min) over 1.


        Stefan

Re: point-min and 1

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 12 Aug 2009 22:22:30 -0400
> 
> Just the same old general programming principle that says that you
> should avoid using integer constants and prefer to give them names, so
> the intention is clear.  In the case of "1", there might be many
> different kinds of "1", it can be "1" the size of chars in a buffer, or
> "1" the position of the second char in a string, or ...
> As a general rule, using 1 rather than (point-min) tends to also
> introduce bugs where code only works when the buffer is widened, so it's
> good practice to prefer (point-min) over 1.

Thanks.  I don't necessarily agree with the reasoning, but at least I
understand the reasons for the change now.

If we want this to be a general style convention, perhaps we should
say something about it in the ELisp manual.

Re: point-min and 1

[martin rudalics]

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

 > so it's
 > good practice to prefer (point-min) over 1.

martin

Re: point-min and 1

[David Kastrup]

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

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

Re: point-min and 1

[Stefan Monnier]

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

All kinds, really.  Note that I'm talking about the use of 1 i.s.o
point-min in general, not specifically in calls to goto-char.  For many
other functions (e.g. put-text-property), using 1 rather than
(point-min) can result in signalling an error when the buffer
is narrowed.


        Stefan