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