-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
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.)
Apr 20 · 4 weeks ago · 👍 gritty, stack, johano, hellfire103, skf, taichara
Awesome, thank you! The buggy scrolling in Lagrange had been an issue for a while. I do want to point out that even after updating there is still some unexpected behaviour, although it’s not particularly inconvenient it is weird. If I select a word and then move the front selector forward, everything works as expected. But if I drag the front selector to behind the back selector (the one at the beginning of the word), then the back selector sometimes (not always) jumps to the end of the originally selected word.
I had trouble describing this, so I hope it’s clear.
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!
thank you -- selecting text was a weird whack-a-mole game you could not win! I hope this fixes it. And it does!
@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.)
@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.
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.
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)
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....
Yes, keeping the pivot word selected is counterintuitive...
I do appreciate the word selection, when it works as expected, it's great
-- Response ended
-- Page fetched on Sun May 19 14:42:42 2024