From: Pierre Rouleau <prouleau001@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: [External] : forward-sexp
Date: Sun, 13 Aug 2023 10:02:40 -0400 [thread overview]
Message-ID: <CALTqLiZszq1cg+LaHtZK8HVLTKd0OWqVzzS94Pk2gMrC2LE4Rw@mail.gmail.com> (raw)
In-Reply-To: <87msyvkihg.fsf@dataswamp.org>
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
next prev parent reply other threads:[~2023-08-13 14:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 17:23 forward-sexp Andreas Röhler
2023-08-11 17:43 ` [External] : forward-sexp Drew Adams
2023-08-11 17:58 ` Emanuel Berg
2023-08-11 19:20 ` Andreas Röhler
2023-08-11 19:47 ` Pierre Rouleau
2023-08-11 20:02 ` Andreas Röhler
2023-08-11 20:07 ` Drew Adams
2023-08-11 20:09 ` Pierre Rouleau
2023-08-11 20:17 ` Emanuel Berg
2023-08-11 20:14 ` Emanuel Berg
2023-08-12 20:41 ` Drew Adams
2023-08-12 22:23 ` Emanuel Berg
2023-08-13 14:02 ` Pierre Rouleau [this message]
2023-08-13 15:42 ` Drew Adams
2023-08-13 16:45 ` Pierre Rouleau
2023-08-20 4:08 ` Emanuel Berg
2023-08-20 4:04 ` Emanuel Berg
2023-08-20 3:50 ` Emanuel Berg
2023-08-13 15:08 ` Drew Adams
2023-08-11 20:23 ` Drew Adams
2023-08-11 20:30 ` Emanuel Berg
2023-08-12 20:42 ` Drew Adams
2023-08-12 22:12 ` Emanuel Berg
2023-08-13 15:08 ` Drew Adams
2023-08-12 6:44 ` Andreas Röhler
2023-08-11 20:09 ` Emanuel Berg
2023-08-11 20:01 ` Drew Adams
2023-08-11 20:06 ` Emanuel Berg
2023-08-12 20:41 ` Drew Adams
2023-08-12 22:14 ` Emanuel Berg
2023-08-13 6:53 ` Andreas Röhler
2023-08-13 6:57 ` Eli Zaretskii
2023-08-13 15:04 ` Drew Adams
2023-08-20 4:48 ` Emanuel Berg
2023-09-09 7:22 ` Andreas Röhler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALTqLiZszq1cg+LaHtZK8HVLTKd0OWqVzzS94Pk2gMrC2LE4Rw@mail.gmail.com \
--to=prouleau001@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).