After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 603715 - Paste as plain text
Paste as plain text
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
unspecified
Other All
: Normal enhancement
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[composer]
: 302941 554392 607133 608147 609805 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-12-03 18:08 UTC by John Lange
Modified: 2010-02-13 03:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Print clipboard formats when pasting (969 bytes, patch)
2009-12-04 00:47 UTC, Matthew Barnes
reviewed Details | Review

Description John Lange 2009-12-03 18:08:49 UTC
When copy & pasting into a plain text email, Evolution should have an option for "Past as plain text" to strip out any formatting.

For example, when copy & pasting from OpenOffice Calc, Evolution currently puts the pasted text into a table (or I think more recently an image attachment!?!).

In this email thread it was revealed that many users find this frustrating:

http://mail.gnome.org/archives/evolution-list/2009-December/msg00010.html

The work-around is to have plain text-editor (for example, gedit) running and to copy and paste there to strip formatting and then re-copy and paste into evolution. Given that gedit is doing what we want, there is probably some code there that could be utilized for this feature?

Suggested key combination would be SHIFT-CTRL-V "Paste as Plain Text".

Alternatively, other users suggested that "Paste as Plain Text" should always be the default when composing email in plain text so that should be considered as well.
Comment 1 Matthew Barnes 2009-12-03 19:56:20 UTC
We only have partial control over how things are pasted.  It also depends on what data formats these applications are making available to the clipboard.  We can only retrieve what's available, and maybe do some limited conversion in certain cases.  I think the proposal makes sense though and should certainly be doable for HTML and maybe even rich text data.

I'd be interested to hear more use cases to get a better sense of what users are trying to paste.  There's some guesswork involved when the clipboard is advertising multiple data formats.

Not sure if I agree with making "Paste as Plain Text" default for plain text mode.  I'll have to think on that.
Comment 2 John Lange 2009-12-03 22:09:25 UTC
The proper action would depend on the context. Here are some examples:

In Nautilus I select a file and "copy" it. I then compose an email and select paste.

By default, it should make the file an attachment.

If I select, "Paste as plain text" it should paste the full path to the file into the message body.

If I copy from OpenOffice Writer and paste into HTML, it should preserve formatting. In plain text, it should paste only the text, no formatting.

If I copy some cells from OOCalc and paste into HTML, it should paste as a table. If I paste into plain text, it should paste as a "simulated" table, that is, paste the text from the cells and replicate the "table" appearance of original cells using whitespace.

If I copy an image from f-spot then paste into HTML, it should put the picture in the body. If I paste into plain-text, it should make the image an attachment.

If I copy from Firefox and paste as HTML, (obviously) it should paste the HTML. if I paste plain text, it should paste the text and possibly we could think about if it should paste the images as attachments (that could be ugly but potentially useful in many cases).

If I copy from gnome terminal and paste into HTML, it should paste the text in a mono-spaced font. Past into plain text should be obvious.

