Web lists-archives.com

Re: Caja's file search --- BUG or Feature?

On 3/10/19, Richard Owlett <rowlett@xxxxxxxxxxx> wrote:
> I'm running Stretch with MATE desktop.
> If I submit a sub-string of a filename to "MATE Search Tool", *ANY* hit
> reports the full path to the target. That is *GOOD*!
> HOWEVER, if I'm exploring a specific directory with Caja and then search
> for the *IDENTICAL* sub-string I get a "hit" with ABSOLUTELY no
> indication of the file's location :{
> My test case:
> I created a test file at
> /home/richard/Downloads/tk8.6.9/tests/ttk/owltstmarch9 .
> I hope that is arbitrary enough ;}
> Using 'march' as test string when using:
>   1. "MATE Search Tool" yields exact location.
>   2, Caja admits file exists *SOMEWHERE*
> As an end USER:
>   1. "MATE Search Tool" gives expected result - i.e. giving
>       full path to target.
>   2. Caja's search otherwise:
>      A. The first time I used it, I expected to get hits *ONLY*
>         in the current sub-directory.
>      B. However it reports hits for *ANY* sub-directory at or
>         below the current one. This can be very useful.
>         *HOWEVER* it's usefulness is reduced by not reporting the
>         full path to the target.
> Comments?

#GlassHalfFull: Thank goodness it only grabs from the bottom shelves
and doesn't also reach up over its head into higher parent directories
for those inquires. A developer type file name such as /readme.md or
/make comes to mind as an example there.

Since *your experience* is that Caja does only reach deeper into
[child] directories and not back up overhead, is there maybe something
explicitly expressed in their documentation that covers that feature?

If no documentation on the topic can be found AND so a bug report is
to be filed, a user could state that the current behavior inhibit's
the user's perception of full usability. The user could then offer a
bug report disclaimer stating that the user understands that the
current behavior may be by conscious design so maybe this is a
wishlist bug report item, instead.

A wishlist bug report could suggest that it would be nice to be
offered a toggle-able, e.g. radio button or checkbox type, option that

* Only searches deeper into the file hierarchy thus still honoring the
maintainers' conscious current intended status quo..


* Searches the entire file hierarchy then provides query results that
include easily cull-able, usability-friendly full file paths.

It is a curious feature for which I can't immediately think of a usage
case. All that means is I've simply never encountered a situation that
mandated just such a search. *I think* the MANY searches I've done
over the years have been with the intention of needing that full file
path to accomplish whatever related task had instigated each search.

Cindy :)
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *