Hello, On Sun, 15 Sep 2013 12:16:53 -0400 Felix Miata <mrma...@earthlink.net> wrote:
> http://lists.opensuse.org/opensuse-kde/2013-09/msg00072.html seems to > describe a bug in mc-edit. Is the responder there correct that > auto-indent switched off would stop the bad behavior? Should it need > to be? Adding all those spaces and/or tabs doesn't make any sense to > me regardless of how line endings are handled. I've been having that problem for ages - with Gnome though. If you think about it, it's "logical", assuming pasting is handled by terminal emulator, and not mc itself. And term emu can only implement pasting by sending pasted content as key presses, including spaces and tab, and mcedit, with autoindent on, has no idea that it's something else but keypresses, so blindly applies autoindent as usual. So, long ago I indeed worked that around by going to setting and turning autoindent off then on (boring!). Then however I noticed that depending on the way you paste you may be able to work it around by several paste attempts. For example, Gnome terminal has 3 ways to paste: menu command, Ctrl+Shift+V, Shift+Ins. So far, my background pattern matcher didn't find exact rule what works better, it seems to be just non-deterministic, though intuitively, Shift+Ins appear to work better. The way to resolve it would be to handle paste on mc side, and knowing that mc already has some X integration, I may imagine, when Shift+Ins works, that's what happens. The culprit is that it doesn't work all the time and with all paste methods. Which probably partly due to braindead X clipboard design (multiple buffers, etc). -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel