FR: Virtual keyboard: whole word deletions

[jonnyl2]

FR: Virtual keyboard: whole word deletions

[hius07]

3. but probably not if there's only one?

Currently yes for one space too, to keep the punctuation character close to the previous word, I mean:
good boy, after deleting "boy" becomes good, (without the space).

I think it should depend on what is the more frequent action: if we write a new word instead of the deleted one, the space should not be deleted; if we just delete a word, the space should be deleted.

Also it depends on the question 2.
If only the part is deleted, the space should be kept for sure.

[hius07]

The usage of Backspace was rejected in this thread: #11182 (comment).

Another way is to extend the Clipboard dialog:

[Frenzie]

I don't think swipe on backspace was covered. Swipe left on backspace to delete a word (as in up to the first space) makes sense to me.

[jonnyl2]

Right, I remember that thread. If I understood correctly, the final consensus was that long-press on backspace should not be changed, but it didn't seem that anyone was against swiping on the button. On the contrary; here, @poire-z specifically said that swiping on backspace to access additional functions would be okay, and that comment received wide support. However, I am a bit confused because that comment also implied that it would be in conjunction with a key pop-up, as on all other keys, but on all other keys the pop-up is opened with a long-press, which again was rejected for the backspace key.

How about this: Engaging the ⌥- button will change the ⌫ button to something like ⌫…, and this will then enable a key-pop-up on long-press and corresponding swipes. It could have the following options: swipe north to delete from the beginning of the paragraph, west to delete a word left to the cursor, and south to delete to the end of the paragraph. (I would advise against diagonal swipes here as the risk of accidental deletions from misdrawn or misinterpreted gestures would be too high.)

However, your suggestion with the expanded Clipboard dialog could also be a possible solution, although a little less accessible and less intuitive than options directly on the keyboard itself. Would it be possible to press Delete word several times while previewing the text on the dialog behind it? (At the moment each action closes the dialog.) And will the cursor position be updated even when the dialog is not in the foreground?

Or lastly, a combination of the two ways might be of interest: Engaging ⌥ will change the ⌫ to ⌫^word (or some symbol) and will delete whole words on short taps. Long press could delete the paragraph (up to the cursor). No pop-up or swipes. And the additional delete and copy features (sans "word"), could still be added to the Clipboard dialog, where these lesser used options could still be accessed.

[Frenzie]

However, I am a bit confused because that comment also implied that it would be in conjunction with a key pop-up, as on all other keys, but on all other keys the pop-up is opened with a long-press, which again was rejected for the backspace key.

@poire-z wrote that if a keyboard popup were implemented, that's how he thinks it should be. Not that there should be a popup.

[jonnyl2]

@poire-z wrote that if a keyboard popup were implemented, that's how he thinks it should be. Not that there should be a popup.

Got it. Thanks for clarifying.

[poire-z]

Quickly rereading all this and what I and others wrote in the linked comment, I think I would be fine with a keypopup (and I would not mind breaking habits, as people would just get a popup and could quickly tap on a nearby key to erase to start of line). Engaging the ⌥- key is also a solution.
But with both of these, the main issue is: how to express on a 1-or-2-glyph key popup key "erase to previous word", "erase to start of visual line", "erase to start of paragraph"... I can't think of anything obvious that would not need the user to test it and see - and so addtionally a way to restore the state of text before that last action :/
(⌫word might be too wide - even wider in some languages. Dunno if popup keys can have larged width...)

I don't really like having these buttons on the clipboard widget as they feel a bit out of context (but not that much, Copy would act on the same "segments")

but somehow, it may be the most clear way to have it.
(It would also need to be positionned a bit out of the text, so one get a chance to see where the cursor is.)

[hius07]

"erase to start of visual line"

It actually works like "erase to start of paragraph":

koreader/frontend/ui/widget/inputtext.lua

Lines 875 to 879 in 46449eb

	-- If not, remove chars until first found \n (but keeping it)
	while self.charpos > 1 and self.charlist[self.charpos-1] ~= "\n" do
	self.charpos = self.charpos - 1
	table.remove(self.charlist, self.charpos)
	end

