[konsole drag&drop] Drag&drop function to terminal

[ciranus]

ble version: 0.4.0-devel2+276baf2 Bash version: 5.1.16 (x86_64-pc-linux-gnu)

Problem: when a function block is dropped from a text editor to terminal, each line is immediately analyzed, and then errors reported. note: this problem does not exist in zsh.

Proposal: when dropping a function to terminal, ble.sh should detect a function declaration line, and wait the end of the function block before reporting any error.

Test : drag and drop a basic function to terminal

f1() { echo A
}

Or is there any configuration tricks to make it work ?

[akinomyoga]

Thank you for the report! But it doesn't reproduce in my environment. ble.sh is supposed to work as you expect. Maybe this is related to the behavior of your terminal in pasting texts (e.g., it directly writes \n in the pasted text) or the keybinding settings.

• Q1: What is your terminal?
• Q2: What is the result of the following commands?

$ ble/debug/keylog#start
$      <-- (paste a small function)
$ ble/debug/keylog#end

• Q3: Do you set up custom keybindings for C-m, C-j, or RET?
• Q4: What is the result of the following command?

$ ble-bind -P | grep 'C-[mj]'

[ghost]

note: it works fine with kitty terminal.

A1: konsole (kde)

A2:

===== bytes =====
102 49 40 41 32 123 32 101 99 104 111 32
 65 10 125 10 192 155 91 50 48 48 126 98
 108 101 47 100 101 98 117 103 47 107 10
1 121 108 111 103 35 101 110 100 192 155
 91 50 48 49 126 13

