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 <[email protected]>: > On 8 May 2011 16:51, Křištof Želechovski <[email protected]> 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-tutorial-fallacy/ > [2] http://mvanier.livejournal.com/1205.html > _______________________________________________ > Geany mailing list > [email protected] > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany > _______________________________________________ Geany mailing list [email protected] https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
