RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> > And the text about indentation and the use of sub-mode for only a given
> > chunk of text in a buffer is incomprehensible without some explanation.
> > Normally, a major mode, no matter whether it is derived from some other
> > major mode, has its effect on the entire buffer.
> >
> > It seems there is some non-negligible functionality/behavior/feature
> > that has not been documented.  Not up to Emacs standards, it appears.
> >
> > It looks like someone perhaps implemented something and just tossed
> > some minimal doc into the manual, in the form of doc-string-like text
> > for a couple functions.  Insufficient.
> 
> "Compliments" such as these for something that caused me a
> considerable effort to produce where no documentation by the code
> developers existed in the first place is a very efficient method of
> convincing me never to make such efforts again.  Not for this
> community, anyway.  Thanks a lot!

Please consider it instead as a statement that "the code
developers" for this feature (whatever it might be) should
themselves have documented it.  Which is also what I think
you suggest.

My plaint wrt what the user sees now (incomplete doc) is
essentially the same as your plaint that the code developers
did not provide adequate doc.  I don't at all complain about
your effort to improve a complete lack by providing something
helpful.

You improved things by adding some explanation.  I made a
(minor) effort to improve things after that, by saying that,
IMO, the doc is still not sufficient.

My guess is that those responsible for adding this feature
are the best placed to provide the technical content (if not
necessarily the wording) for telling users what it is.

I don't know what that content is - dunno what the feature is.
As a user learning about this question for the first time, I
searched the manuals for "sub-mode" and similar expressions
to learn more, and came up empty-handed.  I reported that.

Perhaps you too have only a partial feel for this feature.
I have no gripe whatsoever with what you've done to help us
understand this, Eli.  Quite the contrary.

Had you not documented this at all, I would not have noticed
it and would not have posed questions about it.  You need not
be defensive about my saying the doc is incomplete here.
You can be proud that you tried to make it more complete.

Thank you for that.  In fact, I thank Emacs everyday for your
unflagging concern about the doc and your efforts to maintain
and improve it.

This concern with doc is an Emacs tradition that dates from
Day One and for which RMS was always a prominent advocate and
participant.  Today, you remain the main stalwart in this
endeavor.  Thank goodness you are still at it.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Eli Zaretskii]

> Date: Thu, 24 Mar 2016 07:41:50 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: andreas.roehler@online.de, spinuvit@gmail.com, emacs-devel@gnu.org
> 
> > > And the text about indentation and the use of sub-mode for only a given
> > > chunk of text in a buffer is incomprehensible without some explanation.
> > > Normally, a major mode, no matter whether it is derived from some other
> > > major mode, has its effect on the entire buffer.
> > >
> > > It seems there is some non-negligible functionality/behavior/feature
> > > that has not been documented.  Not up to Emacs standards, it appears.
> > >
> > > It looks like someone perhaps implemented something and just tossed
> > > some minimal doc into the manual, in the form of doc-string-like text
> > > for a couple functions.  Insufficient.
> > 
> > "Compliments" such as these for something that caused me a
> > considerable effort to produce where no documentation by the code
> > developers existed in the first place is a very efficient method of
> > convincing me never to make such efforts again.  Not for this
> > community, anyway.  Thanks a lot!
> 
> Please consider it instead as a statement that "the code
> developers" for this feature (whatever it might be) should
> themselves have documented it.  Which is also what I think
> you suggest.
> 
> My plaint wrt what the user sees now (incomplete doc) is
> essentially the same as your plaint that the code developers
> did not provide adequate doc.  I don't at all complain about
> your effort to improve a complete lack by providing something
> helpful.

The documentation is complete.  I have just re-read it to be sure, and
I see no flaws there.  If you still think there are gaps, and if the
current text is unclear to you, that's a clear sign that the use cases
in which these features are supposed to be used are something you
never bumped into, and therefore you don't have a clear picture of the
issues.  Which is not a catastrophe, but it does mean that you are not
the best person to criticize this part of the documentation.

> As a user learning about this question for the first time, I
> searched the manuals for "sub-mode" and similar expressions
> to learn more, and came up empty-handed.  I reported that.

It is clear to anyone who understand the situations which need these
features.  Examples of such situations are part of the text in the
manual.  The fact is that this discussion thread references "sub-mode"
or "submode" several times, and people who used that terminology
evidently have to difficulty understanding what it is.

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> > > > And the text about indentation and the use of sub-mode for only a
> given
> > > > chunk of text in a buffer is incomprehensible without some
> explanation.
> > > > Normally, a major mode, no matter whether it is derived from some
> other
> > > > major mode, has its effect on the entire buffer.
> > > >
> > > > It seems there is some non-negligible functionality/behavior/feature
> > > > that has not been documented.  Not up to Emacs standards, it appears.
> > > >
> > > > It looks like someone perhaps implemented something and just tossed
> > > > some minimal doc into the manual, in the form of doc-string-like text
> > > > for a couple functions.  Insufficient.
> > >
> > > "Compliments" such as these for something that caused me a
> > > considerable effort to produce where no documentation by the code
> > > developers existed in the first place is a very efficient method of
> > > convincing me never to make such efforts again.  Not for this
> > > community, anyway.  Thanks a lot!
> >
> > Please consider it instead as a statement that "the code
> > developers" for this feature (whatever it might be) should
> > themselves have documented it.  Which is also what I think
> > you suggest.
> >
> > My plaint wrt what the user sees now (incomplete doc) is
> > essentially the same as your plaint that the code developers
> > did not provide adequate doc.  I don't at all complain about
> > your effort to improve a complete lack by providing something
> > helpful.
> 
> The documentation is complete.  I have just re-read it to be sure, and
> I see no flaws there.  If you still think there are gaps, and if the
> current text is unclear to you, that's a clear sign that the use cases
> in which these features are supposed to be used are something you
> never bumped into, and therefore you don't have a clear picture of the
> issues.  Which is not a catastrophe, but it does mean that you are not
> the best person to criticize this part of the documentation.
> 
> > As a user learning about this question for the first time, I
> > searched the manuals for "sub-mode" and similar expressions
> > to learn more, and came up empty-handed.  I reported that.
> 
> It is clear to anyone who understand the situations which need these
> features.  Examples of such situations are part of the text in the
> manual.  The fact is that this discussion thread references "sub-mode"
> or "submode" several times, and people who used that terminology
> evidently have to difficulty understanding what it is.
                 ^^
                 no (?)

Excuse me, but that's a crock.  You are essentially saying that it is
OK to refer to a "florksit" over and over, with no explanation of what
such a critter is, as long as some developers who implemented the code
that uses and provides for florsits understand what it is.  This is
the Elisp manual - for all users of Elisp.

