Skip to first unread message
Tony G
Dec 24, 2015, 4:00:32 PM12/24/15
to abstractspoon-t...@googlegroups.com
Select a few paragraphs of text from a web page, maybe this text you're reading.
Paste it into a plain text comment field.
You get the original text as expected, followed by the same text with <br> tags and line breaks which probably match the raw HTML text. That entire second block is surrounded by parentheses, so : "(this<br>text here...)"
Do the same with rich text and it doesn't add the extra block. Paste the text into other applications, the extra block isn't there.
So it looks like this is coming from TDL and only for plain text.
HTH
T
Paste it into a plain text comment field.
You get the original text as expected, followed by the same text with <br> tags and line breaks which probably match the raw HTML text. That entire second block is surrounded by parentheses, so : "(this<br>text here...)"
Do the same with rich text and it doesn't add the extra block. Paste the text into other applications, the extra block isn't there.
So it looks like this is coming from TDL and only for plain text.
HTH
T
Tony G
Dec 24, 2015, 4:39:49 PM12/24/15
to ToDoList (AbstractSpoon) Support
Seems to be related to this.
Shift-insert fixes the problem compared to ctrl-V or context/Paste.
But this is on Plain text where that other report was about RTF.
T
Shift-insert fixes the problem compared to ctrl-V or context/Paste.
But this is on Plain text where that other report was about RTF.
T
.dan.g.
Dec 26, 2015, 7:55:24 AM12/26/15
to ToDoList (AbstractSpoon) Support
Hi Tony
Can you always include an image where possible?
Makes a hug difference because there's usually so much else on the image that may help me that you won't think to put into words.
Thx
.dan.g.
Dec 26, 2015, 8:26:19 AM12/26/15
to ToDoList (AbstractSpoon) Support
ps. I can't reproduce this.
On Friday, 25 December 2015 08:00:32 UTC+11, Tony G wrote:
Tony G
Jan 4, 2016, 2:31:17 PM1/4/16
to ToDoList (AbstractSpoon) Support
I hear ya....
I'm getting a selection from Firefox of the text from my original post:
Now I'm using ctrl-V to paste into a Comment:
The red area is the HTML version of the plain text. So the copy pulls both the source and the rendered text. A normal paste with ctrl-V pastes both the source code as well as the rendered text. But shift-INS pastes only the rendered version.
This could be considered a feature rather than a bug. :)
I have tried pasting the same text into plain text areas in other apps as well as apps that accept formatting. An app that accepts rich text does render the rich version - apps that only accept plain text only show the unrendered version.
I have not done any work with buffers but I just did some research and found that Copy in a browser and other rich text providers returns a structured copy buffer, not just plain text:
https://msdn.microsoft.com/en-us/library/aa767917%28v=vs.85%29.aspx
Here is the HTML for this bold and underlined text.
That came from Notepad++ by going to Edit>Paste Special>Paste HTML Content.
With that info and related keywords I'm sure you'll be able to find code for parsing out the plain text.
OR... Perhaps we could document this as a feature, recommend shift-INS to paste the text component of a copy buffer which includes HTML, and provide a context help button on the Comments area which links directly to the relevant wiki page. That would take care of everything.
For extra points, perhaps you could detect when the copy buffer has an HTML component and prompt the user: "This text is HTML-encoded. If you wish to preserve formatting, switch the comments to Rich Text. If you wish to see the HTML in your paste, click OK. If you only want the plain text, click Cancel here, then use Shift-INS to do the paste."
Thanks!
T
I'm getting a selection from Firefox of the text from my original post:
Now I'm using ctrl-V to paste into a Comment:
The red area is the HTML version of the plain text. So the copy pulls both the source and the rendered text. A normal paste with ctrl-V pastes both the source code as well as the rendered text. But shift-INS pastes only the rendered version.
This could be considered a feature rather than a bug. :)
I have tried pasting the same text into plain text areas in other apps as well as apps that accept formatting. An app that accepts rich text does render the rich version - apps that only accept plain text only show the unrendered version.
I have not done any work with buffers but I just did some research and found that Copy in a browser and other rich text providers returns a structured copy buffer, not just plain text:
https://msdn.microsoft.com/en-us/library/aa767917%28v=vs.85%29.aspx
Here is the HTML for this bold and underlined text.
Version:0.9
StartHTML:00000206
EndHTML:00000320
StartFragment:00000240
EndFragment:00000284
SourceURL:https://groups.google.com/forum/?hl=en#!category-topic/abstractspoon-todolist-support/NhBRwk4I5-k
<html><body>
<!--StartFragment-->this <b>bold</b> and <u>underlined</u> text.<!--EndFragment-->
</body>
</html>That came from Notepad++ by going to Edit>Paste Special>Paste HTML Content.
With that info and related keywords I'm sure you'll be able to find code for parsing out the plain text.
OR... Perhaps we could document this as a feature, recommend shift-INS to paste the text component of a copy buffer which includes HTML, and provide a context help button on the Comments area which links directly to the relevant wiki page. That would take care of everything.
For extra points, perhaps you could detect when the copy buffer has an HTML component and prompt the user: "This text is HTML-encoded. If you wish to preserve formatting, switch the comments to Rich Text. If you wish to see the HTML in your paste, click OK. If you only want the plain text, click Cancel here, then use Shift-INS to do the paste."
Thanks!
T
.dan.g.
Jan 4, 2016, 6:38:55 PM1/4/16
to abstractspoon-t...@googlegroups.com
Thx Tony.
It may be that this issue only manifests with Firefox so I'll need to check that.
[Update] Indeed, it seems that Firefox copies text to the clipboard differently to Chrome and I'm not handling it. [/Update]
.dan.g.
Jan 14, 2016, 3:31:36 AM1/14/16
to ToDoList (AbstractSpoon) Support
Fixed in 7.0.12
On Tuesday, 5 January 2016 06:31:17 UTC+11, Tony G wrote:
On Tuesday, 5 January 2016 06:31:17 UTC+11, Tony G wrote:
Reply all
Reply to author
Forward
0 new messages