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@gnu.org> wrote:

> > Cc: 62892@debbugs.gnu.org
> > From: Zachary Kanfer <zkanfer@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?
>