Marco Barisione wrote:
> My version of EggRegex is at http://techn.ocracy.org/eggregex/ and a
> copy of the documentation is at http://www.barisione.org/eggregex/
And a tar.gz generated by "make dist" is at
http://www.barisione.org/eggregex/eggregex-0.1.tar.gz
In these days I
gt; > actively thinking and talking about a central UCD wrapper. For now, I
> > suggest just copying it internally into EggRegex.
> >
>
> Is this something that will see the light of day in the Gnome 2.18
> timeframe ?
Yes, that's quite possible.
--
behdad
http:/
t; suggest just copying it internally into EggRegex.
>
Is this something that will see the light of day in the Gnome 2.18
timeframe ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
and not LGPL.
> >
> > I was wrong, it's in the library and not in the app so it's LGPLed.
> >
> > What should I do with the scripts? Obviously eggregex cannot depend of
> > libgucharmap.
>
> Having a function to get the script as an enum seems reaso
Owen Taylor wrote:
> The libgucharmap code is likely just a cut-and-paste of the code in
> Pango; not that eggregex can depend on that either, but I don't think
> there is any theoretical issue with moving at least
> pango_script_for_unichar() into GLib.
I didn't know this
app so it's LGPLed.
>
> What should I do with the scripts? Obviously eggregex cannot depend of
> libgucharmap.
The libgucharmap code is likely just a cut-and-paste of the code in
Pango; not that eggregex can depend on that either, but I don't think
there is any theoretical iss
e app so it's LGPLed.
>
> What should I do with the scripts? Obviously eggregex cannot depend of
> libgucharmap.
Having a function to get the script as an enum seems reasonable to me
(considering that giulia seems to be way off). Not so sure about the script
names, but i
Marco Barisione wrote:
> gucharmap handles this internally but I can't copy the code because, as
> far as I know, it's under GPL and not LGPL.
I was wrong, it's in the library and not in the app so it's LGPLed.
What should I do with the scripts? Obviously eggregex cann
Marco Barisione wrote:
> Can someone take a look to pcre/ucptable.c, pcre/ucp.h and
> pcre/pcre_ucp_searchfuncs.c?
Now the internal PCRE uses glib for Unicode properties.
There is a problem, PCRE allows script names in \p{}, so you can match
an arabic character using \p{Arabic}. But AFAIK glib
ty bug in PCRE, distros
have to update two libraries instead of just libpcre.
Can someone take a look to pcre/ucptable.c, pcre/ucp.h and
pcre/pcre_ucp_searchfuncs.c?
The files are here:
http://techn.ocracy.org/eggregex/?f=03897669abe3;file=pcre/ucp.h;style=raw
http://techn.ocracy.org/eggregex/?f=3ad
On Thu, 2006-07-20 at 11:57 +0200, Marco Barisione wrote:
> > And it brings its own implementation of the necessary Unicode
> > data, instead of using the GLib one.
>
> Yes, but it shouldn't be too difficult to port pcre to use glib for
> Unicode. I can't do it because my knowledge of Unicode is
Matthias Clasen wrote:
> When I was last looking at regular expressions for GLib (which
> resulted in the current eggregex code), the first decision was to
> go for Perl regular expression, rather than posix. That naturally
> leads to PCRE. The main gripe with PCRE was (and is) that i
When I was last looking at regular expressions for GLib (which
resulted in the current eggregex code), the first decision was to
go for Perl regular expression, rather than posix. That naturally
leads to PCRE. The main gripe with PCRE was (and is) that it
had (and probably still has) relatively
On Wed, 2006-07-19 at 18:30 -0400, Hubert Figuiere wrote:
> The thing is that Regexp seems to be a requirement in term of features
> for a library like glib. Qt has it. For Python and Perl, it is built
> into the language, etc.
> So basically, not having a regexp in glib is really something missin
Marco Barisione wrote:
> Hi,
> GtkSourceView 2 will have a new syntax highlighting engine that will
> require a more powerful and fast regular expression library. This is why
> I worked on EggRegex (a wrapper library around PCRE) to correct bugs and
> to add new features.
Tristan Van Berkom wrote:
>> If eggregex links to a pcre version without unicode egg_regex_new()
>> prints an error message and fails.
>
> Are you sugesting that highlighting be a site-dependant feature ?
> i.e. g_regexp_supported() ... similar to g_thread_supported() ?
N
Marco Barisione wrote:
[...]
>
> If eggregex links to a pcre version without unicode egg_regex_new()
> prints an error message and fails.
Are you sugesting that highlighting be a site-dependant feature ?
i.e. g_regexp_supported() ... similar to g_thread_supported() ?
Is that an a
wever,
>this support has to be explicitly enabled; it is not the default."
Today most distributions ship a copy of pcre that supports utf-8 and
unicode properties.
However you can pass --enable-internal-pcre to configure to statically
link an internal copy of pcre.
If eggregex lin
Στις 19-07-2006, ημέρα Τετ, και ώρα 22:19 +0200, ο/η Marco Barisione
έγραψε:
> Behdad Esfahbod wrote:
> > Last time I checked, PCRE's didn't use Unicode Character Database to
> > classify characters and so is a poor choice for a highlighting engine
> > and definitely suboptimal in GNOME.
>
> It su
e pattern ^ab against the string a
the match fails but pcre knows that there is a partial match so adding
more characters may lead to a match), see
http://www.barisione.org/eggregex/eggregex-eggregex.html#egg-regex-is-partial-match
- DFA matching (matching <.*> against you get , an
On Wed, 2006-07-19 at 11:08 -0400, Marco Barisione wrote:
> Hi,
> GtkSourceView 2 will have a new syntax highlighting engine that will
> require a more powerful and fast regular expression library. This is why
> I worked on EggRegex (a wrapper library around PCRE) to correct bugs a
A little clarification:
Marco Barisione wrote:
>Hi,
>GtkSourceView 2 will have a new syntax highlighting engine that will
>require a more powerful and fast regular expression library. This is why
>I worked on EggRegex (a wrapper library around PCRE) to correct bugs and
>to a
ing of regular expressions. The sources might be helpful.
> This is why
> I worked on EggRegex (a wrapper library around PCRE) to correct bugs and
> to add new features.
>
> My version of EggRegex is at http://techn.ocracy.org/eggregex/ and a
> copy of the documentatio
Hi,
GtkSourceView 2 will have a new syntax highlighting engine that will
require a more powerful and fast regular expression library. This is why
I worked on EggRegex (a wrapper library around PCRE) to correct bugs and
to add new features.
My version of EggRegex is at http://techn.ocracy.org
24 matches
Mail list logo
