|
| From: | Éloi Rivard |
| Subject: | Re: [Denemo-devel] Indentation (was Re: Command generation mechanism) |
| Date: | Tue, 7 May 2013 11:46:42 +0200 |
On Mon, 2013-05-06 at 17:54 +0200, Éloi Rivard wrote:I have built this version and it seems to be running just fine - of
> I idented src and utils directories with indent -nut -l500, to use
> tabs instead of spaces so the code displays the same on every editors,
> and to not break lines after 80 columns.
>
> This is on the 'indent' branch. Let me know if it is ok to you
course we have no regression tests, but I trust GNU indent.
One thing that surprised me is the coding style is not what I remembered
(about 15 years ago I worked in a company that specified GNU coding
style for newly-written code) and my memory was that it involved opening
braces on the same line as the function name, ie
void myfun (void) {
}
whereas what you have looks more like the K&R that I first got to know,
ie
int myfun ()
{
}
but so long as this is current GNU coding standards I am happy to go
with it.
Richard
>
>
>
> 2013/5/6 Éloi Rivard <address@hidden>
> That's what I mean :)
>
>
>
> 2013/5/6 Richard Shann <address@hidden>
> 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 <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. »
> >
>
>
>
>
>
>
> --
> É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
>
>
>
>
> --
> Éloi Rivard - address@hidden
>
> « On perd plus à être indécis qu'à se tromper. »
>
| [Prev in Thread] | Current Thread | [Next in Thread] |