cssed-devel — cssed development discussion

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[<mic...@ea...>]

Le 15 sept. 2004, à 10:04, Iago Rubio a écrit :

> On Tue, 2004-09-14 at 22:25, Michèle Garoche wrote:
>> Le 14 sept. 2004, à 22:17, Iago Rubio a écrit :
>>> On Tue, 2004-09-14 at 17:11, Michèle Garoche wrote:
>>>> Le 14 sept. 2004, à 14:50, Iago Rubio a écrit :
>>>>>> What I mean here is when using the contextual menu in the document
>>>>>> and
>>>>>> the search in file base's.
>>>>> Sorry but I'm misunderstunding you :)
>>>>> What you want is to search a yet used term - so in the search term
>>>>> entry
>>>>> - in the current file's base directory, isn't it ?
>>>> Not exactly, I want to be able to search in the current document 
>>>> with
>>>> the search term given in the search term entry in the bottom panel.
>>> Mostly a task for the find dialog, isn't it ?
>> Yes, exactly.
> This dialog must be updated. Right now it only searches from caret
> position to end of document. The bits to search backwards are in place
> so I must update it.
It works for me backwards and upwards.

>>>> What do you think if we restrict to maxdepth=1 for Darwin? Otherwise
>>>> it
>>>> will take ages before we can have something functional if ever.
>>> We can easily do it by hidding all the depth related widgets, and a
>>> couple of #ifdef.
>>> May be we could limit maxdepth meanwhile we don't find a better
>>> solution, and go for the release,
>>> The we could have time to further investigate those problems.
>> Yes, I think so, but don't impede other systems to use the most of it,
>> just restrict it on systems where there are problems.
> And as find is bogus there, what about egrep.
> We can avoid maxdepth and set recursive or not.
> Non recursive:
> egrep -in term
> Recursive:
> egrep -irn term
> Does it works in your system ?
It does not work at all on my system, so I've reintroduced the first 
string for search, it is not perfect, but that's the most valid one at 
the moment.

Here's the diff:

Re: [cssed-devel] Improved English wording in cssed-findinfiles-plugin

[<mic...@ea...>]

Le 15 sept. 2004, =E0 13:48, Iago Rubio a =E9crit :

> On Tue, 2004-09-14 at 13:09, Mich=E8le Garoche wrote:
>> Here are some minor changes to various files.
>
> Updated thanks, but I had to merge so please update your copy and test
> everything is OK (no string change, just the po header have been
> *changed* (in fact it should not change in your local copy).
It's OK.

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] Improved English wording in cssed-findinfiles-plugin

[Iago R. <iag...@hi...>]

On Tue, 2004-09-14 at 13:09, Mich=C3=A8le Garoche wrote:
> Here are some minor changes to various files.

Updated thanks, but I had to merge so please update your copy and test
everything is OK (no string change, just the po header have been
*changed* (in fact it should not change in your local copy).

--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD

Re: [cssed-devel] UTF-8 strings not correct in plugins window

[Iago R. <iag...@hi...>]

On Wed, 2004-09-15 at 03:51, Mich=C3=A8le Garoche wrote:
> When loading a plugin, the strings are correct (accented characters),=20
> but when opening cssed once plugins have been loaded previously (in a=20
> previous run), the accented characters are not shown correctly.
>=20
> If I unload the plugin, then reload it, the strings are correct. I'm=20
> unable to find where is the bug.

Thanks for the report. Will test it right now.
--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[Iago R. <iag...@hi...>]

On Tue, 2004-09-14 at 22:25, Mich=C3=A8le Garoche wrote:
> Le 14 sept. 2004, =C3=A0 22:17, Iago Rubio a =C3=A9crit :
> > On Tue, 2004-09-14 at 17:11, Mich=C3=A8le Garoche wrote:
> >> Le 14 sept. 2004, =C3=A0 14:50, Iago Rubio a =C3=A9crit :
> >>>> What I mean here is when using the contextual menu in the document=20
> >>>> and
> >>>> the search in file base's.
> >>> Sorry but I'm misunderstunding you :)
> >>> What you want is to search a yet used term - so in the search term
> >>> entry
> >>> - in the current file's base directory, isn't it ?
> >> Not exactly, I want to be able to search in the current document with
> >> the search term given in the search term entry in the bottom panel.
> > Mostly a task for the find dialog, isn't it ?
> Yes, exactly.

This dialog must be updated. Right now it only searches from caret
position to end of document. The bits to search backwards are in place
so I must update it.=20

> >>> If so I must add another menu item to the pop menu.
> > [snip]
> >>> What do you think about that ??
> >> This is another option, but it is not the same as I thought of. Maybe
> >> it is more related to quicksearch plugin, now that I think about it.
> > Yes, we could add a pop menu entry for the quickserch plugin.
> Yes, maybe it's clearer.

Will take a try then.

> >> What do you think if we restrict to maxdepth=3D1 for Darwin? Otherwise=
=20
> >> it
> >> will take ages before we can have something functional if ever.
> > We can easily do it by hidding all the depth related widgets, and a
> > couple of #ifdef.
> > May be we could limit maxdepth meanwhile we don't find a better
> > solution, and go for the release,
> > The we could have time to further investigate those problems.
> Yes, I think so, but don't impede other systems to use the most of it,=20
> just restrict it on systems where there are problems.

And as find is bogus there, what about egrep.

We can avoid maxdepth and set recursive or not.

Non recursive:
egrep -in term

Recursive:
egrep -irn term

Does it works in your system ?

> And while you're at release step, did you check the changes I've made=20
> to quicksearch?

All is ok, and neat :)

