|
| From: | Éloi Rivard |
| Subject: | Re: [Denemo-devel] Indentation (was Re: Command generation mechanism) |
| Date: | Mon, 6 May 2013 17:54:39 +0200 |
That's what I mean :)2013/5/6 Richard Shann <address@hidden>
Ah, yes, I have it now, a separate package called indent ( :) ) onOn 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.
Debian.Yes, it was never my favorite, but I value standardization above
>
> 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 ?
personal preference.Do you mean a separate commit that does nothing but correct indentation.
>
> 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 ?
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 <address@hidden>
> 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. »
> >
>
>
>
>
>
> --
> Éloi Rivard - address@hidden
>
> « On perd plus à être indécis qu'à se tromper. »
>
_______________________________________________
Denemo-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/denemo-devel
| [Prev in Thread] | Current Thread | [Next in Thread] |