On 13-10-11 11:23 AM, Dimitar Zhekov wrote:
On Wed, 09 Oct 2013 18:43:41 -0700
Matthew Brush <mbr...@codebrainz.ca> wrote:

On 13-10-09 01:01 PM, Dimitar Zhekov wrote:

Proposition: move the presentation to glade as much as possible, and
fill the content with code, as in any normal program.


I have done this before in a branch, but just the Glade part, which
AFAIK is basically unmergable now because of volatility of Glade XML
file. What I did was I made one single Search dialog in Glade that
always showed the widgets that are in common between the various search
dialogs (find, replace, fif), and then the specific options for the
search type were each in their own container widget so they could be
hidden/shown depending on which search dialog needs to be shown. There's
some extra code to setup the dialog to be shown/work for the correct
search type but it probably dwarfs the amount of code removed by putting
all of them in the Glade file into a single DRY dialog.

Interesting... though I would probably have followed the current logic,
simply moving the visual part to XML.

3. For non-recursive searches, grep does not allow a directory to be
specified instead of file. To work around that, we read the directory,
back-parse all --include=*.x patterns, and match them manually.

Proposition: grep -rl --include=*.c --exclude-dir=[^.]*
--exclude-dir=.?* void . :)

We pass our Directory as a workind  directory to spawn, and the
recursive search already uses . as a grep FILE argument.
--exclude-dir is supported since more than 5 years.


Is there any reason we cannot just walk the directory/subdirectories
ourselves and search the files using GRegex stuff?

There's nobody willing to do it?..

GIO/GFile has all the stuff needed to walk a
directory tree and open files both asynchronously and portably IIRC.

Looking at the "spawn" problems, which are realy GIOChannel
set_flags and/or add_watch problems, I woudn't be so sure about that.


OK, assuming some obscure bug from one part API doesn't somehow manifest itself in a seemingly completely different part of the API (IO Channels vs GIO/GFile).

Also, the current FiF doesn't block Geany. If you want to keep that,
you'll need a 2nd thread or an event source, and neither would be so
easy to write.


The GIO/GFile stuff I'm referring to is asynchronous.

Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Reply via email to