#111 Don't indent or wrap when pasting
When pasting text into the terminal, joe should not re-indent or re-wrap that text.
There is currently a similar feature in joe called "joexterm", but it requires xterm as terminal (I'm not aware of any other terminal supporting the required underlying feature of base64 paste), requires manually enabling the "joexterm" option which is harmful on other terminals, requires mouse support enabled, and then disables autoindent and wrapping if pasting text using the mouse.
There's a much more standard extension called "bracketed paste mode" supported by many terminals. It's safe to ask for this feature, causes no harm on terminals that don't support it. It has nothing to do with mouse support. If data is pasted by any means (no matter if it's mouse or hotkey), it's guarded by special marks so the application knows it's being pasted rather than typed in.
Please see my patch which adds support for this feature.
Official doc about the feature is at
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#Bracketed%20Paste%20Mode
Currently supported by at least xterm, vte (gnome-terminal etc.), urxvt, putty, Terminal.app, iTerm2; probably many others. Patch for konsole pending.
Egmont,
I've made a couple of changes: handle the terminator better, and only conditionally initialize t->brp/bre (I mimicked a little bit of bash's logic with some of JOE's). Could you have a look at them before I check in?
On a completely unrelated side note, this gave me fits. PuTTY supports bracketed paste, but it was slooooow. I couldn't tell where the problem was because ^\ + bracketed paste (to bypass 'brpaste') was quite fast. Turns out PuTTY throttles sending the paste if it doesn't receive packets. If I output simple cursor movements (back, fwd) on each iteration, you'd swear it was a native paste. Anyway hope that explains the delay on this one =p
Thanks -jj
Hi John,
"I mimicked a little bit of bash's logic" - what do you mean exactly? Bash doesn't seem to have bracketed paste mode, am I wrong?
I don't understand this "ansiish" thing, and also, does it ever really happen that an escape sequence is started by a literal backslash followed by a literal uppercase E?
The assignment to ansiish and to t->brp/bre seem to be swapped, one gets this weird literal backslash-E for "ifndef TERMINFO", the other gets it for "ifdef TERMINFO".
It just occurred to me that it's quite ugly to take the start string of bracketed paste from the config file, and the terminating one hardcoded in the source. It's a problem with my patch, of course. I'll take a look if it can be improved.
I'm so glad you dropped in as a new maintainer of joe, Welcome :) I'll try to take a closer look on this tomorrow.
Last edit: Egmont Koblinger 2014-11-15
I should read things I find on the internet more carefully. I found this email thread on bash and readline: https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00211.html -- I'm not sure whether that ever made it to the master. Note the "ANSI-ish" comments about halfway down. The main difference is it's checking 'te'.
JOE already has some logic where it sets up color support based on whether a terminal looks like it's ANSI, right below where I set bre/brp. I just did a little refactoring.
Thanks, I got the #ifdef's backwards. I knew I'd miss something like that. The other thing I forgot was to ask whether overtype should be handled the same way as wordwrap, etc.
(The "\E" thing is termcap format and will get converted to '\033' by escape1 in texec)
It would be possible to have the two commands: one to basically push wordwrap/autoindent/spaces state onto a stack and the other to pop it. But that means a very different route for the input. Each key goes through the full editor loop, gets a screen update and is potentially handled as key sequences. Your patch does the same as jhallen's old xterm patch, and I'd tend to trust his judgment here. On the other hand, it would shore up the issue I saw with PuTTY and "^[X brpaste" would be less detrimental.
The other approach is to write directly into the buffer with binsc and pfwrd. I gave this one a shot, but I wound up duplicating a bunch of logic from utypebw.
Lastly, I'm not the new maintainer. Joe is still around, he even made some commits a few weeks ago. I've just got some time on my hands to try and clear up the backlog a little bit and merge some of the changes I've made locally over the past couple years.
Cheers -jj
The bash feature is so brand new that I haven't heard about it, thanks for the heads up! It made it into bash master, unfortunately disabled by default. The "te" workaround is a bit of a hack, but it's okay.
The bash patch also lets you configure the begninning 200~ sequence in inputrc, but the trailing one is hardcoded to 201~. It's ugly, but makes me too lazy to change this in joe ;)
I tried your patch, changing #ifdef (above t->brp assignment) to #ifndef, and it works.
I can't reproduce the slowness with local pterm, or putty to localhost. Even if it's a putty bug, I'd argue it's their fault and they should fix it rather than joe providing a workaround.
"Each key goes through the full editor loop, [...] and is potentially handled as key sequences" -- this is something we must avoid, and is the very reason for bash receiving this feature. See e.g. https://bugzilla.gnome.org/show_bug.cgi?id=697571 . Pasting data from untrusted source (e.g. a malicious webpage, containing control characters and such) must never trigger joe commands.
"The other thing I forgot was to ask whether overtype should be handled the same way as wordwrap, etc." - There's no clear hardwired rule on what to do. In my opinion, autoindent should be disabled to avoid the staircase effect (I'm 100% firm here), probably wordwrapping should be disabled (probably yes, but depends on the use case), I'm not sure about any automatic tab<->space conversion (if joe has any), and really not sure if overtype should be disabled or not. Maybe a weak "no" vote goes for disabling overtype.
Last edit: Egmont Koblinger 2014-11-16
I'd say we're pretty much in agreement then. I'll commit the updated patch tomorrow probably. Thanks!
In the mean time, I recommend removing the obsolete "joexterm" and corresponding "paste64" features, including the xterm-{patch,readme} files.
The patch only applies on top of an ancient xterm. By now I believe everyone uses either a much newer version of xterm (where the patch doesn't apply cleanly), or another emulator. I really doubt more than 1 or 2 people in the world would bother patching and compiling their own xterm for joe's sake, and I don't think any distribution ships xterm with this patch.
Bracketed paste mode offers a cleaner, mainstream solution that works out of the box on most terminals. The extended mouse support allows to have arbitrary mouse coordinates, not only up to 208.
I'm not sure what the intent with offscreen mouse coordinates was and how joe was using them, it's indeed something we lose for good.
Agree. I was going to add a task to pull all that stuff out once this one is checked in :-).
For the record, the offscreen mouse coordinates facilitated auto-scrolling, so that dragging off the side of the window (vertically) automatically scrolls the buffer at an interval. You can still achieve this if you have multiple windows open, and it works in the up direction because of the status line. But you're right, it's a rare case that anyone would apply it.
This is a really cool idea.
Recently I've been doing tons of gnome-terminal development, and was in touch with xterm's developer and contributed to some other terminals too. I'll raise this idea as a feature request. If he accepts and puts it in xterm, it'll probably be quite easy to get it into some of the most popular emulators.
The new 1006 mouse extension encodes positions in decimal, (1,1) being the top left. We can safely extend this protocol without breaking it to report offscreen values (even if some ANSI framework disallows the usage of negative values, we still can report 0 which is much better than nothing).
That's awesome, I didn't realize we had an 'in' over there :-).
I would recommend that you open a ticket here in case any major developments happen on the other end of this, so you have a place to report them (and we can track them). However, I don't intend to remove the autoscroller so I think JOE ought to work out of the box if this change is taken on by the terminal emulator maintainers (outside of maybe parsing negative coordinates, if that route is chosen).
Also this one will close shortly. I've just pushed.
Patch applied in [e7a1ad]. Thanks!
Related
Commit: [e7a1ad]