On Mon, 2013-05-06 at 11:27 +0200, Éloi Rivard wrote: > Indent is a GNU program that let you indent your code the way you > want: http://www.gnu.org/software/indent/ > > I think most of linux distributions have a package for this. Ah, yes, I have it now, a separate package called indent ( :) ) on Debian. > > This let you chose the indentation policy you want (number of spaces, > use of tabulations or not, braces at end of lines or at beginning > etc.) > > The default style of indent is "GNU" that is recommended for GNU > projects, what do you think of this one ?
Yes, it was never my favorite, but I value standardization above personal preference. > > Maybe automatic indentation can not be a good idea in some case > indeed, though indent is pretty safe, because sometimes you just want > a particular alignment, for instance with arrays. > > Perhaps a code indent commit would be a good idea ? Do you mean a separate commit that does nothing but correct indentation. That would be very good indeed, it is really bad to mix code changes with indentation changes as I have been doing (but then, no-one else has been caring much ...). Richard > > > > 2013/5/6 Richard Shann <richard.sh...@virgin.net> > Indentation is often terrible in Denemo - I don't seem to have > any > indent command - this hook seems to refer to one, what would > that be? > I am not sure that automatic re-indenting on commit will be > good - > anything altering the programmer's text is controversial, but > I would be > very happy to adopt a convention given a tool to enable it. I > have been > fixing indentation myself by hand during the past year as I > have edited > code, despite the annoyance that doing it while making code > changes > makes the commit much harder to read. So a global tidy up > followed by > testing (it should be a *very* trusted indent tool!) would be > good I > think. > > Richard > > On Sun, 2013-05-05 at 20:50 +0200, Éloi Rivard wrote: > > Here is an interesting indent pre-commit hook > > https://gist.github.com/eroullit/1250603 > > > > > > > > 2013/5/5 Éloi Rivard <azm...@gmail.com> > > > > > > > > 2013/5/5 Richard Shann <richard.sh...@virgin.net> > > On Sun, 2013-05-05 at 17:09 +0200, Éloi > Rivard wrote: > > > > > > > > > > > > 2013/5/5 Richard Shann > <richard.sh...@virgin.net> > > > On Sun, 2013-05-05 at 13:41 +0200, > Éloi > > Rivard wrote: > > > > Let's imagine a user wants to > create a > > scheme command and > > > add it as a > > > > denemo default command. What > process > > should be followed ? > > > > > > > > > 1)Use View->Scheme to get an > editor. Type in > > the scheme for > > > the new > > > command. > > > 2)Decide on a position in the menu > system > > for the new command. > > > Right > > > Click on the item above the > desired > > position, and choose Save > > > As New > > > Menu Item. > > > 3)Give a name for the command > > > 4)Give a Label for the menu item > that will > > activate it > > > 5)(optionally) give a submenu name > > > 6)Save with default commands. > > > > > > > > I am not sure I understand roles > of > > tools : extract_all.sh, > > > > > > this creates files that the > translation tool > > xgettext can use > > > > generate_sources > > > generate_sources.c generates > (ancient) > > built-in commands > > > > and the sources it generates, > > > > > > > commands.c, > > > > > > this exists for translatability, > but is is > > executed at startup > > > making > > > the original mechanism of reading > > Default.commands generally > > > redundant > > > (except where new commands have > been created > > since the binary > > > was > > > generated) > > > > > > > > > Why is it needed to generate some c dummy > files for > > translation since > > > scheme is supported by xgettext ? > > > > > > there are no c dummy files, commands.c is > executed, it > > is not scheme > > that is getting translatable it is menu > labels and > > tooltips. > > > > > > > > > > > > > > denemoui.xml, > > > this is hand-written, it defines > where the > > built-in commands > > > appear in > > > the menu system > > > > GENERATE_SOURCE_CODE define > etc. > > > This is used to create a version > of Denemo > > which generates the > > > source > > > code commands.c, that is you make > Denemo > > with that > > > preprocessor flag > > > defined, run it and it loads all > the > > commands (from > > > Default.commands) > > > and generates new source code for > Denemo > > that contains > > > translatable > > > strings for all the commands. You > then > > re-compile Denemo > > > without that > > > flag and it uses the new source > code; the > > program's behavior > > > has not in > > > fact been altered, but it has > labels and > > tooltips for all > > > commands > > > translatable. > > > > > > > > > Why not create another program dedicated > to this > > task and let denemo > > > behavior more regular ? > > > > > > yes, please do :) You just have to parse > > Default.commands and generate > > C-code from it. > > > > > > > > See attached patch. utils/generate_commands creates > the very > > same code than launching denemo with > -DGENERATE_SOURCE_CODE > > I indented some code in keyboard.c so some line have > been > > changed but the behavior is the same. I also fixed > some unused > > variable warnings. > > > > What about some indent commit hook ? > > > > > > > > > > > > > > and some other I probably miss. > > > > > > It could be. I seem to remember > you > > suggested the word > > > Pharaonic to > > > describe what was needed to make > Denemo > > translatable :) > > > > > > > > > > > It should be understandable by > reading and > > hacking, but as > > > the process > > > > seems quite complicated, I think > > developers comments would > > > be helpful. > > > > > > > > > It is very complicated - In the > latest > > release I missed the > > > fact that > > > after running extract_all.sh there > are > > generally further text > > > files > > > generated that need a git commit > otherwise > > the make dist step > > > fails to > > > create the po stuff. Those text > files are in > > > actions/commandscripts and > > > exist purely to allow xgettext to > see the > > (_ ) procedures - > > > the > > > translatable strings - in the > scheme of the > > scripted commands. > > > (By > > > contrast, the commands.c is > generated to > > allow xgettext to see > > > the > > > labels of the commands and their > tooltips). > > > > > > There are a lot of steps needed to > create a > > release and I am > > > very happy > > > to rehearse them here - it > improves the > > chance of me getting > > > it right > > > next time first time. > > > > > > > > > > > > Something that may be discouraging for a > beginner at > > the current > > > state, is that when you edit some code, > you can't > > just compile & see > > > since there seem to be some intermediate > generation > > steps. Maybe > > > including those in the build system would > make > > things easier. > > > > > > which code? The intermediate steps are just > for > > translation. > > > > > > If you want for instance add some metadata to > actions/menu xml > > files, you may have to update translation steps too. > > > > > > (Well, there is that ancient built in stuff, > which we > > really don't want > > people expanding - new stuff should be > scheme > > generally. However, as it > > is, it has advantages for re-engineering the > built-in > > stuff. There is an > > ancient classification of commands in there > which may > > come in useful > > some day, and it does generate the commands > for notes > > A-G and durations > > 0-7 programatically, which saves having to > edit > > multiple times if we > > alter something about how they appear in the > program. > > But I wouldn't > > seriously defend that stuff, if someone were > to write > > it cleanly from > > scratch). > > > > Richard > > > > > > > > > > > > > > -- > > Éloi Rivard - azm...@gmail.com > > > > « On perd plus à être indécis qu'à se tromper. » > > > > > > > > > > -- > > Éloi Rivard - azm...@gmail.com > > > > « On perd plus à être indécis qu'à se tromper. » > > > > > > > > -- > Éloi Rivard - azm...@gmail.com > > « On perd plus à être indécis qu'à se tromper. » > _______________________________________________ Denemo-devel mailing list Denemo-devel@gnu.org https://lists.gnu.org/mailman/listinfo/denemo-devel