Those are the ones I use day-in-and-day-out. I hope others can give some additional examples.
Comment 3 Matthew Barnes 2009-12-03 22:57:18 UTC
(In reply to comment #2)
> The proper action would depend on the context. Here are some examples:
> 
> In Nautilus I select a file and "copy" it. I then compose an email and select
> paste.
> 
> By default, it should make the file an attachment.

I just implemented that today (bug #551464).  :)


> If I select, "Paste as plain text" it should paste the full path to the file
> into the message body.

I agree, that makes sense.

 
> If I copy from OpenOffice Writer and paste into HTML, it should preserve
> formatting. In plain text, it should paste only the text, no formatting.
> 
> If I copy some cells from OOCalc and paste into HTML, it should paste as a
> table. If I paste into plain text, it should paste as a "simulated" table, that
> is, paste the text from the cells and replicate the "table" appearance of
> original cells using whitespace.

Also makes sense.  I'll have to see what data formats OpenOffice makes available to the clipboard.

 
> If I copy an image from f-spot then paste into HTML, it should put the picture
> in the body. If I paste into plain-text, it should make the image an
> attachment.

That should work already.  In fact, I think the "pasting a table inserts an image" bug is a side-effect of that feature.   OpenOffice apparently includes "image/png" among its available clipboard formats for tables, and we happen to check for image data first.


> If I copy from Firefox and paste as HTML, (obviously) it should paste the HTML.
> if I paste plain text, it should paste the text and possibly we could think
> about if it should paste the images as attachments (that could be ugly but
> potentially useful in many cases).

Sifting through an arbitrary hunk of HTML and extracting attachments is not feasible right now, but I believe the rest of that works already.  The image tags are left alone, and the recipient will have to fetch the images for themselves.


> If I copy from gnome terminal and paste into HTML, it should paste the text in
> a mono-spaced font. Past into plain text should be obvious.

It may not be possible to distinguish text from a terminal program.  I'll check what data formats GNOME Terminal makes available to the clipboard.  My guess is probably just "text/plain".


This is good stuff.  I think I'm convinced of the usefulness of a "Paste as Plain Text" option and these are some good use cases to focus on.
Comment 4 Nick Jenkins 2009-12-03 23:44:25 UTC
Was going to log this as a new bug (I'm reading the mailing list in digest mode, so I'm typically a bit behind, sorry!). Here's what I was going to submit:

-----------------------------------------------------------------
Always "Paste as plain text" when pasting text into a plain text email.

Steps to reproduce:
1) In Evo, go File -> New -> Mail message.
2) Make sure that it is a plain text mail, i.e. make sure that Format -> Plain Text is selected.
3) Copy some formatted text from a web page (e.g. do a select-all copy from http://au.yahoo.com/ ), or from a document with tables/formatting/etc from OpenOffice.org writer.

What happens:
The pasted text includes non-plain text elements, such as HTML tables, HTML text fields, HTML buttons, HTML checkboxes, listboxes, etc. The result is neither fully formatted as per the original, nor is it straight plain text.

What should happen instead:
Only plain text should be pasted when pasting text into a plain text email, as per the following workaround:
1) Copy the formatted text.
2) Open a text editor (e.g. gedit)
3) Paste into Gedit
4) Do a select-all + copy in Gedit
5) Paste this into Evolution's composer
6) The result is straight plain text, and is what should happen, except without steps 2), 3) and 4) being required.

Reproducible:
Always.
-----------------------------------------------------------------

... so expanding on this and thinking aloud about the above cases some more, with a plain text email, there really are only 3 kinds of valid pasting:
1) Paste as plain text.
2) Paste as email attachment.
3) "paste as quotation", which is really a user-selected variation that means "paste as plain text" + add line wrapping and ">" marks.

That's it, and every kind of paste into a plain text email ultimately has to reduce to one of these options.

As to which should be the default ctrl-V action for the different data types when in plain text mode:
* copied files from nautilus -> paste as attachment, as per bug 551464. (working in 2.30)
* copied from Firefox -> paste as plain text. (not working, currently includes HTML artifacts, as described above)
* Copied from OpenOffice.org writer -> paste as plain text. (not working, currently includes tables, as described above)
* Copied from OpenOffice.org calc -> paste as plain text (probably as tab separated text, as per paste into gedit) (not working, pastes as image rather than as text).
* An image copied from Firefox or an image editor -> paste as attachment (seems to work already).
* Copied from a terminal -> paste as plain text. (seems to work already).

And presumably then for HTML mails there are 4 kinds of paste, namely:
1) Paste as formatted HTML.
2) Paste as plain text.
3) Paste as email attachment.
4) "paste as quotation", which is really a user-selected variation that means "paste as plain text" + add line wrapping and ">" marks.

I personally don't use HTML mails much, so John's suggestions for defaults sound reasonable to me, i.e.:
* copied files from nautilus -> paste as attachment.
* copied from Firefox -> paste as HTML.
* Copied from OpenOffice.org writer -> paste as formatted HTML text.
* Copied from OpenOffice.org calc -> paste as formatted text in a table.
* An image copied from firefox or an image editor -> paste as attachment or inline image.
* Copied from a terminal -> paste as mono-spaced text.
Comment 5 Matthew Barnes 2009-12-04 00:47:27 UTC
Created attachment 149061 [details] [review]
Print clipboard formats when pasting

I hacked together a little toy patch to print available clipboard formats when pasting.  Posting this here mainly so I can come back to it, but it might also be of interest to others.

I'll run through some of the use cases posted here.  Bear in mind the list of formats is all we have to go on.  There's no way to determine the source of the data.

1) Open http://au.yahoo.com/ in a browser, select all, and copy.

Available Clipboard Targets:
  TIMESTAMP
  TARGETS
  MULTIPLE
  text/html        <-- we choose this
  UTF8_STRING
  COMPOUND_TEXT
  TEXT
  STRING
  text/plain;charset=utf-8
  text/plain

Bear in mind that Evolution's composer allows you to switch between plain text and HTML modes on the fly, and that GtkHTML only deals with HTML.  We choose "text/html" regardless of the current editing mode.  If the editing mode is plain text, GtkHTML converts the raw HTML to different HTML that -looks like- plain text.  (And clearly the converter needs some improvement.)  So if you then switch to HTML mode, ideally you should see exactly what you see in your browser.  But because GtkHTML doesn't understand CSS, most modern web pages look like ass.  That should improve drastically when we switch to WebKit.

A "Paste as Plain Text" option probably makes the most sense here, because then we would simply select the "text/plain" format as GEdit is doing.


2) Open http://www.google.com/, right click on the Google logo and copy the image.

Available Clipboard Targets:
  TIMESTAMP
  TARGETS
  MULTIPLE
  SAVE_TARGETS
  image/png
  image/x-icon
  image/x-ico
  image/x-win-bitmap
  image/tiff
  image/jpeg
  image/bmp
  image/x-bmp
  image/x-MS-bmp

In HTML mode, we insert the image directly in the message body.  In plain text mode, we save the image to disk as a PNG file and then add it as an attachment.  What sucks about this case is we have no way to find out what format the source image really is.  So we always blindly choose "image/png", even if the source image is a JPEG.

"Paste as Plain Text" would not be enabled in this case.


3) Select some text in GNOME Terminal and copy:

Available Clipboard Targets:
  TIMESTAMP
  TARGETS
  MULTIPLE
  SAVE_TARGETS
  UTF8_STRING
  COMPOUND_TEXT
  TEXT
  STRING
  text/plain;charset=utf-8
  text/plain

There's nothing here to distinguish the data as coming from a terminal program.


4) Select some files in Nautilus and copy:

Available Clipboard Targets:
  TIMESTAMP
  TARGETS
  MULTIPLE
  x-special/gnome-copied-files
  text/uri-list        <-- we choose this
  UTF8_STRING
  COMPOUND_TEXT
  TEXT
  STRING
  text/plain;charset=utf-8
  text/plain

As of today this now works, because I added a check for "text/uri-list".  We grab the URIs and add them to the attachment list.  Prior to today we were choosing "text/plain", which pastes the raw URIs.  "Paste as Plain Text" would do just that.


5) Select some cells in OpenOffice Calc and copy:

Available Clipboard Targets:
  text/plain;charset=utf-8
  text/plain;charset=UTF-8
  UTF-8
  UTF8_STRING
  COMPOUND_TEXT
  STRING
  application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
  application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)"
  application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile"
  application/x-openoffice-emf;windows_formatname="Image EMF"
  application/x-openoffice-wmf;windows_formatname="Image WMF"
  application/x-openoffice-bitmap;windows_formatname="Bitmap"
  PIXMAP
  image/bmp        <-- we choose this
  text/html
  application/x-openoffice-sylk;windows_formatname="Sylk"
  application/x-openoffice-link;windows_formatname="Link"
  application/x-openoffice-dif;windows_formatname="DIF"
  text/richtext
  MULTIPLE