Imagine if we did that for other concepts: keymap, syntax table, or
whatever.  Instead, we introduce the concept with some care, so that
readers of doc about functions that make use of keymaps etc. know what
that doc is talking about.

As I said earlier, one might guess that a "sub-mode" is a mode that
derives from another mode.  OK.  But one will not guess what that might
mean for zones of text in one or another sub-mode, what it might mean
for indentation there, or whether sub-modes can nest or otherwise
overlap.  And so on.

None of this is clear to a reader of this doc, and it should be, IMO.
What's a "sub-mode" in this context?  Answer that clearly in the doc
and Bob will be our uncle.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Stefan Monnier]

Hi Vitalie,

For tentative branches where you don't want to have to follow all the
coding conventions (especially the convention about formatting and
content of commit messages), please use branch names of the form "scratch/*".


        Stefan


>>>>> "Vitalie" == Vitalie Spinu <spinuvit@gmail.com> writes:

> branch: widen-limits
> commit c331b6626a427fb89303fea75faebd8c39d343a8
> Author: Vitalie Spinu <spinuvit@gmail.com>
> Commit: Vitalie Spinu <spinuvit@gmail.com>

>     Implement buffer-widen-limits functionality
    
>      `widen` now respects restrictions imposed by new variable
>      `hard-widen-limits`
> ---
>  src/buffer.c  |   19 +++++++++++++++++--
>  src/buffer.h  |   17 +++++++++++++++++
>  src/editfns.c |   15 ++++++++++++++-
>  3 files changed, 48 insertions(+), 3 deletions(-)

> diff --git a/src/buffer.c b/src/buffer.c
> index f06d7e0..1b62d3a 100644
> --- a/src/buffer.c
> +++ b/src/buffer.c
> @@ -329,6 +329,11 @@ bset_scroll_up_aggressively (struct buffer *b, Lisp_Object val)
b-> scroll_up_aggressively_ = val;
>  }
>  static void
> +bset_widen_limits (struct buffer *b, Lisp_Object val)
> +{
> +  b->widen_limits_ = val;
> +}
> +static void
>  bset_selective_display (struct buffer *b, Lisp_Object val)
>  {
b-> selective_display_ = val;
> @@ -847,6 +852,7 @@ CLONE nil means the indirect buffer's state is reset to default values.  */)
>        bset_display_count (b, make_number (0));
>        bset_backed_up (b, Qnil);
>        bset_auto_save_file_name (b, Qnil);
> +      bset_widen_limits (b, b->base_buffer->widen_limits_);
>        set_buffer_internal_1 (b);
>        Fset (intern ("buffer-save-without-query"), Qnil);
>        Fset (intern ("buffer-file-number"), Qnil);
> @@ -961,6 +967,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too)
>       things that depend on the major mode.
>       default-major-mode is handled at a higher level.
>       We ignore it here.  */
> +  bset_widen_limits(b, Qnil);
>    bset_major_mode (b, Qfundamental_mode);
>    bset_keymap (b, Qnil);
>    bset_mode_name (b, QSFundamental);
> @@ -2167,7 +2174,7 @@ so the buffer is truly empty after this.  */)
>  {
>    Fwiden ();
 
> -  del_range (BEG, Z);
> +  del_range (BEGWL, ZWL);
 
current_buffer-> last_window_start = 1;
>    /* Prevent warnings, or suspension of auto saving, that would happen
> @@ -5037,6 +5044,7 @@ init_buffer_once (void)
>    bset_display_count (&buffer_local_flags, make_number (-1));
>    bset_display_time (&buffer_local_flags, make_number (-1));
>    bset_enable_multibyte_characters (&buffer_local_flags, make_number (-1));
> +  bset_widen_limits (&buffer_local_flags, make_number (-1));
 
>    /* These used to be stuck at 0 by default, but now that the all-zero value
>       means Qnil, we have to initialize them explicitly.  */
> @@ -5160,6 +5168,7 @@ init_buffer_once (void)
>    bset_cursor_type (&buffer_defaults, Qt);
>    bset_extra_line_spacing (&buffer_defaults, Qnil);
>    bset_cursor_in_non_selected_windows (&buffer_defaults, Qt);
> +  bset_widen_limits (&buffer_defaults, Qnil);
 
>    bset_enable_multibyte_characters (&buffer_defaults, Qt);
>    bset_buffer_file_coding_system (&buffer_defaults, Qnil);
> @@ -5367,7 +5376,6 @@ defvar_per_buffer (struct Lisp_Buffer_Objfwd *bo_fwd, const char *namestring,
>      emacs_abort ();
>  }
 
> -
>  /* Initialize the buffer routines.  */
>  void
>  syms_of_buffer (void)
> @@ -5796,6 +5804,13 @@ If you set this to -2, that means don't turn off auto-saving in this buffer
>  if its text size shrinks.   If you use `buffer-swap-text' on a buffer,
>  you probably should set this to -2 in that buffer.  */);
 
> +  DEFVAR_PER_BUFFER ("buffer-widen-limits", &BVAR (current_buffer, widen_limits),
> +                     Qnil,
> +                     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
> +of hard widen limits in this buffer. This is an experimental variable
> +intended primarily for multi-mode engines.  */);
> +
>    DEFVAR_PER_BUFFER ("selective-display", &BVAR (current_buffer, selective_display),
>  		     Qnil,
>  		     doc: /* Non-nil enables selective display.
> diff --git a/src/buffer.h b/src/buffer.h
> index 87b7cee..4075bbf 100644
> --- a/src/buffer.h
> +++ b/src/buffer.h
> @@ -59,6 +59,10 @@ INLINE_HEADER_BEGIN
>  #define Z (current_buffer->text->z)
>  #define Z_BYTE (current_buffer->text->z_byte)
 
> +/* Positions that take into account widen limits.  */
> +#define BEGWL (BUF_BEGWL (current_buffer))
> +#define ZWL (BUF_ZWL(current_buffer))
> +
>  /* Macros for the addresses of places in the buffer.  */
 
>  /* Address of beginning of buffer.  */
> @@ -128,6 +132,15 @@ INLINE_HEADER_BEGIN
>      : NILP (BVAR (buf, begv_marker)) ? buf->begv_byte	\
>      : marker_byte_position (BVAR (buf, begv_marker)))
 
> +/* Hard positions in buffer. */
> +#define BUF_BEGWL(buf)  	                                \
> +  ((NILP (BVAR (buf, widen_limits))) ?  BUF_BEG (buf)    \
> +   : XINT( XCAR (BVAR (buf, widen_limits))))
> +
> +#define BUF_ZWL(buf)  	                                \
> +  ((NILP (BVAR (buf, widen_limits))) ?  BUF_Z (buf)      \
> +   : XINT( XCDR (BVAR (buf, widen_limits))))
> +
>  /* Position of point in buffer.  */
>  #define BUF_PT(buf)					\
>     (buf == current_buffer ? PT				\
> @@ -150,6 +163,7 @@ INLINE_HEADER_BEGIN
>      : NILP (BVAR (buf, zv_marker)) ? buf->zv_byte	\
>      : marker_byte_position (BVAR (buf, zv_marker)))
 
> +
>  /* Position of gap in buffer.  */
>  #define BUF_GPT(buf) ((buf)->text->gpt)
>  #define BUF_GPT_BYTE(buf) ((buf)->text->gpt_byte)
> @@ -748,6 +762,9 @@ struct buffer
>       See `cursor-type' for other values.  */
>    Lisp_Object cursor_in_non_selected_windows_;
 
> +  /* Cons of hard widen limits */
> +  Lisp_Object widen_limits_;
> +
>    /* No more Lisp_Object beyond this point.  Except undo_list,
>       which is handled specially in Fgarbage_collect.  */
 
> diff --git a/src/editfns.c b/src/editfns.c
> index 2ac0537..e5ab637 100644
> --- a/src/editfns.c
> +++ b/src/editfns.c
> @@ -3480,12 +3480,25 @@ DEFUN ("delete-and-extract-region", Fdelete_and_extract_region,
>      return empty_unibyte_string;
>    return del_range_1 (XINT (start), XINT (end), 1, 1);
>  }
> +
>  \f
>  DEFUN ("widen", Fwiden, Swiden, 0, 0, "",
>         doc: /* Remove restrictions (narrowing) from current buffer.
> -This allows the buffer's full text to be seen and edited.  */)
> +This allows the buffer's full text to be seen and edited.
> +If `buffer-widen-limits` is non-nil, widen only to those limits.  */)
>    (void)
>  {
> +
> +  if (!NILP (BVAR(current_buffer, widen_limits)))
> +    {
> +      Lisp_Object hl = BVAR(current_buffer,  widen_limits);
> +      CHECK_CONS(hl);
> +      CHECK_NUMBER(XCAR(hl));
> +      CHECK_NUMBER(XCDR(hl));
> +      Fnarrow_to_region(XCAR(hl), XCDR(hl));
> +      return Qnil;
> +    }
> +
>    if (BEG != BEGV || Z != ZV)
current_buffer-> clip_changed = 1;
>    BEGV = BEG;

> _______________________________________________
> Emacs-diffs mailing list
> Emacs-diffs@gnu.org
> https://lists.gnu.org/mailman/listinfo/emacs-diffs

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Vitalie Spinu]

