Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atom-movement key theme would be more useful if it were inhibited inside comments #284

Open
bpstahlman opened this issue Feb 5, 2021 · 3 comments

Comments

@bpstahlman
Copy link

I doubt I'm the only one accustomed to using delete and change operators with word and WORD text objects to edit the text of an existing comment. With the "atom-movement" key theme enabled, the results can be pretty surprising (and disconcerting). Even moving around in a comment becomes a challenge without w, W, b, B, etc. Is there a valid use case for having atom movements work within a comment? I suspect that changing/deleting to the end of a comment (or the beginning of what follows) is a much less frequent operation than changing/deleting words within a comment. Perhaps there could be an option to inhibit the atoms when point is within a comment.

@noctuid
Copy link
Owner

noctuid commented Apr 6, 2021

Maybe new commands or an option could be added, but I think the default commands should always act on atoms. For now, you could use general-predicated-dispatch (or the equivalent if you don't use general), for example, to create your own version that behaves differently in comments.

@bpstahlman
Copy link
Author

Hmm... My reading of the relevant section in the Emacs manual leaves me nearly convinced that comments aren't considered "atoms" in the lisp sense. I get the sense that comment and code spaces are orthogonal, and that the concepts of "list" and "atom" have meaning only in the latter.

At any rate, I have atom-motions disabled for now because it makes editing comments so painful. Thanks for the suggested workaround. I'll try to look at general-predicated-dispatch (and General, more generally) when I get some free time...

@noctuid
Copy link
Owner

noctuid commented Apr 8, 2021

Here is a self contained example (general.el not needed):

(cl-defmacro general-predicate-dispatch
    (fallback-def &rest defs
                  &key docstring
                  &allow-other-keys)
  (declare (indent 1))
  "Create a menu item that will run FALLBACK-DEF or a definition from DEFS.
DEFS consists of <predicate> <definition> pairs. Binding this menu-item to a key
will cause that key to act as the corresponding definition (a command, keymap,
etc) for the first matched predicate. If no predicate is matched FALLBACK-DEF
will be run. When FALLBACK-DEF is nil and no predicates are matched, the keymap
with the next highest precedence for the pressed key will be checked. DOCSTRING
can be specified as a description for the menu item."
  ;; remove keyword arguments from defs and sort defs into pairs
  (let ((defs (cl-loop for (key value) on defs by 'cddr
                       unless (keywordp key)
                       collect (list key value))))
    `'(menu-item
       ,(or docstring "") nil
       :filter (lambda (&optional _)
                 (cond ,@(mapcar (lambda (pred-def)
                                   `(,(car pred-def) ,(cadr pred-def)))
                                 defs)
                       (t ,fallback-def))))))

(define-key lispyville-mode-map
  [remap evil-forward-word-begin]
  (general-predicate-dispatch #'lispyville-forward-atom-begin
    (lispy--in-string-or-comment-p) #'evil-forward-word-begin))

(lispy--in-string-or-comment-p) could be replaced with (lispy--in-comment-p) or whatever.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants
@bpstahlman @noctuid and others