|
| From: | Éloi Rivard |
| Subject: | Re: [Denemo-devel] Indentation (was Re: Command generation mechanism) |
| Date: | Mon, 6 May 2013 11:27:51 +0200 |
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 <address@hidden>
>
>
>
> 2013/5/5 Richard Shann <address@hidden>
> On Sun, 2013-05-05 at 17:09 +0200, Éloi Rivard wrote:
> >
> >
> >
> > 2013/5/5 Richard Shann <address@hidden>
> > 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 - address@hidden
>
> « On perd plus à être indécis qu'à se tromper. »
>
>
>
>
> --
> Éloi Rivard - address@hidden
>
> « On perd plus à être indécis qu'à se tromper. »
>
| [Prev in Thread] | Current Thread | [Next in Thread] |