GNU bug report logs -
#62892
proposal to extend mark-sexp to go forward and backward on command
Previous Next
To reply to this bug, email your comments to 62892 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Mon, 17 Apr 2023 02:26:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Zachary Kanfer <zkanfer <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 17 Apr 2023 02:26:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
C-M-@ is bound to `#'mark-sexp`. This command works incrementally -- that
is, calling this once marks the sexp after point; calling it again marks
one more sexp (in total, the two sexps after point).
It would be convenient to easily be able to mark sexps backwards as well.
If you've already marked sexps backwards, mark-sexp extends the region
backwards. But if you haven't, the only way to mark backwards is to pass a
negative prefix argument.
It often is a better experience to iteratively select the sexps you want.
Finally, there's no way to mark both directions, e.g., one sexp forward and
two backwards.
Attached is a patch to add #'mark-sexp-forwards and #'mark-sexp-backwards.
These functions extend the region by sexps forward and backward. They are
mutually incremental: you can call mark-sexp-fowards, then
mark-sexp-backwards twice, then mark-sexp-forwards. After this, the region
will consist of the two sexps before point and the two sexps after point.
These functions are very similar to #'mark-sexp:
- They will extend the region if it already exists.
- They can be called from lisp code with a numeric argument.
- They can take a prefix argument if called interactively.
Thanks,
Zachary Kanfer
[Message part 2 (text/html, inline)]
[0001-Add-mark-sexp-forward-mark-sexp-backward.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Mon, 17 Apr 2023 03:18:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
Zachary Kanfer <zkanfer <at> gmail.com> writes:
> Attached is a patch to add #'mark-sexp-forwards and #'mark-sexp-backwards. These functions extend the region by sexps forward and
> backward. They are mutually incremental: you can call mark-sexp-fowards, then mark-sexp-backwards twice, then mark-sexp-forwards. After
> this, the region will consist of the two sexps before point and the two sexps after point.
If this is to be accepted, why not extend it to all like mark functions,
listed below? Implementing them should be pretty similar, and you might
even be able to reuse the same helper for all these variants. Also, the
helper function might need to contain a double-dash in its name because
this is inherently a private function.
- `mark-defun'
- `mark-page'
- `mark-paragraph'
- `mark-word'
> +(defun mark-sexp-helper (number-of-expressions)
> + "A helper function for 'mark-sexp-[forward, backward]'.
> +
> +If NUMBER-OF-EXPRESSIONS is positive, mark that many sexps forward;
> +otherwise, amrk backward."
Please use `quote' to quote things in Emacs docstrings. Also, both here
and in other docstrings, the newline immediately after the first line,
while seems necessary, is usually redundant in Emacs docstrings. And
there is a typo: "amrk" -> "mark".
I also think you shouldn't use wildcard-like elements in quotes (in your
case, you reuse part of the name in the quote), but I'm not sure.
--
Best,
RY
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Mon, 17 Apr 2023 03:18:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Mon, 17 Apr 2023 07:14:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> C-M-@ is bound to `#'mark-sexp`. This command works incrementally -- that
> is, calling this once marks the sexp after point; calling it again marks
> one more sexp (in total, the two sexps after point).
>
> It would be convenient to easily be able to mark sexps backwards as well.
Did you know that it's possible to switch directions by typing 'C-x C-x'.
After that 'C-M-@' extends the region backwards.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 20 Apr 2023 05:26:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> If this is to be accepted, why not extend it to all like mark functions,
> listed below? Implementing them should be pretty similar, and you might
> even be able to reuse the same helper for all these variants. Also, the
> helper function might need to contain a double-dash in its name because
> this is inherently a private function.
This makes sense to me, although I have not found the same need for these
to be marked. I'm happy to extend them as such; I'll add that in a later
patch.
> Please use `quote' to quote things in Emacs docstrings. Also, both here
> and in other docstrings, the newline immediately after the first line,
> while seems necessary, is usually redundant in Emacs docstrings. And
> there is a typo: "amrk" -> "mark".
>
> I also think you shouldn't use wildcard-like elements in quotes (in your
> case, you reuse part of the name in the quote), but I'm not sure.
Done. Updated patch attached.
On Sun, Apr 16, 2023 at 11:17 PM Ruijie Yu <ruijie <at> netyu.xyz> wrote:
>
> Zachary Kanfer <zkanfer <at> gmail.com> writes:
>
> > Attached is a patch to add #'mark-sexp-forwards and
> #'mark-sexp-backwards. These functions extend the region by sexps forward
> and
> > backward. They are mutually incremental: you can call mark-sexp-fowards,
> then mark-sexp-backwards twice, then mark-sexp-forwards. After
> > this, the region will consist of the two sexps before point and the two
> sexps after point.
>
> If this is to be accepted, why not extend it to all like mark functions,
> listed below? Implementing them should be pretty similar, and you might
> even be able to reuse the same helper for all these variants. Also, the
> helper function might need to contain a double-dash in its name because
> this is inherently a private function.
>
> - `mark-defun'
> - `mark-page'
> - `mark-paragraph'
> - `mark-word'
>
> > +(defun mark-sexp-helper (number-of-expressions)
> > + "A helper function for 'mark-sexp-[forward, backward]'.
> > +
> > +If NUMBER-OF-EXPRESSIONS is positive, mark that many sexps forward;
> > +otherwise, amrk backward."
>
> Please use `quote' to quote things in Emacs docstrings. Also, both here
> and in other docstrings, the newline immediately after the first line,
> while seems necessary, is usually redundant in Emacs docstrings. And
> there is a typo: "amrk" -> "mark".
>
> I also think you shouldn't use wildcard-like elements in quotes (in your
> case, you reuse part of the name in the quote), but I'm not sure.
>
> --
> Best,
>
>
> RY
>
[Message part 2 (text/html, inline)]
[0001-Add-mark-sexp-forward-mark-sexp-backward.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 20 Apr 2023 05:26:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 20 Apr 2023 07:17:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> Cc: 62892 <at> debbugs.gnu.org
> From: Zachary Kanfer <zkanfer <at> gmail.com>
> Date: Thu, 20 Apr 2023 01:25:29 -0400
>
> > If this is to be accepted, why not extend it to all like mark functions,
> > listed below? Implementing them should be pretty similar, and you might
> > even be able to reuse the same helper for all these variants. Also, the
> > helper function might need to contain a double-dash in its name because
> > this is inherently a private function.
>
> This makes sense to me, although I have not found the same need for these to be marked. I'm happy
> to extend them as such; I'll add that in a later patch.
>
> > Please use `quote' to quote things in Emacs docstrings. Also, both here
> > and in other docstrings, the newline immediately after the first line,
> > while seems necessary, is usually redundant in Emacs docstrings. And
> > there is a typo: "amrk" -> "mark".
> >
> > I also think you shouldn't use wildcard-like elements in quotes (in your
> > case, you reuse part of the name in the quote), but I'm not sure.
>
> Done. Updated patch attached.
Thanks.
Did you see the comment by Juri, viz.:
> Did you know that it's possible to switch directions by typing 'C-x C-x'.
> After that 'C-M-@' extends the region backwards.
AFAIU, this means we already have an easy method to have C-M-@ switch
directions, and the changes you propose might therefore be
unnecessary. WDYT?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Fri, 21 Apr 2023 05:05:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
It's able to be worked around, yes -- but I think it's easier to have
separate methods for forward and backward, the way we do for so many other
commands. For one, having separate functions makes it easier to start
moving backward, (rather than giving a -1 prefix argument.
It's especially useful, I think, because on default Emacs, both C-M-SPC and
C-M-S-SPC are bound to mark-sexp; it's quite nice to have C-M-SPC bound to
mark-sexp-forward and C-M-S-SPC bound to mark-sexp-backward. So there are
seemingly obvious keybindings to use for it (even if not in stock Emacs).
On Thu, Apr 20, 2023 at 3:16 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Cc: 62892 <at> debbugs.gnu.org
> > From: Zachary Kanfer <zkanfer <at> gmail.com>
> > Date: Thu, 20 Apr 2023 01:25:29 -0400
> >
> > > If this is to be accepted, why not extend it to all like mark
> functions,
> > > listed below? Implementing them should be pretty similar, and you
> might
> > > even be able to reuse the same helper for all these variants. Also,
> the
> > > helper function might need to contain a double-dash in its name because
> > > this is inherently a private function.
> >
> > This makes sense to me, although I have not found the same need for
> these to be marked. I'm happy
> > to extend them as such; I'll add that in a later patch.
> >
> > > Please use `quote' to quote things in Emacs docstrings. Also, both
> here
> > > and in other docstrings, the newline immediately after the first line,
> > > while seems necessary, is usually redundant in Emacs docstrings. And
> > > there is a typo: "amrk" -> "mark".
> > >
> > > I also think you shouldn't use wildcard-like elements in quotes (in
> your
> > > case, you reuse part of the name in the quote), but I'm not sure.
> >
> > Done. Updated patch attached.
>
> Thanks.
>
> Did you see the comment by Juri, viz.:
>
> > Did you know that it's possible to switch directions by typing 'C-x C-x'.
> > After that 'C-M-@' extends the region backwards.
>
> AFAIU, this means we already have an easy method to have C-M-@ switch
> directions, and the changes you propose might therefore be
> unnecessary. WDYT?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Fri, 21 Apr 2023 06:07:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> From: Zachary Kanfer <zkanfer <at> gmail.com>
> Date: Fri, 21 Apr 2023 01:04:30 -0400
> Cc: ruijie <at> netyu.xyz, 62892 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>
> It's able to be worked around, yes -- but I think it's easier to have separate methods for forward and
> backward, the way we do for so many other commands. For one, having separate functions makes it
> easier to start moving backward, (rather than giving a -1 prefix argument.
Adding functions and commands is not free, it does come with a price:
they need to be documented in our two manuals (something your patch
neglected to do, btw), users need to learn them, etc.
So I wonder whether on balance it is justified to add this. Lars,
Stefan: any comments or opinions?
Does anyone else have an opinion?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Fri, 21 Apr 2023 07:25:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 62892 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Zachary Kanfer <zkanfer <at> gmail.com>
>> Date: Fri, 21 Apr 2023 01:04:30 -0400
>> Cc: ruijie <at> netyu.xyz, 62892 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>>
>> It's able to be worked around, yes -- but I think it's easier to have separate methods for forward and
>> backward, the way we do for so many other commands. For one, having separate functions makes it
>> easier to start moving backward, (rather than giving a -1 prefix argument.
>
> Adding functions and commands is not free, it does come with a price:
> they need to be documented in our two manuals (something your patch
> neglected to do, btw), users need to learn them, etc.
>
> So I wonder whether on balance it is justified to add this. Lars,
> Stefan: any comments or opinions?
>
> Does anyone else have an opinion?
Not really a strong opinion, but just a couple of thoughts:
- The ability to extend the selection forward and backward is a nice and
desirable feature.
- C-x C-x is a general mechanism that's useful in many situations and
users are hopefully already familiar with it (although not necessarily
aware of this specific use case, I wasn't!), so if it fits the bill it
makes sense to reuse it rather than introducing new specialized commands.
- Whatever decision is made with regards to mark-sexp, I think it should
be consistent with similar marking commands. Notably, mark-word
currently behaves like mark-sexp, and I think that adding e.g.
mark-sexp-backward without also adding mark-word-backward would somewhat
hinder consistency.
Regards,
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Fri, 21 Apr 2023 09:53:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி ஏப்ரல் 21, 2023] Eli Zaretskii wrote:
>> From: Zachary Kanfer <zkanfer <at> gmail.com>
>> Date: Fri, 21 Apr 2023 01:04:30 -0400
>> Cc: ruijie <at> netyu.xyz, 62892 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>>
>> It's able to be worked around, yes -- but I think it's easier to have separate methods for forward and
>> backward, the way we do for so many other commands. For one, having separate functions makes it
>> easier to start moving backward, (rather than giving a -1 prefix argument.
>
> Adding functions and commands is not free, it does come with a price:
> they need to be documented in our two manuals (something your patch
> neglected to do, btw), users need to learn them, etc.
>
> So I wonder whether on balance it is justified to add this. Lars,
> Stefan: any comments or opinions?
>
> Does anyone else have an opinion?
In situations like these, I extend the region simply by motion commands
after marking the current sexp. If I want to go in the opposite
direction, I type C-x C-x. I don't see myself ever using these
commands.
This mechanism works for every object that has a mark command, not just
sexp which I consider a plus.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Fri, 21 Apr 2023 13:11:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> If this is to be accepted, why not extend it to all like mark functions,
> listed below? Implementing them should be pretty similar, and you might
> even be able to reuse the same helper for all these variants. Also, the
> helper function might need to contain a double-dash in its name because
> this is inherently a private function.
>
> - `mark-defun'
> - `mark-page'
> - `mark-paragraph'
> - `mark-word'
Agreed: we should move towards a more orthogonal/composable design,
where the granularity of the operation (char, word, line, sexp,
paragraph, page, defun, ...) and the operation itself (move, mark) and
the direction and all independent such that we can use any combination
of them.
Both at the ELisp level and at the key-binding level.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 23 Apr 2023 05:35:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Attached is a patch with a few updates:
1. Added documentation in doc/emacs/mark.texi, under the mark-sexp section.
I'm unfamiliar with standards for how the manuals are written, but am happy
to update further as needed.
2. Extracted a new helper function mark--helper. This takes two arguments
-- a move function, and a number of how many things to move.
The helper function is able to be used for all mark-*-forward and
mark-*-backward functions; I think this should handle at least some of your
concerns about the composability of the design -- different mark functions
can be made by passing a different move function. For example,
mark-word-forward and mark-word-backward would be defined this way:
(defun mark-word-forward (&optional number-of-words)
"Mark NUMBER-OF-WORDS words forward.
Repeated calls to this mark more words."
(interactive "p")
(mark--helper #'forward-word (or number-of-words 1)))
(defun mark-word-backward (&optional number-of-words)
"Mark NUMBER-OF-WORDS words backward.
Repeated calls to this mark more words."
(interactive "p")
(mark--helper #'forward-word (- (or number-of-words 1))))
I'm not exactly sure of the best place to put the helper function, nor
exactly how the different lisp files in Emacs work together. There's no
provide statement; are all the files in lisp/emacs-lisp loaded at the same
time? If so, I'll make the other relevant functions (for marking word,
defun, page, paragraph, line, and char).
Also, whatever the outcome of this patch, I think it would be advisable to
explain somewhere how mark-sexp extends region by the end of region
opposite point; this is not in the docstring or any other documentation
I've seen.
On Fri, Apr 21, 2023 at 9:10 AM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:
> > If this is to be accepted, why not extend it to all like mark functions,
> > listed below? Implementing them should be pretty similar, and you might
> > even be able to reuse the same helper for all these variants. Also, the
> > helper function might need to contain a double-dash in its name because
> > this is inherently a private function.
> >
> > - `mark-defun'
> > - `mark-page'
> > - `mark-paragraph'
> > - `mark-word'
>
> Agreed: we should move towards a more orthogonal/composable design,
> where the granularity of the operation (char, word, line, sexp,
> paragraph, page, defun, ...) and the operation itself (move, mark) and
> the direction and all independent such that we can use any combination
> of them.
>
> Both at the ELisp level and at the key-binding level.
>
>
> Stefan
>
>
[Message part 2 (text/html, inline)]
[0001-Add-mark-sexp-forward-mark-sexp-backward.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Tue, 25 Apr 2023 22:27:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 62892 <at> debbugs.gnu.org (full text, mbox):
Zachary Kanfer <zkanfer <at> gmail.com> writes:
>
> Also, whatever the outcome of this patch, I think it would be advisable to
> explain somewhere how mark-sexp extends region by the end of region
> opposite point; this is not in the docstring or any other documentation
> I've seen.
>
In my opinion, the description of that feature should not be part of the
mark-sexp command documentation, because the feature is actually
provided by C-x C-x (exchange-point-and-mark). The Emacs manual in
section 12.1 Setting the Mark describes this use case well, I think:
‘C-x C-x’ is useful when you are
satisfied with the position of point but want to move the other end of
the region (where the mark is).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Wed, 26 Apr 2023 04:43:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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. 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.
> In my opinion, the description of that feature should not be part of the
> mark-sexp command documentation, because the feature is actually
> provided by C-x C-x (exchange-point-and-mark).
One way for this situation to occur is by using C-x C-x, yes, but it's not
the only way. You can set point, move forward sexps, and then calling
mark-sexp will mark sexps backwards.
There is specific code in mark-sexp to check which direction to move; it
should be documented as such.
On Tue, Apr 25, 2023 at 6:26 PM Daniel Martín <mardani29 <at> yahoo.es> wrote:
> Zachary Kanfer <zkanfer <at> gmail.com> writes:
>
> >
> > Also, whatever the outcome of this patch, I think it would be advisable
> to
> > explain somewhere how mark-sexp extends region by the end of region
> > opposite point; this is not in the docstring or any other documentation
> > I've seen.
> >
>
> In my opinion, the description of that feature should not be part of the
> mark-sexp command documentation, because the feature is actually
> provided by C-x C-x (exchange-point-and-mark). The Emacs manual in
> section 12.1 Setting the Mark describes this use case well, I think:
>
> ‘C-x C-x’ is useful when you are
> satisfied with the position of point but want to move the other end of
> the region (where the mark is).
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Wed, 26 Apr 2023 06:29:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> Cc: Ruijie Yu <ruijie <at> netyu.xyz>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> 62892 <at> debbugs.gnu.org
> From: Zachary Kanfer <zkanfer <at> gmail.com>
> Date: Wed, 26 Apr 2023 00:41:45 -0400
>
> 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?
> 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.
> > In my opinion, the description of that feature should not be part of the
> > mark-sexp command documentation, because the feature is actually
> > provided by C-x C-x (exchange-point-and-mark).
>
> One way for this situation to occur is by using C-x C-x, yes, but it's not the only way. You can set point,
> move forward sexps, and then calling mark-sexp will mark sexps backwards.
>
> There is specific code in mark-sexp to check which direction to move; it should be documented as
> such.
Please also demonstrate this behavior and point to that code, so we
will know what you are alluding to.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 27 Apr 2023 02:39:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> > 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.
> > > In my opinion, the description of that feature should not be part of
the
> > > mark-sexp command documentation, because the feature is actually
> > > provided by C-x C-x (exchange-point-and-mark).
> >
> > One way for this situation to occur is by using C-x C-x, yes, but it's
not the only way. You can set point,
> > move forward sexps, and then calling mark-sexp will mark sexps
backwards.
> >
> > There is specific code in mark-sexp to check which direction to move;
it should be documented as
> > such.
>
> Please also demonstrate this behavior and point to that code, so we
> will know what you are alluding to.
Here is the line of code:
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/lisp.el#n107.
When the region is active, and no prefix arg is given to mark-sexp, the
function resets `arg` as follows:
(setq arg (if arg (prefix-numeric-value arg)
(if (< (mark) (point)) -1 1)))
When no prefix arg is given, when the region is active, it sets arg to
either 1 or -1, depending on the relative positions of point and mark.
The behavior can be seen in the instructions above, but here's a simpler
way to see it:
1. `emacs -Q --eval '(progn (insert "foo bar baz") (goto-char 5))`
2. C-space. (Set mark)
3. M-f. (forward word). We have now set up the situation I was referring to
-- point is set after mark, and mark is active.
4. C-M-@. Here, we see mark-sexp extend region backwards without ever using
C-x C-x (exchange-point-and-mark). The feature of extending the region
backwards cannot be provided by exchange-point-and-mark.
On Wed, Apr 26, 2023 at 2:28 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Cc: Ruijie Yu <ruijie <at> netyu.xyz>, Stefan Monnier <
> monnier <at> iro.umontreal.ca>,
> > 62892 <at> debbugs.gnu.org
> > From: Zachary Kanfer <zkanfer <at> gmail.com>
> > Date: Wed, 26 Apr 2023 00:41:45 -0400
> >
> > 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?
>
> > 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.
>
> > > In my opinion, the description of that feature should not be part of
> the
> > > mark-sexp command documentation, because the feature is actually
> > > provided by C-x C-x (exchange-point-and-mark).
> >
> > One way for this situation to occur is by using C-x C-x, yes, but it's
> not the only way. You can set point,
> > move forward sexps, and then calling mark-sexp will mark sexps backwards.
> >
> > There is specific code in mark-sexp to check which direction to move; it
> should be documented as
> > such.
>
> Please also demonstrate this behavior and point to that code, so we
> will know what you are alluding to.
>
> Thanks.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 27 Apr 2023 12:26:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> From: Zachary Kanfer <zkanfer <at> gmail.com>
> Date: Wed, 26 Apr 2023 22:37:58 -0400
> Cc: mardani29 <at> yahoo.es, ruijie <at> netyu.xyz, monnier <at> iro.umontreal.ca,
> 62892 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 27 Apr 2023 18:15:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> 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.
mark-sexp has a counterpart mark-word that has almost the same
implementation and docstring. So this could be fixed in both places.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Fri, 28 Apr 2023 05:29:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I made some minor changes below. Alongside my suggestions are explanations
as to why. This is a hard command to describe!
> (defun mark-sexp (&optional arg allow-extend)
> "Set mark ARG sexps from point or move mark ARG sexps.
Mark can be moved ARG steps. Press C-M-@ C-M-@ C-u 3 C-M-@. There will be
five total sexps marked. I'm hoping this explains that case as well, and
giving an intuition for what this command does ("move mark ARG steps").
> When invoked interactively without a prefix argument and no active
> region, mark moves one sexp forward.
I moved this first, both because I suspect it's the most common use case,
but also because it's the the simplest to understand.
> When invoked interactively without a prefix argument, and region
> is active, mark moves one sexp away from point (i.e., forward
> if mark is at or after point, back if mark is before point), thus
> extending the region by one sexp.
> 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.
Moved this earlier to keep the entire interactive block together.
> When the region is active, the direction the region is extended
> depends on the relative position of mark and point. This means the
> direction can be changed by pressing \\[exchange-point-and-mark]
> before this command..
I moved this to a separate section to simplify the earlier parts, and to
call out that this is possible whenever the region is active.
> When called from Lisp with ALLOW-EXTEND omitted or nil, mark is
> set ARG (defaulting to 1) sexps from point.
Removed extra m from "omitted".
> This command assumes point is not in a string or comment."
Altogether, the docstring with my suggestions looks like:
> (defun mark-sexp (&optional arg allow-extend)
> "Set mark ARG sexps from point or move mark ARG sexps.
> 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 from point (i.e., forward
> if mark is at or after point, back if mark is before point), thus
> extending the region by one sexp.
> 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.
> When the region is active, the direction the region is extended
> depends on the relative position of mark and point. This means the
> direction can be changed by pressing \\[exchange-point-and-mark]
> before this command.
> When called from Lisp with ALLOW-EXTEND omitted or nil, mark is
> set ARG (defaulting to 1) sexps from point.
> This command assumes point is not in a string or comment."
This is a complicated command, for sure -- which is partially why I want
simple functions to mark sexps forward and backward: to not have to think
about different cases. Can we fork off a discussion about those functions?
Having simple functions allows the user to do what they want without having
to learn complex nuance.
On Thu, Apr 27, 2023 at 2:14 PM Juri Linkov <juri <at> linkov.net> wrote:
> > 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.
>
> mark-sexp has a counterpart mark-word that has almost the same
> implementation and docstring. So this could be fixed in both places.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Fri, 28 Apr 2023 17:08:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> Attached is a patch with a few updates:
Thanks for the patch. It would be nice to have such commands
even not bound to default keys, so the users are free to bind
them to any keys.
> I'm not exactly sure of the best place to put the helper function, nor
> exactly how the different lisp files in Emacs work together. There's no
> provide statement; are all the files in lisp/emacs-lisp loaded at the same
> time? If so, I'll make the other relevant functions (for marking word,
> defun, page, paragraph, line, and char).
Let's see:
- mark-sexp and mark-defun are defined in emacs-lisp/lisp.el
- mark-page in textmodes/page.el
- mark-paragraph in textmodes/paragraphs.el
- mark-word in simple.el
So looks like the best place to define the helper is simple.el,
before mark-word.
> +(defun mark--helper (move-fn number-of-things)
A nicer name would be 'mark-thing' as a reference to thingatpt.el.
> + "Use MOVE-FN to move NUMBER-OF-THINGS things, extending region over them.
> +
> +The MOVE-FN should take a numeric argument, and move that many
> +items forward (negative means backward).
> +
> +NUMBER-OF-THINGS is the number of additional things to move."
Another variant is to use a single argument JUMPFORM like
in 'isearch-yank-internal' that allows not to leak the
prefix argument to the helper function:
(defun isearch-yank-char (&optional arg)
(isearch-yank-internal (lambda () (forward-char arg) (point))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Fri, 28 Apr 2023 19:29:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> > +(defun mark--helper (move-fn number-of-things)
>
> A nicer name would be 'mark-thing' as a reference to thingatpt.el.
FWIW, I have a different take on this.
Is it an "internal" function? Then its name should
maybe use `--'. (But why should it be internal?)
Is it a helper function? Then its name should maybe
use a suffix that indicates that, such as `-helper'
or `-1' (old-school Lisp, I suppose).
`mark-thing' should be reserved for a function that
takes a THING name as arg: `sexp', `page', etc.,
instead of a movement function such as `forward-sexp'.
___
FWIW, I think MOVE-FN is a fine name for the argument.
My own preference, and what I use in my code, is the
name FORWARD-THING-FUNCTION.
___
FWIW, in my library isearch+.el), I use the arg name
THING for a thing name, not a movement or other
function.
E.g.: Function `isearchp-in-thing-p' is a helper
function for defining specific THING-type predicates,
such as `isearch(-not)-in-email-address-p'.
___
FWIW, my library `thing-cmds.el' has a command named
`mark-things', which prompts for a THING type as arg:
mark-things is an alias for 'select-things' in 'thing-cmds.el'.
(mark-things THING &optional ARG ALLOW-EXTEND)
Set point at one end of THING and set mark ARG THINGs from point.
THING is a symbol that names a type of thing. Interactively, you are
prompted for it. Completion is available (lax).
(If THING doesn't have an associated `forward-'THING operation then
do nothing.)
Put mark at the same place command `forward-'THING would move point
with the same prefix argument.
Put point at the beginning of THING, unless the prefix argument (ARG)
is negative, in which case put it at the end of THING.
If `select-things' is repeated or if the mark is active (in Transient
Mark mode), then it marks the next ARG THINGs, after the ones already
marked. In this case the type of THING used is whatever was used the
last time `select-things' was called - you are not prompted for it.
This region extension reusing the last type of THING happens even if
the active region is empty. This means that you can, for instance,
just use `C-SPC' to activate an empty region and then use
`select-things' to select more THINGS of the last kind selected.
If there is no THING at point, and `thgcmd-use-nearest-thing-flag' is
non-nil, then select a THING near point.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Wed, 03 May 2023 06:11:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Thanks for the patch. It would be nice to have such commands
> even not bound to default keys, so the users are free to bind
> them to any keys.
That's my hope, unless sufficiently good default keys can be found. I like
C-M-space and C-M-S-space, which are both currently bound to mark-sexp, but
changing the default keys is not trivially done.
> So looks like the best place to define the helper is simple.el,
> before mark-word.
Sure! I'll get a patch out for this.
> Another variant is to use a single argument JUMPFORM like
> in 'isearch-yank-internal' that allows not to leak the
> prefix argument to the helper function:
This is tempting. The downside I'm seeing to this -- which I'll think more
about to see if I can get around it -- is that we don't know if we need to
call JUMPFORM from point or mark.
We can do it from both, something like:
(defun mark--helper (fn-to-find-new-mark)
"Extend region by calling FN-TO-FIND-NEW-MARK.
The MOVE-FN should take a numeric argument, and move that many
items forward (negative means backward).
NUMBER-OF-THINGS is the number of additional things to move."
(if (use-region-p)
(let* ((beginning-of-region (region-beginning))
(end-of-region (region-end))
(at-end-of-region (= end-of-region (point)))
(move-from-front (save-excursion (goto-char
beginning-of-region)
(funcall fn-to-find-new-mark)
(point)))
(move-from-end (save-excursion (goto-char end-of-region)
(funcall fn-to-find-new-mark)
(point)))
(new-beginning-of-region (min beginning-of-region
move-from-front))
(new-end-of-region (max end-of-region move-from-end)))
(goto-char (if at-end-of-region
new-end-of-region
new-beginning-of-region))
(set-mark (if at-end-of-region
new-beginning-of-region
new-end-of-region)))
(progn (push-mark (save-excursion
(funcall fn-to-find-new-mark)
(point)))
(activate-mark))))
Downsides include:
1. We have to call the function twice each time. This doesn't seem like
such a big deal unless it's expensive or has side effects -- neither of
which should be the case.
2. The current implementation errors when there are no more objects to
mark. This doesn't. I think we probably could error if we don't change the
region.
3. I'm not 100% convinced this will always do the right thing. I would like
to be.
4. I'm not sure going to one argument is worth it. The two arguments seem
pretty simple; changing to one argument might add more complexity than it
removes.
On Fri, Apr 28, 2023 at 1:07 PM Juri Linkov <juri <at> linkov.net> wrote:
> > Attached is a patch with a few updates:
>
> Thanks for the patch. It would be nice to have such commands
> even not bound to default keys, so the users are free to bind
> them to any keys.
>
> > I'm not exactly sure of the best place to put the helper function, nor
> > exactly how the different lisp files in Emacs work together. There's no
> > provide statement; are all the files in lisp/emacs-lisp loaded at the
> same
> > time? If so, I'll make the other relevant functions (for marking word,
> > defun, page, paragraph, line, and char).
>
> Let's see:
> - mark-sexp and mark-defun are defined in emacs-lisp/lisp.el
> - mark-page in textmodes/page.el
> - mark-paragraph in textmodes/paragraphs.el
> - mark-word in simple.el
>
> So looks like the best place to define the helper is simple.el,
> before mark-word.
>
> > +(defun mark--helper (move-fn number-of-things)
>
> A nicer name would be 'mark-thing' as a reference to thingatpt.el.
>
> > + "Use MOVE-FN to move NUMBER-OF-THINGS things, extending region over
> them.
> > +
> > +The MOVE-FN should take a numeric argument, and move that many
> > +items forward (negative means backward).
> > +
> > +NUMBER-OF-THINGS is the number of additional things to move."
>
> Another variant is to use a single argument JUMPFORM like
> in 'isearch-yank-internal' that allows not to leak the
> prefix argument to the helper function:
>
> (defun isearch-yank-char (&optional arg)
> (isearch-yank-internal (lambda () (forward-char arg) (point))))
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Wed, 03 May 2023 17:35:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 62892 <at> debbugs.gnu.org (full text, mbox):
>> Thanks for the patch. It would be nice to have such commands
>> even not bound to default keys, so the users are free to bind
>> them to any keys.
>
> That's my hope, unless sufficiently good default keys can be found. I like
> C-M-space and C-M-S-space, which are both currently bound to mark-sexp, but
> changing the default keys is not trivially done.
Please also note that the reason why the current single binding is sufficient
is because it's needed only to extend the region at the opposite side of
the selected region where the mark is located, i.e. it only moves the mark.
Whereas to move the region boundary under point is easy with sexp navigation
commands (that keep the region active). However, your two commands
are duplicating the task of moving point. But maybe this is easier to use
for some users.
>> Another variant is to use a single argument JUMPFORM like
>> in 'isearch-yank-internal' that allows not to leak the
>> prefix argument to the helper function:
>
> This is tempting. The downside I'm seeing to this -- which I'll think more
> about to see if I can get around it -- is that we don't know if we need to
> call JUMPFORM from point or mark.
Indeed, because you need to handle motion in two directions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 04 May 2023 04:50:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Is it an "internal" function? Then its name should
> maybe use `--'. (But why should it be internal?)
Hrm, I figured it would be an internal function because it's intended to be
wrapped by other code. But this describes a whole lot of functions. So it
can't be that.
I suppose that if there are other types of things that are created that one
might want to mark, then a user could use this method to mark them. So
perhaps it shouldn't be internal -- it really could be used by other code.
> Is it a helper function? Then its name should maybe
> use a suffix that indicates that, such as `-helper'
> or `-1' (old-school Lisp, I suppose).
It's certainly a helper function -- it's intended to be called by a bunch
of different functions we write.
> `mark-thing' should be reserved for a function that
> takes a THING name as arg: `sexp', `page', etc.,
> instead of a movement function such as `forward-sexp'.
This makes a lot of sense to me.
On Fri, Apr 28, 2023 at 3:28 PM Drew Adams <drew.adams <at> oracle.com> wrote:
> > > +(defun mark--helper (move-fn number-of-things)
> >
> > A nicer name would be 'mark-thing' as a reference to thingatpt.el.
>
> FWIW, I have a different take on this.
>
> Is it an "internal" function? Then its name should
> maybe use `--'. (But why should it be internal?)
>
> Is it a helper function? Then its name should maybe
> use a suffix that indicates that, such as `-helper'
> or `-1' (old-school Lisp, I suppose).
>
> `mark-thing' should be reserved for a function that
> takes a THING name as arg: `sexp', `page', etc.,
> instead of a movement function such as `forward-sexp'.
> ___
>
> FWIW, I think MOVE-FN is a fine name for the argument.
> My own preference, and what I use in my code, is the
> name FORWARD-THING-FUNCTION.
> ___
>
> FWIW, in my library isearch+.el), I use the arg name
> THING for a thing name, not a movement or other
> function.
>
> E.g.: Function `isearchp-in-thing-p' is a helper
> function for defining specific THING-type predicates,
> such as `isearch(-not)-in-email-address-p'.
> ___
>
> FWIW, my library `thing-cmds.el' has a command named
> `mark-things', which prompts for a THING type as arg:
>
> mark-things is an alias for 'select-things' in 'thing-cmds.el'.
>
> (mark-things THING &optional ARG ALLOW-EXTEND)
>
> Set point at one end of THING and set mark ARG THINGs from point.
> THING is a symbol that names a type of thing. Interactively, you are
> prompted for it. Completion is available (lax).
>
> (If THING doesn't have an associated `forward-'THING operation then
> do nothing.)
>
> Put mark at the same place command `forward-'THING would move point
> with the same prefix argument.
>
> Put point at the beginning of THING, unless the prefix argument (ARG)
> is negative, in which case put it at the end of THING.
>
> If `select-things' is repeated or if the mark is active (in Transient
> Mark mode), then it marks the next ARG THINGs, after the ones already
> marked. In this case the type of THING used is whatever was used the
> last time `select-things' was called - you are not prompted for it.
>
> This region extension reusing the last type of THING happens even if
> the active region is empty. This means that you can, for instance,
> just use `C-SPC' to activate an empty region and then use
> `select-things' to select more THINGS of the last kind selected.
>
> If there is no THING at point, and `thgcmd-use-nearest-thing-flag' is
> non-nil, then select a THING near point.
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sat, 06 May 2023 08:49:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Zachary Kanfer <zkanfer <at> gmail.com>, mardani29 <at> yahoo.es,
> ruijie <at> netyu.xyz, monnier <at> iro.umontreal.ca, 62892 <at> debbugs.gnu.org
> Date: Thu, 27 Apr 2023 21:12:55 +0300
>
> > 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.
>
> mark-sexp has a counterpart mark-word that has almost the same
> implementation and docstring. So this could be fixed in both places.
Done on the emacs-29 branch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Mon, 08 May 2023 12:29:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Attached is a patch with the following changes:
* Uses the helper function to create mark-foo-forward, mark-foo-backward
for word, paragraph, sexp, page, and defun.
* Adds tests for all of these.
* Adds these new functions to etc/NEWS and various .texi files in
doc/emacs/.
On Thu, May 4, 2023 at 12:48 AM Zachary Kanfer <zkanfer <at> gmail.com> wrote:
> > Is it an "internal" function? Then its name should
> > maybe use `--'. (But why should it be internal?)
>
> Hrm, I figured it would be an internal function because it's intended to
> be wrapped by other code. But this describes a whole lot of functions. So
> it can't be that.
>
> I suppose that if there are other types of things that are created that
> one might want to mark, then a user could use this method to mark them. So
> perhaps it shouldn't be internal -- it really could be used by other code.
>
> > Is it a helper function? Then its name should maybe
> > use a suffix that indicates that, such as `-helper'
> > or `-1' (old-school Lisp, I suppose).
>
> It's certainly a helper function -- it's intended to be called by a bunch
> of different functions we write.
>
> > `mark-thing' should be reserved for a function that
> > takes a THING name as arg: `sexp', `page', etc.,
> > instead of a movement function such as `forward-sexp'.
>
> This makes a lot of sense to me.
>
> On Fri, Apr 28, 2023 at 3:28 PM Drew Adams <drew.adams <at> oracle.com> wrote:
>
>> > > +(defun mark--helper (move-fn number-of-things)
>> >
>> > A nicer name would be 'mark-thing' as a reference to thingatpt.el.
>>
>> FWIW, I have a different take on this.
>>
>> Is it an "internal" function? Then its name should
>> maybe use `--'. (But why should it be internal?)
>>
>> Is it a helper function? Then its name should maybe
>> use a suffix that indicates that, such as `-helper'
>> or `-1' (old-school Lisp, I suppose).
>>
>> `mark-thing' should be reserved for a function that
>> takes a THING name as arg: `sexp', `page', etc.,
>> instead of a movement function such as `forward-sexp'.
>> ___
>>
>> FWIW, I think MOVE-FN is a fine name for the argument.
>> My own preference, and what I use in my code, is the
>> name FORWARD-THING-FUNCTION.
>> ___
>>
>> FWIW, in my library isearch+.el), I use the arg name
>> THING for a thing name, not a movement or other
>> function.
>>
>> E.g.: Function `isearchp-in-thing-p' is a helper
>> function for defining specific THING-type predicates,
>> such as `isearch(-not)-in-email-address-p'.
>> ___
>>
>> FWIW, my library `thing-cmds.el' has a command named
>> `mark-things', which prompts for a THING type as arg:
>>
>> mark-things is an alias for 'select-things' in 'thing-cmds.el'.
>>
>> (mark-things THING &optional ARG ALLOW-EXTEND)
>>
>> Set point at one end of THING and set mark ARG THINGs from point.
>> THING is a symbol that names a type of thing. Interactively, you are
>> prompted for it. Completion is available (lax).
>>
>> (If THING doesn't have an associated `forward-'THING operation then
>> do nothing.)
>>
>> Put mark at the same place command `forward-'THING would move point
>> with the same prefix argument.
>>
>> Put point at the beginning of THING, unless the prefix argument (ARG)
>> is negative, in which case put it at the end of THING.
>>
>> If `select-things' is repeated or if the mark is active (in Transient
>> Mark mode), then it marks the next ARG THINGs, after the ones already
>> marked. In this case the type of THING used is whatever was used the
>> last time `select-things' was called - you are not prompted for it.
>>
>> This region extension reusing the last type of THING happens even if
>> the active region is empty. This means that you can, for instance,
>> just use `C-SPC' to activate an empty region and then use
>> `select-things' to select more THINGS of the last kind selected.
>>
>> If there is no THING at point, and `thgcmd-use-nearest-thing-flag' is
>> non-nil, then select a THING near point.
>>
>>
[Message part 2 (text/html, inline)]
[0001-Add-foo-mark-forward-foo-mark-backward-for-various-f.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 18 May 2023 03:18:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Is there anything I can do to make this patch easier to evaluate? As far as
I'm aware, I've addressed all comments that have been made in this thread.
On Mon, May 8, 2023 at 8:28 AM Zachary Kanfer <zkanfer <at> gmail.com> wrote:
> Attached is a patch with the following changes:
>
> * Uses the helper function to create mark-foo-forward, mark-foo-backward
> for word, paragraph, sexp, page, and defun.
> * Adds tests for all of these.
> * Adds these new functions to etc/NEWS and various .texi files in
> doc/emacs/.
>
> On Thu, May 4, 2023 at 12:48 AM Zachary Kanfer <zkanfer <at> gmail.com> wrote:
>
>> > Is it an "internal" function? Then its name should
>> > maybe use `--'. (But why should it be internal?)
>>
>> Hrm, I figured it would be an internal function because it's intended to
>> be wrapped by other code. But this describes a whole lot of functions. So
>> it can't be that.
>>
>> I suppose that if there are other types of things that are created that
>> one might want to mark, then a user could use this method to mark them. So
>> perhaps it shouldn't be internal -- it really could be used by other code.
>>
>> > Is it a helper function? Then its name should maybe
>> > use a suffix that indicates that, such as `-helper'
>> > or `-1' (old-school Lisp, I suppose).
>>
>> It's certainly a helper function -- it's intended to be called by a bunch
>> of different functions we write.
>>
>> > `mark-thing' should be reserved for a function that
>> > takes a THING name as arg: `sexp', `page', etc.,
>> > instead of a movement function such as `forward-sexp'.
>>
>> This makes a lot of sense to me.
>>
>> On Fri, Apr 28, 2023 at 3:28 PM Drew Adams <drew.adams <at> oracle.com> wrote:
>>
>>> > > +(defun mark--helper (move-fn number-of-things)
>>> >
>>> > A nicer name would be 'mark-thing' as a reference to thingatpt.el.
>>>
>>> FWIW, I have a different take on this.
>>>
>>> Is it an "internal" function? Then its name should
>>> maybe use `--'. (But why should it be internal?)
>>>
>>> Is it a helper function? Then its name should maybe
>>> use a suffix that indicates that, such as `-helper'
>>> or `-1' (old-school Lisp, I suppose).
>>>
>>> `mark-thing' should be reserved for a function that
>>> takes a THING name as arg: `sexp', `page', etc.,
>>> instead of a movement function such as `forward-sexp'.
>>> ___
>>>
>>> FWIW, I think MOVE-FN is a fine name for the argument.
>>> My own preference, and what I use in my code, is the
>>> name FORWARD-THING-FUNCTION.
>>> ___
>>>
>>> FWIW, in my library isearch+.el), I use the arg name
>>> THING for a thing name, not a movement or other
>>> function.
>>>
>>> E.g.: Function `isearchp-in-thing-p' is a helper
>>> function for defining specific THING-type predicates,
>>> such as `isearch(-not)-in-email-address-p'.
>>> ___
>>>
>>> FWIW, my library `thing-cmds.el' has a command named
>>> `mark-things', which prompts for a THING type as arg:
>>>
>>> mark-things is an alias for 'select-things' in 'thing-cmds.el'.
>>>
>>> (mark-things THING &optional ARG ALLOW-EXTEND)
>>>
>>> Set point at one end of THING and set mark ARG THINGs from point.
>>> THING is a symbol that names a type of thing. Interactively, you are
>>> prompted for it. Completion is available (lax).
>>>
>>> (If THING doesn't have an associated `forward-'THING operation then
>>> do nothing.)
>>>
>>> Put mark at the same place command `forward-'THING would move point
>>> with the same prefix argument.
>>>
>>> Put point at the beginning of THING, unless the prefix argument (ARG)
>>> is negative, in which case put it at the end of THING.
>>>
>>> If `select-things' is repeated or if the mark is active (in Transient
>>> Mark mode), then it marks the next ARG THINGs, after the ones already
>>> marked. In this case the type of THING used is whatever was used the
>>> last time `select-things' was called - you are not prompted for it.
>>>
>>> This region extension reusing the last type of THING happens even if
>>> the active region is empty. This means that you can, for instance,
>>> just use `C-SPC' to activate an empty region and then use
>>> `select-things' to select more THINGS of the last kind selected.
>>>
>>> If there is no THING at point, and `thgcmd-use-nearest-thing-flag' is
>>> non-nil, then select a THING near point.
>>>
>>>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 18 May 2023 06:53:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> Cc: Ruijie Yu <ruijie <at> netyu.xyz>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> "62892 <at> debbugs.gnu.org" <62892 <at> debbugs.gnu.org>, Juri Linkov <juri <at> linkov.net>
> From: Zachary Kanfer <zkanfer <at> gmail.com>
> Date: Wed, 17 May 2023 23:17:01 -0400
>
> Is there anything I can do to make this patch easier to evaluate? As far as I'm aware, I've addressed
> all comments that have been made in this thread.
My POV is still as it was before: I'm not sure we should add these new
commands, since the existing commands already provide this
functionality, if you use "C-x C-x" to switch the direction.
I've seen nothing in the discussion which made me change my mind. Did
I overlook some convincing arguments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 21 May 2023 05:47:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I think I've made as good an argument as I'm going to. It basically boils
down to:
* if the keys are bound, it's quicker to call mark-foo-forward and then
mark-foo-backward than to call mark-foo, then exchange-point-and-mark, then
mark-foo again.
* This behavior is simpler and more predictable: mark-foo-forward always
marks forward. mark-foo sometimes marks forward and sometimes backwards.
The complexity of the various mark-foo functions can be seen in how many
cases the docstring has. The behavior of the mark-foo-forward,
mark-foo-backward functions can be gathered from the name, without reading
the docstrings.
I understand we have different opinions, so if this isn't convincing, I'll
bow out here. Thanks.
On Thu, May 18, 2023 at 2:52 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Cc: Ruijie Yu <ruijie <at> netyu.xyz>, Stefan Monnier <
> monnier <at> iro.umontreal.ca>,
> > "62892 <at> debbugs.gnu.org" <62892 <at> debbugs.gnu.org>, Juri Linkov <
> juri <at> linkov.net>
> > From: Zachary Kanfer <zkanfer <at> gmail.com>
> > Date: Wed, 17 May 2023 23:17:01 -0400
> >
> > Is there anything I can do to make this patch easier to evaluate? As far
> as I'm aware, I've addressed
> > all comments that have been made in this thread.
>
> My POV is still as it was before: I'm not sure we should add these new
> commands, since the existing commands already provide this
> functionality, if you use "C-x C-x" to switch the direction.
>
> I've seen nothing in the discussion which made me change my mind. Did
> I overlook some convincing arguments?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 21 May 2023 05:59:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> From: Zachary Kanfer <zkanfer <at> gmail.com>
> Date: Sun, 21 May 2023 01:46:21 -0400
> Cc: drew.adams <at> oracle.com, ruijie <at> netyu.xyz, monnier <at> iro.umontreal.ca,
> 62892 <at> debbugs.gnu.org, juri <at> linkov.net
>
> I think I've made as good an argument as I'm going to. It basically boils down to:
>
> * if the keys are bound, it's quicker to call mark-foo-forward and then mark-foo-backward than to call
> mark-foo, then exchange-point-and-mark, then mark-foo again.
> * This behavior is simpler and more predictable: mark-foo-forward always marks forward. mark-foo
> sometimes marks forward and sometimes backwards. The complexity of the various mark-foo
> functions can be seen in how many cases the docstring has. The behavior of the mark-foo-forward,
> mark-foo-backward functions can be gathered from the name, without reading the docstrings.
>
> I understand we have different opinions, so if this isn't convincing, I'll bow out here. Thanks.
Stefan, WDYT about this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 21 May 2023 14:32:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> Stefan, WDYT about this?
There's a tension: on the one hand, there's a large number of
alternative UIs with many slightly different commands from the ones we
have, so we can't just add every single one of them to Emacs (instead,
we aim to provide convenient building blocks for them), but on the other
hand, we also want to make it easy for end users who don't want to
program to use slightly different UIs.
Maybe the new building block is useful enough (i.e. can be used in
existing code, thus reducing overall complexity)? I haven't looked
closely enough to have a clear opinion, I'm afraid.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 21 May 2023 14:40:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Zachary Kanfer <zkanfer <at> gmail.com>, ruijie <at> netyu.xyz,
> 62892 <at> debbugs.gnu.org, drew.adams <at> oracle.com, juri <at> linkov.net
> Date: Sun, 21 May 2023 10:31:41 -0400
>
> Maybe the new building block is useful enough (i.e. can be used in
> existing code, thus reducing overall complexity)?
That'd be preferable, certainly. Enlarging the set of the commands is
not my preference.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 21 May 2023 14:55:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> Cc: ruijie <at> netyu.xyz, juri <at> linkov.net, zkanfer <at> gmail.com, 62892 <at> debbugs.gnu.org,
> drew.adams <at> oracle.com
> Date: Sun, 21 May 2023 17:39:44 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Maybe the new building block is useful enough (i.e. can be used in
> > existing code, thus reducing overall complexity)?
>
> That'd be preferable, certainly. Enlarging the set of the commands is
> not my preference.
Btw, these new commands keep the complicated, hard-to-remember MO of
mark-sexp: they do different things depending on whether
transient-mark-mode is on or off and whether the region is or isn't
active. Why is this a Good Thing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 21 May 2023 14:58:01 GMT)
Full text and
rfc822 format available.
Message #107 received at submit <at> debbugs.gnu.org (full text, mbox):
One data point that I think is worth taking into consideration:
Currently, `mark-sexp` and `mark-defun` are not consistent with each
other. This can be seen in the following example:
--8<---------------cut here---------------start------------->8---
(foo)
(bar)
(baz)
--8<---------------cut here---------------end--------------->8---
With point before `(bar)`, doing `C-2 C-M-SPC C-- C-M-SPC` leaves only
`(bar)` selected. OTOH, doing `C-2 C-M-h C-- C-M-h` leaves all three
expressions selected.
In contrast, the proposed `mark-sexp-forward` and `mark-defun-forward`
are consistent with each other (both behave like `mark-defun` in the
above example).
I'm not sure if that's the preferred behavior, but I do think that
consistently between the different marking commands is a good thing.
--
Best,
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 21 May 2023 14:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 21 May 2023 15:12:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier
> <monnier <at> iro.umontreal.ca>, ruijie <at> netyu.xyz, juri <at> linkov.net, Zachary
> Kanfer <zkanfer <at> gmail.com>, 62892 <at> debbugs.gnu.org, drew.adams <at> oracle.com
> Date: Sun, 21 May 2023 17:56:54 +0300
>
> I'm not sure if that's the preferred behavior, but I do think that
> consistently between the different marking commands is a good thing.
Why do you think there should be consistency here? These are
different commands which target different use-cases.
Did you read the doc string of C-M-SPC? It does something
extra-special when transient-mark-mode is enabled and the region is
active.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Sun, 21 May 2023 15:42:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 62892 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Eshel Yaron <me <at> eshelyaron.com>
>>
>> I'm not sure if that's the preferred behavior, but I do think that
>> consistently between the different marking commands is a good thing.
>
> Why do you think there should be consistency here? These are
> different commands which target different use-cases.
>
I see, so `mark-word` and `mark-sexp` differ from `mark-paragraph`,
`mark-defun` and `mark-page` by design. That's apparent from the Info
manual on second look. Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Mon, 22 May 2023 22:03:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Attached is a patch with the following changes:
> >
> > * Uses the helper function to create mark-foo-forward, mark-foo-backward
> > for word, paragraph, sexp, page, and defun.
I think these functions would make sense, but I wonder hwo they
would do users any good.
Are you envisioning that we would create standard key bindings
for these functions?
Are you envisioning that users would bind some of these functions
to keys themselves?
Are you envisioning that users would call these functions from their
own Lisp code?
Any of those would make sense in the abstract, but I doubt that any of
them would be convenient enough to make this change worth installing.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Tue, 23 May 2023 14:12:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Are you envisioning that we would create standard key bindings
> for these functions?
I was not suggesting that here. However,I think this would be ideal,
especially given that mark-sexp is bound to three different keybindings
(C-M-@, C-M-SPC, C-M-S-SPC). What is the process for finding out if a new
keybinding would be appropriate? Or for determining whether enough people
use a keybinding to keep it, vs changing it?
> Are you envisioning that users would bind some of these functions
> to keys themselves?
Yes. This is the main use-case I envisioned.
> Are you envisioning that users would call these functions from their
> own Lisp code?
This was not my main proposal, but users can do so if they want.
On Mon, May 22, 2023 at 6:02 PM Richard Stallman <rms <at> gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > > Attached is a patch with the following changes:
> > >
> > > * Uses the helper function to create mark-foo-forward,
> mark-foo-backward
> > > for word, paragraph, sexp, page, and defun.
>
> I think these functions would make sense, but I wonder hwo they
> would do users any good.
>
> Are you envisioning that we would create standard key bindings
> for these functions?
>
> Are you envisioning that users would bind some of these functions
> to keys themselves?
>
> Are you envisioning that users would call these functions from their
> own Lisp code?
>
> Any of those would make sense in the abstract, but I doubt that any of
> them would be convenient enough to make this change worth installing.
>
>
>
> --
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 25 May 2023 22:34:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
I don't think we could find standard key bindings that are easy enough
to be worth thinking about.
> > Are you envisioning that users would bind some of these functions
> > to keys themselves?
> Yes. This is the main use-case I envisioned.
This is not outright unreasonable. I still doubt they would
interest many users, and I would not favor documenting these
features fully in the Emacs Manual.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Fri, 26 May 2023 06:07:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> Cc: ruijie <at> netyu.xyz, 62892 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> drew.adams <at> oracle.com, juri <at> linkov.net
> From: Richard Stallman <rms <at> gnu.org>
> Date: Thu, 25 May 2023 18:32:56 -0400
>
> I don't think we could find standard key bindings that are easy enough
> to be worth thinking about.
>
> > > Are you envisioning that users would bind some of these functions
> > > to keys themselves?
>
> > Yes. This is the main use-case I envisioned.
>
> This is not outright unreasonable. I still doubt they would
> interest many users, and I would not favor documenting these
> features fully in the Emacs Manual.
After some more thinking, I came to the conclusion that I can only
support adding these new commands if they would work in a much more
predictable fashion: always move forward/back by ARG sexps and set the
region on all the sexps they moved across. IOW, no change in behavior
depending on whether transient-mark-mode is ON or OFF, no change in
behavior depending on whether the region is active or not, and no
confusing notion of "extending the region" lumped into them.
Adding such simple commands could cater to those users who want
predictable marking behavior; perhaps those user will also want to
rebind C-M-f and C-M-b to these new commands.
But adding new commands that still change behavior in mysterious ways
depending on transient-mark-mode and active region is not something I
would like to do.
Sorry for bringing this up so late, I probably should have said this
at the very beginning of this discussion, if I were thinking fast
enough to realize this back then.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Wed, 31 May 2023 03:24:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 62892 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This is interesting. Let me see if I'm understanding properly. In this,
I'll talk only about sexps, but I believe this argument should apply to all
the forms we've talked about (word, sexp, paragraph, defun, page). These
commands should:
1. Always move forward/back by ARG sexps (defaulting to 1), setting the
region on all sexps it moves across.
I'm in agreement with #1, for sure. That is the basis for what I wanted
initially.
2. Ignore whether transient-mark-mode is enabled.
3. Don't change behavior if the region is active or not.
#2 and #3 I believe can be considered together. There are a few things that
could do this, but I think what you're saying is that this function should
*only* move mark. That is, point should stay the same no matter what is
called here. Additionally, it should activate mark. Is that what you meant?
> But adding new commands that still change behavior in mysterious ways
> depending on transient-mark-mode and active region is not something I
> would like to do.
My understanding was that #'use-region-p (which checks transient-mark-mode,
and whether the region is active) is a standard way for determining whether
to act on the region or not, and should generally be looked at before
acting on the region. Is that not accurate?
On Fri, May 26, 2023 at 2:06 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Cc: ruijie <at> netyu.xyz, 62892 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> > drew.adams <at> oracle.com, juri <at> linkov.net
> > From: Richard Stallman <rms <at> gnu.org>
> > Date: Thu, 25 May 2023 18:32:56 -0400
> >
> > I don't think we could find standard key bindings that are easy enough
> > to be worth thinking about.
> >
> > > > Are you envisioning that users would bind some of these functions
> > > > to keys themselves?
> >
> > > Yes. This is the main use-case I envisioned.
> >
> > This is not outright unreasonable. I still doubt they would
> > interest many users, and I would not favor documenting these
> > features fully in the Emacs Manual.
>
> After some more thinking, I came to the conclusion that I can only
> support adding these new commands if they would work in a much more
> predictable fashion: always move forward/back by ARG sexps and set the
> region on all the sexps they moved across. IOW, no change in behavior
> depending on whether transient-mark-mode is ON or OFF, no change in
> behavior depending on whether the region is active or not, and no
> confusing notion of "extending the region" lumped into them.
>
> Adding such simple commands could cater to those users who want
> predictable marking behavior; perhaps those user will also want to
> rebind C-M-f and C-M-b to these new commands.
>
> But adding new commands that still change behavior in mysterious ways
> depending on transient-mark-mode and active region is not something I
> would like to do.
>
> Sorry for bringing this up so late, I probably should have said this
> at the very beginning of this discussion, if I were thinking fast
> enough to realize this back then.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Wed, 31 May 2023 12:02:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> From: Zachary Kanfer <zkanfer <at> gmail.com>
> Date: Tue, 30 May 2023 23:23:13 -0400
> Cc: rms <at> gnu.org, ruijie <at> netyu.xyz, 62892 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca, drew.adams <at> oracle.com, juri <at> linkov.net
>
> This is interesting. Let me see if I'm understanding properly. In this, I'll talk only about sexps, but I
> believe this argument should apply to all the forms we've talked about (word, sexp, paragraph, defun,
> page). These commands should:
>
> 1. Always move forward/back by ARG sexps (defaulting to 1), setting the region on all sexps it moves
> across.
>
> I'm in agreement with #1, for sure. That is the basis for what I wanted initially.
>
> 2. Ignore whether transient-mark-mode is enabled.
> 3. Don't change behavior if the region is active or not.
>
> #2 and #3 I believe can be considered together. There are a few things that could do this, but I think
> what you're saying is that this function should *only* move mark.That is, point should stay the same no
> matter what is called here. Additionally, it should activate mark. Is that what you meant?
No, it should only move point, not the mark. The mark should stay
where point was before invoking the command.
Whether it should activate the mark is open to discussion. One
possibility is that the command will work like shift-select commands.
Another possibility is that it should activate the mark only if
transient-mark-mode is turned ON, like other commands that push the
mark.
> My understanding was that #'use-region-p (which checks transient-mark-mode, and whether the region
> is active) is a standard way for determining whether to act on the region or not, and should generally
> be looked at before acting on the region. Is that not accurate?
This is correct, but only for commands that do something with the text
in the region: limit search/replace to it, or spell-check the text in
it, etc. mark-sexp doesn't do anything like that, it actually
_modifies_ the region. So the fact that it changes its effect
depending on whether the region is active is IMO pretty confusing and
unexpected.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 01 Jun 2023 03:56:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 62892 <at> debbugs.gnu.org (full text, mbox):
>> #2 and #3 I believe can be considered together. There are a few things
>> that could do this, but I think
>> what you're saying is that this function should *only* move mark.That is,
>> point should stay the same no
>> matter what is called here. Additionally, it should activate mark. Is that what you meant?
>
> No, it should only move point, not the mark. The mark should stay
> where point was before invoking the command.
Hmm? Really?
That would make it equivalent to `forward-sexp`, no?
> This is correct, but only for commands that do something with the text
> in the region: limit search/replace to it, or spell-check the text in
> it, etc. mark-sexp doesn't do anything like that, it actually
> _modifies_ the region. So the fact that it changes its effect
> depending on whether the region is active is IMO pretty confusing and
> unexpected.
Agreed, tho for `mark-sexp` when `transient-mark-mode` is enabled, it
makes sense to treat "region not active" differently from "region
active", since `mark-sexp` mostly moves the mark but when the region is
not active, it means the mark is "an old obsolete mark" that the user
may not remember any more.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#62892; Package
emacs.
(Thu, 01 Jun 2023 06:33:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 62892 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Zachary Kanfer <zkanfer <at> gmail.com>, rms <at> gnu.org, ruijie <at> netyu.xyz,
> 62892 <at> debbugs.gnu.org, drew.adams <at> oracle.com, juri <at> linkov.net
> Date: Wed, 31 May 2023 23:54:48 -0400
>
> > No, it should only move point, not the mark. The mark should stay
> > where point was before invoking the command.
>
> Hmm? Really?
> That would make it equivalent to `forward-sexp`, no?
That's exactly the idea: move like forward-sexp and mark the sexps
moved across.
> > This is correct, but only for commands that do something with the text
> > in the region: limit search/replace to it, or spell-check the text in
> > it, etc. mark-sexp doesn't do anything like that, it actually
> > _modifies_ the region. So the fact that it changes its effect
> > depending on whether the region is active is IMO pretty confusing and
> > unexpected.
>
> Agreed, tho for `mark-sexp` when `transient-mark-mode` is enabled, it
> makes sense to treat "region not active" differently from "region
> active", since `mark-sexp` mostly moves the mark but when the region is
> not active, it means the mark is "an old obsolete mark" that the user
> may not remember any more.
I'm not lobbying for changing the behavior of mark-sexp. It's too
late for that, no matter what my opinion about that is. I'm saying
that it could make sense to have much simpler commands whose effect is
always predictable in advance, even if you don't use them frequently,
and even if you sometimes have transient-mark-mode on and sometimes
off.
This bug report was last modified 2 years and 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.