Allow tabs for indentation in text edit widget

[the-drunk-coder]

Hi,

it seems like the Tab key is not captured in the text edit widget, could that be ?

Like, when I put some debug output in the event handling loop, it seems like there's no event emitted at all ... just the outer frame flickers ...

Is there a way to capture the tab key ?

Best,
N

[emilk]

Egui uses the tab key to move focus between TextEdit widgets. You can try it in the web demo by clicking the "Hello World!" text edit field and pressing tab. The focus will move to the next field.

What do are you trying to accomplish? Do you have a text edit field where you would like the Tab key to insert a \t char instead of moving focus?

[the-drunk-coder]

Exactly that ... I use a customized TextEdit widget for a (toy) code editor ... having the tab key would be somewhat essential for that ...

[DrOptix]

Hello. I just created this draft PR #246.

How should I render the TAB?

• render 4 spaced instead of TAB
• render a quad that occupies the spaces of 4 regular spaces?

I'm still investigating how the font rendering is done, but I decided to create this draft PR to be able to get some early reviews, suggestions and hints.

[DrOptix]

I kept hammering at the tabs as space idea, where a TAB is replaced by 4 Space chars, but I have two problems and I don't know how to fix one of them.

With this commit, 94c1801, I took the approach of keeping TAB in the text string, but when we compute the TextEdit::content_ui I replace all tabs by 4 Space chars. I do this because I wanted to handle the case when the TextEditis initialized with a string that already contains TAB. Later I noticed that I actually mutate the original string. This means the TABs from the original string are gone and I'm not sure if this is what we want. For this issue I'm looking into replacing the TABs with Spaces without modifying the original string when we create a multi line TextEdit or when we render it in TextEdit::content_ui. I hope it makes sense what I'm saying, if not let me know and I will try to reword it.

Now onto the problem I have no idea how to fix. When I detect a TAB key I insert it in the string and then I advance the cursor, but the advancement of the cursor works only if I press TAB in the middle of the string. If I press it at the end it will render 4 Space chars, but it will not advance the cursor.

After work I will play a bit more with it.

[DrOptix]

I'm back the only thing left to do is to actually render TAB as a "space" with the size of n spaces, but I think I need to do some API breaking changes to the font.rs because Rust does not allow default values for parameters.

This commit has more details: ba12f9e

[emilk]

The simplest approach is to always use the \t tab character, and simply say one tab = 4 spaces. I just pushed a commit that does that: cbe6faa. With that there is no need for any special handling in labels and TextEdit.

Then the only thing left is handling the focus issue. I think your lock_focus method is good, but there has to be a way to break out of the lock. In VS Code I notice that I can move the focus with option+tab (on Mac) even when in a text field. On Windows maybe that's ctrl-tab ?

[DrOptix]

That moment when I am... damn that's so easy :). I will rebase with your changes and update the PR.

For me on Fedora, but on Windows too, alt+tab switches between apps. From my knowledge option key is the same as the alt key.

On Fedora, ctrl+tab switches between VS Code tabs, forward and ctrl+shift+tab goes trough the editor tabs backwards and my guess on Windows is doing the same thing.

I'll try to figure out how it is done.

[DrOptix]

Found it for VS Code, ctrl+M activates a "tab moves focus" mode.
Should me come up with a similar convention?

[emilk]

Maybe we can keep it simple for now.

I think the "tab-as-character" behavior should be opt-in, i.e. TextEdit::multiline(text).code_editor(true) or something. (this could maybe also turn on monospace and other code-like behavior).

In most cases I think we would want tab/shift-tab to move focus even for multiline text (as in: most multiline text field do not need tab characters), so the locking-in is much less of an issue. A user can always press ESC to escape the locked in editing.

[DrOptix]

@emilk, with your help and suggestions I think I have the final version of the PR #246. When you have time to review it please do so. I'm really excited about this infinitesimal small contribution I did. 😄

[DrOptix]

A small update. For the shift+tab shortcut you suggested I finished it for when the editor is in tab-as-spaces mode.
Later today I will finish when the editor is in tab-as-tabs mode. I have to say I used VS Code as inspiration on how to render the tabs.

Just a remark. I've noticed there is some alignment issues. I'll try to figure out at the end, but if you suspect anything let me know.

And the detailed view from VS Code.

When I render a tab I'm following your suggestion of getting the GlyphInfo for space and then doing a glyph_info.advance_width *= tab_size computation. I suspect the alignment issue comes from the fact that when we have separate space chars there is some space inserted between the characters.

[DrOptix]

My PR is ready for review again. I'm curious what do you think.