Re: [Patch] hard-widen-limits [was Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]]

[Vitalie Spinu]

Sounds reasonable. But whatever is the internal implementation shouldn't
hard-widen-limits be there anyways?

Why to bother with call-with-hard-narrowing and not have all the logic in
with-hard-narrowing directly? I looks to me that it's better to expose hard
narrowing to elisp only. If possible it should be transparent to low level code.

  Vitalie

>> On Mon, Mar 21 2016 08:39, Stefan Monnier wrote:

>> +  DEFVAR_LISP ("hard-widen-limits", Vhard_widen_limits,
>> +           doc: /* When non-nil `widen` will widen to these limits.
>> +Must be a cons of the form (MIN . MAX) where MIN and MAX are integers or 
>> markers.  */);
>> +  Vhard_widen_limits = Qnil;

> Sorry to nitpick, but I'm not completely happy with this API.  As an
> implementation it might be OK, but I can imagine wanting to change the
> implementation in the future but being stuck by the exposed internals.

> So I suggest we instead expose only a new primitive
> "call-with-hard-narrowing" which could look like:

>     (defun call-with-hard-narrowing (from to func)
>       (make-local-variable 'internal--hard-widen-limits)
>       (let ((internal--hard-widen-limits (cons from to)))
>         (funcall func)))

> which could be supplemented with a corresponding macro

>     (defmacro with-hard-narrowing (from to &rest body)
>       `(call-with-hard-narrowing ,from ,to (lambda () ,body)))

> -- Stefan