Currently long-pressing on Backspace has no visual indication, so we can add silent "swipe west" to delete a word under cursor, and mention it in the User guide only.

[Frenzie]

Sounds good to me. It also works that way on several other touch keyboards btw.

[hius07]

Taken from #11843 for broader discussion.
The gesture is "swipe west" on Backspace.
(1) What characters should be treated as word delimiters?
(Currently "[\n\r%s.,;:!?]". I excluded underscore and hyphen for purpose. Doubt about different brackets)
(2) Should it delete the whole word or a part left to cursor?
(Currently: the whole word, it is hard to set the cursor precisely)
(3) If after the whole word deletion we get two consecutive spaces, should one of them be deleted?
(Currently: delete, it allows easy deletion of several words in a row)

[Frenzie]

1. No hyphen should be fine.
2. I'm inclined towards left of cursor but it's not a strong preference.
3. I think it should be deleted when there are two, but probably not if there's only one?

[jonnyl2]

(1) What characters should be treated as word delimiters?
(Currently "[\n\r%s.,;:!?]". I excluded underscore and hyphen for purpose. Doubt about different brackets)

My preference would be to include hyphens and (especially) underscores as word delimiters. Both would be useful for renaming parts of filenames (e.g., 20240521_142213-033.pdf).

I would also include dashes as word delimiters –, —, ―. They are often used in lieu of spaces in books, but always delimit words.

Other characters may be helpful as well, but too many would unnecessarily restrict the flow of deleting chunks of text. I guess the list can always be adapted later, after some practical use and experience with the feature?

(2) Should it delete the whole word or a part left to cursor?
(Currently: the whole word, it is hard to set the cursor precisely)

I'm a bit conflicted on this question. Normal user expectation would indeed be just the part left to the cursor, but it's also true that it makes it a lot easier on an e-reader to place the cursor anywhere on the word to delete the whole word. So I'd say to keep it as is.

[Not expecting this, but just an idea-- delete just left of the cursor on swipe west; delete the whole word on swipe north-west. (I know I said preferably no diagonal swipes before, but here the damage that could be done between deleting parts of a word or a whole word would be rather negligible.)]

(3) If after the whole word deletion we get two consecutive spaces, should one of them be deleted?
(Currently: delete, it allows easy deletion of several words in a row)

Yes, delete IMO.

[poire-z]

Dunno if it can help and is usable, but xtext has a method to get the word boundaries of the word at some position in a string, using libunibreak's word break (so, Unicode) notion of where words break :)

koreader/frontend/ui/widget/textboxwidget.lua

Lines 2080 to 2084 in 40814bf

	-- Delegate word boundaries search to xtext.cpp, which can
	-- use libunibreak's wordbreak features.
	-- (50 is the nb of chars backward and ahead of selection indices
	-- to consider when looking for word boundaries)
	local selected_text = self._xtext:getSelectedWords(sel_start_idx, sel_end_idx, 50)

https://github.com/koreader/koreader-base/blob/99a6bd1a0b36f9ba2d3772bf7d5e34f899e95d74/xtext.cpp#L2066-L2144

It currently just returns the word, but it could additionally return the indices if needed.
Also, CJK chars are (mostly) single words, so with this on CJK text, you may delete the whole sentence :) but I guess CJK readers/writers just won't use it.

No strong opinion about the questions asked.

[jonnyl2]

Another idea that I think would be very useful (on top of the short swipes for words):

Swipe west >2/3 of the screen-width to delete from the cursor to the beginning of the line.

[Frenzie]

Note that long-press already does that.

[jonnyl2]

It deletes to the start of the paragraph (see hius07's comment above).

I also used to think it was the beginning of the line (because most input masks are one-lined, and user patches usually have short lines that are treated like separate paragraphs), but while editing bookmarks from PDF highlights I noticed that everything to the beginning gets deleted. (Because paragraph breaks don't carry over into PDF highlights, there aren't any paragraph breaks.)

[Frenzie]

Potayto potahto, change it then. ;-)