Required parameter autocomplete

[slideclimb]

Adds live templates to insert placeholders for all required parameters.

Summary of additions and changes

• Insert live template instead of single {} when completing a command that has required parameters.
• Remove the frac live template since we don't need it anymore.

How to test this pull request

• Type a command with required parameters and invoke autocomplete.

Wiki

• Updated the wiki: https://github.com/Hannah-Sten/TeXiFy-IDEA/wiki/Autocomplete

[HannahSchellekens]

Just realised this now: back in the days we chose explicitly to not do this because of optional parameters.

When autocompleting \usepackage[default,osfigures]{opensans} you now end up with \usepackage{I} -> \usepackage{opensans}I -> navigating to after \usepackage -> adding the opt. parameter.

Do you have any experience with these use cases? It does seem that this does not occur that often compared to just required parameters?

[slideclimb]

Indeed, I've noticed this, too. However, after using this for a while I'd say that it's not a big deal. Yes, it's annoying when you have to go back for an optional parameter, but it happens far more often that you don't need the optional parameter and can Tab to the next required parameter without having to type any braces. In my experience this definitely outweighs the optional parameter annoyance.

The only command (in my experience) where it is really annoying is \includegraphics as - most of the time - you want an optional parameter to set the width. Maybe, for this one, we can add an extra item to the autocomplete that also inserts the optional parameter? Or a live template? Any suggestions?

I do feel like, if we're going to give this command a special treatment, why not all commands? Just because this is one we use a lot doesn't mean that's the same for other users... So in that sense a live template might be better, so users can remove and edit it and/or add their own for other commands.

[PHPirates]

Can we provide autocomplete for both versions of the command, with and without optional parameters? So then this appears in the autocomplete:

\usepackage{package}
\usepackage[options]{package}

if I'm not mistaken then IJ will learn if you always use the second.
I think this is like Kotlin autocomplete showing two methods with the same name but different parameters.

[HannahSchellekens]

Sounds promising. I'd love to see a prototype of this to see if it works. Because if it does, I think you have found a very nice solution.

One problem with this still might be commands that you rarely use in a new project, and then you don't necessarily select the right option because the autocomple hasn't adapted yet?

[slideclimb]

I suppose that makes sense. I'll have a go at it :)

One problem with this still might be commands that you rarely use in a new project, and then you don't necessarily select the right option because the autocomplete hasn't adapted yet?

I think that that will not be too much of a problem. I guess it's similar to what we currently have: after selecting the wrong option you have to go back to fix an optional parameter (delete or add it).

What I'm afraid of is that the autocomplete list will be cluttered with a lot of double (or even more) commands, but we'll see if that turns out to actually be annoying.

[slideclimb]

For a prototype, try out 9f4a289.

For now, this only shows the additional elements in the autocomplete (don't expect anything when inserting), which is enough to try out how quick the autocompletion adapts to your preferences. I've found that you have to select your favourite command twice, then the third time it has already adapted. I think that's quick enough, even for commands you rarely use. Some screenshots of the new completion list:

Currently, this shows the power set of optional parameters (including the empty set, which is only the required parameters), which lead to seemingly double results (see the \citea screenshot). Maybe we could filter out the tail texts that have the same order of brackets, but then there's no way to know whether to show the after or before argument (as in the screenshot) without consulting the documentation/implementation of the package the command belongs to. (In this case it would be after, to only get something before you have to pass an empty argument to after.)

@HannahSchellekens any thoughts/ideas/suggestions before I continue with the insertion handler?