TextEdit code completion with ItemList h_scroll

[AlexHolly]

closes #16542, closes #23264, closes #22121

Tests
Min Length (you can see a small jump on pressing backspace no idea why it happens)

Show scrolls only when needed

H Scroll for long words

[AlexHolly]

I intregrated #21742 to see the result.
You can close it and merge this one instead.

The finished version

#8171

[KoBeWi]

I wrote some (a bigger some) code with your auto-completion changes and while in itself it works perfectly, it has some issues:

• The highlighted text is hard to read. This has something to do with colors or maybe it should be bold, but it's just a bit unreadable.
• Scroll bars, especially the horizontal one, overlap the text.
  
  As you can see, the last line isn't really visible and it's a bit bothering. Especially since this popup would do well without scrolling at all, as it's so small.
• Third, and the worst issue, is that sometimes it ignores what you already wrote and appends the whole text instead of missing part. Sadly, I can't find a way to reproduce it consistently, but I wrote many lines and it happens enough to be really annoying. E.g. when you write Vec and auto-complete it to Vector3, you sometimes end up with VecVector3. Terrible.

Other than that, great work. It really makes coding faster, because results are more predictable.

[AlexHolly]

1. Using cache.word_highlighted_color now
   eda697d#diff-71709879dd36a28d4ff43c570b3b4c8bR5756

2. Should be better now.
   

3. The only case I know is using the completion inbetween but this was there before.
   

Fixed Mouse Scrolling, the selection was moving out of view.

I still don't like the sort function so many casts and the input variable is the same on each Entry

Is there a way to remove the casts?
https://github.com/godotengine/godot/pull/21742/files#diff-0e0c9dec15a95e1c0d8e658a4ab39d4cR455

Is there a better way to pass a variable to the sort function?
https://github.com/godotengine/godot/pull/21742/files#diff-71709879dd36a28d4ff43c570b3b4c8bR5771
https://github.com/godotengine/godot/pull/21742/files#diff-0e0c9dec15a95e1c0d8e658a4ab39d4cR445
https://github.com/godotengine/godot/pull/21742/files#diff-0e0c9dec15a95e1c0d8e658a4ab39d4cR453

[KoBeWi]

I found a way to reproduce my third issue. Actually 2 ways, not sure if there was another case or it always happened like this.
They both boil down to autocompletion somehow "remembering" a position in word and completing by starting from that position, instead of where is the cursor. You can see that on a video: https://youtu.be/8qYieOiW8gk

It actually doesn't happen with vectors, as I usually don't write them this way.

[AlexHolly]

Hmm I am still not able to reproduce. Can you create a minimal example? Is it only happening with this PR or was it there before?

[KoBeWi]

After further investigating, seems like this issue doesn't happen in clean Godot (tested with official alpha). The reason it doesn't is that auto-complete closes after you complete the word. With your changes, it doesn't disappear and if you press Enter to close it, it produces unexpected outcome.

Here's a guide how to reproduce it, again with Vector type:

1. Start with writing Vec and press Ctrl + Enter or just wait for auto-complete to appear
   
2. Complete the word, either as Vector2 or Vector3
   
3. As you can see, the auto-complete prompt is still there. Now press Enter, and depending probably on timing, it will produce either VVector2 or VecVector3.
   

So probably to fix this, the prompt should close automatically or replace whole word.

[AlexHolly]

I am still not able to reproduce it

I think we should simply fix the issue that was always there it will probably fix this issue too(if there is any).

[KoBeWi]

