Is any rule about put information in Filter field, regexp or something?For example if I want set visible only .xml and .py files?
On Thu, 7 May 2009 11:42:38 -0400, Vadim wrote:
Is any rule about put information in Filter field, regexp or something? For example if I want set visible only .xml and .py files?
I'd love this too... I open C files but don't want the headers always.
*.c *.py *.xml
should work.
However, while testing it to verify I noticed it filters also directories which might not be desirable. Any opinions of users who uses the filebrowser plugin?
Just for reference, the following is a quote of the GLib API documentation describing the filtering rules which are used in the file browser plugin:
The g_pattern_match* functions match a string against a pattern containing '*' and '?' wildcards with similar semantics as the standard glob() function: '*' matches an arbitrary, possibly empty, string, '?' matches an arbitrary character.
Note that in contrast to glob(), the '/' character can be matched by the wildcards, there are no '[...]' character ranges and '*' and '?' can not be escaped to include them literally in a pattern.
Regards, Enrico
Hi,
I'm using geany (always last copy from svn :) to develop a python application. I like the filebrowser filter but, as you have said, it filters directories entries aswell. I was thinking in report this bad behabiour but you did before. Can anyone fix it? I haven't wrote a C line in one year.
Thanks for this wonderfull editor.
Kind regards, Tomás
2009/5/7 Enrico Tröger enrico.troeger@uvena.de
On Thu, 7 May 2009 11:42:38 -0400, Vadim wrote:
Is any rule about put information in Filter field, regexp or something? For example if I want set visible only .xml and .py files?
I'd love this too... I open C files but don't want the headers always.
*.c *.py *.xml
should work.
However, while testing it to verify I noticed it filters also directories which might not be desirable. Any opinions of users who uses the filebrowser plugin?
Just for reference, the following is a quote of the GLib API documentation describing the filtering rules which are used in the file browser plugin:
The g_pattern_match* functions match a string against a pattern containing '*' and '?' wildcards with similar semantics as the standard glob() function: '*' matches an arbitrary, possibly empty, string, '?' matches an arbitrary character.
Note that in contrast to glob(), the '/' character can be matched by the wildcards, there are no '[...]' character ranges and '*' and '?' can not be escaped to include them literally in a pattern.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, 7 May 2009 22:26:45 +0200, Tomás wrote:
Hi,
I'm using geany (always last copy from svn :) to develop a python application. I like the filebrowser filter but, as you have said, it filters directories entries aswell. I was thinking in report this bad behabiour but you did before. Can anyone fix it? I haven't wrote a C
Changed in SVN r3772, the filter is now only applied to files not directories.
Regards, Enrico
Thanks so much Enrico.
It's working fine for me.
Kind Regards, Tomás
2009/5/8 Enrico Tröger enrico.troeger@uvena.de
On Thu, 7 May 2009 22:26:45 +0200, Tomás wrote:
Hi,
I'm using geany (always last copy from svn :) to develop a python application. I like the filebrowser filter but, as you have said, it filters directories entries aswell. I was thinking in report this bad behabiour but you did before. Can anyone fix it? I haven't wrote a C
Changed in SVN r3772, the filter is now only applied to files not directories.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
of course I realised that I can put *.py but I want connect two rules like *.py and * .xml
2009/5/7 Enrico Tröger enrico.troeger@uvena.de
On Thu, 7 May 2009 11:42:38 -0400, Vadim wrote:
Is any rule about put information in Filter field, regexp or something? For example if I want set visible only .xml and .py files?
I'd love this too... I open C files but don't want the headers always.
*.c *.py *.xml
should work.
However, while testing it to verify I noticed it filters also directories which might not be desirable. Any opinions of users who uses the filebrowser plugin?
Just for reference, the following is a quote of the GLib API documentation describing the filtering rules which are used in the file browser plugin:
The g_pattern_match* functions match a string against a pattern containing '*' and '?' wildcards with similar semantics as the standard glob() function: '*' matches an arbitrary, possibly empty, string, '?' matches an arbitrary character.
Note that in contrast to glob(), the '/' character can be matched by the wildcards, there are no '[...]' character ranges and '*' and '?' can not be escaped to include them literally in a pattern.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Am Donnerstag, den 07.05.2009, 22:54 +0200 schrieb Marcin:
2009/5/7 Enrico Tröger enrico.troeger@uvena.de
On Thu, 7 May 2009 11:42:38 -0400, Vadim wrote: >>Is any rule about put information in Filter field, regexp or >>something? >>For example if I want set visible only .xml and .py files? > >I'd love this too... I open C files but don't want the headers always. *.c *.py *.xml should work. However, while testing it to verify I noticed it filters also directories which might not be desirable. Any opinions of users who uses the filebrowser plugin? Just for reference, the following is a quote of the GLib API documentation describing the filtering rules which are used in the file browser plugin: The g_pattern_match* functions match a string against a pattern containing '*' and '?' wildcards with similar semantics as the standard glob() function: '*' matches an arbitrary, possibly empty, string, '?' matches an arbitrary character. Note that in contrast to glob(), the '/' character can be matched by the wildcards, there are no '[...]' character ranges and '*' and '?' can not be escaped to include them literally in a pattern.of course I realised that I can put *.py but I want connect two rules like *.py and * .xml
That is unfortunately not possible yet with the file browser plugin. But I personally think that would be a cool feature and I think I'm not the only one with that. :) So, anyone who would write a patch would be welcome I think. I'll may have a look on it too if I find the time.
Regards, Dominic
Enrico Tröger wrote:
However, while testing it to verify I noticed it filters also directories which might not be desirable. Any opinions of users who uses the filebrowser plugin?
Much prefer it to not filter out directories.
Multiple extension filters in whichever form would be very nice, not worried whether it would be by globbing or by regex. Whilst globbing is quite familiar to most, regex would also allow exclusions (e.g. all except .jpg, .gif, .png etc. that Geany can't edit)
Best: can there be an attribute of the project to remember the filter? i.e. something that is remembered when switching from a PHP project to a C++ project or a Python project, etc.
Also: standardised sets of lists via a drop-down, e.g.
* XML type files: .xml, .xsl, .xhtml, etc. * web scripts: .html, .xhtml, .htm, .php*, .asp*, .css, ... * C++ files: .c, .h, .c++, .cxx, .h++, .hxx, .hpp, ...
I know, I know, go forth and create a patch, but... you did ask! :)
On Fri, 08 May 2009 19:34:02 +1000, Ross wrote:
Enrico Tröger wrote:
However, while testing it to verify I noticed it filters also directories which might not be desirable. Any opinions of users who uses the filebrowser plugin?
Much prefer it to not filter out directories.
As mentioned in the other post, done in SVN.
Multiple extension filters in whichever form would be very nice, not worried whether it would be by globbing or by regex. Whilst globbing is quite familiar to most, regex would also allow exclusions (e.g. all except .jpg, .gif, .png etc. that Geany can't edit)
Without thinking too deeply about it, two problems instantly pop up in my mind: a) "real" globbing would be cool but glob() is not that portable, IIRC it's missing completely on Windows and I'm not sure about the various Unix variants. The manpage says it is conforming to POSIX.2 and POSIX.1-2001, so what about the other systems?
b) regex would be way more flexible and it's more portable (for systems without it we have a small implementation embedded) but it would also be harder to use. E.g. something like "*.py" wouldn't work anymore as it's not globbing.
Best: can there be an attribute of the project to remember the filter? i.e. something that is remembered when switching from a PHP project to a C++ project or a Python project, etc.
Surely possible but it still needs someone to implement it.
Also: standardised sets of lists via a drop-down, e.g.
- XML type files: .xml, .xsl, .xhtml, etc.
- web scripts: .html, .xhtml, .htm, .php*, .asp*, .css, ...
- C++ files: .c, .h, .c++, .cxx, .h++, .hxx, .hpp, ...
See above.
Regards, Enrico
On Fri, 8 May 2009 18:25:52 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
b) regex would be way more flexible and it's more portable (for systems without it we have a small implementation embedded) but it would also be harder to use. E.g. something like "*.py" wouldn't work anymore as it's not globbing.
Maybe this could be solved by adding some kind of switch like "Use regex for more complex rules". But easy to use is something different.
Regards, Frank
On Fri, 8 May 2009 18:30:43 +0200, Frank wrote:
On Fri, 8 May 2009 18:25:52 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
b) regex would be way more flexible and it's more portable (for systems without it we have a small implementation embedded) but it would also be harder to use. E.g. something like "*.py" wouldn't work anymore as it's not globbing.
Maybe this could be solved by adding some kind of switch like "Use regex for more complex rules". But easy to use is something different.
Yeah, just adding everything doesn't always solve problems.
Regards, Enrico