INTERVAL_EXPRESSLY_WRITABLE_P

INTERVAL_EXPRESSLY_WRITABLE_P

[Eli Zaretskii]

> +/* Is this interval writable by virtue of an explicit inhibit-read-only
> +   property, or the specific presence of its Qread_only property in
> +   Vinhibit_read_only?  */
> +#define INTERVAL_EXPRESSLY_WRITABLE_P(i, ro)                   \
> +  (!NILP (textget ((i)->plist, Qinhibit_read_only))            \
> +   || (!NILP (ro)                                              \
> +       && CONSP (Vinhibit_read_only)                           \
> +       && !NILP (Fmemq ((ro), Vinhibit_read_only))))

The comment is IMO misleading, since the code doesn't use Qread_only.

OTOH, why did you need the RO argument if it is always set to the
Qread_only property of the interval's text?

Re: INTERVAL_EXPRESSLY_WRITABLE_P

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> The comment is IMO misleading, since the code doesn't use Qread_only.

It does, through RO.

> OTOH, why did you need the RO argument if it is always set to the
> Qread_only property of the interval's text?

To avoid calling textget twice (or thrice, if an error should be
signaled in response to the interval's being non-writable).

Re: INTERVAL_EXPRESSLY_WRITABLE_P

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 May 2024 22:04:25 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The comment is IMO misleading, since the code doesn't use Qread_only.
> 
> It does, through RO.

And you think I didn't see it?  My point is that the comment should
talk about RO, not about Qread_only, because the latter is nowhere in
sight.

> > OTOH, why did you need the RO argument if it is always set to the
> > Qread_only property of the interval's text?
> 
> To avoid calling textget twice (or thrice, if an error should be
> signaled in response to the interval's being non-writable).

That could be done by using a local variable.

Anyway, my point is that the documentation of these macros "needs
work".

Re: INTERVAL_EXPRESSLY_WRITABLE_P

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That could be done by using a local variable.

Which is being passed to the macro as RO.

> Anyway, my point is that the documentation of these macros "needs
> work".

Okay.