Uh, now that I look at it, seems like you misunderstood one step. At 2), you need to complete the world manually. So write Vec, then wait, then write tor3 (don't press Enter). Normally, the autocompletion popup should close now, but with your changes, it seems to stay there. The error triggers when you press Enter afterwards.
It happens to me once in a while when I casually write a word and autocompletion decides to help me even if I don't need it. Still, vanilla autocompletion is terrible, so I keep using custom Godot with your fixes. I can genuinely say that it needs to be merged, but after fixing that one issue.

[AlexHolly]

Now I can reproduce, thanks.
Looks like a perfect match on build in Types has some issues.

[AlexHolly]

I fixed a few things, needs testing.

1. Highlight color is now using cache.word_highlighted_color this means you can edit it in
   Editor -> Editor Settings -> Text Editor -> Highlighting -> Word Highlighted Color
   The default color looks pretty bad, maybe we need to change it?

2. Code completion in words now replaces the whole word (needs testing)

3. Perfect match will close the completion window (the issue was in the code_editor.cpp missing update call text_editor->code_complete on build in types(specific error? See prev post)).
   

4. I don't like that the scroll space is used even if it is not needed
   https://user-images.githubusercontent.com/4741886/46813409-e95fba00-cd76-11e8-9a70-5af0b9be0bee.gif

5. There is still a bug with replacing old word if the cursor is between the word and () it works better than before so far.
   

[KoBeWi]

Uh, this version crashes for me if I follow the previous steps.

[AlexHolly]

It works for me, can you give more details?

[KoBeWi]

Well, seems like it's conflicting with something on master branch, as cloning your fork fixed the issue. To reproduce my crash, you can get the official master branch and apply your PR (I did it using patch).

EDIT:
It just crashed even at your fork, although not sure what caused it ;_;

EDIT2:
Heh, seems like it's a bug with vanilla Godot, because I had a crash with clean alpha 2.

[KoBeWi]

Also related: #4704
Not sure if it fully closes that though, looking at this comment: #17357 (comment)

[KoBeWi]

@AlexHolly Could you rebase the PR? >_>

[AlexHolly]

@akien-mga This take more and more time to solve, is it going to be merged anytime soon?
@KoBeWi I have no time to test it, I used the master code for the following case(s) since functions don't end with '(' anymore, it looks like that kind of issues are back again.

[KoBeWi]

I did a brief test yesterday and, aside from what you already mentioned, spotted 4 issues:
1.

Long text overlaps scroll bar.

Sometimes selecting with Enter when two words start with the same, it inserts the first word from the list, instead of the one you selected.

The quotes bug. It was fixed by #31450, so you have regression in your code.

Sorting isn't alphabetical. Not sure what it's caused by. Also, this particular example is affected by 1. I selected position and it inserted scale.

[AlexHolly]

Thanks for testing it.

1. Feels like I am fixing this the third time 🌝
2. completion_current was still in some places which is now replaced by completion_options[completion->get_current()]
3. Should be fixed again I added some _cancel_completion in the prev. commit to solve a case where I got stuck in the Path scope but I am not able to reproduce anymore.
4. Sort Order
   1. By Length
   2. *new: If same length, By alphabet
      

It is not possible to activate the completion in this case (place the cursor somewhere in the string) preload("res://test").

[KoBeWi]

Oh, also you can't change the match color. It seems to always be red. (the previous fixes seem to work alright btw)

[AlexHolly]

cache.word_highlighted_color is not working for some reason, I used get_color(...), should work now.
cache probably needs a cleanup

[KoBeWi]

Me again XD
Two things (hopefully last ones):

• autocompletion for paths is terribly inaccurate:
  
  See how I looked for Food.tscn and it showed at the bottom of the list, preceded by some irrelevant entries with partial matches.

• I'm not sure if word_highlighted_color is a good choice. It's used when you select something to highlight all occurrences of the selection. Default one is very subtle and not very visible in autocompletion and setting a more vibrant color makes word highlighting much less readable.
  
  
  Not sure which color from the existing would be good here. You could set a matching color, but totally irrelevant to the function. I guess it could be easier to introduce a new color, but this should be avoided.

[AlexHolly]

I have no idea why a new color is not working, a color change in editor settings will not update the color.

[akien-mga]

While the enhancements from this PR seem quite interesting to have, the scope is very big and there's a lot of code to review... and visibly various regressions or outstanding bugs to resolve.

I think this should probably be split into separate PRs with a better separation of concerns, so that the code completion experience can be improved gradually with well tested iterations.

I'm also concerned about making TextEdit even more complex for the purpose of the code editor, when it's meant as a general purpose text edition field and not an IDE Control (see #31739). Maybe these changes should wait on the refactor described in #31739 so that it can be done with a better architecture.

Moving to the 4.0 milestone as it's sadly too late in any case to integration this in 3.2.

[aaronfranke]

@AlexHolly Is this still desired? If so, it needs to be rebased on the latest master branch.

If not, abandoned pull requests will be closed in the future as announced here.

[aaronfranke]

This PR has not received any new commits for almost a year and is abandoned, closing.