unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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 --]

  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).