Re: trunk r113878: Refine previous change.

Re: trunk r113878: Refine previous change.

[Glenn Morris]

Xue Fuqiao wrote:

[set-marker]

> +POSITION is less than 1, MARKER is moved to the beginning of the
> +buffer.  If POSITION is greater than the size of the buffer, marker is
> +moved to the end of the buffer.

I'm not sure this should be documented (yes, I know it is in the manual;
perhaps it should not be). Especially the first sentence.

Re: trunk r113878: Refine previous change.

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 14 Aug 2013 15:34:28 -0400
> Cc: emacs-devel@gnu.org
> 
> Xue Fuqiao wrote:
> 
> [set-marker]
> 
> > +POSITION is less than 1, MARKER is moved to the beginning of the
> > +buffer.  If POSITION is greater than the size of the buffer, marker is
> > +moved to the end of the buffer.
> 
> I'm not sure this should be documented (yes, I know it is in the manual;
> perhaps it should not be). Especially the first sentence.

I think both of them should not be in the doc.  These are internal
self-defenses of the implementation, we don't expect users to pass
such invalid arguments (a.k.a. "undefined behavior") at all.  Besides,
this is a slippery slope, as we have such restrictions all over the
place.

Re: trunk r113878: Refine previous change.

[Xue Fuqiao]

On Thu, Aug 15, 2013 at 3:45 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Glenn Morris <rgm@gnu.org>
>> Date: Wed, 14 Aug 2013 15:34:28 -0400
>> Cc: emacs-devel@gnu.org
>>
>> Xue Fuqiao wrote:
>>
>> [set-marker]
>>
>> > +POSITION is less than 1, MARKER is moved to the beginning of the
>> > +buffer.  If POSITION is greater than the size of the buffer, marker is
>> > +moved to the end of the buffer.
>>
>> I'm not sure this should be documented (yes, I know it is in the manual;
>> perhaps it should not be). Especially the first sentence.
>
> I think both of them should not be in the doc.  These are internal
> self-defenses of the implementation, we don't expect users to pass
> such invalid arguments (a.k.a. "undefined behavior") at all.  Besides,
> this is a slippery slope, as we have such restrictions all over the
> place.

OK, I'll remove them.  BTW in "(elisp) Character Motion" and "(elisp)
Creating Markers", there are similar sentences, should I remove them all?

-- 
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: trunk r113878: Refine previous change.

[Juanma Barranquero]

On Wed, Aug 14, 2013 at 9:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> These are internal
> self-defenses of the implementation, we don't expect users to pass
> such invalid arguments (a.k.a. "undefined behavior") at all.

If they are self defenses, wouldn't be better to signal an error? It
would break some code, but arguably that code is already broken, and
silently so.

   J

Re: trunk r113878: Refine previous change.

[Glenn Morris]

Juanma Barranquero wrote:

>> These are internal self-defenses of the implementation, we don't
>> expect users to pass such invalid arguments (a.k.a. "undefined
>> behavior") at all.
>
> If they are self defenses, wouldn't be better to signal an error?

I don't think we can go from "this is documented in the manual to work"
to "this is an error" in the space of a day. For now, we can just go to
"this is undocumented", with a view to perhaps making it an error some
years down the line. Cf bug#15059.

> It would break some code, but arguably that code is already broken,
> and silently so.

It's not broken to intentionally make use of documented behaviour,
and we have no way of knowing whether this was being intentionally used
anywhere. (I don't think it matters much.)

Re: trunk r113878: Refine previous change.

[Glenn Morris]

Xue Fuqiao wrote:

> OK, I'll remove them.  BTW in "(elisp) Character Motion" and "(elisp)
> Creating Markers", there are similar sentences, should I remove them all?

I think so.
Rather than removing, I suggest enclosing them inside ignore/end ignore
with a comment that says the behavior used to be documented until 2013/08.

Re: trunk r113878: Refine previous change.

[Juanma Barranquero]

On Thu, Aug 15, 2013 at 4:16 AM, Glenn Morris <rgm@gnu.org> wrote:

> I don't think we can go from "this is documented in the manual to work"
> to "this is an error" in the space of a day. For now, we can just go to
> "this is undocumented", with a view to perhaps making it an error some
> years down the line. Cf bug#15059.

Well, I wasn't proposing to do it in a day. Your way makes perfect sense.

    J

Re: trunk r113878: Refine previous change.

[Stefan Monnier]

FWIW, I've fairly often written code which uses goto-char with
a position that can be outside of point-min...point-max, knowing that it
will go to the closest possible position.

I probably also wrote code with similar assumptions for set-marker or
copy-marker.


        Stefan

Re: trunk r113878: Refine previous change.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 15 Aug 2013 10:29:10 -0400
> Cc: xfq.free@gmail.com, Juanma Barranquero <lekktu@gmail.com>,
> 	Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> FWIW, I've fairly often written code which uses goto-char with
> a position that can be outside of point-min...point-max, knowing that it
> will go to the closest possible position.

Quod licet Iovi, non licet bovi...

Re: trunk r113878: Refine previous change.

[Glenn Morris]

Stefan Monnier wrote:

> FWIW, I've fairly often written code which uses goto-char with
> a position that can be outside of point-min...point-max, knowing that it
> will go to the closest possible position.

Did you ever pass a negative position?
Were you passing a position outside the currently accessible portion of
the buffer, but within the unnarrowed limits, or was it just an arbitrarily
large value to mean "point-max" (and if so, why not just use point-max)?

Re: trunk r113878: Refine previous change.

[Stefan Monnier]

>> FWIW, I've fairly often written code which uses goto-char with
>> a position that can be outside of point-min...point-max, knowing that it
>> will go to the closest possible position.

> Did you ever pass a negative position?
> Were you passing a position outside the currently accessible portion of
> the buffer, but within the unnarrowed limits, or was it just an arbitrarily
> large value to mean "point-max" (and if so, why not just use point-max)?

Typically it's a slightly sloppy value.  E.g. (1- pos) or (1+ pos) or
just `pos' but where that position was valid in the past and some
buffer changes may have rendered it invalid.

So it typically is a valid position in 99% of the cases, but I know that
it's not guaranteed to be so in 100% of the cases.


        Stefan

Re: trunk r113878: Refine previous change.

[Glenn Morris]

Stefan Monnier wrote:

> Typically it's a slightly sloppy value.  E.g. (1- pos) or (1+ pos) or
> just `pos' but where that position was valid in the past and some
> buffer changes may have rendered it invalid.

Thanks, makes sense.

Re: trunk r113878: Refine previous change.

[Xue Fuqiao]

On Thu, Aug 15, 2013 at 10:18 AM, Glenn Morris <rgm@gnu.org> wrote:
> Xue Fuqiao wrote:
>
>> OK, I'll remove them.  BTW in "(elisp) Character Motion" and "(elisp)
>> Creating Markers", there are similar sentences, should I remove them all?
>
> I think so.
> Rather than removing, I suggest enclosing them inside ignore/end ignore
> with a comment that says the behavior used to be documented until 2013/08.

OK, done as revision 113906.

-- 
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/