:set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0
Works most of the case.. (maybe not perfect, but..)
Thanks a lot! I just put it in the programming guidelines.
Federico
Hi,
I have some working code that does use the pluginrc to store the additional
locale info for plugins (as described in my earlier mail). Additionally
the framework for setting the domain (and optionally a path) from a plugin
through a PDB call is complete and tested.
The new PDB call would
Hi,
Ok, one shouldn't just bitch about other people's code, so here is my patch
that adds an optional locale_domain and locale_path to the plugin structure
and extends the pluginrc code to read and write that information from/into
the pluginrc. This code is obviously a few lines longer than
On Wed, 23 Feb 100, Miles O'Neal wrote:
[snip thought GNU style was bad but it's OK]
I still don't. Two spaces just isn't enough. Three
or four is much better. And I like space before the
paren only if it isn't after a function or procedure
name.
And I firmly believe that if God had
On 23 Feb, Sven Neumann wrote:
gimp_plugin_add_locale_domain (gchar *domain_name,
gchar *domain_path)
and can only be called in the query function of a plug-in. The
domain_path may optionally be NULL. Proposals for a better name are
welcome.
I'd recommend
Hi,
I'd recommend gimp_plugin_domain_add (gchar *domain_name)
and gimp_plugin_domain_add_with_path (gchar *domain_name,
gchar *domain_path)
because it IMHO fits better into the namespace and is more obvious
than to have just 1 function with two
On 23 Feb, Sven Neumann wrote:
No, that won't work. Of course you need to hook somewhere into
plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins
won't be able to register their domain on the first call.
Of course you are right, just a braino.
The only thing missing now is
On Tue, 22 Feb 2000, [EMAIL PROTECTED] wrote:
On 22 Feb, Manish Singh wrote:
True, although we have a couple other inconsistencies already. The
coding style needs to be the same as the rest of gimp though.
I tried to bring it as near as possible. Of course a lot things could
be
On 22 Feb, Raphael Quinet wrote:
I did not like the GNU style at first (especially the space before the
opening parenthesis) but now I understand that it is very important
to keep a consistent coding style in each project, because it keeps
the code manageable and maintainable. So I always
Raphael Quinet said...
|
|I did not like the GNU style at first (especially the space before the
|opening parenthesis)
I still don't. Two spaces just isn't enough. Three
or four is much better. And I like space before the
paren only if it isn't after a function or procedure
name.
|but now I
Hi,
This idea will cirumvent most of the problems which gettext alone
just can't deal with. It's little and as such not very likely to
introduce many new bugs.
With the usage of static array and buffer lengths you demonstrated in
your patch it will most likely introduce one or two new
On Tue, Feb 22, 2000 at 10:50:55AM +0100, Sven Neumann wrote:
Hi,
This idea will cirumvent most of the problems which gettext alone
just can't deal with. It's little and as such not very likely to
introduce many new bugs.
With the usage of static array and buffer lengths you
On 22 Feb, Sven Neumann wrote:
With the usage of static array and buffer lengths you demonstrated in
your patch it will most likely introduce one or two new bugs, but
that could easily be hacked up a little cleaner
Of course I could have used a linked list, but I'm not sure if
it's worth
On 22 Feb, Manish Singh wrote:
True, although we have a couple other inconsistencies already. The
coding style needs to be the same as the rest of gimp though.
I tried to bring it as near as possible. Of course a lot things could
be better
It's not that much code, and does fix a
On Tue, 22 Feb 2000, Sven Neumann wrote:
I also don't like the format of the localerc you proposed since it doesn't
look like the other files in ~/.gimp-1.1. Why not use the scheme-like
syntax people are used to use and that the gimp can parse anyway?
I agree strongly with this... there
On Tue, Feb 22, 2000 at 02:59:18PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote:
scripts and, to a lesser extent, the Perl scripts. Is there a
recommended style for these?
Yes, just copy mine ;)
For perl-only-syntax-questions, the reference should be "perldoc
perlstyle". All the remaining
On Tue, Feb 22, 2000 at 10:50:55AM +0100, Sven Neumann [EMAIL PROTECTED]
wrote:
I'm not yet convinced that this goal is worth all the hassle. What do
other people on this list think about this?
Being able to add plug-ins with i18n support is _extremely_
important. Unless the release would be
On Tue, Feb 22, 2000 at 03:56:44PM +0100, [EMAIL PROTECTED] wrote:
Okay, will turn from the Standard vi indention into GNU coding style.
"Standard vi indentation" is fine. Just follow the GNU coding style on
when to indent, and when not (and when to add spaces, when not...) ;)
The idea,
Uhm, I use vim and vim uses tabs by default and doesn't indent
the { after an if like GNU suggests. Du you have working settings to
achieve this?
I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentation
Hi,
[ ... many thought about localerc deleted ... ]
Well, you are right in all your points. I just decided
to use a new file because I don't need much functionality
and therefore could keep it simple as well as the functions
in GIMP and libgimp to deal with it.
IMHO adding lines
On Tue, Feb 22, 2000 at 07:59:21PM +0100, [EMAIL PROTECTED] wrote:
Uhm, I use vim and vim uses tabs by default and doesn't indent
vim, like vi and emacs, has a manual and can be configured quite freely ;)
the { after an if like GNU suggests. Du you have working settings to
achieve this?
On 22 Feb, Federico Mena Quintero wrote:
I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentation style.
This is the standard vim style.
If you tweak it a bit it may work for GNU indentation style.
No,
On Tue, Feb 22, 2000 at 11:54:03PM +0100, [EMAIL PROTECTED] wrote:
Well, that the thing I'm talking about.
I tried this options and think that it doesn't match it very good.
After the first { of a function the source isn't indented for example.
Then, most probably, you have a very very
If you tweak it a bit it may work for GNU indentation style.
No, unfortunately I couldn't get vim used to GNU indention style.
Please tell me if this works or if you had to change something; I'd
like to keep that part of the programming guidelines as accurate as
possible.
Hi,
Actually I don't see hundreds
of internationalized plugins in addition to the ones that come with
gimp
But even those will have their own entry. One entry per plugin.
Considering the amount of plugins we ship with GIMP nowadays this
would alone lead above hundred entries.
Why
On 22 February, 2000 - [EMAIL PROTECTED] sent me these 0.6K bytes:
On 22 Feb, Federico Mena Quintero wrote:
I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentation style.
This is the standard vim
Hi,
I have thought about the problem a little more and there's one
question that has not been addressed until now. How should the
plugin now where its mo-file will be installed? If we want to
stay with the existing procedure that the plug-in may be
installed in a configured list of paths, it
On 23 Feb, Marc Lehmann wrote:
Then, most probably, you have a very very old or broken version of vim
(or maybe you use another editor, or vim in vi-emulation mode).
Actually it's the latest stable version of vim.
The whole point of these options is to make indentation automatic and
On 23 Feb, Sven Neumann wrote:
The current solution for the plugins
distributed with The GIMP works reasonably good.
Really? I wouldn't call "we have to pre-add the menuentries to GIMPs
core source otherwise it wouldn't work" working good. Actually my
patch doesn't really address those
29 matches
Mail list logo
