Re: [External] : forward-sexp

[Pierre Rouleau]

On Sun, Aug 13, 2023 at 8:52 AM Emanuel Berg <incal@dataswamp.org> wrote:

> Drew Adams wrote:
>
> >>> But similarly, if you try just ["abc] or ["(abc] then
> >>> you'll run into the same group-didn't-end
> >>> (no-matching-delimiter) behavior.
> >>
> >> There should be no incorrect commands, if there are there
> >> will be people using them "incorrectly", if you will.
> >> But if every command work everywhere none of that can
> >> happen, right?
> >
> > What do you think is incorrect in the examples given?
> > When you ask Emacs to go forward in such a way as to take
> > into account balanced delimiters such as parens, then if it
> > doesn't find a closing delimiter that matches before the end
> > of the buffer, it tells you that. Seems like the right
> > behavior, to me...
>
> No, that would be the way to do it, if there is no notion of
> symbolic expressions, one would fall back to some other
> behavior, preferably something not to far away from both the
> name of the function or the usual way it is used in practice,
> i.e. what would be thought to be expected to reflect that in
> the supposed sexp-less setting ...
>
> So either one would have a small set of functions that would
> work everywhere, but differently depending on the context,
> _or_ one would have a huge, always growing set of functions
> and every one of those would work in one and only one
> context ...
>
>
Would it not help to have a selectable behaviour:
- by default the end of a balanced expression expects inner expressions to
also be balanced (ignoring nested comments)
- another mode would try to match the starting character to the matching
end character, ignoring comments and unbalanced/partial expressions made of
other characters.

So by default:

- [  (  ]        : would find an unbalanced () and would not find ]  - as
it behaves now
- [ ( { } ) ]    : would match fine

But when operating in that other (new) "mode":

- [ ( ]        : would match '[' to ']'  regardless of the characters
between them, even if there is an unbalanced expression
- [ ( { } ) ]  : would match any of the 3 balanced pairs.

It might be useful to have that other mode.

For example:  I often have to identify an area of code (in any programming
language) that needs to be looked at or changed, or whatever.
For that I often write 2 comments surrounding the code area.
If the second mode worked as described above, I could write a starting
comment  like

/* [ Beginning of the area */

And later the end comment :

/* End of the area ] */

And then I could select the entire area between the '[' in the first
comment and the ']' in the last
comment with this matching command, regardless of the content of the code,
even if that code
has unbalanced arrays.


-- 
/Pierre