X11 paste in IDE

Hi,

one very useful feature on X11 based systems is PRIMARY buffer. As soon as any text is selected it is copied to the buffer, then clicking mouse button 3 (often scroll wheel click) then pastes the buffer.

This is about an order of magnitude faster the all the right-click context menu cut and paste method.

Unfortunately neither the copy not the paste works with arduino IDE

This makes even minor editing of the code in the IDE window is much more labourious than it needs to be.

This feature is inherent to all X11 windows, so what is preventing this from working in the IDE?

Can it be fixed?

I didn't realise that. I usually use the keyboard for copy/paste (I find it faster than having to move a hand to the mouse). As the IDE is written in Java, I suspect it relates to that. A quick google suggests that, at least, some other Java based applications suffer the same problem (including some versions of Eclipse). jEdit on the Sun box I have here doesn't support middle-click paste. Even though it is standardised, I presume it still has to be implemented as a mouse click event.

I just use CTRL-C to copy and CTRL-V to paste. Seems quick enough.

Or Ctrl-Insert/Shift-Insert. Keyboard controls are usually quicker.

On Mac, I use x-style select for copy, and cmd-V for paste into arduino. There may be an additional cmd-C needed as well, connecting X paste buffers with Mac paste buffers presents interesting challenges. Probably true of windows as well.

CrossRoads:
I just use CTRL-C to copy and CTRL-V to paste. Seems quick enough.

Well it's better than going through the menus but if I'm selecting text it's almost sure that I'm doing it with the mouse, editing and shifting code around, or copying code from browser or other files. This is where X11 pasting is a huge time saver.

So rather than needing to pick up the mouse to do the paste it's a case of dropping the mouse to do
CTRL-V

I was forgetting the "IDE" was written in java. I'll have to dig a bit to see if it's a universal problem with java or a common java programming defect.

Thanks for the replies.

BTW the mouse copy-on-select does not work either.

f I'm selecting text it's almost sure that I'm doing it with the mouse

That's the difference. Almost all my editing is pretty much keyboard based.

dxw00d:

f I'm selecting text it's almost sure that I'm doing it with the mouse

That's the difference. Almost all my editing is pretty much keyboard based.

Trying to copy text from one window to another is hardly "editing." The sequence of buttons could either be
windows:

1.Select text on one window
2.Press "ctrl-c"
3.Click on other window
4.Press "ctrl-v"

X11:

1.Select text on one window
2.Middle click on other window

Ctrl-C, Ctrl-V easy enough to remember for me. And more likely to work in more places.
I don't see how just highlighting the text copies it into a paste buffer.

Trying to copy text from one window to another is hardly "editing."

Indeed, but as a generic term, 'editing' will do.

I don't see how just highlighting the text copies it into a paste buffer.

That's the way X11 has worked for, I dunno, 25 years or more?

I'm a keyboard kind of guy, but if you are already moving between windows to copy and paste, that implies a mouse (to select the "copy" text even if you use the keyboard to switch windows), which means you've got your finger on the trigger to paste, X11 style. Depending on your settings, you can select the target window and paste with a single click.

-j

This thread seems to have devolved into people who have used X11 saying how nice the middle click paste is and the people who haven't saying it seems useless/impossible.

I'm pretty sure there's nothing the IDE developers can do about this and that it should be reported upstream.

Which "upstream" would that be?

Here's a new twist. The error window of the IDE does support X11 c&p but does not respond to a right click to do it windows style off context menus.

This can not be laid at the door of java or anyone else it has to be arduino IDE.

(both windows work with control key sequences, apparently the only copy/paste method that was tested)

Since the official team have not fixed the disastrous heap allocation bugs in the two years since a fix was provided , I don't see much hope of this getting any attention.

I could be wrong, but it does not inspire hope.

Gotta remember, the Due will most probably need a new IDE, hopefully the standard arduinos go with it, hopefully they have considered a lot of what has been reported in its design. But yes its not java's fault.