Sure. Fixed. This convention is not mentioned in CONTRIBUTE btw.

  Vitalie

>> On Tue, Mar 22 2016 08:08, Stefan Monnier wrote:

> Hi Vitalie,

> For tentative branches where you don't want to have to follow all the
> coding conventions (especially the convention about formatting and
> content of commit messages), please use branch names of the form "scratch/*".

>         Stefan

>>>>>> "Vitalie" == Vitalie Spinu <spinuvit@gmail.com> writes:

>> branch: widen-limits
>> commit c331b6626a427fb89303fea75faebd8c39d343a8
>> Author: Vitalie Spinu <spinuvit@gmail.com>
>> Commit: Vitalie Spinu <spinuvit@gmail.com>

>>     Implement buffer-widen-limits functionality

>>      `widen` now respects restrictions imposed by new variable
>>      `hard-widen-limits`
>> ---
>>  src/buffer.c  |   19 +++++++++++++++++--
>>  src/buffer.h  |   17 +++++++++++++++++
>>  src/editfns.c |   15 ++++++++++++++-
>>  3 files changed, 48 insertions(+), 3 deletions(-)

>> diff --git a/src/buffer.c b/src/buffer.c
>> index f06d7e0..1b62d3a 100644
>> --- a/src/buffer.c
>> +++ b/src/buffer.c
>> @@ -329,6 +329,11 @@ bset_scroll_up_aggressively (struct buffer *b, Lisp_Object val)
> b-> scroll_up_aggressively_ = val;
>>  }
>>  static void
>> +bset_widen_limits (struct buffer *b, Lisp_Object val)
>> +{
>> +  b->widen_limits_ = val;
>> +}
>> +static void
>>  bset_selective_display (struct buffer *b, Lisp_Object val)
>>  {
> b-> selective_display_ = val;
>> @@ -847,6 +852,7 @@ CLONE nil means the indirect buffer's state is reset to default values.  */)
>>        bset_display_count (b, make_number (0));
>>        bset_backed_up (b, Qnil);
>>        bset_auto_save_file_name (b, Qnil);
>> +      bset_widen_limits (b, b->base_buffer->widen_limits_);
>>        set_buffer_internal_1 (b);
>>        Fset (intern ("buffer-save-without-query"), Qnil);
>>        Fset (intern ("buffer-file-number"), Qnil);
>> @@ -961,6 +967,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too)
>>       things that depend on the major mode.
>>       default-major-mode is handled at a higher level.
>>       We ignore it here.  */
>> +  bset_widen_limits(b, Qnil);
>>    bset_major_mode (b, Qfundamental_mode);
>>    bset_keymap (b, Qnil);
>>    bset_mode_name (b, QSFundamental);
>> @@ -2167,7 +2174,7 @@ so the buffer is truly empty after this.  */)
>>  {
>>    Fwiden ();

>> -  del_range (BEG, Z);
>> +  del_range (BEGWL, ZWL);

> current_buffer-> last_window_start = 1;
>>    /* Prevent warnings, or suspension of auto saving, that would happen
>> @@ -5037,6 +5044,7 @@ init_buffer_once (void)
>>    bset_display_count (&buffer_local_flags, make_number (-1));
>>    bset_display_time (&buffer_local_flags, make_number (-1));
>>    bset_enable_multibyte_characters (&buffer_local_flags, make_number (-1));
>> +  bset_widen_limits (&buffer_local_flags, make_number (-1));

>>    /* These used to be stuck at 0 by default, but now that the all-zero value
>>       means Qnil, we have to initialize them explicitly.  */
>> @@ -5160,6 +5168,7 @@ init_buffer_once (void)
>>    bset_cursor_type (&buffer_defaults, Qt);
>>    bset_extra_line_spacing (&buffer_defaults, Qnil);
>>    bset_cursor_in_non_selected_windows (&buffer_defaults, Qt);
>> +  bset_widen_limits (&buffer_defaults, Qnil);

>>    bset_enable_multibyte_characters (&buffer_defaults, Qt);
>>    bset_buffer_file_coding_system (&buffer_defaults, Qnil);
>> @@ -5367,7 +5376,6 @@ defvar_per_buffer (struct Lisp_Buffer_Objfwd *bo_fwd, const char *namestring,
>>      emacs_abort ();
>>  }

>> -
>>  /* Initialize the buffer routines.  */
>>  void
>>  syms_of_buffer (void)
>> @@ -5796,6 +5804,13 @@ If you set this to -2, that means don't turn off auto-saving in this buffer
>>  if its text size shrinks.   If you use `buffer-swap-text' on a buffer,
>>  you probably should set this to -2 in that buffer.  */);

>> +  DEFVAR_PER_BUFFER ("buffer-widen-limits", &BVAR (current_buffer, widen_limits),
>> +                     Qnil,
>> +                     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
>> +of hard widen limits in this buffer. This is an experimental variable
>> +intended primarily for multi-mode engines.  */);
>> +
>>    DEFVAR_PER_BUFFER ("selective-display", &BVAR (current_buffer, selective_display),
>>  		     Qnil,
>>  		     doc: /* Non-nil enables selective display.
>> diff --git a/src/buffer.h b/src/buffer.h
>> index 87b7cee..4075bbf 100644
>> --- a/src/buffer.h
>> +++ b/src/buffer.h
>> @@ -59,6 +59,10 @@ INLINE_HEADER_BEGIN
>>  #define Z (current_buffer->text->z)
>>  #define Z_BYTE (current_buffer->text->z_byte)

>> +/* Positions that take into account widen limits.  */
>> +#define BEGWL (BUF_BEGWL (current_buffer))
>> +#define ZWL (BUF_ZWL(current_buffer))
>> +
>>  /* Macros for the addresses of places in the buffer.  */

>>  /* Address of beginning of buffer.  */
>> @@ -128,6 +132,15 @@ INLINE_HEADER_BEGIN
>>      : NILP (BVAR (buf, begv_marker)) ? buf->begv_byte	\
>>      : marker_byte_position (BVAR (buf, begv_marker)))

>> +/* Hard positions in buffer. */
>> +#define BUF_BEGWL(buf)  	                                \
>> +  ((NILP (BVAR (buf, widen_limits))) ?  BUF_BEG (buf)    \
>> +   : XINT( XCAR (BVAR (buf, widen_limits))))
>> +
>> +#define BUF_ZWL(buf)  	                                \
>> +  ((NILP (BVAR (buf, widen_limits))) ?  BUF_Z (buf)      \
>> +   : XINT( XCDR (BVAR (buf, widen_limits))))
>> +
>>  /* Position of point in buffer.  */
>>  #define BUF_PT(buf)					\
>>     (buf == current_buffer ? PT				\
>> @@ -150,6 +163,7 @@ INLINE_HEADER_BEGIN
>>      : NILP (BVAR (buf, zv_marker)) ? buf->zv_byte	\
>>      : marker_byte_position (BVAR (buf, zv_marker)))

>> +
>>  /* Position of gap in buffer.  */
>>  #define BUF_GPT(buf) ((buf)->text->gpt)
>>  #define BUF_GPT_BYTE(buf) ((buf)->text->gpt_byte)
>> @@ -748,6 +762,9 @@ struct buffer
>>       See `cursor-type' for other values.  */
>>    Lisp_Object cursor_in_non_selected_windows_;

>> +  /* Cons of hard widen limits */
>> +  Lisp_Object widen_limits_;
>> +
>>    /* No more Lisp_Object beyond this point.  Except undo_list,
>>       which is handled specially in Fgarbage_collect.  */

>> diff --git a/src/editfns.c b/src/editfns.c
>> index 2ac0537..e5ab637 100644
>> --- a/src/editfns.c
>> +++ b/src/editfns.c
>> @@ -3480,12 +3480,25 @@ DEFUN ("delete-and-extract-region", Fdelete_and_extract_region,
>>      return empty_unibyte_string;
>>    return del_range_1 (XINT (start), XINT (end), 1, 1);
>>  }
>> +
>>  \f
>>  DEFUN ("widen", Fwiden, Swiden, 0, 0, "",
>>         doc: /* Remove restrictions (narrowing) from current buffer.
>> -This allows the buffer's full text to be seen and edited.  */)
>> +This allows the buffer's full text to be seen and edited.
>> +If `buffer-widen-limits` is non-nil, widen only to those limits.  */)
>>    (void)
>>  {
>> +
>> +  if (!NILP (BVAR(current_buffer, widen_limits)))
>> +    {
>> +      Lisp_Object hl = BVAR(current_buffer,  widen_limits);
>> +      CHECK_CONS(hl);
>> +      CHECK_NUMBER(XCAR(hl));
>> +      CHECK_NUMBER(XCDR(hl));
>> +      Fnarrow_to_region(XCAR(hl), XCDR(hl));
>> +      return Qnil;
>> +    }
>> +
>>    if (BEG != BEGV || Z != ZV)
> current_buffer-> clip_changed = 1;
>>    BEGV = BEG;

>> _______________________________________________
>> Emacs-diffs mailing list
>> Emacs-diffs@gnu.org
>> https://lists.gnu.org/mailman/listinfo/emacs-diffs

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> >>  DEFUN ("widen", Fwiden, Swiden, 0, 0, "",
> >>         doc: /* Remove restrictions (narrowing) from current buffer.
> >> -This allows the buffer's full text to be seen and edited.  */)
> >> +This allows the buffer's full text to be seen and edited.
> >> +If `buffer-widen-limits` is non-nil, widen only to those limits.  */)

