Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text input double click selects a word on all systems #2244

Closed
wants to merge 1 commit into from

Conversation

DoctorGester
Copy link
Contributor

I can see the behavior of "double click to select the whole text on non-osx" was done on purpose, but I have tried various editors and text inputs on windows and they all select a word on double click.

@ocornut
Copy link
Owner

ocornut commented Jan 3, 2019

Hello Kirill and thanks for pushing this!

I do agree with this. I think the original "select all" behavior was implemented very early on (pre < 1.0) because it was simpler to implement, but there's no reason keeping it this way. Especially as it is redundant with CTRL+A providing a select all.

My concern is that by pushing this we are making the feature more visible than it was, and it currently doesn't behave the way all user would expect in all situations.

  1. For example, punctuation are crossed by word left/right actions whereas a double-click doesn't tend to cross punctuations.

  2. There's a triple click behavior in most editors that promote the word selection to a paragraph or line selection.

It would be good if we can study the differences and implement something suitable? It is ok if we rely on knowledge of ASCII punctuation (aka we don't have to full-fill expectation of e.g. asian languages in a first version - we don't already - and those can be improved later based on user requests).

Quick notes of some noted behaviors:

Firefox (Windows)

  • Double-click: selection starts at the beginning of the current word, selection ends before the next word (including one or more space), but stops before punctuation. Double-click over a space finds the word before and act as if clicked on the word.
  • Triple-click: promote to paragraph selection.

SublimeText (Windows)

  • Double-click: selection starts at the beginning of the current word, stop before the next space or punctuation. Clicking on a single space without punctuation finds the nearest words (based on click position) and acts as if clicked on it. Clicking on multiple spaces or single space touching punctuation select the space and punctuation.
  • Triple-click: promote to full line selection.

Visual Studio (Windows)

  • Double-click: behave similarly to SublimeText but seems to have different rules for punctuations or language specific feature. Clicking in the space of char* word in visual studio select * word, in SublimeText selects * or word. May not matter.
  • Triple-click: promote to full line selection.

For info: STB_TEXTEDIT_K_WORDRIGHT calls through STB_TEXTEDIT_MOVEWORDRIGHT which is is implemented imgui_widgets as STB_TEXTEDIT_MOVEWORDRIGHT_IMPL(). It is possible that the right solution don't need to call through this code, we could scan the string ourselves?

@DoctorGester
Copy link
Contributor Author

Adding to your research: double clicking on space in chrome selects that actual space/multiple spaces as if it was a word (which kind of makes more sense to me than what the rest do but maybe I'm too used to Chrome behavior). I'll take a look into it/implementing triple click when I have more free time!

@elect86
Copy link
Contributor

elect86 commented Feb 17, 2020

Any update on this?

Ps: Intellij Idea behaves exactly as SublimeText. Also I'd bet FF selects everything till the next \n. I'd be fine with whatever you choose though, I just find unnatural the current behavior

elect86 added a commit to kotlin-graphics/imgui that referenced this pull request Feb 17, 2020
- implemented single word double click selection (and fixed it) ocornut/imgui#2244
@kudaba
Copy link
Contributor

kudaba commented May 15, 2020

Once #3229 gets committed I'll be putting up a PR for this. I upgraded the system to support double, triple and (optionally) quadruple click and tried to add more consistency with the current state of text editing.

You can test the latest version in my fork: https://github.com/kudaba/imgui/tree/docking, I'm still looking to get some testing on Mac to make sure it's not doing anything unexpected.

@elect86
Copy link
Contributor

elect86 commented May 16, 2020

What is supposed to do a quadruple click?

@kudaba
Copy link
Contributor

kudaba commented May 17, 2020

I was testing as many different text selection systems I could get my hand on and noticed that a few of them did a select all on the 4th click so I added an option for that. I realized that text editing features does depend a bit on context, code editors don't want select all, but smaller text editors might benefit from it, and single line editors might want double click to select all instead of word.

elect86 added a commit to kotlin-graphics/imgui that referenced this pull request Jan 8, 2021
- implemented single word double click selection (and fixed it) ocornut/imgui#2244
@ocornut ocornut force-pushed the master branch 2 times, most recently from 0c1e5bd to bb6a60b Compare August 27, 2021 19:10
@ocornut
Copy link
Owner

ocornut commented Oct 25, 2021

#3229 is merged now so we can easily use multiple click count, I'm looking at this now.

ocornut added a commit that referenced this pull request Oct 25, 2021
…rd delimitation logic differs slightly from the one used by CTRL+arrows. (#2244)
@ocornut
Copy link
Owner

ocornut commented Oct 25, 2021

Pushed 126a6f8

  • Double-click selects words on all-platforms, triple-click selects line.
  • Select behavior was reworked so that: double-click on edge of line doesn't bleed to previous line, the word delimitation rule for double-click selects always use the ctrl+arrow logic that was used on Mac (in other words, double-click differs from the position we would reach with ctrl+left followed by ctrl+right).
  • It's absolutely not perfect but those changes makes it sensible. We'll probably work on more formal tests later to clarify and evolve specs.
  • On InputInt, InputFloat etc, the character filters + word delimitation rules end up selecting all on double-click. This would however fail with if PlatformLocaleDecimalPoint (internal) is reassigned to ',' (as per Using localized decimal point in InputTextFilterCharacter #2278) would be nice to fix that.

@ocornut ocornut closed this Oct 25, 2021
actondev pushed a commit to actondev/imgui that referenced this pull request Nov 26, 2021
…rd delimitation logic differs slightly from the one used by CTRL+arrows. (ocornut#2244)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants