X11 paste in IDE

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". :roll_eyes:

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! :slight_smile:

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!

The thing is (unless you go the whole way and drop using IDE, which is looking more and more appealing) you need to understand all the preprocessing and file copying tricks in order to put you externally edited files where IDE wants them, not just #include them which, as I have just discovered, gets them ignored if the included file is not open in a "tab" in the IDE. :cold_sweat:

It's actually more trouble learning all the, not so clearly documented, tricks you need to work around.

That's why I said, it's not a case of "simply select".

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.

Yep, I met that one as well.

You've confirmed my impression that sketchland is more of a hinderance than a help and that I'm not missing some stunningly useful functionality.

Can you post an example Makefile , that would save me some head scratching.

thx.

I think an article somewhere on how do all of this straight off the bat would be a good idea at some point once I've mastered it a bit better.

Adding a section on Nick's work around for the heap allocation problem and we may be near to a workable development environment.

Here's an example makefile, to give you some idea:

ARDUINO_SHELL_DIR = \Arduino\arduino-0023
ARDUINO_DIR  = \Arduino\arduino-0023

PERL_EXE = \strawberry\perl\bin\perl
TARGET       = dht22_test3a
ARDUINO_LIBS = DHTxx2

BOARD_TAG    = pro5v328
ARDUINO_PORT = \\.\COM14

ARDUINO_MAKE = \Arduino\make\arduino-mk-0.8

include $(ARDUINO_MAKE)\Arduino-W32.mk

#
# Hopefully these will be self-explanatory but in case they're not:
#
#    ARDUINO_DIR  - Where the Arduino software has been unpacked
#
#    TARGET       - The basename used for the final files. Canonically
#                   this would match the .pde file, but it's not needed
#                   here: you could always set it to xx if you wanted!
#
#    ARDUINO_LIBS - A list of any libraries used by the sketch (we
#                   assume these are in
#                   $(ARDUINO_DIR)/libraries 
#
#    ARDUINO_PORT - The serial port where the Arduino can be found (only needed
#                   when uploading
#
#    BOARD_TAG    - The ard-parse-boards tag for the board e.g. uno or mega
#                   'make show_boards' shows a list
#
# You might also want to specify these, but normally they'll be read from the
# boards.txt file i.e. implied by BOARD_TAG
#
#    MCU,F_CPU    - The target processor description

Read that thread I pointed to, it has links to downloading Martin Oldfield's makefiles, which do all the "voodoo", but in make scripts instead of hard-coded Java in the IDE. He's done all the hard yards on this. The simple config file above is all the users (e.g., you and I) have left to do. Oh, and type "make" at the command prompt.

But before you dive into all that, I suggest first just trying out the "external editor" check-box option. Just to prove you really don't have to use the makefiles to use the IDE in external editor mode, you just press the build/upload button on the IDE and it does its usual build voodoo.

One step at a time -- flexibility is good.

BTW, one thing that's good about the makefiles is that is also demystifies the "voodoo" a bit. It's all pretty mundane what's going on, really.

Edit: Oh, in case you are wondering why I use backslashes rather than forward slashes in the example script, it is because I used this script for a Windows XP installation of the Arduino 0023 environment. Martin Oldfield's scripts are actually Unix/Linux oriented -- I did a little bit of "porting" of his scripts to cajole them to work under Windows with Msys.

But before you dive into all that, I suggest first just trying out the "external editor" check-box option. Just to prove you really don't have to use the makefiles to use the IDE in external editor mode, you just press the build/upload button on the IDE and it does its usual build voodoo.

Yes, I looked at external editor but to do that you need to know all the tricks the IDE is doing , like moving files somewhere else before compiling.

I recently got stuffed because I referenced a file in #include and put it in the sketch directory but it was not in a "tab". This did not even flag missing (missing by the time the sketch got silently copied elsewhere) but failed because a function in the (not) included file was not defined.

That means in order to work with an external editor I need to know the ins and outs of the build voodoo.

That seems a pointless effort to me.

Better spend the time setting up a Makefile so that I have a predictable , well-behaved development env.

Thanks for the posted file and the links that should save me some time.

:slight_smile:

ardnut:
Yes, I looked at external editor but to do that you need to know all the tricks the IDE is doing , like moving files somewhere else before compiling.

No, really, you don't. You just press the build button and it does it's "voodoo" just as if the sketch had been edited in the IDE editor. (The only difference is you have to remember to save the file to disk before pressing the compile button, unlike using the IDE editor!)

ardnut:
I recently got stuffed because I referenced a file in #include and put it in the sketch directory but it was not in a "tab". This did not even flag missing (missing by the time the sketch got silently copied elsewhere) but failed because a function in the (not) included file was not defined.

What was the extension of the file? I've read (but haven't yet verified) that in 1.0.1, only .h and .cpp files can now be included by a #include directive from within a sketch (who knows why... the Arduino team seem hell-bent on doing all they can to subvert the expected and otherwise well-defined behaviour of the venerable C preprocessor.)

ardnut:
That means in order to work with an external editor I need to know the ins and outs of the build voodoo.

No really, whatever the problem was, it was independent of using an external editor, or not.

ardnut:
That seems a pointless effort to me.

Better spend the time setting up a Makefile so that I have a predictable , well-behaved development env.

I agree that ultimately going with the makefiles is a better and saner way to go, but it is never pointless effort to try to understand what's really going on with your tools. As I said earlier, one of the advantanges of using the makefiles is that it demystifies the build process a great deal.

ardnut:
Thanks for the posted file and the links that should save me some time.

:slight_smile:

No probs, good luck!

What was the extension of the file? I've read (but haven't yet verified) that in 1.0.1, only .h and .cpp files can now be included by a #include directive from within a sketch (who knows why... the Arduino team seem hell-bent on doing all they can to subvert the expected and otherwise well-defined behaviour of the venerable C preprocessor.)

Well there you go. It was a .c file. How the hell is anyone supposed to follow that kind of behaviour?

This is getting so reminiscent of MS mentality I'm ready to puke.

Dumb down the user and make things "easy" to the point where actually doing what you need to get done gets 10 times more difficult.

If they think they can do this in a micro-controller hardware design environment .... words fail me.

I was initially quite impressed when I read they provided an open source IDE. Then I found out it was not really an IDE , then I found out it was more hindrance than anything else.

Hopefully I'll stop wasting so much time chasing oddball behaviours once set up with Make.

Just have to hope I can write a function prototype without my IDE nanny. :wink:

It is even possible to make X11 style (mouse only) copy and paste work to/from Java-swing based applications?