On 7 May 2011 09:05, Eugenio Rustico jfrusciante@tiscali.it wrote:

2011/5/7 Lex Trotman elextr@gmail.com:

...

Sorry you are going to have to be more specific, exactly what does the build menu look like? Which menu item are you choosing that runs a make instead of a compile?

In the build menu I see: make, compile custom target, compile (there is no "build" item); all these three launch a "make" command.

So why do you think that the [build_menu ] settings worked if it isn't in the menu?

Cheers Lex

Eugenio _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany

On 7 May 2011 09:40, Eugenio Rustico jfrusciante@tiscali.it wrote:

2011/5/7 Lex Trotman elextr@gmail.com:

...

...

In the build menu I see: make, compile custom target, compile (there is no "build" item); all these three launch a "make" command.

So why do you think that the [build_menu ] settings worked if it isn't in the menu?

Above the standards, I see "nvcc" voice, working (it executes nvcc as I specified in the config). I was listing the "standard" build commends. After those, there are "next error", "prev error", "execute" and so on.

Which voice is supposed to execute the commands specified in [build_settings]? "Compile" (that insteads calls a make) and "Build" (but I see no build voice when a .cu file is loaded)?

Basically you shouldn't mix the two sets of build settings. Geany will try to combine them in a sensible manner, but as their semantics differ, it doesn't always work.

You should define all your menu and the commands using [build_menu]. The cheats method is to remove all build settings from your cu filetype file load a cu file in Geany then define the menu in the Set build Commands dialog, close Geany (unless you are using the *very* latest SVN) and the settings will be written to your user cu filetype file.

As to why your make object menu item has changed name to compile, see if it has been edited in the set build commands dialog (click on clear to return to the default).

Cheers Lex

On 7 May 2011 19:56, Eugenio Rustico jfrusciante@tiscali.it wrote:

I removed the [build_settings] and [build-menu] sections in $HOME/.config/geany/filedefs/filetypes.CUDA.conf; then I open geany with

geany tex.cu

and in "Set build commands" dialog I set a new one in "CUDA file commands" section (nvcc -o "%e.o" %f). This makes the trick, i.e. after closing geany there is a new section in my filetype:

[build-menu]    FT_00_LB=Compila con nvcc    FT_00_CM=nvcc -o "%e.o" %f    FT_00_WD=

However, if I change the default "compile object" command, in "Independent Commands" section, this setting is not written to the config file and, above all, it seems to be a global setting (i.e. if I open a normal .cc file afterwards, the setting remains "nvcc", while it should be g++ again). I guess this is the right behaviour in design.

Yes, they are called "independent commands" because they are independent of the filetype :-)

So they are stored in the user preferences, not in any filetype file.

These three commands are not normally compile commands, they normally default to being called "Make", "Make Custom target" and "Make object" and by default they run make not a compile command. That is why they are independent of the filetype, because make uses the makefile and doesn't care about the types of the source files.

Are you using a translated version, maybe there is an error or misunderstanding in the translation that makes it read "compile object"?

So, there is no way to change the default compile command (to have the same shortcut) only for a specific filetype? Wasn't the "compiler" option in the filetype definition meant for this?

The settings in the [build settings] group applied to pre- 0.19 Geany and set the commands for the three filetype commands. With Geany 0.19 and later these are only loaded if no [build_menu] commands exist. This meant that all the filetype files didn't need to be re-written all at once, and in fact very few have been done yet. But as I said before mixing the two groups in the same file may not work well.

No commands set in the filetype files in either [build_settings] or [build_menu] affect the filetype independent commands.

Same question in a different way: I have to redistribute my filetype definition. Can i set somewhere that I want to compile any .cu file with nvcc without creating an additional voice in build menu (so that, for example, the compile object shortcut is the same for .cc and .cu files)?

By default the compile command is the first filetype command, which is what you have defined with the [build_menu] settings saved above. In the C filetype that is also the case even though the system filetype.c uses the old [build_settings], so the shortcut will be the same, by default F8.

Cheers Lex

On 7 May 2011 23:48, Eugenio Rustico jfrusciante@tiscali.it wrote:

2011/5/7 Lex Trotman elextr@gmail.com:

...

No commands set in the filetype files in either [build_settings] or [build_menu] affect the filetype independent commands.

By default the compile command is the first filetype command, which is what you have defined with the [build_menu] settings saved above.  In the C filetype that is also the case even though the system filetype.c uses the old [build_settings], so the shortcut will be the same, by default F8.

Ok, thank you, it's much clearer now. May I suggest you to be such clear also in documentation? :)

Writing documentation about something one understands for people who don't understand is difficult, one doesn't know what they don't understand, so patches are welcome.

Yes, I have translated interface, and it's causing confusion. I think it might need some improvements, I'll subscribe to the translators mailing; in the while, I'll switch to english.

Is there any other way than exporting LANG env var? I often use command line... is there any way to disable at all a locale?

