view-mode keymap

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

Re: view-mode keymap

[Jambunathan K]

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

-- 

Re: view-mode keymap

[Daimrod]

Jambunathan K <kjambunathan@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'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

Re: view-mode keymap

[Jambunathan K]

Daimrod <daimrod@gmail.com> writes:

> Jambunathan K <kjambunathan@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?

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

-- 

Re: view-mode keymap

[Daimrod]

Jambunathan K <kjambunathan@gmail.com> writes:

> Daimrod <daimrod@gmail.com> writes:
>
>> Jambunathan K <kjambunathan@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?

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

Re: view-mode keymap

[Daimrod]

Daimrod <daimrod@gmail.com> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> Daimrod <daimrod@gmail.com> writes:
>>
>>> Jambunathan K <kjambunathan@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?
>
> 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.

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

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

Re: view-mode keymap

[Eric Abrahamsen]

Daimrod <daimrod@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...

Re: view-mode keymap

[Daimrod]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Daimrod <daimrod@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...
>
>

You're welcome :)

-- 
Daimrod/Greg

Re: view-mode keymap

[Michael Heerdegen]

Daimrod <daimrod@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.

Re: view-mode keymap

[Daimrod]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Daimrod <daimrod@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?

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

Re: view-mode keymap

[William Xu]

Daimrod <daimrod@gmail.com> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Daimrod <daimrod@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?
>
> 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.

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

Re: view-mode keymap

[Daimrod]

William Xu <william.xwl@gmail.com> writes:

> Daimrod <daimrod@gmail.com> writes:
>
>> Michael Heerdegen <michael_heerdegen@web.de> writes:
>>
>>> Daimrod <daimrod@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?
>>
>> 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.
>
> 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.  

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

-- 
Daimrod/Greg