forward-sexp

forward-sexp

[Andreas Röhler]

Hi,

see example-code below. M-x forward-sexp RET works from the beginning of 
the first line, but does nothing from the beginning at the second.
Are there reasons for this?

[ asdf ]
[(&asdf]

Thanks,
Andreas

GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0) of 2023-06-16

RE: [External] : forward-sexp

[Drew Adams]

> M-x forward-sexp RET works from the beginning of
> the first line, but does nothing from the beginning at the second.
> Are there reasons for this?
> 
> [ asdf ]
> [(&asdf]

The syntactic definition of "sexp" depends
on the context, e.g., the current major mode.
Without knowing how a "sexp" is defined in
your context, we can't help much.

That said, trying it in a Lisp mode tells
me that an error is raised when I try it at
the beginning of the second line, because:

Debugger entered--Lisp error:
(scan-error "Unbalanced parentheses" 450 459)
  scan-sexps(450 1)
  forward-sexp(1)
  funcall-interactively(forward-sexp 1)
  call-interactively(forward-sexp nil nil)
  command-execute(forward-sexp)

IOW, the `(' char isn't balanced with a `)'
char, so parsing to the end of the `[' sexp
isn't possible.

Re: [External] : forward-sexp

[Emanuel Berg]

Drew Adams wrote:

>> [ asdf ]
>> [(&asdf]
>
> That said, trying it in a Lisp mode [...]

If that is Lisp, I QUIT!

:D

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Andreas Röhler]

Am 11.08.23 um 19:43 schrieb Drew Adams:
>> M-x forward-sexp RET works from the beginning of the first line, but 
>> does nothing from the beginning at the second. Are there reasons for 
>> this? [ asdf ] .

> The syntactic definition of "sexp" depends on the context, e.g., the 
> current major mode. Without knowing how a "sexp" is defined in your 
> context, we can't help much. That said, trying it in a Lisp mode tells 
> me that an error is raised when I try it at the beginning of the 
> second line, because: Debugger entered--Lisp error: (scan-error 
> "Unbalanced parentheses" 450 459) scan-sexps(450 1) forward-sexp(1) 
> funcall-interactively(forward-sexp 1) call-interactively(forward-sexp 
> nil nil) command-execute(forward-sexp) IOW, the `(' char isn't 
> balanced with a `)' char, so parsing to the end of the `[' sexp isn't 
> possible. 

let assume fundamental mode, cursor at opening bracket: what puzzles me,

with [ asdf ] it recognizes the opening bracket.

In such a case, it should not look inside, just travel onto the closing one.

But with [(&asdf] it fails.

Re: [External] : forward-sexp

[Pierre Rouleau]

Hi Andreas,

Does it work with quotes?
For instance:
["(&adsf"]

On Fri, Aug 11, 2023 at 3:21 PM Andreas Röhler <
andreas.roehler@easy-emacs.de> wrote:

>
> Am 11.08.23 um 19:43 schrieb Drew Adams:
> >> M-x forward-sexp RET works from the beginning of the first line, but
> >> does nothing from the beginning at the second. Are there reasons for
> >> this? [ asdf ] .
>
> > The syntactic definition of "sexp" depends on the context, e.g., the
> > current major mode. Without knowing how a "sexp" is defined in your
> > context, we can't help much. That said, trying it in a Lisp mode tells
> > me that an error is raised when I try it at the beginning of the
> > second line, because: Debugger entered--Lisp error: (scan-error
> > "Unbalanced parentheses" 450 459) scan-sexps(450 1) forward-sexp(1)
> > funcall-interactively(forward-sexp 1) call-interactively(forward-sexp
> > nil nil) command-execute(forward-sexp) IOW, the `(' char isn't
> > balanced with a `)' char, so parsing to the end of the `[' sexp isn't
> > possible.
>
> let assume fundamental mode, cursor at opening bracket: what puzzles me,
>
> with [ asdf ] it recognizes the opening bracket.
>
> In such a case, it should not look inside, just travel onto the closing
> one.
>
> But with [(&asdf] it fails.
>
>

-- 
/Pierre

RE: [External] : forward-sexp

[Drew Adams]

> > The syntactic definition of "sexp" depends on the context, e.g., the
> > current major mode. Without knowing how a "sexp" is defined in your
> > context, we can't help much. That said, trying it in a Lisp mode tells
> > me that an error is raised when I try it at the beginning of the
> > second line, because: Debugger entered--Lisp error: (scan-error
> > "Unbalanced parentheses" 450 459) scan-sexps(450 1) forward-sexp(1)
> > funcall-interactively(forward-sexp 1) call-interactively(forward-sexp
> > nil nil) command-execute(forward-sexp) IOW, the `(' char isn't
> > balanced with a `)' char, so parsing to the end of the `[' sexp isn't
> > possible.
> 
> let assume fundamental mode, cursor at opening bracket: what puzzles me,
> 
> with [ asdf ] it recognizes the opening bracket.
> 
> In such a case, it should not look inside, just travel onto the closing one.
> 
> But with [(&asdf] it fails.

As I said, it all depends on how `forward-sexp' is defined in the current mode, which essentially means it depends on what constitutes a sexp.

With point before the second [ or after the first ], `forward-sexp' raises the error (user-error "No next sexp"):

Debugger entered--Lisp error: (user-error "No next sexp")
  user-error("No next sexp")
  forward-sexp(1 10)
  funcall-interactively(forward-sexp 1 10)
  command-execute(forward-sexp)

The code defining `forward-sexp' has this, for interactive use:

(condition-case _
    (forward-sexp arg nil)
  (scan-error (user-error (if (> arg 0)
                              "No next sexp"
                            "No previous sexp"))))

The Elisp manual, node `Motion Via Parsing', says this about `scan-error':

 If the scan reaches the beginning or end of the accessible part of
 the buffer before it has scanned over COUNT parenthetical
 groupings, the return value is ‘nil’ if the depth at that point is
 zero; if the depth is non-zero, a ‘scan-error’ error is signaled.

So it seems that the `(' starts a "parenthetical grouping", which has no end.

IOW, even `fundamental-mode' recognizes parentheses as paired delimiters.

Re: [External] : forward-sexp

[Andreas Röhler]

Il 11.08.23 21:47, Pierre Rouleau ha scritto:
> Hi Andreas,
>
> Does it work with quotes?
> For instance:
> ["(&adsf"]

yes, it does.

Re: [External] : forward-sexp

[Emanuel Berg]

Drew Adams wrote:

> As I said, it all depends on how `forward-sexp' is defined
> [...]

Actually the OP is right, we should have everything Lisp work
everywhere else as well, and it should always make sense.

Maybe not impossible to do BTW ... ?

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : forward-sexp

[Drew Adams]

> > Does it work with quotes?
> > For instance: ["(&adsf"]
> 
> yes, it does.

Because there's no sexp starting with `('.

"..." is just a string, a sexp in its own right.

But similarly, if you try just ["abc] or ["(abc]
then you'll run into the same group-didn't-end
(no-matching-delimiter) behavior.

Re: [External] : forward-sexp

[Pierre Rouleau]

Andreas,

In what version of Emacs do you see [(&asdf] handled the way you want it?

-- 
/Pierre

Re: [External] : forward-sexp

[Emanuel Berg]

Andreas Röhler wrote:

> Does it work with quotes?
> For instance:
> ["(&adsf"]

It works better! Because then it can be evaluated into
a string.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Emanuel Berg]

Drew Adams wrote:

>>> Does it work with quotes?
>>> For instance: ["(&adsf"]
>> 
>> yes, it does.
>
> Because there's no sexp starting with `('.
>
> "..." is just a string, a sexp in its own right.
>
> 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?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Emanuel Berg]

Pierre Rouleau wrote:

> In what version of Emacs do you see [(&asdf] handled the way
> you want it?

It's a make system for Common Lisp that is actually really
nice! But it isn't optimal in theory since the files way of
sticking together, from that can be infeed what libraries and
packages are to be installed - and in what order, also ...

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : forward-sexp

[Drew Adams]

Put your cursor just before a `[' char and use `C-u C-x ='.
Same thing for a `(' char and a `"' char.  What does it say
for syntax?

For `[' it says this (in fundamental-mode):

 syntax: (] which means: open, matches ]

For `)' it says this:

 syntax: () which means: open, matches )

For `"' it says this:

 syntax: " which means: string

Re: [External] : forward-sexp

[Emanuel Berg]

Drew Adams wrote:

> Put your cursor just before a `[' char and use `C-u C-x ='.
> Same thing for a `(' char and a `"' char. What does it say
> for syntax?

One EASY way of solving this would be that everyone just used
the Lisp syntax ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Andreas Röhler]

Am 11.08.23 um 22:23 schrieb Drew Adams:
> Put your cursor just before a `[' char and use `C-u C-x ='.
> Same thing for a `(' char and a `"' char.  What does it say
> for syntax?
>
> For `[' it says this (in fundamental-mode):
>
>   syntax: (] which means: open, matches ]


It would match also }

Looks like an inability to discern (), [], {} syntactically.

Likewise, when jumping backward from ], it reaches (


Same with {(asdf}

RE: [External] : forward-sexp

[Drew Adams]

> > As I said, it all depends on how `forward-sexp' is defined
> > [...]
> 
> Actually the OP is right, we should have everything Lisp work
> everywhere else as well, and it should always make sense.

Right about what?  The notion of a sexp, just
like the notion of a word, depends on the context.
That's a feature, not a bug.

If some particular context doesn't define sexp
syntax usefully, then `M-x report-emacs-bug' with
the specifics about what you think is wrong.

RE: [External] : forward-sexp

[Drew Adams]

> > 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...

RE: [External] : forward-sexp

[Drew Adams]

> > Put your cursor just before a `[' char and use `C-u C-x ='.
> > Same thing for a `(' char and a `"' char. What does it say
> > for syntax?
> 
> One EASY way of solving this would be that everyone just used
> the Lisp syntax ...

Solving what?  If you think you see a bug, then
`M-x report-emacs-bug'.  (I don't see any bug.)

Different contexts, whether programming language
or anything else, are free to define different
syntax.

It's up to any given context to come up with
appropriate behavior for moving over various
syntactic thingies there, whether words, sexps,
sentences, whatever.  A comma in Lisp isn't the
same as a comma in JavaScript...

Vive la différence !

Re: [External] : forward-sexp

[Emanuel Berg]

Drew Adams wrote:

>>> Put your cursor just before a `[' char and use `C-u C-x
>>> ='. Same thing for a `(' char and a `"' char. What does it
>>> say for syntax?
>> 
>> One EASY way of solving this would be that everyone just
>> used the Lisp syntax ...
>
> Solving what? If you think you see a bug, then `M-x
> report-emacs-bug'. (I don't see any bug.) [...] Vive
> la différence!

But if everyone used the same syntax, everyone could access
everyone's data in any way they would like. So in a way it
would be even more different what way. But I think it would be
awkward to submit this as a bug to Emacs - especially since we
already use the Lisp syntax.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Emanuel Berg]

Drew Adams wrote:

>>> As I said, it all depends on how `forward-sexp' is defined
>>> [...]
>> 
>> Actually the OP is right, we should have everything Lisp
>> work everywhere else as well, and it should always
>> make sense.
>
> Right about what? The notion of a sexp, just like the notion
> of a word, depends on the context. That's a feature, not
> a bug.

Indeed, it would be allowed to do different things based
on context.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Emanuel Berg]

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 ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Andreas Röhler]

Am 12.08.23 um 22:41 schrieb Drew Adams:
>>> As I said, it all depends on how `forward-sexp' is defined
>>> [...]
>>

While every mode is entitled to design commands at their needs, it
must respect semantic.

‘sexp’ is documented as ‘balanced expression’.

If an expression starts with an [, I'm holding its balancing
counterpart as obvious. No ( or other char may come into scope.

Re: [External] : forward-sexp

[Eli Zaretskii]

> Date: Sun, 13 Aug 2023 08:53:41 +0200
> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> 
> 
> While every mode is entitled to design commands at their needs, it
> must respect semantic.
> 
> ‘sexp’ is documented as ‘balanced expression’.
> 
> If an expression starts with an [, I'm holding its balancing
> counterpart as obvious. No ( or other char may come into scope.

But only if [ and ( are treated as a parenthesis by the major mode.

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

RE: [External] : forward-sexp

[Drew Adams]

> > While every mode is entitled to design commands at their needs, it
> > must respect semantic.
> >
> > ‘sexp’ is documented as ‘balanced expression’.
> >
> > If an expression starts with an [, I'm holding its balancing
> > counterpart as obvious. No ( or other char may come into scope.
> 
> But only if [ and ( are treated as a parenthesis by the major mode.

Exactly the point.
___

Andreas: If you feel that a sexp is defined
poorly for `fundamental-mode', or if you feel
that it's defined as you think it should be
but `forward-sexp' in `fundamental-mode'
doesn't fit that definition, then consider
reporting a bug or requesting an enhancement:
`M-x report-emacs-bug'.

That's the point.  A "sexp" is _whatever the
major mode says it is_.  And `forward-sexp',
in any mode, should move past the next sexp
according to what the mode defines as a sexp.

(By "should", I mean _conventionally_, so
that code relying on `forward-sexp' works as
one expects.  Nothing _prevents_ a mode from
defining `forward-sexp' from doing anything
it wants: ringing a bell, baking a cake,...

And no, it's not "obvious" that `]' is a
balanced counterpart to `['.  And neither is
it obvious, even if that were always the case,
that what follows `[' up till the next `]' is
to be ignored.

All such "sexp" behavior is _defined_ by the
mode, _for_ the mode.  "Sexp is of the mode,
by the mode, and for the mode." - A.L. 

You seem to have some underlying assumptions
wrt `[' (or perhaps wrt `(') that you don't
express explicitly, and which conflict with
how "sexp" is defined for `fundamental-mode'
(or perhaps for _any_ mode?).

`M-x report-emacs-bug', to make your
expectations/preferences explicit.   But be
specific, wrt both the mode and the exact
behavior you expect/want.

RE: [External] : forward-sexp

[Drew Adams]

> >>> Put your cursor just before a `[' char and use `C-u C-x
> >>> ='. Same thing for a `(' char and a `"' char. What does it
> >>> say for syntax?
> >>
> >> One EASY way of solving this would be that
> >> everyone just used the Lisp syntax ...
> >
> > Solving what? If you think you see a bug, then `M-x
> > report-emacs-bug'. (I don't see any bug.) [...] Vive
> > la différence!
> 
> But if everyone used the same syntax, everyone could
> access everyone's data in any way they would like.

"La différence" in question is not this person
versus that person (but that too is available,
through customization).  The difference is that
of different major modes.  And different major
modes are often for different programming or
natural _languages_.

And different languages treat different char
and sequences of chars differently.  Likewise
different kinds of textual data - "everyone's
data" is not the same.  The syntax of JSON
data is not that of XML data.

> So in a way it would be even more different
> what way. But I think it would be awkward to
> submit this as a bug to Emacs

I don't expect such a bug/ER to gain traction,
but then again, nothing specific specifying
what's requested has been presented so far.
Maybe the devil is in the details.

My point in suggesting `M-x report-emacs-bug'
is that that's how to specify some change in
behavior you'd like Emacs to adopt.  (It's not
the only way, but it is one recommended way.)

> - especially since we already use the Lisp syntax.

No, we don't.  Certainly not for many major
modes.  Otherwise, much of what a major mode
defines wouldn't even exist - from movement
(including `forward-sexp'), to font-locking,
to error handling, to ...

This is the point.  (And I'm surprised it's
not getting across more easily.)  Different
modes use different syntax.  Sometimes,
often (even most often?).  Is this really a
surprise or hard to fathom?

RE: [External] : forward-sexp

[Drew Adams]

> >>> 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 ...

Sorry, but I can't grok your reply.  I have a
feeling it might have nothing to do with what
I wrote, but that might be mistaken.  In any
case, I don't follow it; sorry.

RE: [External] : forward-sexp

[Drew Adams]

> > >>> 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.

What's the "default" syntax?  What default
syntax makes sense globally?  What does a
"balanced expression" mean, by default?
What does an "inner expression" mean by
default?

More basically: what does an _"expression"_
mean by default?

I've just defined a mode `foobar'.  I don't
tell you anything about it.  What do you
suppose an expression looks like in my mode?
Can't you guess?  Why not?  That's the point
- you can't, and neither can I.

Modes (can, and generally do) establish the
syntax relevant for their buffers.

And to be clear, `fundamental-mode' isn't
really a mode that anyone is expected to
use interactively (but you can, of course).
It's pretty much there as a base, for
defining other modes.  From (emacs) node
`Major Modes':

 The least specialized major mode is called
 “Fundamental mode”.  This mode has no
 mode-specific redefinitions or variable
 settings, so that each Emacs command behaves
 in its most general manner, and each user
 option variable is in its default state.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Major-Modes.html

> 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.

If this is (the beginning of) a request for a
different "sexp" definition & behavior for
`fundamental-mode', I suggest you send it for
consideration to the Emacs developers, using
`M-x report-emacs-bug', or you send it by mail
to emacs-devel@gnu.org for discussion.

This help-gnu-emacs@gnu.org list is mainly for
help questions.  (There's nothing _wrong_ with
sending other comments/ideas here.  But this
generally isn't the best place to do so.)

> 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.

"in any programming language", even if true,
would already be too specific for
`fundamental-mode', i.e., for a global,
general default notion of "sexp".  It would,
if true, likely be appropriate for any mode
that inherits from `prog-mode' (see
`derived-mode-p').

(emacs) `Major Modes' also tells you:

 Most major modes fall into three major groups.
 The first group contains modes for normal
 text, either plain or with mark-up.  It includes
 Text mode, HTML mode, SGML mode, TeX mode and
 Outline mode.  The second group contains modes
 for specific programming languages.  These
 include Lisp mode (which has several variants),
 C mode, Fortran mode, and others.  The third
 group consists of major modes that are not
 associated directly with files; they are used in
 buffers created for specific purposes by Emacs.

`fundamental-mode' underlies them all.  Its idea
of "sexp" needs to be so general as to be, well,
pretty useless.  No one is really expected to use
`fundamental-mode' interactively, except perhaps
for some testing.

(emacs) `Major Modes' also tells you:

 The default value of ‘major-mode’ determines
 the major mode to use for files that do not
 specify a major mode, and for new buffers
 created with ‘C-x b’.  Normally, this default
 value is the symbol ‘fundamental-mode’, which
 specifies Fundamental mode.

 You can change this default value via the
 Customization interface, or by adding a line
 like this to your init file:

 (setq-default major-mode 'text-mode)

 If the default value of ‘major-mode’ is ‘nil’,
 the major mode is taken from the previously
 current buffer.

(emacs) `Major Modes' also tells you:

 all text-based major modes run ‘text-mode-hook’,
 and many programming language modes (including
 all those distributed with Emacs) run
 ‘prog-mode-hook’

See also (elisp) node `Defining Derived Modes':

https://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html

Re: [External] : forward-sexp

[Pierre Rouleau]

On Sun, Aug 13, 2023 at 11:42 AM Drew Adams <drew.adams@oracle.com> wrote:

>
> If this is (the beginning of) a request for a
> different "sexp" definition & behavior for
> `fundamental-mode', I suggest you send it for
> consideration to the Emacs developers, using
> `M-x report-emacs-bug', or you send it by mail
> to emacs-devel@gnu.org for discussion.
>

Indeed, this is an idea for a different feature, some sort of pair-matching
mechanism that would be independent of the major mode perhaps.

Once I have enough time, I'll develop something first to play with the
ideas.  It'll take time as I've been quite busy and expect to be for a
while..


-- 
/Pierre

Re: [External] : forward-sexp

[Emanuel Berg]

Pierre Rouleau wrote:

>> 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.

For programming one could absolutely think of such an idea,
a default behavior.

Because there is so much that are based on the parenthesis,
brackets and such delimiters.

And it would be harmless to since if the local modes didn't
like it, they could overwrite the functions with local ones.

And it would be even cooler if the local variation would be
a local variation of the sexp, local to that mode, and then
the navigation would not have to be reset, just the
local sexp!

Maybe difficult to do so overwriting the navigation would
still be allowed ;)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Emanuel Berg]

Drew Adams wrote:

> More basically: what does an _"expression"_
> mean by default?

I think you are onto something with the families of
programming languages BTW.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Emanuel Berg]

Pierre Rouleau wrote:

>> If this is (the beginning of) a request for a different
>> "sexp" definition & behavior for `fundamental-mode',
>> I suggest you send it for consideration to the Emacs
>> developers, using `M-x report-emacs-bug', or you send it by
>> mail to emacs-devel@gnu.org for discussion.
>>
>
> Indeed, this is an idea for a different feature, some sort
> of pair-matching mechanism that would be independent of the
> major mode perhaps.

1. local definition
2. language family default
3. global default

With inheritance at levels 1-2.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Emanuel Berg]

Drew Adams wrote:

> If you feel that a sexp is defined poorly for
> `fundamental-mode'

Ah, now I remember it in the front of the head as well,
thanks, it already works the way I had it "figured out"
... nevermind.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : forward-sexp

[Andreas Röhler]

Am 13.08.23 um 17:04 schrieb Drew Adams:
>>> While every mode is entitled to design commands at their needs, it
>>> must respect semantic.
>>>
>>> ‘sexp’ is documented as ‘balanced expression’.
>>>
>>> If an expression starts with an [, I'm holding its balancing
>>> counterpart as obvious. No ( or other char may come into scope.
>> But only if [ and ( are treated as a parenthesis by the major mode.
> Exactly the point.
> ___
>
> Andreas: If you feel that a sexp is defined
> poorly for `fundamental-mode', or if you feel
> that it's defined as you think it should be
> but `forward-sexp' in `fundamental-mode'
> doesn't fit that definition, then consider
> reporting a bug or requesting an enhancement:
> `M-x report-emacs-bug'.

bug#65823: 30.0.50; sexp mismatches