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>