Re: Edebug corrupting point in buffers; we need buffer-point and set-buffer-point, perhaps.

[Stefan Monnier]

>> Anyhow, I proposed buffer-point and set-buffer-point.  They would be a
>> lot faster than set-buffer followed by point and goto-char.  Here is my
>> first version of these.  What do you think?
>
> I'm not sure performance in a debugger is a reason good enough to add
> 2 more primitives.  The fact that we didn't need them until now should
> tell us something, no?
> Stefan, Lars, WDYT?

I'd be interested to see numbers showing that it's indeed "too costly"
to just use `set-buffer`, before we add such primitives.

> Anyway, a couple of minor comments:

AFAIK `get-buffer` will return non-nil when passed a killed buffer, so
I think those two functions currently would misbehave when passed
a killed buffer.

>> +DEFUN ("buffer-point", Fbuffer_point, Sbuffer_point, 1, 1, 0,
>> +       doc: /* Return the buffer point of BUFFER-OR-NAME.
>> +The argument may be a buffer or the name of an existing buffer.  */)
>> +  (Lisp_Object buffer_or_name)
>
> Why not an optional argument to 'point'?

That would be a lot more invasive, so hard to justify for
a functionality that we're not even sure we want to have.

> And why in buffer.c and not in editfns.c?

[ Truth be told, I don't really understand how these are split :-(  ]

>> +  CHECK_FIXNUM_COERCE_MARKER (pos);
>> +  p = XFIXNUM (pos);
>
> This is sub-optimal: a marker holds both character and byte position,
> and you lose it here.  Ignoring the byte position is only justified if
> the marker belongs to the wrong buffer.

I suspect the performance impact is negligible compared to what it would
cost using `set-buffer`.  Since we're not convinced the cost of
`set-buffer` is high enough to justify `set-buffer-point`, I wouldn't
worry about optimizing the case where the arg is a marker.


        Stefan