š¾ Archived View for bbs.geminispace.org āŗ u āŗ tepez āŗ 16250 captured on 2024-08-31 at 14:51:24. Gemini links have been rewritten to link to archived content
ā¬ ļø Previous capture (2024-08-18)
-=-=-=-=-=-=-
Re: "Updated mobile builds are available: Android Beta 27 and..."
Updated on Android. Unfortunately selecting text is quite difficult and I can't copy the selected text. I'm not sure this problem was introduced by the new version though!
Apr 20 Ā· 4 months ago
š stack Ā· Apr 20 at 14:16:
thank you -- selecting text was a weird whack-a-mole game you could not win! I hope this fixes it. And it does!
š¹ļø skyjake [OP/mod...] Ā· Apr 20 at 14:21:
@satch I think what you're describing is intended behavior: Lagrange's mobile text selection works on a per-word basis. This is on purpose because of the "fat finger" issue... Native text selection usually has some sort of a popout/over that lets you see exactly which character is being selected, but my implementation is much less sophisticated.
@tepez Difficult in what way? Note that it works differently than Android's native selection, and has its own internal logic. Specifically, to act on the marked selection, you'll need to tap on the selected text region and a context menu appears from the bottom with suitable actions. (Tapping outside the region clears the selection.)
š satch Ā· Apr 20 at 15:35:
@skyjake so the issue Iām describing is not about text selection being on a per word basis. It really is a minor quirk, which is difficult to explain over text. I might make a screen recording of it to show you.
š satch Ā· Apr 20 at 15:59:
See
Pay attention to the way the selection changes when the moving selector crosses the stationary one. Its behavior is inconsisent between the different times this happens in the recording.
š stack Ā· Apr 20 at 17:42:
It seems that selection is word based, however the logic between words is iffy. When the start marker is at the beginning of a word and the end marker moved before it, the word is included and the marker moves to the end of it. I think internally, the marker indexes the word, not the actual position, and it is rendered before or after depending on direction, but the bounding word is included either way.
I've seen two words flip at the end, so I think there is a bug even accepting the oddness of word-based selection. Although I think there is a way to implement this so it's less disturbing (the code to flip markers is much harder as it needs to find prev/next word, etc)
š¹ļø skyjake [OP/mod...] Ā· Apr 20 at 17:58:
The current logic with the markers is not waterproof, certainly. One detail that may cause confusion is that the start and end markers don't switch roles if you move the end marker before the start. The range is just applied as inverted. Also, the "word flip" only occurs when the end marker is moved in front of the initially selected word. Moving the start marker past the end does not behave the same.
I should probably remove the extra complication here and not try to "assist" you by attempting to keep the initially marked word inside the range, especially when it doesn't actually work 100% of the time....
š stack Ā· Apr 20 at 19:41:
Yes, keeping the pivot word selected is counterintuitive...
š stack Ā· Apr 20 at 20:42:
I do appreciate the word selection, when it works as expected, it's great
Updated mobile builds are available: Android Beta 27 and TestFlight 1.17 (9) These fix a couple of issues with text selection: Changes in the desktop v1.17 caused a regression on touch devices when dragging selection markers. Scrolling while selecting sometimes jumped the view to the top/bottom of the page. (A classic integer overflow when calculating the scrolling speed.)
š¬ skyjake [mod...] Ā· 10 comments Ā· 6 likes Ā· Apr 20 Ā· 4 months ago