Ticket #67 (assigned enhancement)

Opened 12 years ago

Last modified 4 years ago

savannah: x selection in editor

Reported by: me4mc Owned by:
Priority: major Milestone: Future Releases
Component: mcedit Version: master
Keywords: Cc: zaytsev, gotar@…
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description (last modified by ossi) (diff)

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

Submitted by:me <me4mc>Submitted on:Sat 21 Apr 2007 10:25:44 AM UTC
Category:EditorSeverity:3 - Normal
Assigned to:NoneOpen/Closed:Open
Release:4.6.1Operating 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");

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

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


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)

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:

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

with patch, or using nano or cat:


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


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 ?


12559-mc-4.6.1-xselect-editcolor.patch (357 bytes) - added by slavazanko 12 years ago.
added by me4mc
12560-mc-4.6.1-xselect-editcolorc.patch (317 bytes) - added by slavazanko 12 years ago.
added by me4mc
12561-mc-4.6.1-xselect-edit-cleanline.patch (433 bytes) - added by slavazanko 12 years ago.
added by me4mc

Change History

Changed 12 years ago by slavazanko

added by me4mc

Changed 12 years ago by slavazanko

added by me4mc

Changed 12 years ago by slavazanko

added by me4mc

comment:1 Changed 12 years ago by 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.

comment:2 Changed 11 years ago by styx

  • Milestone set to future releases

comment:3 Changed 11 years ago by angel_il

  • severity set to no branch
  • Milestone changed from future releases to 4.7.0-pre3

comment:4 Changed 11 years ago by angel_il

  • Milestone changed from 4.7.0-pre3 to 4.7.0-pre4

comment:5 Changed 11 years ago by angel_il

  • Status changed from new to accepted
  • Owner set to angel_il
  • Milestone changed from 4.7.0-pre4 to 4.7.0-pre5

comment:6 Changed 11 years ago by angel_il

  • Milestone changed from 4.7.0 to 4.7

comment:7 Changed 10 years ago by ossi

i would close this as wontfix.

comment:8 Changed 10 years ago by zaytsev

  • Cc zaytsev added
  • Version set to master

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

comment:9 Changed 10 years ago by 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.

comment:10 Changed 10 years ago by ossi

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

comment:11 Changed 10 years ago by 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'

comment:12 Changed 10 years ago by 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 ... ;)

comment:13 Changed 10 years ago by 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

comment:14 Changed 10 years ago by angel_il

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

comment:15 Changed 10 years ago by 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).

comment:16 Changed 10 years ago by 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.

comment:17 Changed 10 years ago by gotar

  • Cc gotar@… added

comment:18 Changed 10 years ago by 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..

comment:19 Changed 9 years ago by andrew_b

  • Branch state set to no branch
  • Milestone changed from 4.7 to Future Releases

comment:20 Changed 7 years ago by ossi

  • Description modified (diff)
  • Reporter changed from slavazanko to me4mc

comment:21 Changed 4 years ago by andrew_b

  • Status changed from accepted to assigned
  • Owner angel_il deleted
Note: See TracTickets for help on using tickets.