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

[Eli Zaretskii]

> Date: Mon, 31 Oct 2022 14:32:12 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> 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?

Anyway, a couple of minor comments:

> +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'?  And why in buffer.c and not
in editfns.c?

> +  return (make_fixnum (b->pt));

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

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

> +  if (p < b->begv) p = b->begv;
> +  if (p > b->zv) p = b->zv;

We have clip_to_bounds.  And again, always use BUF_BEGV and BUF_ZV,
not literal references to members of struct buffer.

> +  SET_PT (p);

We have SET_BUF_PT_BOTH.