Not that I know of.

Cheers Lex

Well what do you think that documentation is for - if not to teach. No bloody use in writing documentation for an audience that already know the product, is there? When you write documentation, you always assume that the reader knows nothing about your product! If that's true, the reader will thank you! If it's not the reader will scan the document until he finds something of interest, or leave it alone altogether.

Of course documentation is intended to provide information about the software, but a program like Geany has a wide range of users, and something that appears crystal clear to the writer may be totally opaque to a reader with different language, cultural, or background knowledge, or experience. Not to mention the delightful imprecision of the English language.

This is an open source project so why don't you put your time where your mouth is and produce improvements to the documentation instead of criticising those who use their time to provide products to share.

You could separate the documentation into reference documentation which presumes a level of expertise and does not teach and user/tutorial material for beginners which does teach.

Cheers Lex

Dnia niedziela, 8 maja 2011 o 03:37:52 Duke Normandin napisał(a):

Well what do you think that documentation is for - if not to teach.

Note: * Internet Explorer and Mozilla Firefox assume that you know what Web is and what a Web browser is. * Open Office assumes that you know the art of typesetting documents. * GCC assumes that you know how to program in C.

And so on. While this practice may be viewed as deplorable, it is a rather common assumption. A book that you should read first is rarely included in materials accompanying software because you are expected to learn what is in the book before doing anything serious, and when you already have, you do not need the book any more.

Of course, there are positive examples also; I would mention the MIT X Window System and Sun’s Java, both providing excellent introductory material. This was, however, long ago.

Chris

Ok guys, I'm sorry this little "flame" started somehow from my request for a clearer documentation. Hopefully, I found a concrete suggestion by rethinking aboud my impact with filedefs.

I read the docs more deeply, and after the explanation of Lex's it seems to me everything is explained. I think I understand what confused me at the beginning: the fact that I copied the cpp filedef, replaced the word "g++" with "nvcc" and didn't see nvcc anywhere in geany.

So, a little improvement may be to specify inside the filedef that the [build_settings] is somehow obsolete. One that does not read fully documentation, or that reads the documentation after a practical trial (shame on me), will change the compiler command and will see no effect at all.

My 2 cents

Cheers Eugenio

PS: little offtopic but quick: is it planned to detect when multiple files are changed on disk? When I work with a versioning system, and all files of my project change, it is a bit annoying to have one confirmation dialog for each single file (and cancel button having focus by default)...

2011/5/8 Lex Trotman elextr@gmail.com:

On 8 May 2011 16:51, Křištof Želechovski giecrilj@stegny.2a.pl wrote:

...

Dnia niedziela, 8 maja 2011 o 03:37:52 Duke Normandin napisał(a):

...

Well what do you think that documentation is for - if not to teach.

Note:   * Internet Explorer and Mozilla Firefox assume that you know what Web is and what a Web browser is.  * Open Office assumes that you know the art of typesetting documents.  * GCC assumes that you know how to program in C.

And so on.  While this practice may be viewed as deplorable, it is a rather common assumption.  A book that you should read first is rarely included in materials accompanying software because you are expected to learn what is in the book before doing anything serious, and when you already have, you do not need the book any more.

Hi Chris,

Its perhaps a little harsh to call it deplorable, more an assumption of the audience for the document.

...

Of course, there are positive examples also; I would mention the MIT X Window System and Sun’s Java, both providing excellent introductory material.  This was, however, long ago.

Thats why documentation is often broken into

tutorial - which does the introduction and hand holding

user guide - which explains common use and idioms

reference - data only, but precise and excruciating detail

As you say above, after a while you don't need the tutorial and less of the user guide, just the reference.

But even the tutorial will make assumptions about the audience having a certain level of knowledge and capabilities, documentation about a programming tool may operate on the basis that the reader knows how to program in some particular language/paradigm but knows nothing about the tool, and then readers without the requisite language/paradigm knowledge will struggle.  But because they operate in an environment where "everyone knows" that background, the writers are unlikely to even think about explaining that background and may even struggle to do so because its so "self evident".  See [1] and [2] for more on trying to explain a mental model of a complex software concept.

And add to that programmers are often not motivated by documentation...

Cheers Lex

[1] http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-... [2] http://mvanier.livejournal.com/1205.html _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany

2011/5/8 Lex Trotman elextr@gmail.com:

Hmmm, yes annoying, which VCS are you using and what are you doing that changes *every* file?

Git too, it's very efficient, but I have branches with many differences (e.g. in one there is the gpl preamble in every file, in another there is not).

Unfortunately what to do when Geany sees a file change is a multiple choice, (...) I would be worried trying to apply a single response to all those file by file options.

Right. One should have a complex dialog allowing to select diffent actions for different files (or, a kate-style doc list). Or maybe just a function "reload all files", with a nice shortcut.

Cheers Eugenio