Why do you need this?  Why don't you just _narrow_ to those limits,
instead of making `widen' do it?

Why does "widening" need a separate set of limits?  That's what we have
narrowing for.  Any restriction of the buffer is a narrowing (which
concept is defined relative to the full buffer), regardless of whether
the previous state was a narrower narrowing (restriction).

Cf. the first line of that doc string, which seems to be contradicted
by the possibility that `widen' can put you in a different restriction.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Vitalie Spinu]

>> On Tue, Mar 22 2016 12:56, Drew Adams wrote:

> Why does "widening" need a separate set of limits?  

Because in multi-modes most of critical operations such as syntax parsing,
syntax-propertize, font-locking and indentations inside submodes occurs in
narrowed regions. That is, sub-mode is placed in a bubble. The problem is that
that buble is easy to escape with widening. These extra limits are intended to
make that escape impossible (at least till the sub-mode start using those hard
limits itself).

> Cf. the first line of that doc string, which seems to be contradicted

Good catch!

Thanks,

  Vitalie
  

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> > Why does "widening" need a separate set of limits?
> 
> Because in multi-modes most of critical operations such as syntax parsing,
> syntax-propertize, font-locking and indentations inside submodes occurs in
> narrowed regions. That is, sub-mode is placed in a bubble. The problem is
> that that buble is easy to escape with widening. These extra limits are
> intended to make that escape impossible (at least till the sub-mode start
> using those hard limits itself).

