akermu / emacs-libvterm

Emacs libvterm integration
GNU General Public License v3.0
1.72k stars 137 forks source link

Automatic copy mode toggle #594

Open psionic-k opened 2 years ago

psionic-k commented 2 years ago

I'm using the following tweaks:

  (defun pmx-vterm-avy-goto-word-1 ()
    "Jump, but enable vterm copy mode first"
    (interactive)
    (unless vterm-copy-mode
      (vterm-copy-mode 1))
    (call-interactively 'avy-goto-word-1))

  (defun pmx-vterm-kill-ring-save ()
    "Kill, but enable vterm copy mode first"
    (interactive)
    (unless vterm-copy-mode
      (vterm-copy-mode 1))
    (call-interactively 'kill-ring-save))

  (defun pmx-vterm-send-enter ()
    "Enter, but disable vterm copy mode first"
    (interactive)
    (when vterm-copy-mode
      (vterm-copy-mode -1))
    (call-interactively 'vterm-send-enter))

  (general-def 'vterm-mode-map "M-j" 'pmx-vterm-avy-goto-word-1)
  (general-def 'vterm-mode-map "M-w" 'pmx-vterm-kill-ring-save)
  (general-def 'vterm-mode-map "RET" 'pmx-vterm-send-enter)

I think you can see where this greatly improves the user experience. If I really need the vanilla vterm-send-M-w, I can call it off of M-x

As for integrating with user settings, it might be best to provide a function to define a new binding. Recommend (vterm-defkey-auto-copy-on BINDING FUNCTION) and (vterm-defkey-auto-copy-off BINDING FUNCTION)

There should be a customize variable that no only controls if the bindings will be made, but also if their behavior is turned on. This way, if I am using a real-time program, I can temporarily toggle off all auto-copy mode bindings.

Sbozzolo commented 2 years ago

My personal take is that vterm should try to behave as a real terminal. Different people have different uses cases, so the best we can do is offer a fully functioning terminal. That said, I completely agree that for most users the use case is simply interactive shell usage, so it would be nice to optimize that experience. You are welcome to develop an extra layer to enable the functions you describe and I would advertise your package in the readme.

Thanks.

psionic-k commented 2 years ago

Question. I worked on a yank. I think I'm missing some indirection though:

  (defun pmx-vterm-yank ()
    "Yank, but disable vterm copy mode first"
    (interactive)
    (when vterm-copy-mode
      (vterm-copy-mode -1))
    (call-interactively 'yank))

  (general-def 'vterm-mode-map "C-y" 'pmx-vterm-yank)

Enter works. It's using the vterm command, vterm-send-enter. Similar code for yank does not work. I get a warning about being in read-only mode even though the buffer is not in read-only mode :frowning_face:

pmx-vterm-yank: Buffer is read-only: #<buffer *vterm*>

Sbozzolo commented 2 years ago

Try using vterm-yank instead.

psionic-k commented 2 years ago

Kind of works, but the region behavior could be better. I'm getting whole lines even though I only marked a word.

psionic-k commented 2 years ago

I think I'm just using call-interactively incompletely, but I'm not sure. The interaction with editing commands feels a little inconsistent with the behavior in other buffers. Two behaviors I don't expect:

I can't tell if this is because of how I'm doing it or if vterm is adding some behavior to accommodate other terminal behavior.

Regarding placing functionality in another package, I don't think it's the best way since there are no new data models being discussed. Users have editing commands. They need editing commands that toggle the read-write state. This isn't particular to which editing commands a user likes as long as there is a wrapper to modify a command into one that interacts with the read-write state.