Integrate the built-in view-mode with Meow

[mmarshall540]

Sometimes I like to use view-mode, which provides a great environment for reviewing a file without accidentally making any changes to it. (Though honestly, my primary use is for the SPC and DEL bindings for page-up and page-down.)

In general, it coexists ok with Meow, but it is a bit cumbersome.

I'd like to use the meow-keypad space-bar leader to enter view-mode. However, after starting view-mode, I need to switch to meow-insert-mode, because otherwise the space-bar continues to bring up the meow-leader map.

So I'm wondering if there are any suggestions for configuring view-mode to work more seamlessly with Meow, so that I can enter view-mode almost as if it were its own Meow-mode, without having to separately switch to meow-insert-mode when starting view-mode and then back to meow-normal-mode when exiting view-mode. Ideally, it would remember the previous Meow-mode when entering view-mode and return to it when exiting.

Also, this seems (to me) like something that would fit with Meow's philosophy of cooperating with existing Emacs features and conventions. So would it be worth doing a pull-request if we can think of the right way to do it?

[DogLooksGood]

All integrations located in this file: https://github.com/meow-edit/meow/blob/master/meow-shims.el.
I would suggest switch to motion state automatically in view-mode, then switch back when exit.

[mmarshall540]

Thanks for the reply!

Only problem with motion-state is it overrides view-mode's space-bar binding, which is its most important keybinding IMO. Switching to insert-state works, but it seems incongruous, since you can't insert text at all in view-mode.

It feels conceptually to me like view-mode should have its own "state" in Meow. It affects the same things that a Meow "state" affects. It could be a user-level option, maybe?

Maybe a command called meow-view-mode? I think I just found out how this is done (meow-define-state), so I'll try it in my own config first.

[mmarshall540]

OTOH, maybe it's better to use the shims and temporarily override meow-motion-state SPC binding.

Another complicating factor is that view-mode has 6 different keybindings to exit. Each of them handles state differently.

q quit View mode, restoring this window and buffer to previous state.
q is the normal way to leave view mode.
e exit View mode but stay in current buffer. Use this if you started
viewing a buffer (file) and find out you want to edit it.
This command restores the previous read-only status of the buffer.
E exit View mode, and make the current buffer editable
even if it was not editable before entry to View mode.
Q quit View mode, restoring all windows to previous state.
c quit View mode and maybe switch buffers, but don’t kill this buffer.
C quit View mode, kill current buffer and go back to other buffer.

The effect of c, q and C depends on how view-mode was entered. If it was
entered by view-file, view-file-other-window, view-file-other-frame, or
M-x dired-view-file (M-x view-file, M-x view-file-other-window,
M-x view-file-other-frame, or the Dired mode v command),
then q will try to kill the current buffer.
If view-mode was entered from another buffer, by M-x view-buffer,
M-x view-buffer-other-window, M-x view-buffer-other-frame, M-x view-file,
M-x view-file-other-window, or M-x view-file-other-frame,
then c, q and C will return to that buffer.

Thus e should switch to meow-insert-state, but q should go back to whichever meow-state was active before.

So yeah, using the shim approach makes more sense, because then we aren't changing Meow-state except with the e and E commands (when exiting view-mode)... I was overthinking it and probably still am.

[DogLooksGood]

What about using read-only-mode instead of entering view-mode. It's kinda difficult to integrate view-mode into Meow, because view-mode is another modal layer.

[mmarshall540]

EDIT: I'm now completely converted to your thinking on this.

It makes more sense to just use read-only-mode in meow-normal-mode. I can bind any of the desirable View-mode commands within normal-mode, either directly, under the leader-key, or under a new prefix. Could even define some repeat-maps to make using them easier.

I'd thought that integration of view-mode might be a worthy feature to add to the project, but it really just adds unnecessary complexity.

Well I gave up on the idea of creating a new Meow-mode to integrate view-mode, and I went with your first suggestion. The only difference is I went with insert-state instead of motion-state.

I was going to use motion-state, per your suggestion. But I couldn't get SPC to work for view-mode's page-down binding in motion-state, even if I double-tapped space-bar.

SPC works fine for me in special-mode's like info-mode (which uses motion-state). A single tap of SPC in Info-mode brings up the Keypad-leader. Tapping SPC a second time in Info-mode pages down. However, in an emacs-lisp-mode buffer with view-mode and meow-motion-mode, pressing SPC once brings up the Keypad-leader, but then the second tap of SPC does nothing.

The shim currently works by enabling meow-insert-mode and then switching back to whatever mode we were in before enabling view-mode. That allows view-mode's keybindings to work. It also allows switching between insert-state and normal-state within view-mode, so that Meow's cursor movement bindings can be used.

But using "insert state" for a mode that prevents you from inserting text still seems... weird.

[DogLooksGood]

Well, meow supports creating new state by meow-define-state. But if you look at the whole picture, you don't need a new state just for a minor-mode. You only want a new state, when an independent layer is necessary for solving a particular problem.

[mmarshall540]

In case anyone's interested, here's what I came up with.

It puts the main view-mode commands under the "v" key in the Meow leader. Provides an easy way to page-up and page-down without moving your hands away from the main typing area, and without using modifiers (as with C-v/M-v). It also provides more control, allowing for half-page movements and line-by-line scrolling, among a few other things.

After entering this faux "view-mode", the bindings will keep working for moving around the buffer until you press a key that isn't listed.

;; In order for the bindings in this prefix to remain active until you
;; press ESC (or some other key not bound under the prefix), you must
;; have `repeat-mode' enabled.  Note that `repeat-mode' is only
;; available in Emacs 28+.
(when (version< "28" emacs-version)
  (repeat-mode 1))
(defvar my-view-prefix)
(define-prefix-command 'my-view-prefix)
(define-key mode-specific-map (kbd "v") 'my-view-prefix)
(defvar my-view-rep-map (make-sparse-keymap))
(dolist (kb '(("@"    . View-back-to-mark)
	      ("%"    . View-goto-percent)
	      ("G"    . View-goto-line-last)
	      ("g"    . View-goto-line)
	      ("F"    . View-revert-buffer-scroll-page-forward)
	      ("k"    . View-scroll-line-backward)
	      ("j"    . View-scroll-line-forward)
	      ("u"    . View-scroll-half-page-backward)
	      ("d"    . View-scroll-half-page-forward)
	      ("z"    . View-scroll-page-forward-set-page-size)
	      ("w"    . View-scroll-page-backward-set-page-size)
	      ("b"    . View-scroll-page-backward)
	      ("f"    . View-scroll-page-forward)
	      ("o"    . View-scroll-to-buffer-end)))
  (define-key my-view-prefix (kbd (car kb)) (cdr kb))
  (define-key my-view-rep-map (kbd (car kb)) (cdr kb))
  (put (cdr kb) 'repeat-map my-view-rep-map)
  (autoload (cdr kb) "view" nil 'interactive))

[montchr]

I really like this solution! Could it be integrated into Meow core as a shim?

[montchr]

I was ruminating on this issue a lot yesterday, and then I saw #543. This SPC binding conflict in view-mode / Info-mode is another example of an inconsistency that introduces a stumbling block.

A fix for the SPC meow-keypad/Info-scroll-up conflict does feel like something that absolutely belongs in Meow core, because Meow's usage of SPC breaks the pretty significant context of Info-mode, where we go for manuals.

That said, I know that changing the behavior of SPC is a lot more complicated than simply changing the default for a user option, so I don't know what to suggest as a solution. Could one of the options suggested above should be integrated into the core package?