Thanks for the explanation.  I think I see what you are trying to do.

I don't see why changing `widen' would be the only, or necessarily
the best, way to meet that need (which is essentially to make a
sub-mode treat given bounds as if they were the buffer limits).

But you answered my question.  Thank you.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Andreas Röhler]

On 23.03.2016 01:44, Drew Adams wrote:
>>> Why does "widening" need a separate set of limits?
>> Because in multi-modes most of critical operations such as syntax parsing,
>> syntax-propertize, font-locking and indentations inside submodes occurs in
>> narrowed regions. That is, sub-mode is placed in a bubble. The problem is
>> that that buble is easy to escape with widening. These extra limits are
>> intended to make that escape impossible (at least till the sub-mode start
>> using those hard limits itself).
> Thanks for the explanation.  I think I see what you are trying to do.
>
> I don't see why changing `widen' would be the only, or necessarily
> the best, way to meet that need (which is essentially to make a
> sub-mode treat given bounds as if they were the buffer limits).
>
> But you answered my question.  Thank you.
>

Reads as a classical fix at the wrong place - not the first one in Emacs.
Instead of introducing extra limits --and then inner- and outer-extras 
of that extra etc.-- preventing unwanted widen instead seems the way to go.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Vitalie Spinu]

>> On Wed, Mar 23 2016 08:16, Andreas Röhler wrote:

> preventing unwanted widen instead seems the way to go.

That's precisely what extra limit do. Prevent unwanted widen. How do you propose
to implement that?

I see 4 ways to go about it:

  1) Add an extra prog-widen and teach all modes out there to use it in contexts
     like syntax-parsing, indentation, font-lock and who know what else. A half
     backed version of this in already part of emacs.

  2) Have low level restrictions directly in `widen` and a macro
     `with-widen-limit` that multi-modes can use. This is the current patch.

  3) Have two types of narrowing (soft and hard). This is harder to implement
     but has the benefit that it can be used in non-transient situations like
     Info mode.

  4) Bring widen to elisp and allow minor modes (and Info mode) advice widen in
     whatever way they see.

I think (1) is a bad idea. (4) is simplest and very general. (3) might be useful
but it's hard. (2) is implemented to get rid of (1).

I proposed (4) very early in the thread, but didn't hear much support for
it. There are only three trivial usages of Fwiden in C code. Bringing `narrow`
to elisp is equally easy.

  Vitalie

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Andreas Röhler]

On 23.03.2016 12:58, Vitalie Spinu wrote:
>>> On Wed, Mar 23 2016 08:16, Andreas Röhler wrote:
>> preventing unwanted widen instead seems the way to go.
> That's precisely what extra limit do. Prevent unwanted widen. How do you propose
> to implement that?
>
> I see 4 ways to go about it:
>
>    1) Add an extra prog-widen and teach all modes out there to use it in contexts
>       like syntax-parsing, indentation, font-lock and who know what else. A half
>       backed version of this in already part of emacs.
>
>    2) Have low level restrictions directly in `widen` and a macro
>       `with-widen-limit` that multi-modes can use. This is the current patch.
>
>    3) Have two types of narrowing (soft and hard). This is harder to implement
>       but has the benefit that it can be used in non-transient situations like
>       Info mode.
>
>    4) Bring widen to elisp and allow minor modes (and Info mode) advice widen in
>       whatever way they see.
>
> I think (1) is a bad idea. (4) is simplest and very general. (3) might be useful
> but it's hard. (2) is implemented to get rid of (1).
>
> I proposed (4) very early in the thread, but didn't hear much support for
> it. There are only three trivial usages of Fwiden in C code. Bringing `narrow`
> to elisp is equally easy.
>
>    Vitalie

Hi Vitali,

may you point me to spot/bug where widen goes wrong?

Thanks,

Andreas

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Vitalie Spinu]

>> On Wed, Mar 23 2016 14:02, Andreas Röhler wrote:

> may you point me to spot/bug where widen goes wrong?

Widen doesn't go wrong in itself. It what you do when you widen. In multi-modes
which use narrowing to create a micro-universe for inner modes, inner mode might
widen then compute some stuff on code from other language regions. This leads to
errors of all kind.

For example when multi-mode advices font-lock-default-fontify-region it cannot
control what individual functions in font-lock-keywords are doing. In case of
syntax-propertize-function it's a complete black box. The function can decide to
do whatever there.

Luckily if major-modes doesn't use widen or parse-partial-sexp directly it all
seem to work quite well with proper advice of relevant functions.

  Vitalie

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Date: Wed, 23 Mar 2016 15:17:03 +0100
> Cc: emacs-devel@gnu.org
> 
> Widen doesn't go wrong in itself. It what you do when you widen. In multi-modes
> which use narrowing to create a micro-universe for inner modes, inner mode might
> widen then compute some stuff on code from other language regions. This leads to
> errors of all kind.
> 
> For example when multi-mode advices font-lock-default-fontify-region it cannot
> control what individual functions in font-lock-keywords are doing. In case of
> syntax-propertize-function it's a complete black box. The function can decide to
> do whatever there.
> 
> Luckily if major-modes doesn't use widen or parse-partial-sexp directly it all
> seem to work quite well with proper advice of relevant functions.

Isn't prog-widen the solution to those issues?

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Andreas Röhler]

On 23.03.2016 16:34, Eli Zaretskii wrote:
>> From: Vitalie Spinu <spinuvit@gmail.com>
>> Date: Wed, 23 Mar 2016 15:17:03 +0100
>> Cc: emacs-devel@gnu.org
>>
>> Widen doesn't go wrong in itself. It what you do when you widen. In multi-modes
>> which use narrowing to create a micro-universe for inner modes, inner mode might
>> widen then compute some stuff on code from other language regions. This leads to
>> errors of all kind.
>>
>> For example when multi-mode advices font-lock-default-fontify-region it cannot
>> control what individual functions in font-lock-keywords are doing. In case of
>> syntax-propertize-function it's a complete black box. The function can decide to
>> do whatever there.
>>
>> Luckily if major-modes doesn't use widen or parse-partial-sexp directly it all
>> seem to work quite well with proper advice of relevant functions.
> Isn't prog-widen the solution to those issues?

