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

[Stefan Monnier]

[ Duh, sorry I saw this message too late.  ]

> Well, I timed it.  With 207 buffers, creating an alist of (buffer .
> buffer-point) with my new function was 17 times as fast as using
> with-current-buffer and point.  Restoring the buffer-points was
> 8 times as fast with my new function.

I actually expected worse than 17x.

> It's probably moot, though, since the "slow" restoration only took
> 0.00137 seconds for all 207 buffers.

That's the main issue for me, yes.  I mean, I regularly have more than
200 buffers in my Emacs sessions, but AFAICT the rest of the work
performed by Edebug when it interrupts the execution of the main program
will dwarf this anyway.

I think the better way forward is to define `edebug--buffer-point` and
`edebug--set-buffer-point` functions in `debug.el` for now.  If at some
point we can see that it's useful in other packages we can move those
definitions elsewhere and remove their `edebug--` prefix.  And if at
some point they show up as a significant contribution in a CPU profile,
*then* we can move them to C.

> But on the other hand, these two functions feel like they ought to exist.
> They could save a lot of clumsy programming with swapping the buffer,
> just to get or set point.

    (with-current-buffer BUF (point))
and
    (with-current-buffer BUF (goto-char POS))

aren't that terribly verbose.


>> Why not an optional argument to 'point'?  And why in buffer.c and not
>> in editfns.c?
> I'm not sure what you mean by an optional argument, here.

IIUC he's suggesting to redefine `point` to take an optional argument
(and merge it with `buffer-point`).

>> Please never-ever use b->pt etc. directly.  We have BUF_PT and other
>> macros for that, and for a good reason.
> BUF_PT and friends work specifically on current_buffer.

No, that's `PT`.  `BUF_PT` takes a buffer argument.


        Stefan