view-mode keymap

[Daimrod]

I like `view-mode' but it conflicts with others minor mode map (paredit
in my case).

I would like to know if there is a better way to make a keymap that
takes precedence over the others than manipulating
`minor-mode-map-alist'.

Here is my current implementation:

(add-hook 'view-mode-hook
(lambda ()
;; Makes sure `view-mode-map' is the first minor mode map
;; available in `minor-mode-map-alist', because in case of
;; conflicting bindings, the first one is used.
(unless (eq 'view-mode (caar minor-mode-map-alist))
(setf minor-mode-map-alist
(cons (cons 'view-mode view-mode-map)
(cl-remove 'view-mode minor-mode-map-alist
:key #'car))))))

--
Daimrod/Greg

[Jambunathan K]

I think, `make-composed-keymap' can help here.

[Daimrod]

I've looked at it but I don't see how it can help. I don't want to
create a new keymap, I want `view-mode-map' to take priority over other
keymaps.

I've looked at the documentation and it seems that changing the order in
`minor-mode-map-alist' is the only way to manage priorities between
keymap, because they shouldn't conflict in there first place.

--
Daimrod/Greg

[Michael Heerdegen]

Daimrod <dai...@gmail.com> writes:

> I like `view-mode' but it conflicts with others minor mode map (paredit
> in my case).

Why do you need to use `paredit-mode', a mode for editing, and
`view-mode' that makes the buffer read-only, at the same time?


Michael.

[Daimrod]

Well, I was playing with `view-mode', trying to integrate it with some
other minor modes to read a text without too much visual noise (hiding
the header-line, the mode-line and centering the content). And I tried
it on the current buffer which was the source of those modes, it didn't
work as I expected, I tried to understand, and so here I am.

> Michael.
>

--
Daimrod/Greg

[Jambunathan K]

Daimrod <dai...@gmail.com> writes:

> Jambunathan K <kjambu...@gmail.com> writes:
>
>> I think, `make-composed-keymap' can help here.
>>
>>
>>> I like `view-mode' but it conflicts with others minor mode map (paredit
>>> in my case).
>>>
>>> I would like to know if there is a better way to make a keymap that
>>> takes precedence over the others than manipulating
>>> `minor-mode-map-alist'.
>>>
>>> Here is my current implementation:
>>>
>>> (add-hook 'view-mode-hook
>>> (lambda ()
>>> ;; Makes sure `view-mode-map' is the first minor mode map
>>> ;; available in `minor-mode-map-alist', because in case of
>>> ;; conflicting bindings, the first one is used.
>>> (unless (eq 'view-mode (caar minor-mode-map-alist))
>>> (setf minor-mode-map-alist
>>> (cons (cons 'view-mode view-mode-map)
>>> (cl-remove 'view-mode minor-mode-map-alist
>>> :key #'car))))))
>
> I've looked at it but I don't see how it can help. I don't want to
> create a new keymap, I want `view-mode-map' to take priority over other
> keymaps.

I was hoping that something like this

(use-local-map
(make-composed-keymap view-mode-map
(current-local-map)))

will put `view-mode-map' on top of the keymap stack and thus overwrite
paredit's bindings.

I see that DEL (backspace) key is shared between view-mode and paredit.
My little experimentation that the above snippet failst to produce the
effect expected by me.

Do you think I am reading the doc of the APIs (used above) incorrectly?

[Daimrod]

No, the problem is not the way you're building the keymap, but how
keymaps are searched.

From (info "(elisp) Searching Keymaps")
> (or (cond
> (overriding-terminal-local-map
> (FIND-IN overriding-terminal-local-map))
> (overriding-local-map
> (FIND-IN overriding-local-map))
> ((or (FIND-IN (get-char-property (point) 'keymap))
> (FIND-IN TEMP-MAP)
> (FIND-IN-ANY emulation-mode-map-alists)
> (FIND-IN-ANY minor-mode-overriding-map-alist)
> (FIND-IN-ANY minor-mode-map-alist)
> (if (get-text-property (point) 'local-map)
> (FIND-IN (get-char-property (point) 'local-map))
> (FIND-IN (current-local-map))))))
> (FIND-IN (current-global-map)))

It searches through `minor-mode-map-alist' _before_ looking at
`current-local-map'.

I could use `overriding-local-map' instead of `current-local-map' if it
was a buffer local variable. But it's not, and I'm afraid that making it
buffer local might break things in a weird way.

>>
>> I've looked at the documentation and it seems that changing the order in
>> `minor-mode-map-alist' is the only way to manage priorities between
>> keymap, because they shouldn't conflict in there first place.

--

Daimrod/Greg

[Daimrod]

However I've just noticed that I can use `minor-mode-overriding-map-alist'
instead of `minor-mode-map-alist'.

So now my code is:

(add-hook 'view-mode-hook
(lambda ()
;; In `view-mode', `view-mode-map' overrides other minor
;; mode maps.
(pushnew (cons 'view-mode view-mode-map)
minor-mode-overriding-map-alist
:key #'car)))

A bit more cleaner :)

[Eric Abrahamsen]

Daimrod <dai...@gmail.com> writes:

> So now my code is:
>
> (add-hook 'view-mode-hook
> (lambda ()
> ;; In `view-mode', `view-mode-map' overrides other minor
> ;; mode maps.
> (pushnew (cons 'view-mode view-mode-map)
> minor-mode-overriding-map-alist
> :key #'car)))
>
> A bit more cleaner :)

Thanks! This was annoying me too, but not enough to look into it. I'll
try the fix...

[William Xu]

Maybe you can try this minor mode:

;; View file like a simple `less'. Provide limited less keys, mainly j,
;; k, f, b, g, G, etc.

https://github.com/xwl/less/blob/master/less.el

I bind `C-c v' to enable it, type `e' to exit.

--
William

http://xwl.appspot.com

[Daimrod]

Thanks, but I think I'll keep `view-mode' now that I've found a
workaround.

--
Daimrod/Greg

[Daimrod]

You're welcome :)

--
Daimrod/Greg