From: Eli Zaretskii <eliz@gnu.org>
To: Zachary Kanfer <zkanfer@gmail.com>, Juri Linkov <juri@linkov.net>
Cc: ruijie@netyu.xyz, monnier@iro.umontreal.ca,
62892@debbugs.gnu.org, mardani29@yahoo.es
Subject: bug#62892: proposal to extend mark-sexp to go forward and backward on command
Date: Thu, 27 Apr 2023 15:25:59 +0300 [thread overview]
Message-ID: <83r0s5se94.fsf@gnu.org> (raw)
In-Reply-To: <CAFXT+ROk5-ydr22qh0QD0B0F5pyG=vByHcLH1nUyQ32wQGORxQ@mail.gmail.com> (message from Zachary Kanfer on Wed, 26 Apr 2023 22:37:58 -0400)
> From: Zachary Kanfer <zkanfer@gmail.com>
> Date: Wed, 26 Apr 2023 22:37:58 -0400
> Cc: mardani29@yahoo.es, ruijie@netyu.xyz, monnier@iro.umontreal.ca,
> 62892@debbugs.gnu.org
>
> > > Worse still is the next part:
> > >
> > > > Interactively, if this command is repeated
> > > > or (in Transient Mark mode) if the mark is active,
> > > > it marks the next ARG sexps after the ones already marked.
> > >
> > > This says it marks sexps *after* the ones already marked. This is incorrect; if point is *after* mark,
> and
> > > mark is active, this function marks sexps *before* the ones already marked.
> >
> > I cannot reproduce this behavior, if I understand your description
> > correctly. Please show a recipe, starting from "emacs -Q", to
> > reproduce.
>
> Open Emacs with:
>
> emacs -Q --eval '(progn (insert "foo bar baz") (goto-char 8) (set-mark 5))'
>
> It will insert "foo bar baz", put point after "bar", and mark before "bar". Region contains "bar".
>
> Then when we run mark-sexp, we expect to mark some sexps "after the ones already marked". That's
> what the docstring says.
>
> After running the command above to open emacs, press C-M-@ to run mark-sexp. We should see
> sexps marked "after the ones already marked"; that is, we should see "bar baz" marked. But we don't.
> Instead, we see that "foo bar" is highlighted. That is, we have marked sexps *before* the ones already
> marked.
>
> > > The documentation for mark-sexp says:
> > >
> > > > Set mark ARG sexps from point.
> > > > The place mark goes is the same place C-M-<right> would
> > > > move to with the same argument.
> > >
> > > This is correct but misleading.
> >
> > Please elaborate: how could it mislead?
>
> "The same argument" is the misleading part. If I call mark-sexp with no argument, sometimes that code
> passes -1 to forward-sexp. So while I think I'm effectively passing a "1" to mark-sexp, instead -1 is
> passed to forward-sexp. This is somewhat explained by the next part of the docstring, but not entirely.
> Read with the rest of the docstring, it reinforces the belief that the command only marks sexps *after*
> point.
Thanks.
Yes, we have a small mess on our hands here. Over the years, as
features were added to this command, the doc string became more and
more inaccurate. Moreover, the behavior itself is somewhat
inconsistent: AFAIK this is the only command that accepts a numeric
argument and yet behaves differently when invoked without an argument
vs with "C-u 1".
I tried to describe the behavior in the doc string as follows:
(defun mark-sexp (&optional arg allow-extend)
"Set mark ARG sexps from point or move mark one sexp.
When called from Lisp with ALLOW-EXTEND ommitted or nil, mark is
set ARG sexps from point; ARG defaults to 1.
With ALLOW-EXTEND non-nil (interactively, with prefix argument),
the place mark goes is the same place \\[forward-sexp] would move
with the same value of ARG; if the mark is active, it moves ARG
sexps from its current position, otherwise it is set ARG sexps
from point; ARG defaults to 1.
When invoked interactively without a prefix argument and no active
region, mark moves one sexp forward.
When invoked interactively without a prefix argument, and region
is active, mark moves one sexp away of point (i.e., forward
if mark is at or after point, back if mark is before point), thus
extending the region by one sexp. Since the direction of region
extension depends on the relative position of mark and point, you
can change the direction by \\[exchange-point-and-mark].
This command assumes point is not in a string or comment."
It is still somewhat complicated and confusing, but at least it's
accurate, I think.
next prev parent reply other threads:[~2023-04-27 12:25 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-17 2:25 bug#62892: proposal to extend mark-sexp to go forward and backward on command Zachary Kanfer
2023-04-17 3:06 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-20 5:25 ` Zachary Kanfer
2023-04-20 7:16 ` Eli Zaretskii
2023-04-21 5:04 ` Zachary Kanfer
2023-04-21 6:07 ` Eli Zaretskii
2023-04-21 7:24 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-21 9:51 ` Visuwesh
2023-04-21 13:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-23 5:33 ` Zachary Kanfer
2023-04-25 22:26 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-26 4:41 ` Zachary Kanfer
2023-04-26 6:28 ` Eli Zaretskii
2023-04-27 2:37 ` Zachary Kanfer
2023-04-27 12:25 ` Eli Zaretskii [this message]
2023-04-27 18:12 ` Juri Linkov
2023-04-28 5:28 ` Zachary Kanfer
2023-05-06 8:49 ` Eli Zaretskii
2023-04-28 17:04 ` Juri Linkov
2023-04-28 19:28 ` Drew Adams
2023-05-04 4:48 ` Zachary Kanfer
2023-05-08 12:28 ` Zachary Kanfer
2023-05-18 3:17 ` Zachary Kanfer
2023-05-18 6:52 ` Eli Zaretskii
2023-05-21 5:46 ` Zachary Kanfer
2023-05-21 5:58 ` Eli Zaretskii
2023-05-21 14:31 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-21 14:39 ` Eli Zaretskii
2023-05-21 14:54 ` Eli Zaretskii
2023-05-21 14:56 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-21 15:11 ` Eli Zaretskii
2023-05-21 15:41 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-22 22:02 ` Richard Stallman
2023-05-23 14:11 ` Zachary Kanfer
2023-05-25 22:32 ` Richard Stallman
2023-05-26 6:06 ` Eli Zaretskii
2023-05-31 3:23 ` Zachary Kanfer
2023-05-31 12:01 ` Eli Zaretskii
2023-06-01 3:54 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-01 6:32 ` Eli Zaretskii
2023-05-03 6:10 ` Zachary Kanfer
2023-05-03 17:29 ` Juri Linkov
2023-04-17 7:11 ` Juri Linkov
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=83r0s5se94.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=62892@debbugs.gnu.org \
--cc=juri@linkov.net \
--cc=mardani29@yahoo.es \
--cc=monnier@iro.umontreal.ca \
--cc=ruijie@netyu.xyz \
--cc=zkanfer@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).