From: Drew Adams <drew.adams@oracle.com>
To: Pierre Rouleau <prouleau001@gmail.com>,
"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: RE: [External] : forward-sexp
Date: Sun, 13 Aug 2023 15:42:18 +0000 [thread overview]
Message-ID: <SJ0PR10MB54886879464BB9298C339AC1F316A@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CALTqLiZszq1cg+LaHtZK8HVLTKd0OWqVzzS94Pk2gMrC2LE4Rw@mail.gmail.com>
> > >>> 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
next prev parent reply other threads:[~2023-08-13 15:42 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
2023-08-13 15:42 ` Drew Adams [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB54886879464BB9298C339AC1F316A@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=help-gnu-emacs@gnu.org \
--cc=prouleau001@gmail.com \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.