Plenty here to work with but we would have to check for "x-openoffice-*" specifically, which we're not doing currently.  So what happens is we spot the "image/bmp" and choose that.  We check for image formats first so that case #2 works.

Pasting cells from Gnumeric, however, works correctly.  This is its format list:

Available Clipboard Targets:
  TIMESTAMP
  TARGETS
  MULTIPLE
  SAVE_TARGETS
  application/x-gnumeric
  text/html        <-- we choose this
  UTF8_STRING
  COMPOUND_TEXT
  STRING

No image formats available, so we choose "text/html" and it works as expected.


So as you can see from all this, correct pasting behavior is very much a case-by-case issue.
Comment 6 Nick Jenkins 2009-12-04 02:57:25 UTC
Interesting. My completely naive first-instinct, in pseudo-code, would be something very simple for choosing the clipboard format to use, like so:

--------------------------------------------------------
if( list_contains( paste_supported_formats, "text/uri-list" ) )
        return "text/uri-list";
if( is_html_email( msg ) && list_contains( paste_supported_formats, "text/html" ) )
        return "text/html";
if( list_contains( paste_supported_formats, "text/plain" ) )
	return "text/plain";
if( list_contains( paste_supported_formats, "text/plain;charset=utf-8" ) )
	return "text/plain;charset=utf-8";
if( list_contains( paste_supported_formats, "text/plain;charset=UTF-8" ) )
	return "text/plain;charset=UTF-8";
if( list_contains( paste_supported_formats, "UTF8_STRING" ) ) 
	return "UTF8_STRING";
if( list_contains( paste_supported_formats, "TEXT" ) ) 
	return "TEXT";
if( list_contains( paste_supported_formats, "STRING" ) )
	return "STRING";
if( list_contains( paste_supported_formats, "image/jpeg" ) )
	return "image/jpeg";
if( list_contains( paste_supported_formats, "image/png" ) )
	return "image/png";
if( list_contains( paste_supported_formats, "image/bmp" ) )
	return "image/bmp";
--------------------------------------------------------

i.e. in order for the default pasting behavior: URI, then html (but only if msg is not in plain text format), then plain text string variants, then image variants.