> And I'm also finishing a plugin for the doc, the interface works fine=20
> (load, unload of a new item in the plugin menu), now I wonder how to=20
> open a browser, I don't want to use netscape or gtk-doc, but more a=20
> default as dillo and then have a preferences where to change the=20
> browser, i.e. Safari for example as a default on Mac, then if the user=20
> prefers Opera, Mozilla, etc..., he can change it, as in gimp for=20
> example.

In linux there used to be a script called htmlview that defauts to the
preferred browser in the system.

In fact it searches among a bunch of browsers checking the environment.

But I think I must to put an entry in the configuration file asking for
a browser as cssed needs it to show the help.

May be I also should wrap a function in the plugins API called
open_in_default_browser() to make it avaiable to all plugins.

Of course those bits can be on the plugin cose.

If the problem is to open the browser from the plugin, just use
g_spanw_command_line_async() and that's all.

> I'm about to love coding with you in C.

Happy to know that. I was wondering if the plugable interface would be
use by anyone but me :)

--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD

[cssed-devel] UTF-8 strings not correct in plugins window

[<mic...@ea...>]

When loading a plugin, the strings are correct (accented characters),=20
but when opening cssed once plugins have been loaded previously (in a=20
previous run), the accented characters are not shown correctly.

If I unload the plugin, then reload it, the strings are correct. I'm=20
unable to find where is the bug.

Mich=E8le
<http://micmacfr.homeunix.org>=

[cssed-devel] New plugin: developer doc plugin

[<mic...@ea...>]

I've just finished the plugin to view the doc for plugins in the user's=20=

favorite browser.

The whole process consists of:

1 - Copying cssed/include/*.h into cssed-plugin-doc/include to be sure=20=

to have the latest headers
2 - Generate html with doxygen to be sure to have the latest docs
3 - Integrate cssed-plugin-doc/html into a new plugin, namely=20
cssed-plugindoc-plugin

That's to say the source files are not delivered, just the doc in html=20=

format, but the user can browse it from within cssed.

As for browsing I use merely the open command, and the doc is placed in=20=

usr/share/cssed/plugindoc. A patch to src/plugindoc.c is necessary if=20
the doc should not be placed at this location. A new item menu is added=20=

to the Plugins menu to browse the doc.

Tell me if it's OK. Then I'll upload both new doxygen files (updated to=20=

the latest headers) and the new plugin to my site, because they are too=20=

big to put them on the mailing list and post here the urls.

I wonder if the right place in the menu should not be in Help menu=20
(I've put it in Plugins menu). Then I could do the same for the user's=20=

doc, probably in the same plugin.

Mich=E8le
<http://micmacfr.homeunix.org>=

Re: [cssed-devel] Changes in quicksearch plugin

[<mic...@ea...>]

Le 14 sept. 2004, =E0 22:23, Iago Rubio a =E9crit :

> On Tue, 2004-09-14 at 13:30, Mich=E8le Garoche wrote:
>> Le 14 sept. 2004, =E0 10:29, Iago Rubio a =E9crit :
>>
>>> On Mon, 2004-09-13 at 21:42, Mich=E8le Garoche wrote:
>>>> I've made changes locally in quicksearch plugin, so that:
>>>> 1 - It uses the convention for cssed plugin name
>>>> 2 - It checks for the existence of a search term before starting =
the
>>>> search
>>>> Are you OK for this.
>>>> If you're OK, I'll commit the changes, then have a look at them,=20
>>>> since
>>>> it's my first try changing the source (very newbye here).
>>>
>>> Ok, please commit those changes, so i can test it :)
>> They are committed now. Here's the diff. And teach me what is wrong =
in
>> it :-)
>
> Absolutely nothing :))
Wooot, impossible :-)

Mich=E8le's proud as a peacock :))))

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[<mic...@ea...>]

Le 14 sept. 2004, =E0 22:17, Iago Rubio a =E9crit :
> On Tue, 2004-09-14 at 17:11, Mich=E8le Garoche wrote:
>> Le 14 sept. 2004, =E0 14:50, Iago Rubio a =E9crit :
>>>> What I mean here is when using the contextual menu in the document=20=

>>>> and
>>>> the search in file base's.
>>> Sorry but I'm misunderstunding you :)
>>> What you want is to search a yet used term - so in the search term
>>> entry
>>> - in the current file's base directory, isn't it ?
>> Not exactly, I want to be able to search in the current document with
>> the search term given in the search term entry in the bottom panel.
> Mostly a task for the find dialog, isn't it ?
Yes, exactly.

>>> If so I must add another menu item to the pop menu.
> [snip]
>>> What do you think about that ??
>> This is another option, but it is not the same as I thought of. Maybe
>> it is more related to quicksearch plugin, now that I think about it.
> Yes, we could add a pop menu entry for the quickserch plugin.
Yes, maybe it's clearer.

>> What do you think if we restrict to maxdepth=3D1 for Darwin? =
Otherwise=20
>> it
>> will take ages before we can have something functional if ever.
> We can easily do it by hidding all the depth related widgets, and a
> couple of #ifdef.
> May be we could limit maxdepth meanwhile we don't find a better
> solution, and go for the release,
> The we could have time to further investigate those problems.
Yes, I think so, but don't impede other systems to use the most of it,=20=

just restrict it on systems where there are problems.

And while you're at release step, did you check the changes I've made=20
to quicksearch?

And I'm also finishing a plugin for the doc, the interface works fine=20
(load, unload of a new item in the plugin menu), now I wonder how to=20
open a browser, I don't want to use netscape or gtk-doc, but more a=20
default as dillo and then have a preferences where to change the=20
browser, i.e. Safari for example as a default on Mac, then if the user=20=

prefers Opera, Mozilla, etc..., he can change it, as in gimp for=20
example.

I'm about to love coding with you in C.

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] Changes in quicksearch plugin

[Iago R. <iag...@hi...>]

On Tue, 2004-09-14 at 13:30, Mich=C3=A8le Garoche wrote:
> Le 14 sept. 2004, =C3=A0 10:29, Iago Rubio a =C3=A9crit :
>=20
> > On Mon, 2004-09-13 at 21:42, Mich=C3=A8le Garoche wrote:
> >> I've made changes locally in quicksearch plugin, so that:
> >> 1 - It uses the convention for cssed plugin name
> >> 2 - It checks for the existence of a search term before starting the
> >> search
> >> Are you OK for this.
> >> If you're OK, I'll commit the changes, then have a look at them, since
> >> it's my first try changing the source (very newbye here).
> >
> > Ok, please commit those changes, so i can test it :)
> They are committed now. Here's the diff. And teach me what is wrong in=20
> it :-)

Absolutely nothing :))
>=20
> ______________________________________________________________________
--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[Iago R. <iag...@hi...>]

On Tue, 2004-09-14 at 17:11, Mich=C3=A8le Garoche wrote:
> Le 14 sept. 2004, =C3=A0 14:50, Iago Rubio a =C3=A9crit :
[snip]
> > If it's not, use the menu "In file's base directory". This should set
> > the base dir to the file's one, and search for the selected text.
> No it does not set the base dir if there is no previous base dir set in=20
> the bottom panel.

It's a bug.

> >> What I mean here is when using the contextual menu in the document and
> >> the search in file base's.
> > Sorry but I'm misunderstunding you :)
> > What you want is to search a yet used term - so in the search term=20
> > entry
> > - in the current file's base directory, isn't it ?
> Not exactly, I want to be able to search in the current document with=20
> the search term given in the search term entry in the bottom panel.

Mostly a task for the find dialog, isn't it ?

> > If so I must add another menu item to the pop menu.
[snip]
> > What do you think about that ??
> This is another option, but it is not the same as I thought of. Maybe=20
> it is more related to quicksearch plugin, now that I think about it.

Yes, we could add a pop menu entry for the quickserch plugin.

> >>> Does this command line freezes find (in a shell) ?
> >>> find `pwd` -print0 -type f -maxdepth 1 | xargs -0 grep -n term
> >> It seems too, already 10 minutes running, just because in the search
> >> directory there is a pipe, and it freezes at this level.
> > There's a bug here as `find -type -f` should discard named pipes.
> I think the problem is -print0 seels ti discard -type f effect.

Usually find separate file names with a carriage return, with -print0 it
changes the carriage return by a null character '\0'.

If it cxhanges find behaviour in any other way, it's a bug in find.

I must take a closer look at this.=20

> >> It reads ok up to .lyx, then freezes, but the ouput is not very=20
> >> useful:
> >> ...
> >> grep: /Users/michga/.gconf: Operation not permitted
> >> grep: /Users/michga/.gconfd: Operation not permitted
> > Also here as`find -type f` should discard directories.
> Same as above
>=20
> > I must test your `find` binary to check why it doesn't works.
> I know find is buggy on Mac OS X. Generally I search with:
>=20
> find path -name regex | xargs grep searchterm
>=20
> Or:
>=20
> sudo find path -name regex | xargs grep -wni
>=20
> What do you think if we restrict to maxdepth=3D1 for Darwin? Otherwise it=
=20
> will take ages before we can have something functional if ever.

We can easily do it by hidding all the depth related widgets, and a
couple of #ifdef.

May be we could limit maxdepth meanwhile we don't find a better
solution, and go for the release,

The we could have time to further investigate those problems.

--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[<mic...@ea...>]

Le 14 sept. 2004, =E0 14:50, Iago Rubio a =E9crit :
> On Tue, 2004-09-14 at 12:08, Mich=E8le Garoche wrote:
>> Le 14 sept. 2004, =E0 10:10, Iago Rubio a =E9crit :
>>> On Mon, 2004-09-13 at 21:39, Mich=E8le Garoche wrote:
>>>> Le 13 sept. 2004, =E0 15:08, Iago Rubio a =E9crit :
>>>> Besides, it will be a nice plus: you can search by selecting a word=20=

>>>> or
>>>> by entering a word in the search field, very useful when you want =
to
>>>> be
>>>> sure that a term does not exist in a file for example.
>>> You can do it right now. If you can't do it, it's a bug.
>>> Just type something in the search term entry and click "Find".
>> I only can do it if the base directory is set to the document's path.
> If it's not, use the menu "In file's base directory". This should set
> the base dir to the file's one, and search for the selected text.
No it does not set the base dir if there is no previous base dir set in=20=

the bottom panel.

>> What I mean here is when using the contextual menu in the document =
and
>> the search in file base's.
> Sorry but I'm misunderstunding you :)
> What you want is to search a yet used term - so in the search term=20
> entry
> - in the current file's base directory, isn't it ?
Not exactly, I want to be able to search in the current document with=20
the search term given in the search term entry in the bottom panel.

> If so I must add another menu item to the pop menu.
> Current ones:
> ->"In current base directory" - search for the selected text on=20
> document
> on the configured search base directory. Changes the text on the =
search
> term entry.
>
> ->"In file's base directory" - search for the selected text on the
> current document's base directory. Changes the text on the search term
> entry and in the base directory entry.
>
> Those could go to:
> Find in files -> Selected text -> "In current base directory"
> Find in files -> Selected text -> "In file's base directory"
>
> And add:
> ->"Search in file's base directory" - search for the configured search
> term in this file's base directory. Changes the base directory entry.
>
> So the final layout of this pop menu should be something like:
>
> Find In Files	-> "Search in file's base directory"
> 		-> Selected text -> "In current base directory"
> 		-> Selected text -> "In file's base directory"
>
> Quoted items are action widgets (will respond user's clicks).
>
> What do you think about that ??
This is another option, but it is not the same as I thought of. Maybe=20
it is more related to quicksearch plugin, now that I think about it.


>>> Does this command line freezes find (in a shell) ?
>>> find `pwd` -print0 -type f -maxdepth 1 | xargs -0 grep -n term
>> It seems too, already 10 minutes running, just because in the search
>> directory there is a pipe, and it freezes at this level.
> There's a bug here as `find -type -f` should discard named pipes.
I think the problem is -print0 seels ti discard -type f effect.

>> It reads ok up to .lyx, then freezes, but the ouput is not very=20
>> useful:
>> ...
>> grep: /Users/michga/.gconf: Operation not permitted
>> grep: /Users/michga/.gconfd: Operation not permitted
> Also here as`find -type f` should discard directories.
Same as above

> I must test your `find` binary to check why it doesn't works.
I know find is buggy on Mac OS X. Generally I search with:

find path -name regex | xargs grep searchterm

Or:

sudo find path -name regex | xargs grep -wni

What do you think if we restrict to maxdepth=3D1 for Darwin? Otherwise =
it=20
will take ages before we can have something functional if ever.

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[Iago R. <iag...@hi...>]

On Tue, 2004-09-14 at 12:08, Mich=C3=A8le Garoche wrote:
> Le 14 sept. 2004, =C3=A0 10:10, Iago Rubio a =C3=A9crit :
> > On Mon, 2004-09-13 at 21:39, Mich=C3=A8le Garoche wrote:
> >> Le 13 sept. 2004, =C3=A0 15:08, Iago Rubio a =C3=A9crit :
> >> Besides, it will be a nice plus: you can search by selecting a word or
> >> by entering a word in the search field, very useful when you want to=20
> >> be
> >> sure that a term does not exist in a file for example.
> > You can do it right now. If you can't do it, it's a bug.
> > Just type something in the search term entry and click "Find".
> I only can do it if the base directory is set to the document's path.

If it's not, use the menu "In file's base directory". This should set
the base dir to the file's one, and search for the selected text.

> What I mean here is when using the contextual menu in the document and=20
> the search in file base's.

Sorry but I'm misunderstunding you :)

What you want is to search a yet used term - so in the search term entry
- in the current file's base directory, isn't it ?

If so I must add another menu item to the pop menu.

Current ones:
->"In current base directory" - search for the selected text on document
on the configured search base directory. Changes the text on the search
term entry.

->"In file's base directory" - search for the selected text on the
current document's base directory. Changes the text on the search term
entry and in the base directory entry.

Those could go to:
Find in files -> Selected text -> "In current base directory"
Find in files -> Selected text -> "In file's base directory"

And add:
->"Search in file's base directory" - search for the configured search
term in this file's base directory. Changes the base directory entry.

So the final layout of this pop menu should be something like:

Find In Files	-> "Search in file's base directory"=20
		-> Selected text -> "In current base directory"
		-> Selected text -> "In file's base directory"=20

Quoted items are action widgets (will respond user's clicks).

What do you think about that ??
=09
[snip]
> > Does this command line freezes find (in a shell) ?
> > find `pwd` -print0 -type f -maxdepth 1 | xargs -0 grep -n term
> It seems too, already 10 minutes running, just because in the search=20
> directory there is a pipe, and it freezes at this level.

There's a bug here as `find -type -f` should discard named pipes.

> It reads ok up to .lyx, then freezes, but the ouput is not very useful:
> ...
> grep: /Users/michga/.gconf: Operation not permitted
> grep: /Users/michga/.gconfd: Operation not permitted

Also here as`find -type f` should discard directories.

I must test your `find` binary to check why it doesn't works.
--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD

Re: [cssed-devel] Changes in quicksearch plugin

[<mic...@ea...>]

Le 14 sept. 2004, à 10:29, Iago Rubio a écrit :

> On Mon, 2004-09-13 at 21:42, Michèle Garoche wrote:
>> I've made changes locally in quicksearch plugin, so that:
>> 1 - It uses the convention for cssed plugin name
>> 2 - It checks for the existence of a search term before starting the
>> search
>> Are you OK for this.
>> If you're OK, I'll commit the changes, then have a look at them, since
>> it's my first try changing the source (very newbye here).
>
> Ok, please commit those changes, so i can test it :)
They are committed now. Here's the diff. And teach me what is wrong in 
it :-)

[cssed-devel] Improved English wording in cssed-findinfiles-plugin

[<mic...@ea...>]

Here are some minor changes to various files.

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[<mic...@ea...>]

Le 14 sept. 2004, =E0 10:10, Iago Rubio a =E9crit :
> On Mon, 2004-09-13 at 21:39, Mich=E8le Garoche wrote:
>> Le 13 sept. 2004, =E0 15:08, Iago Rubio a =E9crit :
>> Besides, it will be a nice plus: you can search by selecting a word =
or
>> by entering a word in the search field, very useful when you want to=20=

>> be
>> sure that a term does not exist in a file for example.
> You can do it right now. If you can't do it, it's a bug.
> Just type something in the search term entry and click "Find".
I only can do it if the base directory is set to the document's path.

What I mean here is when using the contextual menu in the document and=20=

the search in file base's.

>>> Test fix in CVS.
>>> Patch attached.
>> I've not integrated it since it freezes completely find on the =
command
>> line.
> Does this command line freezes find (in a shell) ?
> find `pwd` -print0 -type f -maxdepth 1 | xargs -0 grep -n term
It seems too, already 10 minutes running, just because in the search=20
directory there is a pipe, and it freezes at this level.

...
drwxr-xr-x   21 michga  michga      714B 29 jui 11:39 .lyx/
prw-r--r--    1 michga  michga        0B 29 jui 08:44 .lyxpipe.in|
prw-r--r--    1 michga  michga        0B 29 jui 08:44 .lyxpipe.out|
-rw-r--r--    1 michga  michga       28B  3 jan  2004 .mailcap
...

It reads ok up to .lyx, then freezes, but the ouput is not very useful:
...
grep: /Users/michga/.gconf: Operation not permitted
grep: /Users/michga/.gconfd: Operation not permitted
/Users/michga/.gdb_history:1:file=20
/sw/src/cssed-0.2.1-17/cssed-0.2.1/src/cssed
grep: /Users/michga/.gimp-1.2: Operation not permitted
...

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] Changes in quicksearch plugin

[Iago R. <iag...@hi...>]

On Mon, 2004-09-13 at 21:42, Mich=C3=A8le Garoche wrote:
> I've made changes locally in quicksearch plugin, so that:
>=20
> 1 - It uses the convention for cssed plugin name
> 2 - It checks for the existence of a search term before starting the=20
> search
>=20
> Are you OK for this.
> If you're OK, I'll commit the changes, then have a look at them, since=20
> it's my first try changing the source (very newbye here).

Ok, please commit those changes, so i can test it :)

--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD

Re: [cssed-devel] Correct string in cssdialogs-menu.c

[Iago R. <iag...@hi...>]

On Mon, 2004-09-13 at 22:37, Mich=C3=A8le Garoche wrote:
> I've changed an erroneous string in cssdialogs-menu.c (line 581), long=20
> standing bug.
>=20
> Then minor change to Spanish translation:  when no match is found in=20
> search.
>=20
> All committed, please update your copy.

Great, thanks !!
--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[Iago R. <iag...@hi...>]

On Mon, 2004-09-13 at 21:39, Mich=C3=A8le Garoche wrote:
> Le 13 sept. 2004, =C3=A0 15:08, Iago Rubio a =C3=A9crit :
[snip]
> > The behaviour will be (?):
> >
> > 	1.- if no text selection, when clicked "In file's base dir", change
> > just the base directory and avoid to start the search.
> >
> > 	2.- if no text selection, when clicked "In file's base dir", change=20
> > the
> > base directory and search for the current search term.
> 2 is better since it allows the user to search for a term in the active=20
> document without the need to first either type the word in the file and=20
> select it or search for the word and select (which is kind of weird=20
> when the plugin claims precisely to be a search plugin :-).

Will go for it then.

> Besides, it will be a nice plus: you can search by selecting a word or=20
> by entering a word in the search field, very useful when you want to be=20
> sure that a term does not exist in a file for example.

You can do it right now. If you can't do it, it's a bug.

Just type something in the search term entry and click "Find".

[snip]
> >> And precisely in WasonDesktop, there are a bunch of files containing
> >> "cssed", which was the search term.
> >> After investigating more, the problem raises when encountering a file
> >> with a space in it, very frequent on Mac.
> >
> > Ah! I see now. It can be easily solved. I will test an approach.
> >
> > Could you please try this command line to test if it correnctly handles
> > file names with embeded spaces ?
> >
> > find /path/to/find -print0 -type f | xargs -0 grep -n search_term
> I have to cancel the find, it does not end.
> Plus it searches in all files, all depth.

It's the intended behaviour of find. If you don't set maxdepth it will
find recursively in all subfolders.
=20
Setting maxdepth it should work.

> > Quick explaination: 'find -print0' will null terminate the file names,
> > 'xargs -0' will search for the null character to get the end of file's
> > name.
> > I think it should work even with carriage return embeded file names.
> That's not a carriage return (it is not an authorized character), it is=20
> a space (code 32).

Yes :) , what I meant is it will work with any file name (even weirdest
ones).

> > Test fix in CVS.
> > Patch attached.
> I've not integrated it since it freezes completely find on the command=20
> line.

Does this command line freezes find (in a shell) ?
find `pwd` -print0 -type f -maxdepth 1 | xargs -0 grep -n term

--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD

[cssed-devel] Correct string in cssdialogs-menu.c

[<mic...@ea...>]

I've changed an erroneous string in cssdialogs-menu.c (line 581), long 
standing bug.

Then minor change to Spanish translation:  when no match is found in 
search.

All committed, please update your copy.

Here's the diff:

[cssed-devel] Changes in quicksearch plugin

[<mic...@ea...>]

I've made changes locally in quicksearch plugin, so that:

1 - It uses the convention for cssed plugin name
2 - It checks for the existence of a search term before starting the=20
search

Are you OK for this.

If you're OK, I'll commit the changes, then have a look at them, since=20=

it's my first try changing the source (very newbye here).

Mich=E8le
<http://micmacfr.homeunix.org>=

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[<mic...@ea...>]

Le 13 sept. 2004, =E0 15:08, Iago Rubio a =E9crit :
> On Mon, 2004-09-13 at 00:57, Mich=E8le Garoche wrote:
>> Le 12 sept. 2004, =E0 21:42, Iago Rubio a =E9crit :
>>>> When using the popup menu in the editor window to search for terms=20=

>>>> and
>>>> if no term is selected in the current file, there is no refresh of=20=

>>>> the
>>>> base directory in the plugin. This only occurs when a search term =
is
>>>> selected in the active file.  A bit confusing for me here.
>>> What pop menu entry, "In current base dir" or "In file's base dir" ?
>> I think the problem does not even raise as far as the current base =
dir
>> is concerned, or maybe I don't understand what is the current base=20
>> dir.
>
> Yes, this is completly confusing.
>
> The "Current base dir" speaks about the current base directory in the
> "Base dir" entry. Not the file's base directory nor the application's
> current directory.
OK, but in the test I've made, it was the same, so that's why I said=20
the problem did not araise.

> The behaviour will be (?):
>
> 	1.- if no text selection, when clicked "In file's base dir", =
change
> just the base directory and avoid to start the search.
>
> 	2.- if no text selection, when clicked "In file's base dir", =
change=20
> the
> base directory and search for the current search term.
2 is better since it allows the user to search for a term in the active=20=

document without the need to first either type the word in the file and=20=

select it or search for the word and select (which is kind of weird=20
when the plugin claims precisely to be a search plugin :-).

Besides, it will be a nice plus: you can search by selecting a word or=20=

by entering a word in the search field, very useful when you want to be=20=

sure that a term does not exist in a file for example.

>>>> When the search process encounters a special file, the search takes
>>>> ages to end and there is a you can have the same error message as =
in
>>>> filebrowser plugin, just to reassure the user.
>>> Hmmm! It should not search into special file (mean character devices
>>> and
>>> such) as we are passing find the "-type -f" parameter.
>>> Could you tell me how to reproduce it ? or, What kind of special =
file
>>> is
>>> opened by the proccess ?
>> Actually I thought that was a special file encountered, because the
>> result does not give all the strings in a row, and I know I have more
>> reference to the search term later in a subdirectory of the base
>> directory. But the problem may not be this one, it seems that there =
is
>> a limit to the number of lines or maybe the buffer size, so that all
>> results are not displayed in a row.
> It seems to be a bug.
>> There is a long time when it seems
>> to do nothing then some other strings are shown, then search, but
>> definitively not all strings are shown. So either, there is a problem
>> of size or some character in a file which is interpreted as command =
or
>> something else which confuses the program. I get those warnings in
>> console:
>>
>> This is the last line shown in cssed (same on the command line, so=20
>> it's
>> not inherent to cssed):
>> ./html/user_interface.html:15: <a class=3D"el"
>> href=3D"index.html#index">Main Page</a> <hr size=3D"1"><address
>> style=3D"align: right;"><small>Generated on Wed Aug 11 22:33:33 2004 =
for
>> cssed plugable interface by
>>
>> Then the warnings in console (fully false since those files exist).
>> grep: ./Pictures/Portraits: No such file or directory
>> grep: choisis.pnpCatalog: No such file or directory
>>
>> grep: ./WasonDesktop/Sans: No such file or directory
>> grep: titre: No such file or directory
>> grep: 3.rtf: No such file or directory
>>
>> grep: ./WasonDesktop/Sans: No such file or directory
>> grep: titre.txt: No such file or directory
>
>> And precisely in WasonDesktop, there are a bunch of files containing
>> "cssed", which was the search term.
>> After investigating more, the problem raises when encountering a file
>> with a space in it, very frequent on Mac.
>
> Ah! I see now. It can be easily solved. I will test an approach.
>
> Could you please try this command line to test if it correnctly =
handles
> file names with embeded spaces ?
>
> find /path/to/find -print0 -type f | xargs -0 grep -n search_term
I have to cancel the find, it does not end.
Plus it searches in all files, all depth.

>
> Quick explaination: 'find -print0' will null terminate the file names,
> 'xargs -0' will search for the null character to get the end of file's
> name.
> I think it should work even with carriage return embeded file names.
That's not a carriage return (it is not an authorized character), it is=20=

a space (code 32).

> Test fix in CVS.
> Patch attached.
I've not integrated it since it freezes completely find on the command=20=

line.

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[Iago R. <iag...@hi...>]

On Mon, 2004-09-13 at 00:57, Michèle Garoche wrote:
> Le 12 sept. 2004, à 21:42, Iago Rubio a écrit :
> 
> > On Sun, 2004-09-12 at 12:27, Michèle Garoche wrote:
> >> When changing the base directory for search, the selection is not
> >> refresh in the base directory dialog (the field at the bottom), though
> >> the right directory is selected.
> > I think it's now fixed in CVS.
> Yes, it is.

Great.

> >> In the same dialog, the popupmenu does not reflect the last base
> >> directory.
> > Yes, it's a GtkFileSelection dialog and does not implement those bits
> > itself.
> > I must wrote support fot this, but I was thinking about to change the
> > base directory entry, by adding a combo box with the last opened
> > directories, as in the file browser.
> Oh, yes, it would be far better, and also add kind of consistency in 
> the UI. From the user's point of view, it is worth to do it.
> Maybe a clean button to clear the result page would be fine too.

Ok, will go for it then.

> >> If the permission is denied to enter a given directory, there is no
> >> error message shown to the user, but instead a dialog window shows as
> >> if you can enter in it, though the selection does not change. I think
> >> first it's very confusing to the user, second it gives a huge
> >> impression of insecurity, not good at all for cssed. Here we should
> >> have an error message= "You have not the required permissions to 
> >> access
> >> this directory".
> > Unfortunately it's a GTK bug. THis behaviour is exposed by each
> > application using the Gtk file selector.
> > It will be soon deprecated, as the new GtkFileChooser have been 
> > released
> > so I don't think Gtk developers will try a fix of this.
> > May be we should file a bug in bugzilla.
> Yes, it does not hurt.

As I supposed:

From Owen Taylor 2004-09-13 08:10 
"We won't be enhancing the old GtkFileSelection widget at all at this point."

http://bugzilla.gnome.org/show_bug.cgi?id=152492

> >> When searching if no match at all is found, there should be a warning
> >> for the user, so that it is clear the search has been performed.
> > Fixed in CVS. Now it's shown a message at search start and end.
> Yes, it is perfect.

Ok.

> >> When using the popup menu in the editor window to search for terms and
> >> if no term is selected in the current file, there is no refresh of the
> >> base directory in the plugin. This only occurs when a search term is
> >> selected in the active file.  A bit confusing for me here.
> > What pop menu entry, "In current base dir" or "In file's base dir" ?
> I think the problem does not even raise as far as the current base dir 
> is concerned, or maybe I don't understand what is the current base dir.

Yes, this is completly confusing.

The "Current base dir" speaks about the current base directory in the
"Base dir" entry. Not the file's base directory nor the application's
current directory.

It occurs when selecting the "In file's base dir".

I see now. 

Well, will go for it then. 

The behaviour will be (?): 

	1.- if no text selection, when clicked "In file's base dir", change
just the base directory and avoid to start the search. 

	2.- if no text selection, when clicked "In file's base dir", change the
base directory and search for the current search term. 
 
> >> When the search process encounters a special file, the search takes
> >> ages to end and there is a you can have the same error message as in
> >> filebrowser plugin, just to reassure the user.
> > Hmmm! It should not search into special file (mean character devices 
> > and
> > such) as we are passing find the "-type -f" parameter.
> > Could you tell me how to reproduce it ? or, What kind of special file 
> > is
> > opened by the proccess ?
> Actually I thought that was a special file encountered, because the 
> result does not give all the strings in a row, and I know I have more 
> reference to the search term later in a subdirectory of the base 
> directory. But the problem may not be this one, it seems that there is 
> a limit to the number of lines or maybe the buffer size, so that all 
> results are not displayed in a row.

It seems to be a bug.

> There is a long time when it seems 
> to do nothing then some other strings are shown, then search, but 
> definitively not all strings are shown. So either, there is a problem 
> of size or some character in a file which is interpreted as command or 
> something else which confuses the program. I get those warnings in 
> console:
> 
> This is the last line shown in cssed (same on the command line, so it's 
> not inherent to cssed):
> ./html/user_interface.html:15: <a class="el" 
> href="index.html#index">Main Page</a> <hr size="1"><address 
> style="align: right;"><small>Generated on Wed Aug 11 22:33:33 2004 for 
> cssed plugable interface by
> 
> Then the warnings in console (fully false since those files exist).
> grep: ./Pictures/Portraits: No such file or directory
> grep: choisis.pnpCatalog: No such file or directory
> 
> grep: ./WasonDesktop/Sans: No such file or directory
> grep: titre: No such file or directory
> grep: 3.rtf: No such file or directory
> 
> grep: ./WasonDesktop/Sans: No such file or directory
> grep: titre.txt: No such file or directory

> And precisely in WasonDesktop, there are a bunch of files containing 
> "cssed", which was the search term.
> After investigating more, the problem raises when encountering a file 
> with a space in it, very frequent on Mac. 

Ah! I see now. It can be easily solved. I will test an approach.

Could you please try this command line to test if it correnctly handles
file names with embeded spaces ?

find /path/to/find -print0 -type f | xargs -0 grep -n search_term

Quick explaination: 'find -print0' will null terminate the file names,
'xargs -0' will search for the null character to get the end of file's
name.

I think it should work even with carriage return embeded file names. 

Tested in Linux and BSD (where exists the same problem but I don't use
spaces in file names, so I didn't noticed it).

Test fix in CVS.

Patch attached.

> It confuses completely find, 
> hence cssed. And it could lead to a crash. (I've separated the warnings 
> above so that you could retrieve the name of the files - there are 3 
> files, but grep reads them as if there were 7 files.

Thanks for the fine report :)

No I clearly see the errors.

Will try to fix all them today.
-- 
Iago Rubio   
- Home page    * http://www.iagorubio.com 
- Last project * http://cssed.sourceforge.net         
- GPG Keyserv  * pgp.rediris.es id=0x909BD4DD

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[<mic...@ea...>]

Le 12 sept. 2004, =E0 21:42, Iago Rubio a =E9crit :

> On Sun, 2004-09-12 at 12:27, Mich=E8le Garoche wrote:
>> When changing the base directory for search, the selection is not
>> refresh in the base directory dialog (the field at the bottom), =
though
>> the right directory is selected.
> I think it's now fixed in CVS.
Yes, it is.

>> In the same dialog, the popupmenu does not reflect the last base
>> directory.
> Yes, it's a GtkFileSelection dialog and does not implement those bits
> itself.
> I must wrote support fot this, but I was thinking about to change the
> base directory entry, by adding a combo box with the last opened
> directories, as in the file browser.
Oh, yes, it would be far better, and also add kind of consistency in=20
the UI. =46rom the user's point of view, it is worth to do it.
Maybe a clean button to clear the result page would be fine too.

>> If the permission is denied to enter a given directory, there is no
>> error message shown to the user, but instead a dialog window shows as
>> if you can enter in it, though the selection does not change. I think
>> first it's very confusing to the user, second it gives a huge
>> impression of insecurity, not good at all for cssed. Here we should
>> have an error message=3D "You have not the required permissions to=20
>> access
>> this directory".
> Unfortunately it's a GTK bug. THis behaviour is exposed by each
> application using the Gtk file selector.
> It will be soon deprecated, as the new GtkFileChooser have been=20
> released
> so I don't think Gtk developers will try a fix of this.
> May be we should file a bug in bugzilla.
Yes, it does not hurt.

>> When searching if no match at all is found, there should be a warning
>> for the user, so that it is clear the search has been performed.
> Fixed in CVS. Now it's shown a message at search start and end.
Yes, it is perfect.

>> When using the popup menu in the editor window to search for terms =
and
>> if no term is selected in the current file, there is no refresh of =
the
>> base directory in the plugin. This only occurs when a search term is
>> selected in the active file.  A bit confusing for me here.
> What pop menu entry, "In current base dir" or "In file's base dir" ?
I think the problem does not even raise as far as the current base dir=20=

is concerned, or maybe I don't understand what is the current base dir.
It occurs when selecting the "In file's base dir".

>> When the search process encounters a special file, the search takes
>> ages to end and there is a you can have the same error message as in
>> filebrowser plugin, just to reassure the user.
> Hmmm! It should not search into special file (mean character devices=20=

> and
> such) as we are passing find the "-type -f" parameter.
> Could you tell me how to reproduce it ? or, What kind of special file=20=

> is
> opened by the proccess ?
Actually I thought that was a special file encountered, because the=20
result does not give all the strings in a row, and I know I have more=20
reference to the search term later in a subdirectory of the base=20
directory. But the problem may not be this one, it seems that there is=20=

a limit to the number of lines or maybe the buffer size, so that all=20
results are not displayed in a row. There is a long time when it seems=20=

to do nothing then some other strings are shown, then search, but=20
definitively not all strings are shown. So either, there is a problem=20
of size or some character in a file which is interpreted as command or=20=

something else which confuses the program. I get those warnings in=20
console:

This is the last line shown in cssed (same on the command line, so it's=20=

not inherent to cssed):
./html/user_interface.html:15: <a class=3D"el"=20
href=3D"index.html#index">Main Page</a> <hr size=3D"1"><address=20
style=3D"align: right;"><small>Generated on Wed Aug 11 22:33:33 2004 for=20=

cssed plugable interface by

Then the warnings in console (fully false since those files exist).
grep: ./Pictures/Portraits: No such file or directory
grep: choisis.pnpCatalog: No such file or directory

grep: ./WasonDesktop/Sans: No such file or directory
grep: titre: No such file or directory
grep: 3.rtf: No such file or directory

grep: ./WasonDesktop/Sans: No such file or directory
grep: titre.txt: No such file or directory

And precisely in WasonDesktop, there are a bunch of files containing=20
"cssed", which was the search term.

After investigating more, the problem raises when encountering a file=20
with a space in it, very frequent on Mac. It confuses completely find,=20=

hence cssed. And it could lead to a crash. (I've separated the warnings=20=

above so that you could retrieve the name of the files - there are 3=20
files, but grep reads them as if there were 7 files.

Mich=E8le
<http://micmacfr.homeunix.org>

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[Iago R. <iag...@hi...>]

On Sun, 2004-09-12 at 12:27, Michèle Garoche wrote:
> When changing the base directory for search, the selection is not 
> refresh in the base directory dialog (the field at the bottom), though 
> the right directory is selected.

I think it's now fixed in CVS.

> In the same dialog, the popupmenu does not reflect the last base 
> directory.

Yes, it's a GtkFileSelection dialog and does not implement those bits
itself.

I must wrote support fot this, but I was thinking about to change the
base directory entry, by adding a combo box with the last opened
directories, as in the file browser.

> If the permission is denied to enter a given directory, there is no 
> error message shown to the user, but instead a dialog window shows as 
> if you can enter in it, though the selection does not change. I think 
> first it's very confusing to the user, second it gives a huge 
> impression of insecurity, not good at all for cssed. Here we should 
> have an error message= "You have not the required permissions to access 
> this directory".

Unfortunately it's a GTK bug. THis behaviour is exposed by each
application using the Gtk file selector.

It will be soon deprecated, as the new GtkFileChooser have been released
so I don't think Gtk developers will try a fix of this.

May be we should file a bug in bugzilla. 

> When searching if no match at all is found, there should be a warning 
> for the user, so that it is clear the search has been performed.

Fixed in CVS. Now it's shown a message at search start and end.

> When using the popup menu in the editor window to search for terms and 
> if no term is selected in the current file, there is no refresh of the 
> base directory in the plugin. This only occurs when a search term is 
> selected in the active file.  A bit confusing for me here.

What pop menu entry, "In current base dir" or "In file's base dir" ?

> When the search process encounters a special file, the search takes 
> ages to end and there is a you can have the same error message as in 
> filebrowser plugin, just to reassure the user.

Hmmm! It should not search into special file (mean character devices and
such) as we are passing find the "-type -f" parameter.

Could you tell me how to reproduce it ? or, What kind of special file is
opened by the proccess ?

> More on that later.

Thanks in advance :)

Attached patch with those fixes.
-- 
Iago Rubio   
- Home page    * http://www.iagorubio.com 
- Last project * http://cssed.sourceforge.net         
- GPG Keyserv  * pgp.rediris.es id=0x909BD4DD