This may be one form of getting things "upstream"

Wizened wrote:

I'm pretty sure there's nothing the IDE developers can do about this and that it should be reported upstream.

That's why I was asking what "upstream" he was referring to.

Thanks for the link to google code arduino but until there is some evidence that someone up there has a will to fix major defects like heap allocation problems and the numerous memory leaks in the official included libs, I will not be wasting time filing bugs.

I'm becoming rather disappointed with the quality of std libraries. It seems that in order to produce a reliable Arduino project it is necessary to vet every line of included code for this sort of careless mistake and/or trawl these forums for bugs and fixes.

All of which rather defeats the point of importing libraries of code.

@ardnut

what "disastrous heap allocation bug" you're referring to?

m

Presumably the one recently discussed here: http://arduino.cc/forum/index.php/topic,115552.0.html
and officially documented here: Google Code Archive - Long-term storage for Google Code Project Hosting.
and here, sort of: Google Code Archive - Long-term storage for Google Code Project Hosting.
It's a bug in the avr-libc that Arduino uses, rather than a bug in the arduino code itself. (The patch associated with 468 was apparently mostly applied in Arduino 1.0, but not the malloc() fix.)

Why not simply select "use external editor", and then use one of the many real programmers editors available under Linux? (Being an emacs guy, I use xemacs when I can, and plain ol' text based emacs when I can't.)

I also can't see how fixing X behaviour under Linux is going to become a pressing issue for the development team anytime soon. Given the long silences, I suspect they more than have their hands full with the over-Due (or perhaps it may even become known as the infamous "bit-off-more-than-they-could-Due" project.)

As is becoming the standard line around here -- we shall see.

Why not simply select "use external editor"

To do that you need to understand all the occult tricks the IDE does. Like making copies of files you include in a project and all the pre-compile voodoo. It's not a case of "simply select".

Then , why not use command line compiler ; then why not use avrdude command

... then remind me what is the IDE actually good for ?

ardnut:

Why not simply select "use external editor"

To do that you need to understand all the occult tricks the IDE does.

No, you don't have to understand anything more than using the IDE with the built-in editor (except how to use the external editor, of course.)

Like making copies of files you include in a project and all the pre-compile voodoo. It's not a case of "simply select".

No, it's exactly the same. It's just that the built-in editor window is read only, not editable. You edit the file in your external editor, and the IDE simply reloads it before each compilation.

Then , why not use command line compiler ; then why not use avrdude command

... then remind me what is the IDE actually good for ?

Ah, well, now there's a loaded question!

The IDE does three basic things: It edits, it preprocesses, and it controls the g++ build/avrdude upload process.

You can bypass the editor using external editor, as I have described.

That leaves two things the IDE does -- sketch preprocessing and build/upload.

It's true you can use "make" for example, to manage the build/upload, but then you "lose" the preprocessing.

Which may be a good thing or a bad thing, depending on your point of view.

The preprocessing only does three things for the user:

a) Obviates the need to declare your functions using prototypes.
b) Obviates the need to declare a main() function.
c) Manages merging the library source code into your sketch code using your #includes as indicators.

oh, yeah

d) Converts non-standard Arduino type "boolean" -> standard C++ type "bool".

so four things.

If you are willing to do a) and b) for yourself (oh yeah, and d)), then it's not too hard to get a Makefile that will do c) for you as well. (That's actually what I do -- see this thread for more details: http://arduino.cc/forum/index.php/topic,112425.0.html .) And then you are free of the IDE!

But, if you want to stay in sketch-land, and really find declaring those prototypes onerous, and really like writing "boolean" rather than "bool", then you need the IDE preprocessor.

Which, by the way, has some well-known and seriously screwy bugs that will result in mangling your perfectly sound sketch code into something that totally confuses the g++ compiler, and very likely you when you start trying to make sense of the resulting compiler error messages.

So that's what the IDE is good for. Not much when you look at it, I suppose, but you asked!