That doesn't really help the case of selecting the right image format to use though.
Comment 7 Matthew Barnes 2009-12-04 04:13:09 UTC
I think I agree overall since case #2 in comment #5 has no text types, so there's no ambiguity.  So for the moment let's collapse the list down to the following:

   1. Check for "text/uri-list".
   2. Check for other text types (most of them are just aliases).
   3. Check for "image/*" (prioritizing the subtypes won't help).

That solves the spreadsheet case.

The next policy decision is what should happen when HTML is pasted in plain text mode.  Two choices:

   1.  Leave Edit -> Paste as is and add a new "Paste as Plain Text" option.
   2.  Pasting in Plain Text mode prefers "text/plain", HTML mode prefers "text/html".

The consensus seems to be for the latter option, in which case maybe we don't need the extra paste option at all.  I don't think users writing HTML mail would use it.
Comment 8 Nick Jenkins 2009-12-04 07:50:10 UTC
> Pasting in Plain Text mode prefers "text/plain",
> HTML mode prefers "text/html".

Yes, that sounds very good to me. 

> in which case maybe we don't need the extra paste option at all

Yes, i.e. avoiding adding another option by having good default behavior. It's certainly worth trying as the first approach, and then if unsolvable cases crop up, then maybe later there could be a "paste as plain text" or "paste special" which is un-grayed when there are multiple applicable choices, and which offers a choice from the available pasting types.

> I don't think users writing HTML mail would use it.

And coming at from the other angle, I don't think users writing in plain text want to be able to paste text/html - I understand about being able to switch from plain-text format to HTML format which composing, but the reality (I think) is that after working out what they like, most users are going to pick either HTML format or Plain Text format and use that for most of their messages, OR they are going to pick a format when they start composing/replying.
Comment 9 John Lange 2009-12-04 20:59:07 UTC
Excellent work guys.

> I don't think users writing in plain text want to be able to paste text/html

I agree. If I want to preserve html, then I'll switch to HTML mode before pasting.

> Pasting in Plain Text mode prefers "text/plain", HTML mode prefers "text/html".

Bingo! But if you aren't going to add "Paste as plain text" that means we have to re-visit what to do with text/uri-list when pasting into plain text.

Sounds like the change you've just made will add them as attachments with no way to paste the list of file names. So we either still need "paste as plain text" option or, plain text is the default with a "Paste as Attachment" option.

Thinking this through, I'm leaning towards the "Paste as Attachment" option simply because "Paste as Plain Text" would effectively be the default when editing in Plain Text mode so it's not needed.

And lets just say for the sake of argument that someone really likes the way oOCalc now pasts as an image attachment. They could still get that functionality with "Paste as Attachment" option.

Are there are other situations where "Paste as Attachment" could be useful? From the examples provided above, it seems that there are. In the case of the google image, if you are editing in HTML mode, "Paste as Attachment" offers an additional useful function. Rather than pasting into the body, it would make an attachment.

I'm just curious what you get when from ooCalc you select  "text/plain;charset=utf-8"? What does oO give you in terms of formatting? Is it a simulated table with white space or just a single space between the cells or ?

Whatever it is we'll have to live with it but I'm just curious.
Comment 10 Matthew Barnes 2009-12-05 03:55:24 UTC
(In reply to comment #9)
> Bingo! But if you aren't going to add "Paste as plain text" that means we have
> to re-visit what to do with text/uri-list when pasting into plain text.
> 
> Sounds like the change you've just made will add them as attachments with no
> way to paste the list of file names. So we either still need "paste as plain
> text" option or, plain text is the default with a "Paste as Attachment" option.

I don't think we do.  The "paste URIs from Nautilus" use case alone doesn't warrant a new Paste option, and I think it's debatable whether that's a real use case.  About the only places I ever paste URIs from is a web browser or email messages.  And those cases still work fine.


> And lets just say for the sake of argument that someone really likes the way
> oOCalc now pasts as an image attachment. They could still get that
> functionality with "Paste as Attachment" option.

Pasting spreadsheet data as an image is a bug (bug #574071 to be exact).  I'm not concerned with preserving that behavior.  If someone finds it useful they can take a screenshot.


> Are there are other situations where "Paste as Attachment" could be useful?
> From the examples provided above, it seems that there are. In the case of the
> google image, if you are editing in HTML mode, "Paste as Attachment" offers an
> additional useful function. Rather than pasting into the body, it would make an
> attachment.

That's a good use case, but "Paste as Attachment" isn't the right answer here either.  You should be able to either focus the attachment bar and click Edit -> Paste or right-click in the attachment bar and click Paste from the pop-up menu.  That doesn't work right now so I'll get that working while I'm still thinking about this stuff.


> I'm just curious what you get when from ooCalc you select 
> "text/plain;charset=utf-8"? What does oO give you in terms of formatting? Is it
> a simulated table with white space or just a single space between the cells or

I'm guessing a simulated table with the data nicely aligned.  In the past, before the image bug was introduced, we would grab the "text/html" data -- which would be an HTML table -- and convert that to plain text ourselves.
Comment 11 Nick Jenkins 2009-12-07 02:12:09 UTC
> add them as attachments with no way to paste the list of file names.
> So we either still need "paste as plain text" option

I don't think pasting the full file path into an email is a common use case. Certainly vastly less common than adding attachments. For the rare occasions when somebody does want this, the workaround of copy in nautilus + paste into the nautilus location bar + copy nautilus location bar address will give them this, even for multiple files.

> I'm just curious what you get when from ooCalc you select 
> "text/plain;charset=utf-8"? What does oO give you in terms of formatting? Is it
> a simulated table with white space

I strongly suspect that it will be tab-delimited plain text (e.g. for a 2x2 table: cell A1 contents + tab character + cell B1 contents + newline character + cell A2 contents + tab character + cell B2 contents), and that's probably what we'd want anyway, as this round-trips cell text contents to/from spreadsheet <-> plain text correctly, and it's also what Excel does (so it's what existing spreadsheet users as likely to expect).
Comment 12 John Lange 2009-12-07 18:06:58 UTC
> I don't think pasting the full file path into an email is a common use case.

I accept that it's not common and we can live without it. It's certainly not a show stopper but keep in mind, it's never been possible so obviously it couldn't be common.

I'm not deeply involved with gnome or evolution development so I apologize if this is out of turn, but if I select files in nautilus, and then paste in gedit, it pastes the full file paths.

And in OpenOffice, "Paste as plain text" does the same.

Should it not be the goal of gnome to have applications do similar things in similar situations?

If we accept that as true, then editing in "plain/text" should be much the same as gedit with exceptions that allow for attachments where that makes sense as the default and "paste as plain text" for other situations.

In 2.28, Evolution makes the "wrong" paste choice in every situation where there is any other choice besides text/plain so using gedit as an intermediate step is how I accomplish all my copy & pasting into Evolution. My goal with filing this bug report is to eliminate the need to use gedit.

Already implementing the things that have been discussed here will make life a lot easier but I'll still have to use gedit for some things.

Ultimately I think I'm convinced that the "paste as plain text" option makes the most sense given that it solves the issue and matches the functionality of other applications that users are already familiar with.
Comment 13 Nick Jenkins 2009-12-08 06:53:14 UTC
As I understand it, what's being proposed should eliminate the need to use gedit in all cases apart from pasting file paths (gedit is taking the plain text formatted data, which is what Evo would prefer too for plain text mails under what's being discussed), when editing plain text formatted emails.

> If we accept that as true, then editing in "plain/text" should be much the 
> same as gedit with exceptions that allow for attachments where that makes
> sense as the default and "paste as plain text" for other situations.

Personally, I definitely question whether the remaining single use-case of pasting the full file path justifies adding a new menu option, especially when it seems to be such a rare thing to do or want (I don't think the previous path-pasting behavior was a by-design use-case, which is how come the original feature request for pasting attachments dated back to 2003, with no objections, so it was a change that has been requested for over 6 years, and I'm rather doubtful that anyone will miss the old behavior).

> Should it not be the goal of gnome to have applications do similar things 
> in similar situations?

I'm all for consistency of behavior, where it makes sense, but in this case the least-surprising thing for an email client is to paste an attachment, not to paste the full file path. You can't attach arbitrary files to a plain text file / spreadsheet, in the same way that you can to an email, but if you could, then presumably those apps would paste attachments too.
Comment 14 Matthew Barnes 2009-12-08 06:59:50 UTC
How about a compromise?  The paste behavior for text/uri-list will depend on the input focus.  If the editing area is focused, we'll paste URIs.  If the attachment area is focused, we'll add attachments.  No loss of functionality, and no superfluous paste option.
Comment 15 John Lange 2009-12-08 16:57:13 UTC
> If the editing area is focused, we'll paste URIs.

Yes, but only in plain text mode. In HTML mode it should attach a file and/or put the image in the body ( assuming thats possible. I don't use HTML mode so I'm not all that familiar with it).

> If the attachment area is focused, we'll add attachments.

Yes, that makes sense in all modes.

Anyhow, I think I've meddled enough ;). You guys are on the right track. As long as it pastes "plain text" while in plain text mode, I'm happy.
Comment 16 Nick Jenkins 2009-12-10 06:45:05 UTC
> > If the editing area is focused, we'll paste URIs.
>
> Yes, but only in plain text mode. In HTML mode it should attach a file
> and/or put the image in the body

No, I think attaching a pasting a URI should not work differently in plain text mode or HTML mode. It should work the same in both modes for maximum user-friendliness.

> If the editing area is focused, we'll paste URIs.  If the
> attachment area is focused, we'll add attachments.

I really want to like it, as I'm very sympathetic to people trying to reach a compromise - but I'm sorry, I just not that keen on it. The reason why I'm not so keen on is that it makes the rare thing easy (pasting full file path), and the common thing non-obvious and hard-to-discover (pasting attachments by noticing the need to focus the attachment bar first). I.e. a user is likely to try pasting a uri into the body text, get the file path instead, and conclude that Evo can't do it. Ideally for maximum user-friendliness, the common use-case should be easy, and potentially the rare thing should be possible.

My personal preferences, with the primary objective of maximizing user-friendliness, are in order:
1) smart pasting on ctrl-v, as per comment 7, with no option for alternative pasting methods. (does what the user wants in a way that solves > 99% of use cases, doesn't add any more options).
2) smart pasting, as per comment 7 on ctrl-v, with a "Paste Special" menu option, if there is more than one supported pasting method, that expands into a sub-menu that has a choice of "paste as plain text", "paste as attachment", and in HTML mode also has "paste as HTML". (or those options could appear directly under the "edit" menu, it doesn't matter much; also the options which were not supported by the data on the clipboard should be greyed out/disabled). This option does what the user wants > 99% of the time automatically, and has options for manual override for the other < 1% of the time, when users want something a bit unusual; but the downside is that the user has to learn more options, which in itself is slightly less friendly.
3) smart pasting, except without the smart attachment pasting, which has to be done via the attachment bar. It does what the user wants 98% of the time.