===== chars =====
f 1 ( ) SP { SP e c h o SP A LF } LF ESC
 [ 2 0 0 ~ b l e / d e b u g / k e y l o
 g # e n d ESC [ 2 0 1 ~ RET

===== keys =====
f 1 ( ) SP { SP e c h o SP A C-j } C-j p
aste_begin C-m

A3 : no custom bindings / just default

A4:

ble-bind -P | grep 'C-[mj]'
ble-bind -m 'isearch' -f 'C-j' 'isearch/accept-line'
ble-bind -m 'isearch' -f 'C-m' 'isearch/exit'
ble-bind -m 'nsearch' -f 'C-j' 'nsearch/accept-line'
ble-bind -m 'nsearch' -f 'C-m' 'nsearch/exit'
ble-bind -m 'emacs' -f 'C-j' 'accept-line'
ble-bind -m 'emacs' -f 'C-m' 'accept-single-line-or-newline'

.blerc

bleopt exec_errexit_mark=
bleopt complete_auto_complete=
bleopt complete_auto_history=
bleopt editor=nano

[akinomyoga]

===== bytes =====
102 49 40 41 32 123 32 101 99 104 111 32
 65 10 125 10 192 155 91 50 48 48 126 98
 108 101 47 100 101 98 117 103 47 107 10
1 121 108 111 103 35 101 110 100 192 155
 91 50 48 49 126 13

===== chars =====
f 1 ( ) SP { SP e c h o SP A LF } LF ESC
 [ 2 0 0 ~ b l e / d e b u g / k e y l o
 g # e n d ESC [ 2 0 1 ~ RET

OK, it seems that even though konsole supports the bracketed paste mode (i.e., ESC [ 200~ paste_text ESC [ 201~), it somehow doesn't use the bracketed paste for drag&drop. Also, konsole seems to directly write LF (10) to the TTY, and this forces to execute the current command line because byte 10 is translated to C-j as the typical key representation and C-j is bound to the forced execution.

I'll later take a look at the behavior of konsole in my environment.

[ghost]

Ok thanks. I'm currently switching back from zsh default shell to bash5, thanks to ble.sh that I lately discovered just few days ago ! ――――――――― [konsole] [Bug 456373] pasted command executes after GUI-app exits

The protection from execution is done via a protocol between the application or shell and the terminal emulator called bracketed paste. The shell or application has to request bracketed paste for it to work. For backwards compatibility, your shell (bash/zsh/...) is disabling bracketed paste prior to executing a program

GNU Bourne-Again SHell - #110686, Execution of pasted text despite "bracketed paste protocol".

Then maybe a zsh trick to make it work. ――――――――― New test for investigation: xclip test is OK.

printf 'f1() { echo A\n}' | xclip
xclip -o

f1() { echo A
}  

[akinomyoga]

I confirmed the behavior of Konsole. It seems GNOME terminal also behaves the same. On the other hand, XTerm and Alacrity do not seem to accept drag & drop. From this observation, I guessed that this drag & drop feature is implemented in each terminal but not something translated to keyboard inputs by a lower layer like the window manager.

Then I have checked the source code of Konsole. In the present version of konsole, the dropped text seems to be directly written to the PTY. This is actually not an expected behavior by terminal applications. The binary representation of C-j (LF) in the terminal communication conflicts with the naive encoding of newlines in texts. Normally, in the terminal communication, newlines are represented by RET (\r), so we need to normalize different representations of newlines in text, such as \n and \r\n, to \r. Konsole seems to correctly handle it for the pasted text. It also handles the bracketed paste mode and other sanitization of the pasted text. I believe the dropped text should also undergo all of these processes of sanitization, newline adjustments, and the addition of bracketed-paste markers.

I have also checked the source code of GNOME terminal to find that they actually have supported these processes for dropped text recently in commit f5f15e67. The current master of GNOME terminal first receives the dropped text in terminal_screen_drag_data_received(). Then the text is relayed through terminal_screen_paste_text(), vte_terminal_paste_text(), vte::terminal::Widget::paste_text(), and vte::terminal::Terminal::widget_paste() and finally arrives in vte::terminal::pastify_string(). The adjustments of LF is processed in pastify_string. The bracketed paste is also processed there.

I will later test the following patch and submit it to the upstream of Konsole:

https://invent.kde.org/akinomyoga/konsole/-/commit/d1f59a63fd6e71c049a9963118f7cfa92087a102

[ghost]

Thanks for your time. This is far beyond my skills. However, zsh is able to bypass this issue I have never seen before using bash as default shell. I then suppose zsh found a solution to force bracketed paste protection.

I also tried to add set enable-bracketed-paste on to .bashrc with no effect.

[akinomyoga]

I then suppose zsh found a solution to force bracketed paste protection.

zsh and plain bash are not affected by this behavior of Konsole because they treat C-j the same as RET / C-m by default. However, ble.sh assigns different roles to C-j and RET / C-m. This is the reason ble.sh is affected. The same problem also arises in other terminal applications that assign different roles to C-j and RET such as lisp-interactive-mode of GNU Emacs.

If you would like to do drag&drop frequently, you can change the keybinding of C-j to the same target as RET as a temporary workaround, but in that case, there is no way to execute the command line in the multiline editing mode. So you need to sacrifice another key combination for the command execution in the multiline mode. For example, M-RET (decoded as C-M-m) inserts a newline in the command line by default, but we may change this to execute the command line instead.

# blerc

# Tentative workaround for Konsole
ble-bind -f C-j accept-single-line-or-newline
ble-bind -f C-M-m accept-line

I also tried to add set enable-bracketed-paste on to .bashrc with no effect.

It's already turned on by ble.sh by default unless the user explicitly disables it, so it wouldn't actually change the setting. By the way, the setting set enable-bracketed-paste on needs to be written in ~/.inputrc. If you would like to put it in .bashrc, you can write as

# bashrc

bind 'set enable-bracketed-paste on'

[ghost]

# Tentative workaround for Konsole
ble-bind -f C-j accept-single-line-or-newline
ble-bind -f C-M-m accept-line

It nearly solves ! Remaining problem: (RET or C-m: insert a newline, C-j: run) -> no way to execute run.

―――――――――

enable-bracketed-paste / It's already turned on by ble.sh by default unless the user explicitly disables it

No effect with any bash config (.bashrc ou .xinputrc). By reading Paste behavior altered after update to Konsole 20.12.0-1 • KDE Community Forums, how to test disabling enable-bracketed-paste with ble ?

bind 'set enable-bracketed-paste off' save and restart konsole.

bleopt term_bracketed_paste_mode=off is rejected by 04.0

[akinomyoga]

no way to execute run.

Yes, so this:

For example, M-RET (decoded as C-M-m) inserts a newline in the command line by default, but we may change this to execute the command line instead.

i.e., ble-bind -f C-M-m accept-line. With this keybinding, you should be able to run the command by pressing M-RET or C-M-m.

[ghost]

you should be able to run the command

No way. However bleopt term_bracketed_paste_mode=off is not understood by 0.4.0. ble.sh/blerc at master · akinomyoga/ble.sh

To summarize.... Drag&drop works fine in default bash with Konsole. Drag&drop breaks with ble.sh .

[akinomyoga]

0.4.0-devel2+276baf2

Ah, wait. I have been thinking that you are using the latest devel version, but you are actually using the version two years ago. Could you update it to the latest version by running ble-update?

No effect with any bash config (.bashrc ou .xinputrc). By reading Paste behavior altered after update to Konsole 20.12.0-1 • KDE Community Forums, how to test disabling enable-bracketed-paste with ble ?

How did you test that it doesn't have effect? The dropped text will never be affected in the current version of Konsole because Konsole just doesn't support the bracketed paste mode for the dropped text. It only supports the bracketed paste mode for the pasted text.

you should be able to run the command

No way.

Hmm, that's different from the behavior I observe in my environment.

Q5: Which version of Konsole do you use?

$ konsole --version
konsole 21.12.2

Q6: Also, what would be inserted when you press C-v and then M-RET?

$ echo [press C-v M-RET]^[^M

However bleopt term_bracketed_paste_mode=off is not understood by 0.4.0.

It's not supported by the old version devel2+276baf2. Also, to turn off the bracketed paste in the latest devel version (i.e., master) of ble.sh, the value should be empty.

bleopt term_bracketed_paste_mode=

ble.sh/blerc at master · akinomyoga/ble.sh

The above is blerc template for master. The template for v0.4.0-devel2 is this: ble.sh/blerc at v0.4.0-devel2.

[ghost]

konsole 22.04.3 new test with ble.sh 20220712+1c7f7a1

No way to tun the command with .blesh modification. Well, I propose to make a pause in this investigation. However, if bash+konsole or zsh+konsole do not have drag&drop issue, but the issue starts with ble.sh enabled, I wonder if something should not be investigated in blesh code.

[akinomyoga]

konsole 22.04.3 new test with ble.sh 20220712+1c7f7a1

Thanks.

No way to tun the command with .blesh modification.

You need to put settings in ~/.blerc but not in ~/.blesh.

Could you try Q6 in my above reply?

However, if bash+konsole or zsh+konsole do not have drag&drop issue, but the issue starts with ble.sh enabled, I wonder if something should not be investigated in blesh code.

I already know the cause as I have already described in my reply. As I have already described, it's just because ble.sh assigns different roles to C-j and RET while zsh and plain bash assigns the same role.

[ghost]

~/.blerc but not in ~/.blesh

Typo. Sorry. In fact I use ~/.config/blesh/init.sh (as proposed as update somewhere).

echo [press C-v M-RET]^[^M [press C-v M-RET]^[^M

[akinomyoga]

~/.blerc but not in ~/.blesh

Typo. Sorry. In fact I use ~/.config/blesh/init.sh (as proposed as update somewhere).

OK, great.

echo [press C-v M-RET]^[^M [press C-v M-RET]^[^M

Thanks! Hmm, maybe I have confused you about the question.

Q8: Could you also try the following? [ Note: <--(press M-RET) is not literal text you are supposed to input, but could you press the key M-RET (i.e. Alt+Enter or Meta+Return on your keyboard) in this position? ]

$ ble/debug/keylog#start
$       <--(press M-RET)
$ ble/debug/keylog#end

[ghost]

===== bytes =====
13 98 108 101 47 100 101 98 117 103 47 1
07 101 121 108 111 103 35 101 110 100 13

===== chars =====
RET b l e / d e b u g / k e y l o g # e 
n d RET

===== keys =====
C-m b l e / d e b u g / k e y l o g # e 
n d C-m

[akinomyoga]

===== chars =====
RET b l e / d e b u g / k e y l o g # e 
n d RET

OK, your Konsole seems to drop Meta for RET. I'll take a look at the settings of Konsole.

[ghost]

Wait wait ......

Without .blerc modif, and default term_bracketed_paste_mode config:

===== bytes =====
13 192 155 91 50 48 48 126 98 108 101 47
 100 101 98 117 103 47 107 101 121 108 1
11 103 35 101 110 100 192 155 91 50 48 4
9 126 13

===== chars =====
RET ESC [ 2 0 0 ~ b l e / d e b u g / k 
e y l o g # e n d ESC [ 2 0 1 ~ RET

===== keys =====
C-m paste_begin C-m

with:

ble-bind -f C-j accept-single-line-or-newline
ble-bind -f C-M-m accept-line

===== bytes =====
13 192 155 91 50 48 48 126 98 108 101 47
 100 101 98 117 103 47 107 101 121 108 1
11 103 35 101 110 100 192 155 91 50 48 4
9 126 192 155 91 50 48 48 126 98 108 101
 47 100 101 98 117 103 47 107 101 121 10
8 111 103 35 101 110 100 192 155 91 50 4
8 49 126 127 127 127 127 127 127 127 127
 127 127 127 127 127 127 127 127 127 127
 127 127 13
===== chars =====
RET ESC [ 2 0 0 ~ b l e / d e b u g / k 
e y l o g # e n d ESC [ 2 0 1 ~ ESC [ 2 
0 0 ~ b l e / d e b u g / k e y l o g # 
e n d ESC [ 2 0 1 ~ DEL DEL DEL DEL DEL 
DEL DEL DEL DEL DEL DEL DEL DEL DEL DEL 
DEL DEL DEL DEL DEL RET
===== keys =====
C-m paste_begin paste_begin C-? C-? C-? 
C-? C-? C-? C-? C-? C-? C-? C-? C-? C-? 
C-? C-? C-? C-? C-? C-? C-? C-m

[ghost]

Finally, with

ble-bind -f C-j accept-single-line-or-newline
ble-bind -f C-M-m accept-line

run command can be activated with Alt+RET

[akinomyoga]

~~Thanks. In every case, M-RET seems to be just encoded as RET in your environment. But M-RET is supposed to be encoded as e.g. ESC RET, and in fact, it is encoded as ESC RET in my environment.~~

~~Hmm, I don't have an idea. Maybe Meta/Alt is stolen by a lower layer in your environment, or you might have special keyboard settings of Konsole.~~

~~Can I try another approach? Could you add the keybinding of~~

run command can be activated with Alt+RET

Oh, have you finally solved the problem?

[ghost]

Oh, have you finally solved the problem?

I would say it's a workaround I would have never been able to imagine with your ble-bind proposal. Now I would suggest that a much cleaner solution is investigated so that ble.sh is more compatible with konsole. ble.sh should not break what works 100% fine with default bash or zsh and konsole. Really a specific ble.sh issue. Thanks.

[akinomyoga]

Now I would suggest that a much cleaner solution is investigated so that ble.sh is more compatible with konsole.

This is a bug of Konsole so should be fixed in Konsole as I have already written. This is the clean solution.

ble.sh should not break what works 100% fine with default bash or zsh and konsole.

It's just accidental that zsh and plain bash are not affected; ble.sh hits the quirk of Konsole just because ble.sh provides a different feature set than zsh and plain bash.

Really a specific ble.sh issue.

It's not a specific issue to ble.sh as I have already written. I'm not interested in surveying and creating a complete list of affected terminal applications, but for example, lisp-interactive-mode of GNU Emacs is also affected as I have already written.

[ghost]

Ok fine. Just surprised it seems I am the first user reporting this for KDE/Konsole which is widely used. Let's hope this time spent will be useful for next kde/ble.sh user !

Also note that KDE bug correction (assuming your request is accepted), can take many years.

[ghost]

Potential proposal: -> generic C-j run not intuitive shortcut replacement by Alt-RET in blesh/keymap/emacs.sh

  [[ ! $info && $opt_multiline ]] &&
    info=$' (\e[35mRET\e[m or \e[35mC-m\e[m: insert a newline, \e[35mAlt-RET\e[m: run)'

[akinomyoga]

Could you carefully read this comment again? First of all, M-RET is used for other purpose in the default setting. The reason that you can use it to run the command is just that you have set it up in your .blerc as ble-bind -f C-M-m accept-line. Next, the actual way to send the terminal key sequence "M-RET" depends on the terminal and its user settings. In most cases, Alt+Enter does that by the default setting but not always. There is no way to retrieve the terminal's default behavior and its keyboard settings from terminal applications.

[ghost]

Ok, then let's say that a custom tweaking is necessary for kde/konsole users. Then, solved for me. Up to you to decide to close this issue ! Thanks for all.

[akinomyoga]

Ok, then let's say that a custom tweaking is necessary for kde/konsole users.

Yes, and that's the raison d'être of ble-bind. I'd keep it open until I test the patch for Konsole and submit it. Thank you for your report!

---

Update (2022-07-22): I first tried to build Konsole in Ubuntu 20.04 LTS because konsole/BUILD.md describes the needed packages for apt. But I couldn't complete it because of the package version compatibility. I have finally instead built it in Fedora 35. The needed packages in Fedora 35 has been the following:

$ sudo dnf install extra-cmake-modules
$ sudo dnf install qt5-base-devel
$ sudo dnf install kf5-k{auto,config,coreaddons,declarative,i18n,cmutils,notifications,notifyconfig,package,parts,pty}-devel
$ sudo dnf install kf5-k{crash,globalaccel,guiaddons,dbusaddons,iconthemes,newstuff}-devel

I confirmed that the problem is fixed with the patched version of Konsole. I have submitted it at !714.

Update (2022-08-01): !714 @ KDE/Utilities/Konsole has been merged.

[ghost]

For information:

• new test made with same bash+konsole versions
• ble.sh 0.2.5_50116 Releases · v0.2.5

C-j default key combination to run in multiline mode works out of the box, with no configuration at all.

[akinomyoga]

What do you mean? Isn't it the same behavior as ble-0.3 and ble-0.4? Without custom configurations, C-j has always been "run" in the multiline editing mode.

[ghost]

Isn't it the same behavior as ble-0.3 and ble-0.4?

No, because I need your specific .blerc keyboard modification for both 0.3 & 0.4 to enable run command with Alt+RET. No other solution identified.

Without custom configurations, C-j has always been "run" in the multiline editing mode.

Humm. No, because I would not have opened this issue ! This only works for me with C-j by default with 0.2.5.

[akinomyoga]

Huh? Everything is wrong. You seem to be already forgetting the original reason that you have opened the issue. The issue is not that "C-j cannot be used to run the command in the multiline editing mode". The original issue is that "the multiline command that has been dragged and dropped into Konsole is run unexpectedly." and is present in all of the versions of ble.sh from 0.1 to 0.4 including 0.2.5, and this is caused by the implementation of Konsole.

• If you want to work around the problem of Konsole's drag and drop, you need to rebind C-j in your configuration in all the versions of ble-0.1..0.4 including 0.2.5. In this case, you cannot use C-j to run the command in the multiline editing mode even in 0.2.5.
• If you don't need to work around the problem of Konsole's drag and drop, you can use any of ble-0.1..0.4 including 0.2.5 without any custom configurations. In this case, you can always run the command in the multiline editing mode by pressing C-j. Instead, the original problem of Konsole's drag and drop is present.

Anyway, all of the versions of ble.sh, 0.1..0.4, behave exactly the same in Konsole in this regard, and the difference you observe is just because of the difference in your configuration.

[ciranus]

You are right. Sorry for this 0.2.5 test disturbance. When discovering ble.sh few days ago, my first test was directly drag&drop of a function: it did not work. . first step : enable the multiline feature (stop breaking line by line) . second step: enable the run command. I did not test & notice before that C-j was OK by default when entering a function line by line. Anyway, it was an opportunity for me to discover that 0.2.5 feature level is enough for my need (with lower memory requirement).