CoCoA » CoCoA-5

I suggest transforming the search string as follows:

• replace all TABs (and any other whitespace chars) by plain spaces
• replace substrings of consecutive spaces by single spaces

I believe spaces at the start and end are already stripped.

? file io --> ? file io

? factor ; abcdefg --> don't know, maybe ? factor

? factor -- comment
? factor // comment --> ? factor

? ? factor // same as ?? factor --> I prefer ? factor

? #illegal char --> don't know, maybe I would just ignore the illegal char
? "string" --> ? string (i.e. ignore quotes)

[...]

Here are the special chars which I have noticed in the manual page headings (obtained by typing just ?):

• comma (to separate several names in the title, e.g. BinomialRepr, BinomialReprShift)
• square brackets (to contain [OBSOLESCENT])
• digits (e.g. Bool01 and BlockMat2x2)
• minus sign (_e.g. CoCoA-4 mode)
• underscore (only in E_ [OBSOLETE]) -- we have both OBSOLETE and OBSOLESCENT??
• colon (e.g. in Tutorial-01: manual)

However the manual search will also search for substrings in the text of a page, thus the following works:

? <>

I think my current preference is not to do anything "clever" with unusual chars: if the user types in a strange char in a manual search then CoCoA will just respond with a message No matches for "bla bla".

I could easily be convinced that double quotes should be silently ignored in manual searches; so the following queries would all be equivalent:

? factor
? "factor" 
? "f"a"c"t"o"r" 

Comments? Opinions? Ideas?

John Abbott wrote:

I think my current preference is not to do anything "clever" with unusual chars: if the user types in a strange char in a manual search then CoCoA will just respond with a message No matches for "bla bla".

I agree

I could easily be convinced that double quotes should be silently ignored in manual searches;

I find the last one a bit funny, but this strategy it the less painful to allow
? "factor"

Yes, the last example was deliberately strange; I do not think it matters if such a strange input works...

Maybe I'll implement it, and we can try it...

John Abbott wrote:

Yes, the last example was deliberately strange; I do not think it matters if such a strange input works...

Maybe I'll implement it, and we can try it...

OK

I am still a bit undecided how best to handle double quotes. I see 3 reasonable options:

1. leave them as they are
2. remove them completely
3. regard them as equivalent to spaces

Approach (1) is the easiest to implement; the user just has to learn to use them only when really needed (when???)
Approach (2) is easy to state but might produce unexpected results ("f"a"c"t"o"r" --> factor)
Approach (3) might be fairly natural....? (this implies "f"a"c"t"o"r" --> f a c t o r)

Opinions?

NOTE I have just checked-in the code "as is"; this implies approach (1) for the moment.