Hi Eli,

doku of prog-widen says

"This variable enables the major mode of the
main language to use the indentation engine of the sub-mode"

This also doesn't sound right. A mode should not need to fiddle with 
other modes. Seems it's time to introduce a true multi-mode, and abandon 
the notion of a buffers major-mode when multi-mode is on - even if the 
symbol of a than regional-mode is still called major-mode for legacy 
reasons.

A multi-mode could keep a register, an index about the modes to employ 
according to position.

Best,

Andreas

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Andreas Röhler <andreas.roehler@online.de>
> Date: Wed, 23 Mar 2016 18:24:38 +0100
> 
> > Isn't prog-widen the solution to those issues?
> 
> Hi Eli,
> 
> doku of prog-widen says
> 
> "This variable enables the major mode of the
> main language to use the indentation engine of the sub-mode"
> 
> This also doesn't sound right.

Please read the description in the ELisp manual instead.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Andreas Röhler]

On 23.03.2016 18:55, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Andreas Röhler <andreas.roehler@online.de>
>> Date: Wed, 23 Mar 2016 18:24:38 +0100
>>
>>> Isn't prog-widen the solution to those issues?
>> Hi Eli,
>>
>> doku of prog-widen says
>>
>> "This variable enables the major mode of the
>> main language to use the indentation engine of the sub-mode"
>>
>> This also doesn't sound right.
> Please read the description in the ELisp manual instead.

So let's read this (prog-widen):

"    ... to remove any restrictions
      imposed by the mode’s indentation engine and restore the
      restrictions recorded in ‘prog-indentation-context’.  This prevents
      the indentation engine of a sub-mode from inadvertently operating
      on text outside of the chunk it was supposed to indent, and
      preserves the restriction imposed by the superior mode.  When no
      superior mode is in effect, this function just calls ‘widen’.
"

Don't see in which way this should be better. It lays the burden of 
dealing with the mode in place into prog-mode. IMO wrong place, wrong 
direction.

Expect prog-mode do deliver very basic things common to all programming 
modes. Not dealing with and fixing special needs there.

Modes must meet the specific languages. Prog-mode must not be specific 
and not provide tools for storing things like indentation-context. Let 
the modes indent, fontify and jump around like they want - not thwarting 
their settings seems all needed here.

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> >> doku of prog-widen says
> >>
> >> "This variable enables the major mode of the
> >> main language to use the indentation engine of the sub-mode"
> >>
> >> This also doesn't sound right.
> > Please read the description in the ELisp manual instead.
> 
> So let's read this (prog-widen):
> 
> "    ... to remove any restrictions
>       imposed by the mode's indentation engine and restore the
>       restrictions recorded in 'prog-indentation-context'.  This prevents
>       the indentation engine of a sub-mode from inadvertently operating
>       on text outside of the chunk it was supposed to indent, and
>       preserves the restriction imposed by the superior mode.  When no
>       superior mode is in effect, this function just calls 'widen'.
> "
> 
> Don't see in which way this should be better. It lays the burden of
> dealing with the mode in place into prog-mode. IMO wrong place, wrong
> direction.
> 
> Expect prog-mode do deliver very basic things common to all programming
> modes. Not dealing with and fixing special needs there.
> 
> Modes must meet the specific languages. Prog-mode must not be specific
> and not provide tools for storing things like indentation-context. Let
> the modes indent, fontify and jump around like they want - not thwarting
> their settings seems all needed here.

Worse yet -

What's a "sub-mode"?  The term is introduced nowhere in either the Emacs
manual or the Elisp manual.  It's not in the Elisp manual index.

It is used only in the node mentioned, and with no definition or
explanation.

That's a bug, IMO.  One might assume that it just means any major mode
that inherits from (i.e., derived from) `prog-mode' (since the term is
used only in the context of `prog-mode').  But one should not have to
assume.

And the text about indentation and the use of sub-mode for only a given
chunk of text in a buffer is incomprehensible without some explanation.
Normally, a major mode, no matter whether it is derived from some other
major mode, has its effect on the entire buffer.

It seems there is some non-negligible functionality/behavior/feature
that has not been documented.  Not up to Emacs standards, it appears.

It looks like someone perhaps implemented something and just tossed
some minimal doc into the manual, in the form of doc-string-like text
for a couple functions.  Insufficient.

Please explain what this is all about.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Vitalie Spinu]

>> On Wed, Mar 23 2016 14:57, Drew Adams wrote:

> It looks like someone perhaps implemented something and just tossed
> some minimal doc into the manual, in the form of doc-string-like text
> for a couple functions.

The issue of prog-widen and prog-indentation-context was discussed extensively
in the thread that led to this diff.

  https://lists.gnu.org/archive/html/emacs-devel/2016-03/threads.html#00859

Too long to be read from scratch I suppose.  My takeaway is that those features
are raw and simplistic and bring more complications than they solve. Hopefully
there will be a common consensus to put those on hold for now.

  Vitalie

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> > It looks like someone perhaps implemented something and just tossed
> > some minimal doc into the manual, in the form of doc-string-like text
> > for a couple functions.
> 
> The issue of prog-widen and prog-indentation-context was discussed
> extensively in the thread that led to this diff.
>   https://lists.gnu.org/archive/html/emacs-devel/2016-03/threads.html#00859

Maybe so.  My comment was about the inadequate doc, which does not define
or in any way explain "sub-mode", its relation to chunks of text within
a "super-mode" etc.

This stuff needs to be defined.  Can sub-modes be nested (sub-sub-mode etc.)?
Etc.  There is nothing clear about this stuff, based on the doc.  And my
comment was limited to the doc - it was not a comment about any mail thread.

> Too long to be read from scratch I suppose.  My takeaway is that those
> features are raw and simplistic and bring more complications than they 
> solve. Hopefully there will be a common consensus to put those on hold
> for now.

I have no opinion on what should be done, other than that whatever is
intended to be added as a feature should be presented and discussed
here first (IMO).  I asked for a mini-spec of the requirements, but
have seen nothing - no reasonable description of the whole problem
the feature is intended to address.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Cc: Andreas Röhler <andreas.roehler@online.de>,  Eli
>  Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 23 Mar 2016 23:13:58 +0100
> 
> The issue of prog-widen and prog-indentation-context was discussed extensively
> in the thread that led to this diff.
> 
>   https://lists.gnu.org/archive/html/emacs-devel/2016-03/threads.html#00859
> 
> Too long to be read from scratch I suppose.  My takeaway is that those features
> are raw and simplistic and bring more complications than they solve. Hopefully
> there will be a common consensus to put those on hold for now.

