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