If I understand correctly, John prefers option 2 (or something quite similar to it), whereas I would prefer option 1. Despite the apparently differences, I think they're actually very very small, and I could easily be happy with option 2. Essentially the discrepancy comes down to: Are the extra pasting menu options justified by the times when users don't want the smart pasting choice? If you think those cases are non-rare or should be kept to allow a manual override, you prefer option 2, otherwise you prefer option 1. And if you observe people debate between option 1 and option 2 for long enough, then probably option 3 starts to look good ;-)

> If the attachment area is focused, we'll add attachments.

Yes, I agree with that, but I think the main game is what happens in the body text, and I don't think the attachment bar pasting nullifies the need to make pasting work in an appropriate way in the body text. Thus, paste with uris in body text should still add attachments IMHO - but if there's genuine desire for pasting the full file path, then okay, I'll compromise, let's have a "paste as plain text" option (i.e. option 2, smart pasting with options for manual override).

> Anyhow, I think I've meddled enough ;)

Ditto - I think I've said all I can productively say on this topic, and will try to butt out now and leave it to the devs to make of it as they wish!
Comment 17 Matthew Barnes 2010-01-16 14:43:05 UTC
*** Bug 607133 has been marked as a duplicate of this bug. ***
Comment 18 Matthew Barnes 2010-01-17 18:51:16 UTC
Spent the weekend working on this so it's finished in time for 2.29.6.  There's still a few more point releases left before 2.30 to test and tweak it.  I still need to make sure drag-and-drop behavior is consistent with pasting.

