Add entry.Insert API to insert text at current cursor position #5334
Conversation
dweymouth
force-pushed
the
3445-entry-insert
branch
from
75ff8f8 to
0b2a001
Compare
|
I think the review comments were removed by the force push. |
I actually think conversation had only been on the linked issue so far and not the PR. But noted on the force push, will use merge commit next time :) |
Ah, that makes sense, sorry for the confusion. |
| return // Nothing to paste into the text content. | ||
| } | ||
|
|
||
| if !e.MultiLine { |
There was a problem hiding this comment.
I think this code is specific to clipboard so maybe it should be outside of the new insert API?
If you think it does belong here please document it in the API doc.
There was a problem hiding this comment.
@matwachich Do you have an opinion on whether the InsertAtCursor API should also reformat multiline text when inserting into a single-line entry (like paste does)? I feel like it maybe shouldn't since it'd be the developer who controls what is being inserted, vs a user action like paste.
|
Default behaviour could be to convert line breaks to spaces
Le ven. 3 janv. 2025 à 20:01, Drew Weymouth ***@***.***> a
écrit :
… ***@***.**** commented on this pull request.
------------------------------
In widget/entry.go
<#5334 (comment)>:
> +// If text is currently selected, the selected text will be replaced
+// with the inserted content.
+//
+// Since: 2.6
+func (e *Entry) InsertAtCursor(text string) {
+ if text == "" {
+ changed := e.selecting && e.eraseSelection()
+
+ if changed {
+ e.Refresh()
+ }
+
+ return // Nothing to paste into the text content.
+ }
+
+ if !e.MultiLine {
@matwachich <https://github.com/matwachich> Do you have an opinion on
whether the InsertAtCursor API should also reformat multiline text when
inserting into a single-line entry (like paste does)? I feel like it maybe
shouldn't since it'd be the developer who controls what is being inserted,
vs a user action like paste.
—
Reply to this email directly, view it on GitHub
<#5334 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANVJ7XQVSK5EG2BUBDQGDT2I3NCNAVCNFSM6AAAAABT7N3UDWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKMRZGU3TIMZTGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
There won't be a default behavior but a single, unchangable behavior since the API doesn't have any other arguments for options. For that reason I'm leaning toward inserting the text exactly as-is, and documenting it as such. It's more flexible since the programmer is in control of the text passed to the API, so if they want to remove newlines, or process the string in any way, they can do so. But if we process the string, there would be no way to disable it. |
|
Makes sense...
Agree
Le ven. 3 janv. 2025 à 21:29, Drew Weymouth ***@***.***> a
écrit :
… Default behaviour could be to convert line breaks to spaces Le ven. 3
janv. 2025 à 20:01, Drew Weymouth *@*.***> a
There won't be a *default* behavior but a single, unchangable behavior
since the API doesn't have any other arguments for options. For that reason
I'm leaning toward inserting the text exactly as-is, and documenting it as
such. It's more flexible since the programmer is in control of the text
passed to the API, so if they want to remove newlines, or process the
string in any way, they can do so. But if we process the string, there
would be no way to disable it.
—
Reply to this email directly, view it on GitHub
<#5334 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANVJ7S6BEYBTB7OOTA5QJD2I3XKBAVCNFSM6AAAAABT7N3UDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRZG43TOMJXGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Description:
Fixes #3445
Checklist:
Where applicable: