Questions about copy/kill and paste/yank default keybindings and behavior in char-mode and semi-char-mode

[papercatlol]

Ghostty

C-k/C-w/C-u kills text inside terminal, C-y yanks it back, M-y cycles kill-ring

Dragging the mouse while holding mouse-1 selects text (primary selection)

mouse-2 or S-<insert> pastes primary selection

C-S-c copies primary selection to clipboard
C-S-v pastes from clipboard

Char mode

C-k/C-w/C-u/C-y/M-y same as Ghostty (nice!)

Mouse does nothing
S-<insert> inserts '2~'

C-S-c gets translated to C-c
C-S-v gets translated to C-v

Semi-char mode

C-k/C-w kills text inside terminal (but you can only paste it from char-mode)
C-y/S-<insert> yanks from emacs kill-ring, M-y cycles emacs kill-ring
C-u is used for emacs prefix-arg

Dragging the mouse while holding mouse-1 selects text and enters copy-mode
<mouse-2> pastes primary selection

C-S-c gets translated to C-c
C-S-v gets translated to C-v

---

So Ghostty supports

• in-terminal kill/yank
• primary selection via mouse + can paste using keyboard
• system clipboard copy/paste

Char mode supports

• in-terminal kill/yank

Semi-char mode supports

• in-terminal kill (but not yank!)
• primary selection via mouse
• emacs clipboard paste (but to copy you need to switch to copy-mode unless I'm missing something)

Char mode is at least consistent, but semi-char is just bizarre.
C-w/C-k kills stuff but you have to switch to another mode to yank it, while
C-y yanks emacs stuff but you have to switch to another mode to copy.

What is the vision/expected workflow here?

[dakra]

Thanks for the issue.

First I want to clarify a few things, Ghostty (same as char-mode Ghostel) does NOT support kill/yank,
it just sends whatever key it receives to your terminal and then your terminal app/shell (that probably uses readline
with Emacs bindings) interprets it as copy/paste etc.
You can check that by just entering cat, then all keys after that are displayed that go straight to the terminal. There you will see that C-k just displays ^K and ghostty doesn't do any special copy there.

So that's why Ghostty and Ghostel in char-mode are behaving the same, they themself don't do anything and just forward the keys to the terminal.

In semi-char we explicitly have our own keybinding for pasting, as when you copy text in another Emacs buffer and have something in your Emacs kill-ring, it feels natural to me that when you paste, this just copied text gets inserted.
If we don't do that, then you copy something in another buffer, and then press e.g. C-y in Ghostel and it would (like in char-mode) paste whatever is in the terminal apps(/readline) kill-ring.

But I agree that it is confusing. I'll have to think a bit more about it.

Do you have an idea/suggestion how it should work in an ideal world?

[papercatlol]

First I want to clarify a few things, Ghostty (same as char-mode Ghostel) does NOT support kill/yank [...]

You're correct, I should've said something like "the user is able to do X in Ghostty".

If we don't do that, then you copy something in another buffer, and then press e.g. C-y in Ghostel and it would (like in char-mode) paste whatever is in the terminal apps(/readline) kill-ring.

Agreed.

Do you have an idea/suggestion how it should work in an ideal world?

My suggestion would be to make C-w & C-k in semi-char add the would-be-killed text to emacs kill-ring before passing the event to the terminal.
This way normal terminal editing works as expected, you can still paste from another buffer and you can even copy from ghostel by using terminal keybindings (e.g. C-a C-k to copy the whole line).

Mind you it's still a bit tricky as you'd need to know what text the terminal command is about to kill. E.g. repeatedly pressing C-w actually appends the text to the last kill. But the resulting behavior should be pretty intuitive IMO. I would love to hear a different perspective though, there might be somebody with a completely different terminal workflow.

[emil-e]

My suggestion would be to make C-w & C-k in semi-char add the would-be-killed text to emacs kill-ring before passing the event to the terminal. This way normal terminal editing works as expected, you can still paste from another buffer and you can even copy from ghostel by using terminal keybindings (e.g. C-a C-k to copy the whole line).

Mind you it's still a bit tricky as you'd need to know what text the terminal command is about to kill. E.g. repeatedly pressing C-w actually appends the text to the last kill. But the resulting behavior should be pretty intuitive IMO. I would love to hear a different perspective though, there might be somebody with a completely different terminal workflow.

If the key still also goes to the terminal, then at least the consequences of getting the kill slightly wrong wouldn't be that high at least. But it has to work reliably enough to warrant the added complexity, I think.

[papercatlol]

If the key still also goes to the terminal, then at least the consequences of getting the kill slightly wrong wouldn't be that high at least. But it has to work reliably enough to warrant the added complexity, I think.

Yeah, while C-k is pretty straightforward, accurately replicating C-w behavior might be a fool's errand. It seems that Bash/Zsh/Sh all have their own quirks even before user customization. I'll have to think about this more.

Maybe a better approach would be to send the ^W event to the shell first, and then figure out what it killed..

[dakra]

My suggestion would be to make C-w & C-k in semi-char add the would-be-killed text to emacs kill-ring before passing the event to the terminal.

I have this in my config: https://github.com/dakra/dmacs/blob/64ec3e0db6dda591f3f521d10bbd3b03c7be8c9e/init.el#L767-L786
and even have the C-k example in the Ghostel readme https://github.com/dakra/ghostel#a-fuller-example

But I feel that stuff should not be in core as it's just not 100% correct.
Sometimes C-k doesn't kill to end-of-line in the terminal app but you would still yank the text in the emacs kill ring.
If you have some TUI input box that has borders, C-k in there would probably only kill the input text while the Emacs version would kill all including spaces and the right border char.
Same for all other yank or kill commands, in Emacs we just don't know what the terminal app does so there can always be a difference.

I feel if you "opt-in" with a snippet like above in your config you "acknowledge" that behavior.
Maybe we should provide "helpers" in Ghostel or even some minor mode to activate or something.
Difficult to get the UX right so that users know what actually happens but also don't have to configure too much.
I'm also open for different suggestions etc if anyone has any good idea.

[papercatlol]

But I feel that stuff should not be in core as it's just not 100% correct.
[...]
I feel if you "opt-in" with a snippet like above in your config you "acknowledge" that behavior.

Yeah, you're right, it's better to have this opt-in rather than enabled by default but unreliable.

Difficult to get the UX right so that users know what actually happens but also don't have to configure too much.

Ain't that the truth!

I made a C-w gigahack for my config that seems to work on local shells so far:

(defvar ghostel--kill-ring-update-timeout 0.1)
(defvar-local ghostel--kill-ring-update-timer nil)

(defun ghostel-C-w ()
  (interactive)
  (labels ((%rest-of-input ()
             (when-let* ((end ghostel--cursor-char-pos)
                         (beg (ghostel-input-start-point))
                         ((<= beg end)))
               (buffer-substring-no-properties beg end)))
           (%kill-handler (input-old appendp)
             (lambda ()
               (if-let* ((input-new (%rest-of-input))
                         (to-kill
                          (if (string-empty-p input-new)
                              input-old
                            ;; Assume that C-w just removes some suffix from
                            ;; INPUT-OLD.
                            (when (string-prefix-p input-new input-old)
                              (substring input-old (length input-new))))))
                   (if appendp
                       (kill-append to-kill 'before-p)
                     (kill-new to-kill))
                 (message "ghostel-C-w: failed to add text to kill-ring")))))

    (let ((input-old (%rest-of-input)))
      (ghostel--send-encoded "w" "ctrl")
      (when (and (stringp input-old) (not (string-empty-p input-old)))
        ;; HACK Buffer state isn't updated synchronously, so we schedule a
        ;; function to update kill-ring. This will fail miserably on tramp
        ;; connections with basically any amount of latency. I wonder if there
        ;; is a good way to sync this. Maybe a hook in the redraw function?
        (when (timerp ghostel--kill-ring-update-timer)
          (cancel-timer ghostel--kill-ring-update-timer))
        (setq ghostel--kill-ring-update-timer
              (run-with-timer ghostel--kill-ring-update-timeout nil
                              (%kill-handler input-old
                                             (eq 'ghostel-C-w last-command))))))))

(define-key ghostel-semi-char-mode-map (kbd "C-w") 'ghostel-C-w)
(evil-define-key 'insert ghostel-semi-char-mode-map
  (kbd "C-w") 'ghostel-C-w)

Maybe we should provide "helpers" in Ghostel or even some minor mode to activate or something.

Somewhat related to this, what would be a good way to run code after ghostel redraw? E.g. if one wanted to implement something similar to the existing password prompt detection or link handling.

[emil-e]

Somewhat related to this, what would be a good way to run code after ghostel redraw? E.g. if one wanted to implement something similar to the existing password prompt detection or link handling.

I don't think there's any good hook for that right now, but but I have been thinking about adding a ghostel-around-redraw-hook or similar that allows you to do things around redraw. Mostly for internal use but it might be useful for others too.

If you want to hack it, you could advice ghostel--redraw which is where the actual redraw happens. It's a native function but I think you advice those too?