Here's the commit:
http://git.gnome.org/browse/evolution/commit/?id=3e7c7808cc65c22bc40a7d1d30ffa0044097a6ff

I decided against adding any more paste options, but I also tried to make sure all the major use cases identified here work as expected.  In particular:

1) Pasting files from Nautilus adds them as attachments.  Always.

2) Pasting image data from a web browser or image viewer embeds a PNG image into the editing area in HTML mode, and adds a PNG image attachment in plain-text mode.

3) Pasting cells from spreadsheet inserts an HTML table in HTML mode, and a formatted text table in plain-text mode.  Note: it's up to the spreadsheet program to provide the data in these two forms -- we don't do any formatting ourselves.

4) Pasting content from a web browser or word processor inserts HTML content (if available) in HTML mode, and plain text in plain-text mode.  Again, it's up to the web browser or word processor to provide the data in these two forms -- we don't do any formatting ourselves.

I think that covers all the major use cases.  Feedback on this new behavior prior to 2.30 would be most appreciated.  Closing this as FIXED, but will reopen if something comes up.
Comment 19 Matthew Barnes 2010-01-17 19:31:58 UTC
*** Bug 302941 has been marked as a duplicate of this bug. ***
Comment 20 Matthew Barnes 2010-01-17 19:36:46 UTC
*** Bug 554392 has been marked as a duplicate of this bug. ***
Comment 21 Paul Smith 2010-01-18 15:04:07 UTC
I rebuilt with this successfully but I think something is still not right.  When I cut something (from this bug in FireFox actually) and try to paste into an Evo email in HTML mode I get a "[?]" pasted, and in the log file I see:

