Autocompletion mechanism

[Tomas-M]

Currently we have autocompletion mechanism which autocompletes strings when user starts to type #TM or #TC. After autocompletion, the text in textbox remains such as #TM(1,1)_12345. This seems very inconvnient to me since the user has probably no idea what it means. What about making it differently?

When I initially implemented that, my main goal was to implement pure text-based autocomplete. But now since we need different logic, I should probably drop the idea of text-based autocompletion and we should switch to something more intelligent.

We could, for example, consider all texts to be a part of autocompletion. Thus it would not be needed to type #TM but user could start typing the DESCR itself, for example SES DATCMD and it would offer autocomplete for the given telecommands starting with that string. Space after SES should not be any problem.

User could trigger the autocomplete dialog by typing any text which can be autocompleted (eg. a parameter name), or by typing #. When the autocomplete is triggered, it should provide an extended dialog, where user can distinguish if he wants to type in telecommand, telemetry report, hk parameter, FCP reference, and so on. Like here:

[cechticky]

I'm not sure if I understand all, because I don't follow this project in detail, but you are writing about auto-completion and I like the solution made in Sublime Merge tool (https://www.sublimemerge.com/), where every git command can be done via a menu or command line. The command line uses a nice auto-completion implementation, here is the example, otherwise check the tool.

[Tomas-M]

@cechticky I am actually proposing something even more complex I guess :)

[Tomas-M]

In previous conversation, we had this image:

On the image, you can see node N1 with text:

Send #TC(3,1)[DPC70001] to define new packet ....

Do we need to keep this in the current form? Maybe it could look like this?

Send DPU_IFSW_DEFINE_HK_DR to define new packet ....

The TC(3,1) text could be visible after hovering the mouse over text DPU_IFSW_DEFINE_HK_DR for example. Will this be better? Or do you need to have TC(3,1) there really?

[pasetti]

For me, the approach proposed by Tomas looks fine (but I do hope it is not too complicated to implement and maintain!).

One question I have is: after the user selects something from the autocompletion menu, what appears in the text? Here I should like to answer one point raised by Tomas:

Currently we have autocompletion mechanism which autocompletes strings when user starts to type #TM or #TC. After autocompletion, the text in textbox remains such as #TM(1,1)_12345. This seems very inconvnient to me since the user has probably no idea what it means.

It is true that the string "#TM(1,1)_12345" is rather confusing for the user but it has the advantage that, if we later parse the text entered by the user, we easily recognize the presence of a reference to a TM report.

On the other hand, the very best approach would probably be one where the text I see is human-friendly and the non-human-friendly information is still present but is hidden and appears in the tip when one hovers over the text.

And let me now come to the last comment made by Tomas. He takes the example diagram and asks whether the user should see something like: "Send DPU_IFSW_DEFINE_HK_DR to define new packet..." or whether he should see something like: "Send #TC(3,1)[DPC70001] to define new packet... ". In fact, in the case of TM and TC reports, the human-friendly name is TC(3,1) or TM(1,2). I know that this is counter-intuitive but it come from the common practice in the industry. Hence, in the case of TM and TC reports, I would suggest that the text in the box refers to "TM(3,1)" or "TC(5,6)" and that the other information about the TM or TC report appears when one hovers over the TM/TC string.

in the case of TM and TC reports, the opposite convention holds: the human-friendly name is a string like "DBS_ADC_SEM_P30V" and the information which should appear in the hovering tip is a non-human-friendly name like "DPT06045".

We could also have the human-friendly text displayed in the node and the non-human-friendly identifiers in the run-code element of the node or in the "notes" attached to the node. I leave the final choice to Tomas but the main requirement is that both kinds of information (the human-friendly names and the non-human-friendly identifiers) be somehow available.

[Tomas-M]

I think I have an idea how to do it now, I estimate it to be just 2-3 hours of work, so I'll just do it and we will see if that is suitable. It will be easier for me to show you working example, instead of proposing and explaining the behavior I have in mind. Stay tuned :)

[pasetti]

Many Thanks, Tomas! Your example-based approach is fine for me. Only one point: I am going on holidays for about one week...

[Tomas-M]

Me too :) I'll do my best to make a working example today because I have some time, and then we can think about it on our holidays :)

[pasetti]

The auto-completion mechanism now works! I close the ticket.