1) We chopped the input into only one word so the script can handle it better and not throw to the tooltip a big error. I put this stripping / to the query string, however it really should move to the search_docs(query) command, where we are executing the search. Sorry but I did add to there and break the ruby code.

Ctrl-H --> documentation_for_word() --> search_docs_all(query) --> search_docs(query)**  --> docsetutil 
Ctrl-H --> documentation_for_word() --> search_docs_all(query) --> man_page(query)**     --> man 



2) If we keep the full string in query variable, then when we print the tooltip, we can show the full text back to the user.
As it stands we show back the doctored text, i.e. the first word or line of the selected text. 


3) With the latest (above) the command it still may not execute right for conditions where there are spaces, tabs, or newline characters etc before the text point. So cleaning up the input should be tested and tweaked some more.

4) If the word is wrapped in square brackets. e.g. [NSArray] - then TM_SELECTED_TEXT will not work but TM_CURRENT_WORD will.
Again, a better place to sanitize this input may be either search_docs(query) or search_docs_all(query)




5) If we have just run the command (Ctrl-H) then we have opened a Web-window and not a text window.
Can we press Ctrl-H here (in the html window) to bring up the dialog again to perform another search? 

This would be much more convenient when we are engaged in the activity only for searching, and reading documentation.
Not to need to switch back to the working document, to run this command ? 



6) As Allan wants we will show the search box only conditionally, when there isnt a current word on the caret. However it would be a nice option to have for those who always want to show it. This may sound like a personal request, however i would be very grateful because pressing Ctrl-W is very much more difficult with RSI than to press enter key with the dialog. So to check on TM_DOC_SEARCH_BOX_ALWAYS or a defaulted argument will allow the user to customise :)

def documentation_for_word( show_always = FALSE ) ?




dreamcat7
dreamcat7@googlemail.com


On 7 Jan 2009, at 21:15, dreamcat7 wrote:

Done - patch available.
Hope they're in the right format, etc.

dreamcat4: patch-1 (trunk/support) http://pastie.org/354995

<dreamcat7-searchbox.patch>
 
<SearchBox.nib>

dreamcat4: patch-2 (trunk/Bundles/Objective-C.tmbundle) http://pastie.org/355007


 <dreamcat7-objc_docset_query.patch>

 


On 6 Jan 2009, at 03:15, Allan Odgaard wrote:

On 1 Jan 2009, at 14:56, dreamcat7 wrote:

[...] searches on Apple Docset [...]
To access this feature you must type in and select the word into your
document before proceeding.

You needn’t select it, just have the caret “on it”.

However it strikes me that adding an alternative method to use the  
script (probably a Search box) could be useful.

Great idea. I often type in keywords followed by ⌃H, but we could  
make ⌃H popup a dialog when there is no current word (or word is not  
found), we do that for ⌃H in HTML mode (and maybe a few others).

We can’t really do a list of terms (to filter) though since there are  
thousands of terms and we don’t really know them beforehand.

Or perhaps we will need some kind of re-write because there another  
place at the beginning of the file where "the selected word" is used  
for input?

Yeah, I don’t think it is an easy change, also because we have  
different doc commands depending on context in Objective-C. The stuff  
is long overdue for refactoring though.


_______________________________________________
textmate mailing list
textmate@lists.macromates.com
http://lists.macromates.com/listinfo/textmate