(evolution:2784): gtkhtml-editor-WARNING **: : No such language

(evolution:2784): libebook-WARNING **: ../../../../evolution-data-server/addressbook/libebook/e-book.c:2214: cannot get book from factory: Invalid source

(not sure if the first line is related or not).  Does this mean I haven't installed something correctly?
Comment 22 Paul Smith 2010-01-18 15:25:23 UTC
FYI I tried a paste into a message in text mode, and that worked.  I also tried pasting (mouse-2) into an html message after selecting text in an xterm, and that worked.

I right-clicked on an image in FF and said "copy image", then pasted into an html message and that worked (I got an inline image).  Pasting it into a text message gave me an attachment.

I tried copying from an OO.o doc and pasting into both text and html messages and that seemed to work.

So, it really seems like most everything is working except pasting text from FF into an html message?
Comment 23 Matthew Barnes 2010-01-26 12:50:15 UTC
*** Bug 608147 has been marked as a duplicate of this bug. ***
Comment 24 Paul Smith 2010-01-26 13:07:02 UTC
Hi Matt: are you going to reopen this bug based on my comment 21 and comment 22 or should I open a new one for that behavior?  thanks!
Comment 25 Matthew Barnes 2010-01-26 13:23:36 UTC
(In reply to comment #24)
> Hi Matt: are you going to reopen this bug based on my comment 21 and comment 22
> or should I open a new one for that behavior?  thanks!

Pasting text from Firefox seems to work fine for me, so I suspect the issue you're seeing is not directly related to these changes.  Better to open a separate bug with detailed reproducer steps, as this one is already getting rather long-winded.
Comment 26 pko 2010-01-26 14:02:27 UTC
Hi Mat,

I can see that the bug is marked with fixed.

You do not indicate in which version this is fixed and I find it
rather annoying with this one. Maybe the fix also should include
version 2.28.x
I know it is not essential from a technical point but how many users
will be running away due to such kind of 'added enhancement'?

The error still lives in Ubuntu 10.04 with Evolution 2.28.2 at writing
moment.
Comment 27 Matthew Barnes 2010-01-26 14:07:22 UTC
It's fixed in 2.29.6.  There are no more releases scheduled for 2.28.
Comment 28 Paul Smith 2010-01-26 14:19:04 UTC
OK added bug 608160 with repro cases.  Note it only fails with C-c/C-v cut/paste; using select/mouse-2 cut/paste works fine (although no formatting is preserved obviously).
Comment 29 Nick Jenkins 2010-02-02 00:53:06 UTC
Just a quick note to say thank you to Matt for implementing this (and doing it so quickly), thank you to John for productively discussing the behavior, and thank you to Paul for testing it, and very much looking forward to using this in Evo 2.30.
Comment 30 Matthew Barnes 2010-02-13 03:09:27 UTC
*** Bug 609805 has been marked as a duplicate of this bug. ***