savannah: x selection in editor

[me4mc]

Original: ​http://savannah.gnu.org/bugs/?19651

Submitted by:	me <me4mc>	Submitted on:	Sat 21 Apr 2007 10:25:44 AM UTC
Category:	Editor	Severity:	3 - Normal
Status:	None	Privacy:	Public
Assigned to:	None	Open/Closed:	Open
Release:	4.6.1	Operating System:	GNU/Hurd

Original submission:

i managed to find another x problem:
when you are in the *term and select some text all newlines are lost
 and filled up with spaces.

i managed to find the problem in the
editordraw.c in print_to_widget
the hline draws blanks at the rest of the line.

i understand that behaviour but there is a possibility to do this right:

SLtt_set_color (DEFAULT_COLOR_INDEX, NULL, "default", "default");
SLsmg_erase_eol();
or
clrtoeol()

however, i tryed to create that behaviour and failed because i 
cannot set the default color index (0) to blue/white.
the problem is that users with other color settings (me: 
black/green) could be angy if i hardcode blue/white

the default state is black/white - looks ugly but works.

if you could suggest how to properly set the fg/bg

should i create a new function in src/color.h?

any suggestions? 

Comment 1 by Pavel Tsekov <ptsekov> at Sat 21 Apr 2007 11:20:23 AM UTC:

Please, calm down. Finding a problem is the easy part - describing 
it properly, so that others can reproduce it, is of great importance
 if you want to get the problem solved.

From you bug report it is clear that you see some problem related 
the way copy/paste works in relation to the internal editor. 
However, I cannot understand what is actually wrong - please, do the
 following:

1) explain what do you do - copy/paste from where to where ?
2) explain what happens
3) explain what do you expect to happen

Comment 2 by Oswald Buddenhagen <ossi> at Sat 21 Apr 2007 11:41:25 AM UTC:

i understood immediately what he means. :-P

me: you can configure most *terms to strip trailing whitespace from 
the selection. without this, i would have freaked out long ago. :)

Comment 3 by me <me4mc> at Sun 22 Apr 2007 09:22:16 AM UTC:

i dont like the idea of changing the terminal just because a 
application misbehaves. my workarround for several years is to cat 
the current file - hopefully it's not a 60M log...

therefore created a patch (that only works for slang and mc 4.6.1) 
that uses a clear eol function to perform the action of clearing the
rest of the current line.
selection works fine for me now, but the display flickers on 
movement - something i can handle

@pavel: did you even read the post? the solution was in it - i hope 
in future we can improve understanding!

to make it work as described i had to create a new function in 
color.c&h that resets the color index 0. if anything simmilar exists
 please adopt the idea.

i dont care if this ever ends up in the main tree - it would save me
 the trouble of patching. once a year..

gentoo ebuild with use flag in testing phase maybe apears in sunrise
 overlay

peace
me

Comment 4 by Pavel Tsekov <ptsekov> at Sun 22 Apr 2007 09:31:31 AM UTC:

Is it so hard to write a proper bug report ? I want to reproduce the
 problem myself and I couldn't - I failed because the lack of 
information. It is not correct to assume that everything has the 
same problem as you do. And how can I apply a patch if I do not 
understand what's going on.

I am sure Oswald can explain the problem to me but after all it is 
up to the submitter to describe the bug it sees.

Comment 5 by me <me4mc> at Sun 22 Apr 2007 09:50:04 AM UTC:

yes it is!
because it is a feature that already works in other situations 
(single line)

reproduce:
start xterm
start mc in xterm
go to a file with newlines (eg COPYING)
edit it (F4)

press SHIFT and click-select some content over lines, do NOT use the
 mc cooledit buffer.

paste the selected text (using MIDDLE mouse) in a application like 
email or in the same editor, notice the blanks.

try the same if you cat the file on the terminal and notice that no 
blanks are in the other app:

example:
without patch (sorry bad to see)
SOL>
<EOL
SOL> Preamble
<- EOL
SOL> <EOL

with patch, or using nano or cat:

<EOL
Preamble<EOL
<EOL

i know that there are many terminals arround - maybe xterm isnt a 
good choice - maybe i have no choice at all

peace

Comment 6 by me <me4mc> at Sun 22 Apr 2007 09:56:32 AM UTC:

mhh i browsed this menu @savannah and found that there is a 
difference between patch and bug and the bugs i submitted could have
 been patches - sorry for the trouble that might have caused, will 
use patches in future

Comment 7 by me <me4mc> at Sun 22 Apr 2007 09:32:43 PM UTC:

bug in a bugfix...
i noticed bad flicker in the console and realized that the setcolor 
function does force a screen redraw.

therefore i moved its call to edit.c init()

now i get a green blinking _ in the console (no X) when i quit mc - 
much less anoying than the flicker.

any suggestions how to fix that?

Comment 8 by Pavel Tsekov <ptsekov> at Thu 26 Apr 2007 04:16:10 PM UTC:

Does it help if you disable "Return does autoindent" from
Options -> General in the editor ?

[slavazanko]

added by me4mc

[slavazanko]

added by me4mc

[slavazanko]

added by me4mc

[slavazanko]

Does it help if you disable "Return does autoindent" from
Options -> General in the editor ?

In 4.6.3 was added hotkey ALT+i for toggle "Return does autoindent" checkbox.

[ossi]

i would close this as wontfix.

[zaytsev]

I think it's not bad to have it implemented one day, e.g. for the pour souls using gnome-terminal.

[angel_il]

ossi: use external clipboard utility, like 'xclip'
now you can set xclip for insert data from/into X clipboard. Please read man for more info.

[ossi]

ilya: that ticket is about selection, not clipboard (as mc uses it, anyway). entirely unrelated.

[angel_il]

you right, but but if you insert text from the X clipboard using the utility 'xclip' (#30) do not have to worry about 'autoindent'

[ossi]

that won't work too well if the target application doesn't support the x clipboard natively (like xterm) - then you'd have to rely on a clipboard/selection synchronizer like klipper, or even play with xclip on the command line. this isn't something we'd want to force upon the poor dwarf-term users, right? hey, wait ... mwahaha ... ;)

[angel_il]

ok, it works in xterm and putty, all you need is set DISPLAY and clipboard_store=xclip -i clipboard_paste=xclip -o into ~/.mc/ini

[angel_il]

if you not have xclip or DISPLAY is not set then all will work as usual

[ossi]

huh, you're right ... xclip defaults to PRIMARY, not CLIPBOARD. how confusing ...

which makes for an interesting problem in itself: if we ever choose to make the x selection directly follow the mc selection, we'd have to use PRIMARY for *that*, which means that the clipboard functions would suddenly move to CLIPBOARD (relative to the example which is in the manual now).

[zaytsev]

Ilia: This ticket is tangential to what you are talking about.

I understand that whenever you use new clipboard integration via xclip you don't have this issue by definition, but if you don't have it and use normal terminal copy functions, what happens is that you get redundant spaces running till EOL in your buffer.

The ticket starter has figured out a way of setting the background, without actually printing white space into the terminal. This way, no matter which terminal you are using, if you just copy and paste using terminal built-in functions you will NOT have any extra spaces in your buffer.

That's why I said that using new clipboard integration from #30 does help, but this feature is nice to have anyway.

[angel_il]

ok, i dont confirm pasting extra spaces from buffer... i try xterm, terminal, putty and couldn't reproduce the problem .
please say how to reproduce paste extra spaces after copy, step by step..