If that's the case, how come these features were admitted into our
codebase?  Should we rip them out, as long as it's not too late?

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Dmitry Gutov]

On 03/24/2016 05:38 AM, Eli Zaretskii wrote:

 >> [prog-indentation-context]

> Should we rip them out, as long as it's not too late?

Yes. If nobody beats me to it, I'll revert it in emacs-25 this weekend. 
The yet-unfinished discussion aside, it doesn't look ready for 25.1 
either way.

I'm sorry you had to work on documenting it; hopefully we can reuse the 
pieces of that text, or at least refer to it when documenting the 
eventual alternative approach.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Eli Zaretskii]

> Cc: andreas.roehler@online.de, drew.adams@oracle.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 24 Mar 2016 14:24:37 +0200
> 
> On 03/24/2016 05:38 AM, Eli Zaretskii wrote:
> 
>  >> [prog-indentation-context]
> 
> > Should we rip them out, as long as it's not too late?
> 
> Yes. If nobody beats me to it, I'll revert it in emacs-25 this weekend. 
> The yet-unfinished discussion aside, it doesn't look ready for 25.1 
> either way.

If you want to leave it in the code on master, don't forget to puts
some telltale phrase in the commit log.

> I'm sorry you had to work on documenting it; hopefully we can reuse the 
> pieces of that text, or at least refer to it when documenting the 
> eventual alternative approach.

Stuff happens.  If we learn from this experience for the future, at
least the effort wouldn't be completely wasted.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Dmitry Gutov]

On 03/24/2016 05:56 PM, Eli Zaretskii wrote:

> If you want to leave it in the code on master, don't forget to puts
> some telltale phrase in the commit log.

Right, thanks.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Eli Zaretskii]

> Date: Wed, 23 Mar 2016 14:57:49 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: spinuvit@gmail.com, emacs-devel@gnu.org
> 
> And the text about indentation and the use of sub-mode for only a given
> chunk of text in a buffer is incomprehensible without some explanation.
> Normally, a major mode, no matter whether it is derived from some other
> major mode, has its effect on the entire buffer.
> 
> It seems there is some non-negligible functionality/behavior/feature
> that has not been documented.  Not up to Emacs standards, it appears.
> 
> It looks like someone perhaps implemented something and just tossed
> some minimal doc into the manual, in the form of doc-string-like text
> for a couple functions.  Insufficient.

"Compliments" such as these for something that caused me a
considerable effort to produce where no documentation by the code
developers existed in the first place is a very efficient method of
convincing me never to make such efforts again.  Not for this
community, anyway.

Thanks a lot!

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Andreas Röhler]

On 23.03.2016 15:17, Vitalie Spinu wrote:
>
>
>>> On Wed, Mar 23 2016 14:02, Andreas Röhler wrote:
>> may you point me to spot/bug where widen goes wrong?
> Widen doesn't go wrong in itself. It what you do when you widen. In multi-modes
> which use narrowing to create a micro-universe for inner modes, inner mode might
> widen then compute some stuff on code from other language regions. This leads to
> errors of all kind.
>
> For example when multi-mode advices font-lock-default-fontify-region it cannot
> control what individual functions in font-lock-keywords are doing. In case of
> syntax-propertize-function it's a complete black box. The function can decide to
> do whatever there.
>
> Luckily if major-modes doesn't use widen or parse-partial-sexp directly it all
> seem to work quite well with proper advice of relevant functions.
>
>    Vitalie
>

Okay, thanks.

Still think it's best to continue with a real-case scenario, discussing 
possible solutions.

Andreas

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Vitalie Spinu]

>> On Wed, Mar 23 2016 18:14, Andreas Röhler wrote:

> Still think it's best to continue with a real-case scenario, discussing
> possible solutions.

Here is a non multi-mode real case:

 1) goto arbitrary Info page
 2) narrow to a region
 3) widen

You will get the whole info manual. Hard narrowing will allow widening to
original page in step (3).


  Vitalie
   

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> > Still think it's best to continue with a real-case scenario, discussing
> > possible solutions.
> 
> Here is a non multi-mode real case:
> 
>  1) goto arbitrary Info page
>  2) narrow to a region
>  3) widen
> 
> You will get the whole info manual.

No.  You will get the full current Info file, which is what you
asked for (with `C-x n w').

> Hard narrowing will allow widening to original page in step (3).

What "original page"?  Perhaps you mean the current Info node?

What do you mean by "allow"?  Do you mean that `C-x w' will no
longer widen to the full Info file?  That would be a regression.

You should use another function if you want to return to the
current Info node in Info mode.  It is sufficient to hit `g'
and give the current node name.

No need for any new-fangled hard-widening feature for this
use case.  And no need to break the use of widening to get
to the full Info file.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Vitalie Spinu]

>> On Wed, Mar 23 2016 17:37, Drew Adams wrote:

> No.  You will get the full current Info file, which is what you
> asked for (with `C-x n w').

I asked for original view (page, node call it as you want). Info gave me a
buffer, I narrowed, then widened and got surprised. The user need not be exposed
to internal implementation of Info.

>> Hard narrowing will allow widening to original page in step (3).

> What do you mean by "allow"?  Do you mean that `C-x w' will no
> longer widen to the full Info file?  

"allow" means that it would be possible to use it for that purpose. It's not up
to me to decide if hard narrowing will be used in info or how it will be used.

  Vitalie

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> > No.  You will get the full current Info file, which is what you
> > asked for (with `C-x n w').
> 
> I asked for original view (page, node call it as you want). Info
> gave me a buffer, I narrowed, then widened and got surprised.

One could argue that the surprise is your fault. ;-)  You asked
to widen to the full buffer, and that's what you got.  Presumably,
if you ask for that then you want the whole buffer (whatever that
might be), and in this context presumably you know what that whole
buffer is (an Info file).  If not, you shouldn't be using `C-x n w'.

> The user need not be exposed to internal implementation of Info.

Need not?  A user of `C-x n w' should have some expectation that
what s?he sees is not the full buffer, and s?he should not have
a false preconception about what the full buffer might be like.

On the other hand, if we take your view about surprise here
then the issue is more general: `C-x n w' could be surprising
in any context where Emacs narrows a buffer by default.

Taking that into account, it should perhaps be the case that
`C-x n w', just like `C-x n n', should have property `disabled'
set to non-nil by default.  That should remove your surprise.

(And it's not just an "internal implementation", IMO.  Not every
Emacs users needs to know that Info uses files and display of a
node narrows to part of a file, of course.  But that information
is available to users, and they can make use of it.)

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Dmitry Gutov]

