From: Zachary Kanfer <zkanfer@gmail.com>
To: Juri Linkov <juri@linkov.net>
Cc: Ruijie Yu <ruijie@netyu.xyz>,
Stefan Monnier <monnier@iro.umontreal.ca>,
62892@debbugs.gnu.org
Subject: bug#62892: proposal to extend mark-sexp to go forward and backward on command
Date: Wed, 3 May 2023 02:10:01 -0400 [thread overview]
Message-ID: <CAFXT+RN2f1JySEjDZTGswT69pGME=Cn63_Yy8mhPGAZX5cDNFQ@mail.gmail.com> (raw)
In-Reply-To: <86jzxwuedr.fsf@mail.linkov.net>
[-- Attachment #1: Type: text/plain, Size: 4537 bytes --]
> 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@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))))
>
[-- Attachment #2: Type: text/html, Size: 5802 bytes --]
next prev parent reply other threads:[~2023-05-03 6:10 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
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 [this message]
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='CAFXT+RN2f1JySEjDZTGswT69pGME=Cn63_Yy8mhPGAZX5cDNFQ@mail.gmail.com' \
--to=zkanfer@gmail.com \
--cc=62892@debbugs.gnu.org \
--cc=juri@linkov.net \
--cc=monnier@iro.umontreal.ca \
--cc=ruijie@netyu.xyz \
/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).