Suggest more doc for call tips and a possible call tip extension

[Greg Smith]

I have spent some interesting time attempting to allow nested tooltips, that is when the arguments to a function are also functions, so the tooltips need to change as you type, then revert to previous tips.

A user was very keen that erasing should allow you to restore previous tips, and I have just about figured out that this is possible... but you have to mess about a lot due to the way that Scintilla decides if it should remove a tip when you delete.

The documentation says:

SCI_CALLTIPCANCEL
This message cancels any displayed call tip. Scintilla will also cancel call tips for you if you use any keyboard commands that are not compatible with editing the argument list of a function.

Can I suggest that you add: Call tips are erased if you delete back past the position that the caret was in when the tip was triggered.

Also, for SCI_CALLTIPSHOW, it would be worth adding that Scintilla stores the current position when the tip is started. The position passed in is solely used for tip alignment.

The problem with Scintilla automatically killing tips is that it makes it much harder to write fancier tip mechanisms as you have to work around the tips being deleted for you, and when you try to revert to an older tip, you have to move the caret to a fake position in order to recreate the previous tip, then restore the caret to the original position.

I wonder if we need an option to stop Scintilla killing off tips itself so that this becomes the containers responsibility... or at least allow erase back and adding a new line to not kill it off so that continuous typing does not kill it.

I think there was another post along these lines recently.

All the best,

Greg Smith

[Neil Hodgson]

Post by Greg Smith
SCI_CALLTIPCANCEL
This message cancels any displayed call tip. Scintilla will also cancel call tips for you if you use any keyboard commands that are not compatible with editing the argument list of a function.
Can I suggest that you add: Call tips are erased if you delete back past the position that the caret was in when the tip was triggered.
Also, for SCI_CALLTIPSHOW, it would be worth adding that Scintilla stores the current position when the tip is started. The position passed in is solely used for tip alignment.

OK.
https://sourceforge.net/p/scintilla/code/ci/6850722b53d0929accc4f712386f2728650a6a70/

Post by Greg Smith
I wonder if we need an option to stop Scintilla killing off tips itself so that this becomes the containers responsibility... or at least allow erase back and adding a new line to not kill it off so that continuous typing does not kill it.

It can be difficult for the application code to track what is happening and so cancel the call tip. There will have to be client code active with each key press to cancel if needed and that code could be inverted to reshow using the current API. Try removing the the first two calls to ct.CallTipCancel in ScintillaBase.cxx and adding application code to perform cancels. This may help discover which behaviour can be reasonably turned off with an option.

There could be a call to explicitly set posStartCallTip, even to INVALID_POSITION (-1).

Neil

[Greg Smith]

Thanks for the doc update.

I suceeded in making nested tips work by saving the current caret position,
setting the position that correponded to the opening bracket of my
function, killing the old tip, creating a new one, then restoring the caret
position. Although a bit tedious, it is not difficult, once you understand
what is required... An extra call to set the "cancel" position (with -1
meaning none) would reduce the container code a little... maybe reuse the
current start call tip code with a nullptr for the text would be the least
code way to do this with no backward compatibility problems. Alternatively
we could have a more advanced start tip that passes in a structure that
contains the text and two positions to do the job in one call. WThe
structure might also include flags for what kills off the tip automatically.

It is a bit tricky to see how to improve call tip handling. At the moment,
for example, tips are removed if you use cursor up or down, but not for
cursor left and right, which allows you to (perversely) drive the cursor
miles away from the tip. A better rule might be to keep tips while you type
characters and delete back (up to the original caret position), but remove
the tip for anything else... you might treat cursor left rather like delete
back, so going past the start removes the tip. Cursor right maybe should be
allowed within the current line. This could then allow Enter to split a
line without killing the tip. It would be up to the user to detect the end
of the tip (in my case matching the closing bracket). This would match my
normal typing when entering code; but everyone is different.

Now to anticipate the next user request, which will undoubtedly be for
AutoComplete to pop-up while typing with a call tip active... probably not
too hard to achive from where I am.

[Neil Hodgson]

An extra call to set the "cancel" position (with -1 meaning none) would reduce the container code a little…

Implementation at http://sourceforge.net/p/scintilla/code/ci/b62f39d70de8d9795514e5b197c894b930dea42b/
While it may be more explanatory to call this a ‘CancelPosition’, the code is still using the term ‘PosStart’ since the corresponding getter already exists and is called CallTipPosStart.

maybe reuse the current start call tip code with a nullptr for the text would be the least code way to do this with no backward compatibility problems.

An explicit call is clearer than a magic value.

Alternatively we could have a more advanced start tip that passes in a structure that contains the text and two positions to do the job in one call.

Due to the difficulty of correctly using structs from scripting languages, Scintilla's API avoids them except for a few places where the Windows edit control API was copied.

It is a bit tricky to see how to improve call tip handling. At the moment, for example, tips are removed if you use cursor up or down, but not for cursor left and right, which allows you to (perversely) drive the cursor miles away from the tip. A better rule might be to keep tips while you type characters and delete back (up to the original caret position), but remove the tip for anything else... you might treat cursor left rather like delete back, so going past the start removes the tip. Cursor right maybe should be allowed within the current line.

This sounds reasonable.

This could then allow Enter to split a line without killing the tip.

Some languages don’t use braces around arguments so new line may mark the end.

Now to anticipate the next user request, which will undoubtedly be for AutoComplete to pop-up while typing with a call tip active... probably not too hard to achive from where I am.

There’s a CallTipCancel at the beginning of AutoCompleteStart and an ac.Cancel at the beginning of CallTipShow. Even if you modify the code, they are likely to overlap or obscure each other.

Neil