On 03/24/2016 03:53 PM, Drew Adams wrote:

> One could argue that the surprise is your fault. ;-)  You asked
> to widen to the full buffer, and that's what you got.  Presumably,
> if you ask for that then you want the whole buffer (whatever that
> might be), and in this context presumably you know what that whole
> buffer is (an Info file).  If not, you shouldn't be using `C-x n w'.

Just how, then, should a user undo the result of narrow-to-region, which 
is a user-level operation?

Even if it's one that's disabled by default.

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> > One could argue that the surprise is your fault. ;-)  You asked
> > to widen to the full buffer, and that's what you got.  Presumably,
> > if you ask for that then you want the whole buffer (whatever that
> > might be), and in this context presumably you know what that whole
> > buffer is (an Info file).  If not, you shouldn't be using `C-x n w'.
> 
> Just how, then, should a user undo the result of narrow-to-region, which
> is a user-level operation?  Even if it's one that's disabled by default.

Good question.  Depends what you mean by "undo" it.  Depends
what the user wants.

In vanilla Emacs, so far, `C-x n w' undoes a buffer restriction,
restoring the full buffer.  That's clear.

But if you mean something other than that as "undo" then you need
to specify just what that other is.

FWIW, my library `zones.el' has this very question at heart, and
it provides some other useful meanings of "undo" for narrowing.
I have no problem with vanilla Emacs adding additional ones.

What I question is co-opting `widen' to redefine it so that it
performs only one particular sort of new kind of "undo" for
narrowing.

Instead, please consider any forms of "undo" for narrowing, other
than widening to the full buffer, to be changes to a different
narrowing.  As long as the result is a buffer restriction (a
narrowing), such a change is still narrowing.

FWIW, zones.el provides for multiple narrowings, and "undoing"
from one to another.

The first title in the doc for this is "Problem: Narrowing is
Fine-Grained, But Widening Is Not".  So I think I understand
the use of having other kinds of undo, besides just `C-x n w'.

(https://www.emacswiki.org/emacs/MultipleNarrowings)

The Emacs world is a wider place than what you have in mind
for one form of widening, whatever that might be.  Your form
can line up with any number of others - they are all narrowings
(buffer restrictions), and I doubt that any one of them should
be privileged to be considered "the hard" widening.

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Stefan Monnier]

> What I question is co-opting `widen' to redefine it so that it
> performs only one particular sort of new kind of "undo" for
> narrowing.

The important part is that we need a command that makes the buffer "as
wide as is meaningful".  Usually that's the whole buffer, but in
info-mode it's not.


        Stefan

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> > What I question is co-opting `widen' to redefine it so that it
> > performs only one particular sort of new kind of "undo" for
> > narrowing.
> 
> The important part is that we need a command that makes the buffer "as
> wide as is meaningful".  Usually that's the whole buffer, but in
> info-mode it's not.

The important part is to define one or more "meaningful" behaviors
for any given context (such as Info).

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Stefan Monnier]

> The important part is to define one or more "meaningful" behaviors
> for any given context (such as Info).

Indeed, there can be several "meaningful" choices.

Currently, narrowing doesn't say anything about what is being narrowed
or why, so we can't distinguish between different cases, which means
that it's impossible for something like font-lock or syntax-ppss (which
can require additional contextual info in order to correctly process
the narrowed pat of the buffer) to know how much to widen.


        Stefan

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Andreas Röhler]

On 24.03.2016 01:03, Vitalie Spinu wrote:
>
>>> On Wed, Mar 23 2016 18:14, Andreas Röhler wrote:
>> Still think it's best to continue with a real-case scenario, discussing
>> possible solutions.
> Here is a non multi-mode real case:
>
>   1) goto arbitrary Info page
>   2) narrow to a region
>   3) widen
>
> You will get the whole info manual. Hard narrowing will allow widening to
> original page in step (3).
>
>
>    Vitalie
>     
Don't see why info couldn't care for that - for example by indexing 
previous narrowing and re-narrow following widen if appropriate.

May think of nested narrows that way, which wouldn't require changes of 
Emacs core.

But info seems a special case anyway, while a true multi-mode really 
being at stake. Instead of diving into info now, suggest to continue 
with a multi-mode issue.

RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality

[Drew Adams]

> > preventing unwanted widen instead seems the way to go.
> 
> That's precisely what extra limit do. Prevent unwanted widen. How do you
> propose
> to implement that?
> 
> I see 4 ways to go about it:
> 
>   1) Add an extra prog-widen and teach all modes out there to use it in
> contexts like syntax-parsing, indentation, font-lock and who know what else. A
> half backed version of this in already part of emacs.
> 
>   2) Have low level restrictions directly in `widen` and a macro
>      `with-widen-limit` that multi-modes can use. This is the current patch.
> 
>   3) Have two types of narrowing (soft and hard). This is harder to
> implement but has the benefit that it can be used in non-transient situations
> like Info mode.
> 
>   4) Bring widen to elisp and allow minor modes (and Info mode) advice widen
> in whatever way they see.
> 
> I think (1) is a bad idea. (4) is simplest and very general. (3) might be
> useful but it's hard. (2) is implemented to get rid of (1).
> 
> I proposed (4) very early in the thread, but didn't hear much support for
> it. There are only three trivial usages of Fwiden in C code. Bringing
> `narrow` to elisp is equally easy.

At least now you're backing up to talk about multiple possible
solutions, instead of digging in deeper in your discussion of a
single implementation (or is it two implementations that you and
Stefan are considering?).

I asked for a clear statement (at least a summary, but preferably a
mini-spec) of the _problem_ you are trying to solve.  My request was
ignored.  So be it.  Continue on, the two of you ... but don't be
surprised if people wonder about your solution after a while.

As for solutions (for what I'm only guessing might be the problem),
I suppose there are additional possibilities, including perhaps a
`with-buffer-limits' macro or perhaps even adapting `point-min' and
`point-max' (e.g. by let-binding global variables that they respond
to - e.g., variables `point-min' and `point-max').

Dunno.  It's hard to guess at a solution without understanding the
problem.  All I've gathered so far is that you want certain zones
of the buffer to act as if the major mode is this or that, and in
those zones you want some code (which code? all code?) to treat
`point-min' and `point-max' as the zone limits, i.e., to act as if
there is nothing outside of the zone limits.

Just what that means in detail is not clear (not specified).
Something about font-locking ... and some other blah.  Not clear.

No, I don't need to understand; I'm just one user, and I probably
have nothing useful to offer as a suggestion.  But my guess is
that if more people here had an idea of what problem you are
trying to solve then you might get some useful input.  Just a guess.