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. » > _______________________________________________ Denemo-devel mailing list Denemo-devel@gnu.org https://lists.gnu.org/mailman/listinfo/denemo-devel