unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Psionic K <psionik@positron.solutions>
To: help-gnu-emacs@gnu.org
Subject: `other-window-prefix' command, running anything in the other window
Date: Mon, 22 Jan 2024 17:09:16 +0900	[thread overview]
Message-ID: <CADQMGASFXdYfPUVKfavXDayCeekwTR_jsv-+zizWmAfoW8RBpA@mail.gmail.com> (raw)

One of my TODO's is to compress all of the `*-other-window` commands
into a prefix command that will make `find-file` do what
`find-file-other-window` does for example.

I think I have an implementation that makes sense.  I'm not sure if it
makes the most sense.

The solution in my head is to create an `other-window-prefix` command.
The command needs to set a prefix state.  During the
`pre-command-hook`, a hook function would check if the prefix was set
and then:
1. If the command has "other-window" in the name, `user-error' because
the user's workflow is crap and they need to unbind that command and
never use it again
2. If the command has an "other-window" version, run that since it
might be smarter
3. Store the selected window (itself an impressive feat due to
minibuffers and dynamic `selected-window` results), create a window,
run the command, restore the selected window

1 & 2 are optional, but could mitigate silliness.

My biggest source of loathing before hacking this out is understanding
C-u, the command loop with minibuffer, and repeat maps, basically the
edge cases.  I think I can read my way through this, but insights
appreciated.  Commands that break when called in another window are
probably just bugs?

Repeat behavior should, like C-u, preserve the `other-window-prefix'
state.  I don't think `other-window-prefix` + `command` can or should
be repeated.  The user intended to stay where they are, and if they
did not, I'm pretty sure no key sequences can be saved.

Btw, pretty please `user-selected-window` and a hook?  Lisp programs
that need to know what the user is doing, not what an enclosing lisp
program is doing, need to know.  Modeline functions are an example.

Curious for better approaches to my `other-window-prefix'.  I may have
just completed copyright assignment and I think this belongs in Emacs.

IMO we should eliminate all instances of suffixed commands that would
be better prefixed by a modifying command, especially when the key
sequences for the longer version are equal to being invoked with a
prefix and the prefix is more versatile for commands that don't have
multiple versions.  Suffixed commands just clog up completions.

Thnkx <3



             reply	other threads:[~2024-01-22  8:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22  8:09 Psionic K [this message]
2024-01-22  8:29 ` `other-window-prefix' command, running anything in the other window Emanuel Berg
2024-01-22 21:06 ` Dmitry Gutov
2024-01-22 21:50   ` Psionic K
2024-01-22 22:21     ` Psionic K
2024-01-22 23:39       ` Dmitry Gutov

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=CADQMGASFXdYfPUVKfavXDayCeekwTR_jsv-+zizWmAfoW8RBpA@mail.gmail.com \
    --to=psionik@positron.solutions \
    --cc=help-gnu-emacs@gnu.org \
    /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.
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).