Intercepting and modifying calltips on the fly

[Tim Rude]

 Is there a way to detect when SciTE is just about to display a calltip, take the calltip text and modify it, and then let SciTE display the modified calltip text instead?

Something like a calltip callback function?

The goal is to take a lengthy calltip and quickly insert \n linebreaks on the fly to wrap the calltip lines at a maximum predetermined width.

Yes, I know the .api file(s) could be pre-edited to insert the \n linebreaks, but some .api files are dynamically generated on the fly by other routines so I wanted to try tweaking a calltip immediately before it's displayed, if it's possible to do so.   

[Neil Hodgson]

Tim Rude:

> Is there a way to detect when SciTE is just about to display a calltip, take the calltip text and modify it, and then let SciTE display the modified calltip text instead?

I can't think of a reasonable way to do this without adding it as a new SciTE feature.

You could write your own calltip display command that finds the current function name, searches the API file, and calls Scintilla's calltip display method with your modified text.

Neil

[Tim Rude]

I can't think of a reasonable way to do this without adding it as a new SciTE feature.

Neil:

Thanks for the reply. Is there a remote possibility of something like this happening? 

Tim

[Neil Hodgson]

Tim Rude:

> Thanks for the reply. Is there a remote possibility of something like this happening?

It would be a reasonable addition but would require contributors. A start may be too specify how it could work.

Neil

[Tim Rude]

 A start may be too specify how it could work.

Neil:

The SciTE Lua Scripting Extension doc links to the SciTE Extension Interface doc which describes a number of event functions (OnOpen, OnClose, OnSwitchFile, OnSave, OnBeforeSave, OnChar, OnKey, OnSavePointReached, OnSavePointLeft, OnDwellStart, OnDoubleClick, OnMarginClick, OnUpdateUI, and OnUserListSelection) and how they can be utilized. I'm thinking that if an event function was added such as 'OnCallTipShow' that fired just before a CallTip was auto-displayed, and passed as parameters the same (position pos, string definition) values as one would pass to the CallTipShow function, then a custom OnCallTipShow function could be written to modify the 'string definition' value as desired, call the actual CallTipShow function using the original 'position pos' parameter and the modified 'string definition' parameter, and then return True from the custom OnCallTipShow event function to signal to SciTE that it doesn't need to proceed with the rest of the event (displaying the calltip) because it's already been handled.

The OnCallTipShow event function should only be called when SciTE is just about to *automatically* display a calltip, but not when the CallTipShow function is manually called, to prevent a recursive loop.

If there is no OnCallTipShow event function coded, then SciTE would just proceed normally with displaying the calltip as usual.

Admittedly, I'm not versed in LUA programming, but based on the existing functionality in the SciTE Extension Interface, this would seem a logical way to do this.

Tim Rude

[Neil Hodgson]

Tim Rude:

> as 'OnCallTipShow' that fired just before a CallTip was auto-displayed, and passed as parameters the same (position pos, string definition) values as one would pass to the CallTipShow function, then a custom OnCallTipShow function could be written to modify the 'string definition' value as desired, call the actual CallTipShow function using the original 'position pos' parameter and the modified 'string definition' parameter, and then return True from the custom OnCallTipShow event function to signal to SciTE that it doesn't need to proceed with the rest of the event (displaying the calltip) because it's already been handled.

I don't think that will be sufficient to override the current functionality cleanly. SciTE is also responsible for moving the highlight within the calltip by calling CallTipSetHlt as the user enters each parameter. To do that, it maintains several state variables:

std::string functionDefinition;
SA::Position startCalltipWord;
int currentCallTip;
int maxCallTips;
std::string currentCallTipWord;
SA::Position lastPosCallTip;

The core method is FillFunctionDefinition but its supported by StartCallTip and ContinueCallTip.

Neil

[Tim Rude]

Neil:

 

I don't think that will be sufficient to override the current functionality cleanly. SciTE is also responsible for moving the highlight within the calltip by calling CallTipSetHlt as the user enters each parameter.

What if an OnCallTipShow event function fires right after the automatic calltip routine reads the calltip info from the api file, and it passes as a parameter the calltip text that was read. This would be just before the  rest of the calltip processing takes place that sets up the state variables for handling for the parameter highlighting. Then the code in the OnCallTipShow event function could modify that calltip text as desired, and pass the modified text back as the function's return value (rather than a True / False return). If the returned text is blank (as it presumably would be if there's no OnCallTipShow function coded), SciTE just shows the calltip as it was read from the api file as usual. Otherwise, SciTE would use the modified text instead of the original text and proceed with the rest of the calltip functionality.

In this case, maybe a better name for the event function would be OnCallTipRead instead of OnCallTipShow.

Tim Rude

[Neil Hodgson]

Tim Rude:

What if an OnCallTipShow event function fires right after the automatic calltip routine reads the calltip info from the api file, and it passes as a parameter the calltip text that was read. ... Then the code in the OnCallTipShow event function could modify that calltip text as desired, and pass the modified text back as the function's return value (rather than a True / False return).

That's likely workable. There is no good sample for a string returning 'On' function as they follow a pattern where there can be arguments sent to Lua but only return a 'continue processing' boolean.

   Neil