That's what I mean :)
2013/5/6 Richard Shann <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> > > > > > > > > > > > > 2013/5/5 Richard Shann <[email protected]> > > > On Sun, 2013-05-05 at 17:09 +0200, Éloi > > Rivard wrote: > > > > > > > > > > > > > > > > 2013/5/5 Richard Shann > > <[email protected]> > > > > 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 - [email protected] > > > > > > « On perd plus à être indécis qu'à se tromper. » > > > > > > > > > > > > > > > -- > > > Éloi Rivard - [email protected] > > > > > > « On perd plus à être indécis qu'à se tromper. » > > > > > > > > > > > > > > > -- > > Éloi Rivard - [email protected] > > > > « On perd plus à être indécis qu'à se tromper. » > > > > > -- Éloi Rivard - [email protected] « On perd plus à être indécis qu'à se tromper. »
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
