[Konsole-devel] [Bug 89299] prevent paste of newline characters

[reeted at shiftmail.org]

https://bugs.kde.org/show_bug.cgi?id=89299


reeted at shiftmail.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reeted at shiftmail.org




--- Comment #41 from  <reeted shiftmail org>  2011-10-02 22:12:55 ---

Dear sirs, I was directed here from the mailing list. 

On the mailing list I had proposed a different way to tackle this problem,
which I think is better.
After reading the comments in this bug page I have also re-elaborated a bit, so
here it is, improved version:

The Konsole-devel team should create a new (configurable) hotkey for "paste
without newlines".  This one should be used preferably by most users, while the
normal "paste" hotkey, which would retain its current behaviour, would be used
only when users are "really really sure" of what they are doing. [*]

In order to "be really really sure", prior to use the normal "paste", the users
could e.g. make a test paste onto a text editor to check what the buffer really
contains. But the need to do this would be very rare because the "paste without
newlines" can do most things already.

For the internal behaviour of "paste without newlines" hotkey, I think that the
best approach is probably to replace a newline with the sequence "; \\n", that
is: semicolon, space, backslash, newline. If there is a \r\n probably the \r
should be removed in advance, and then the above replacement for \n should be
performed. Also tabs at the beginning of lines should be removed or better
replaced with spaces (see below).

This replacement sequence has the advantage that it can be used to paste a
multiline script into vi or nano without altering the meaning [**], but it can
also be used in bash for obtaining something visually very similar to what is
copied (so that the user can immediately see whether he has pasted the correct
thing or not without re-parsing with the eyes), and which also maintains the
meaning, but does not execute automatically.

However, since I foresee that the decision of the exact newline replacement
sequence can cause a flame-war and also seems to be an important matter because
a wrong decision can drop the usage of the new hotkey from 99% to 85%... (=15
times more chances for a mistake) I can suggest that the replacement sequence
for that hotkey should be made customizable.

If you want to provide a customizable replacement sequence for this "paste
without newlines" hotkey, I recommend the following two fields to be put in the
Profiles-configuration:
- field#1: characters to be removed
- field#2: characters which should replace the newline

Pay attention now: you might think deciding field#1 be easy, while field#2 be
more difficult, but it's not so. Deciding field#1 is actually more difficult.

In field#1 I believe most people would want "\r\t" so to remove both CR and TAB
(each of them placed anywhere on the string, even multiple times). The reason
for tab, *VERY IMPORTANT*, is that if a line starts with \t (can happen when
copying loops from bash scripts) bash starts the command completion routine and
this wreaks havoc on the multiline script. Execution would *NOT* be correct.

To understand what I mean, paste this mini-script into bash (I don't know if
this bugzilla allows me tabs... the second line has 2 tabs in front of it,
please reproduce it in Kate):
#------start------
echo foo; \
        echo bar; \
echo baz
#------end------
output == "foo\nbaz\n" and no "bar" output, i.e. it doesn't work.
That's why you also need \t deletion or replacement with spaces.

*BUT* users of Python wouldn't probably want "\t" to be there, because in
Python the tabs have a meaning and should be kept. 
However in python interactive shell it can still be very difficult to use this
hotkey effectively for multiple lines, due to the newlines and indentation both
being basically required by the language, so Python users might give up on
trying to use the "paste without newlines" when in python interactive shell,
and use the standard "paste" there. And hence again they might still want \t to
be present in field#1 for a better use within Bash.

A better handling of \t would be replacing that with a customizable number of
spaces, and only if it is at the beginning of a line. This requires a separate
customization field, but would retain the visual indentation and thus enhance
the similarity of the pasted content to the original one, so that the konsole
user can more easily check that what is being pasted is really what s/he
intended.

In field#2 I would put "; \\n" so that the script retains its visual shape, but
other people might want just "; " so as I said there is no one size fits all.
(please note that the second version still doesn't improve python interactive
shell use)

So this is my vote to make it customizable. 
Or if you really don't want to, my vote goes for a fixed configuration of:
field#1="\t\r" and field#2="; \\n".


Regarding the paste via middle-click, I have disabled it via xmodmap (xorg). It
was too dangerous to have two buffers imho, too error-prone, too many times I
was pasting from the wrong one, and with the newlines enabled it would go
executing immediately. However if you would map the middleclick to the
algorithm of "paste without newlines", but using text from the x11's
selection-buffer, I would re-enable it.


[*] In order to make the former the default, you could set the keys so that
from the next version of konsole the default keys used for "paste" (shift-ins)
now become the default keys for "paste without newlines"; and standard "paste"
hotkey now gets a more complicated set of keys by default such as
alt-shift-ins.

[**] I would discourage the use of the standard "paste" hotkey even in vi/nano,
or you will learn to use it, and you will eventually use it also in bash by
mistake. So the new "paste without newlines" should try to replace "paste" as
much as possible in most environments, such as at least bash and vi/nano,
possibly also python interactive shell, etc.

Thank you

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.