martinrykfors / key-leap Goto Github PK

Set a buffer's major mode to text mode. Enable visual-line-mode. Make the last line of the buffer long enough to wrap.

Result is that the last visual line of the wrapped line also is assigned a key at the margin. We expect there to be no keys assigned to visual lines, only "true" lines are given a key.

To replicate:

• Do M-x RET key-leap-start-matching.
• Click somewhere in the emacs window.

The key matching will stop, but the keys in the margin are still colored as if they were active.
Tested on Windows.

I recently merged a big change that introduces a more fine-grained handling of how overlays are added and deleted.

The two tests that verify that the overlays are correct are currently failing because of this, and I am struggling to figure out why.
Swithching to the buffers created by the tests the overlays appear as they should, but the overlays-at function used by the tests returns an empty list.

Been getting this when loading key-leap on emacs 28.2.

When callling use-package that has ensure t in its config, it will work once installed (but a lot of warnings about docstrings), but restarting emacs will then cause this error to appear. Key-leap will not work after this.

Enabling key-leap-mode and then linum-mode causes display issues. So far I've just accepted this collision as a natural consequence of them both competing to set the margin.

I'm opening this issue because of the recent discussions on emacs-devel about handling the window margins: http://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00066.html

If future versions of Emacs have a way for multiple packages to alter the margin, key-leap-mode should make use of this.

When hiding subtrees in org-mode, it will still enumerate the lines as if the folded lines were visible. I don't know if this also applies to folding in other modes, but that would be my guess.

If key-leap is enabled in a buffer and the major mode of that buffer is changed, key-leap gets disabled in that buffer. This does not match the behavior of other minor modes that I use, and is kind of annoying.
Expected behavior is that key-leap remains enabled in a buffer whose major mode is changed.

Create an elisp buffer with a few lines of text in the beginning.
Enable key-leap.
Execute the following (it inserts an invisible overlay from the beginning of the buffer to a few lines down)

(progn
  (let* ((start (point-min))
         (end (save-excursion
                (goto-char (point-min))
                (forward-line 3)
                (point)))
         (ol (make-overlay start end)))
    (overlay-put ol 'invisible t)))

The topmost key in the margin is now missing.

When key-leap is active, deleting a character while the Company popup is visible will casue the popup to be hidden. This does not happen when key-leap is inactive

There should be an option to make it work like an evil-motion.

By doing the following:

(evil-define-motion key-leap-motion ()
      :type line
      (key-leap-start-matching))

and then adding to the evil-motions keymap:

(define-key evil-motion-state-map (kbd "<SPC>") 'key-leap-motion)

you are able to use key-leap in visual-state and as a motion for evil-operators. You could delete all lines from point to the line indexed as va by typing d<SPC>va for instance.

Two things need doing:

• Figure out a way for users to enable this feature in their configs. It would need to check that evil-mode is properly installed before defining a motion. Maybe just having a function key-leap-define-evil-motion, that can be added to init.el would do.
• Document how to set this up in the readme.

Create two windows showing different buffers.
Enable key-leap in one of them and switch to the other window.
Calling scroll-other-window will cause the keys to be left behind as the other window scrolls

• Enable key-leap in a buffer.
• Create a new window showing the same buffer.
• Call key-leap-start-matching.

The margin keys of both windows are highlighted in red, but we expect them only to be highlighted in the currently active window

I'm not that happy with having the evil integration functionality as a part of key-leap.el. In order for it to work, evil must have been required before the function is called. It would be better if the integration occured in its own package that properly specifies its dependency on key-leap and evil. This would mean key-leap.el is freed of the evil integration, which did not really belong there in the first place.

The solution would be to create a new package in this repository, evil-key-leap.el that does the same thing that key-leap-create-evil-motion is currently doing.

It would require the following steps:

• Change the melpa recipe to explicitly use only key-leap.el as the package source
• Create evil-key-leap.el and put the integration code there. Its package header should specify key-leap and evil as dependencies
• Remove the implementation of key-leap-create-evil-motion and mark it as obsolete

Create an empty buffer, enable org-mode, then key leap.
Enter a list element - hello then press M-Ret to add a new item.
The key of the first line will be wrong.

There are many more strange things going on with org-mode lists, but this is the easiest way to reliably reproduce one of them.

Currently it differentiates between lines by using forward-visible-line. If a line is wrapped, the wrapped parts are not given keys.

Consider adding an option so one can leap to wrapped lines as well.

With #6 out of the way, the only thing I feel missing is getting #9 implemented. After that, save any show-stopping bugs, I think it is time to get this on melpa to make it more accessible.

To reproduce open an elisp file. Select a whole line and do M-;. Select it again and uncomment it by presing M-; again.

The keys at the margin of the line you just uncommented, and the one below it will be incorrect.