[Geany-devel] Committed Project Build Commands to build-system branch

[Lex Trotman]

2008/11/7 Nick Treleaven <nick.treleaven at btinternet.com>

>
> > > BTW there are some formatting issues:
> > > 1. Some spaces instead of tabs being used for indentation (e.g. in
> > > build.c).
> > > 2. Spacing - instead of:
> > >
> > > if( blah!=foo )some_func( foo );
> > >
> > > use:
> > >
> > > if (blah != foo) some_func(foo);
> > >
> > > Please use the existing code style (see HACKING).
> >
> >
> > Do you have a configuration for one of the usual source formatters to
> > get the format you want, I AM going to continue to get it wrong
> > because it is different to the standard format I use all day every
> > day at work. The fingers just automatically put spaces on the other
> > side of the ( ) etc. Even if I'm thinking about it, it will get done
> > wrong from time to time ;-).  You are correct that it should be
> > consistent within Geany so if there is a formatter that will generate
> > the format used throughout Geany I will ensure that I use it.
>
> I haven't really tried them, I wrestled with GNU indent once but
> couldn't work out how to tell it to use tabs only. Probably there's
> a better formatter out there, but you'll have to play with the options
> to get a matching style.
>
> > > The indentation is the most important one, could you fix this
> > > please?
> > >
> >
> > Well, all editing has been done in Geany with indentation set to tabs
> > so I don't know where the problem came from??? but I can fix it.
>
> Somehow your commit has introduced them, they weren't there before in
> build.c (and elsewhere). Try seaching with the regex "^\t*  +" (note the
> 2 spaces to prevent matches for multiline comments).
>
> There will be a few matches for Glade callback argument alignment, but
> other than these all lines should only use tabs.
>
> Sorry to be pedantic ;-)
>
> No problem, it is more important that a project chooses and sticks to a
style than what the style actually is.  On the other hand formatting is the
sort of rote activity that I believe computers should do, not people.  On
that basis my work experience student now knows much more than she ever
wanted to about C code formatters.  We have found one, 'uncrustify' that
seems to do what we want without doing too much extra, I have committed a
version of build.c run through it for you to have a look at.  uncrustify is
very flexible (about 250-300 options) and it seems to be able to enforce all
the requirements of HACKING. The only extra things that I can't stop it
doing are:
- positioning the alignment of variable definitions and parameters slightly
different to the originals (still aligns and hangs * though)
- aligning function call continuations with the open parens, I think it is
ok, see what you think.  It can cause the call to need more wrapping though.

The wrapping of long lines is a little simplistic for long function calls
that are already manually wrapped, needs a bit of a helping hand but not
very often.

PS thanks for the hint about meld you gave in a previous email, made
comparing formatted and unformatted versions very easy.


>
> Yes, I set 2 project build commands, then checked the menu. It doesn't
> work after updating the dialog, but reopening the project does work.
>

interesting, will look at it, I thought I called update_menu everywhere I
needed, but must have missed somewhere

>
> BTW there was a bug where the 3rd project build menu item is created
> based on the 2nd label.
>

Ah yes, the old copy and paste and forget to edit the names trick ;-) will
fix


>
> > full version will also show them for preferences which isn't
> > implemented in this version. Coming real soon now though :-) maybe [?]


What I meant was that in the full version build (ie make) commands come from
project, user prefs or default whichever is found first.
It is partly implemented, so of course like all software its gonna be
finished "real soon now"

>
>
> Not quite sure what you mean, but I'll read the manual changes first.
>
> OK. Maybe a checkbox to enable them, on by default, might be better.
> But no need to implement this.


I guess its a choice between ways of skinning the cat, having a  checkbox
would allow users to show blank menu items, whilst having blanks hide items
needs clear documentation.  Given that the target users are programmers, I
think either would be ok, I am sure that if they are up to the level of
changing the commands, they would be capable of fiddling with the settings
to get what they want, whichever way it worked.  I'll continue on the
current path for now but I don't have any strong feelings either way.

>
>
> > NOTE: this brings up one significant change needed for the full
> > version, the can compile, can build, flags of the filetype will no
> > longer be used since the existance (or not) of such a command is what
> > determines if a menu item is shown.  Otherwise users would not be
>
> I agree, I wanted to remove them before.
>
> > able to add filetype commands to unused filetype menu items.  So in
> > the full version, a commandwhich is not set will mean use the default
> > whilst one set to nothing (item name) will mean don't use. Have to
> > allow 'command set to nothing' just in case someone wants to use the
> > make custom dialog to type the whole command, possibly useful for
> > occasionally used commands whilst still capturing and parsing the
> > command output.
> >
> > But are there any other important uses of these flags besides
> > controlling what is shown in the build menu?
>
> If so, they can be replaced with if (NZV(ft_command_str)) checks (or
> maybe just checks against null for the custom command).
>

Ok, i'll take that as removal is ok


>
> Regards,
> Nick
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>

Cheers
Lex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20081107/6bddad92/attachment.html>