Opened 12 years ago

Last modified 2 years ago

#1198 new defect

Pasting formatted text should reset formatting after message sent

Reported by: rageboy Owned by: deryni
Milestone: Component: pidgin (gtk)
Version: 2.3.1 Keywords:
Cc: tmetro, elreydetodo, Oo.et.oO

Description

When I copy something from a webpage and paste it into an IM window, all my formatting, except the background is erased. Ok, that's fine. When I push enter though, my default formatting is not reset, as it should be. My text size and text color both stay screwed up.

Quote from sf bug:

There's a second half to this that I'm seeing. If I copy text from one conversation to another (because I like to talk about one person behind his back) the text looses parts of the formatting after being copied. Mostly it's the color that gets lost. Both in the text after its been pasted, and in the chat window where it origianlly came from.

Current workaround: Use Ctrl+R

Change History (35)

comment:1 Changed 12 years ago by rageboy

Another idea would be the quote from a different, related sf bug:

My suggested fix would be either to ignore formatting on pasted text, or make sure that formatting is restored after a paste is made.

comment:2 Changed 12 years ago by lschiere

  • Milestone set to 2.1.0
  • Owner set to seanegan

comment:3 Changed 12 years ago by seanegan

  • Resolution set to fixed
  • Status changed from new to closed

comment:4 Changed 12 years ago by seanegan@…

(In 1021f142edad27e5a1f750f8d439c3bc5bf07b81) Re-arrange a few lines in gtkimhtml's paste function so that we reset formatting after moving the cursor to the new location. Fixes #1198

comment:5 Changed 12 years ago by endolith

On Launchpad 115846, I suggested that the "Reset formatting" option be a toggle instead. By default, it's on, which resets your formatting after each message, but you can turn it off if you want to adopt a different formatting for a while.

comment:6 Changed 11 years ago by endolith

This doesn't appear to be fixed.

comment:7 Changed 11 years ago by Sim-on

  • Milestone changed from 2.1.0 to 2.4.1
  • Resolution fixed deleted
  • Status changed from closed to reopened

i closed #1939, #4343, #2907 and #1552 as duplicates of this

comment:8 Changed 11 years ago by Sim-on

  • Summary changed from Pasting formatted text should reset formatting after message sent to MSN: Pasting formatted text should reset formatting after message sent
  • Version changed from 2.0 to 2.3.1

Does anyone still recognises this in other protocols than MSN?

comment:9 Changed 11 years ago by endolith

I don't think this is protocol-specific

comment:10 Changed 11 years ago by SineSwiper

No, it's not. I have the same problem in AIM, as well. Please change the summary to reflect this, as it is currently misleading.

comment:11 Changed 11 years ago by Sim-on

  • Summary changed from MSN: Pasting formatted text should reset formatting after message sent to Pasting formatted text should reset formatting after message sent

comment:12 Changed 11 years ago by endolith

And please think about implementing this as a toggle, as I suggested several times, in which the button can be pressed in to reset the formatting after each message, or unpressed to keep the formatting after each message.

It's fine if you don't like this idea and reject it, but it seems to have been completely ignored or unnoticed so far, which is not fine.

comment:13 Changed 11 years ago by sean.collins

Not to be a nuisance, but this is pretty annoying. I also think it should be implemented.

Is there a good reason to not have Reset Formatting also be a check box?

comment:14 Changed 10 years ago by bernmeister

Perhaps this could be moved to Patches Welcome?

comment:15 Changed 10 years ago by deryni

Ticket #9354 has been marked as a duplicate of this ticket.

comment:16 Changed 10 years ago by deryni

Ticket #9321 has been marked as a duplicate of this ticket.

comment:17 Changed 10 years ago by bernmeister

Suspect #3183, #4759 and #5879 are all related and partially duplicates of #1198.

comment:18 Changed 10 years ago by darkrain42

  • Owner changed from seanegan to deryni

From #5879:

deryni:

I think the most expected behaviour might actually be to keep the formatting of the last entered text. Which may be what is currently happening, can someone test this? (It sounds like it isn't but I'd like confirmation.)

I'm not sure always-last is any more consistent (from the user's perspective, especially if they've gone back to edit (or potentially edit) text) than the current from-insertion-point (assuming it isn't from-last-edit).

andrixnet:

If by "last entered text" you mean the last character of the message, then I agree, and this is IMHO the expected behaviour and also the existing behaviour of all rich text editors.

Currently, as far as I can determine, pidgin uses the format of the character where the cursor is as reference for formatting text on the next message, which many times is confusing and many times I had to use the "reset formatting" button because of this.

comment:19 Changed 10 years ago by darkrain42

Ticket #5879 has been marked as a duplicate of this ticket.

comment:20 Changed 10 years ago by deryni

My latest comment on #5879 (that'll teach me to read my email out of order):

I mean the last character of the message if that was the last character entered, otherwise whatever other character was last entered.

If you type "This is my messsage.<enter>" then the formatting for . should persist. If, on the other hand, you typed "This is mu message.<left*9> <bksp>y<enter>" then the formatting of the y should persist.

Why is your input cursor not on the last character in the message? did you go back to edit the message? Why would you not expect the formatting you were last typing in to persist? Non-IM applications don't really have a comparable usage to model after (though the closest I can think of is the go-back-and-edit model, which will use whatever the formatting at the point of edit is for future typing until you either unset it or move out of that formatting area).

comment:21 Changed 10 years ago by endolith

The formatting should never persist at all. If you want a default formatting, set it in Preferences. (Though maybe the "Reset formatting" button should be changed into a "Set current formatting as default" instead?)

comment:22 Changed 10 years ago by deryni

"Reset formatting" and "set current formatting as default" are two entirely different functions, and no the formatting from a paste likely should not persist but formatting that is manually specified has every reason to persist, as well as many reasons not to persist, unfortunately only the user knows if they want persistence or not for any given message and formatting.

comment:23 Changed 10 years ago by endolith

Yes, they are entirely different functions. If this bug is fixed, one will become obsolete.

comment:24 follow-up: Changed 10 years ago by deryni

Even if formatting never persisted longer than was desired (as in this bug), and by some magic always did what the user wanted in terms of persisting or not persisting between messages, the "reset formatting" function would still have value.

To be fair I think "set as default" has value as well, just less value and less commonly needed.

comment:25 in reply to: ↑ 24 Changed 10 years ago by endolith

Replying to deryni:

Even if formatting never persisted longer than was desired (as in this bug), and by some magic always did what the user wanted in terms of persisting or not persisting between messages, the "reset formatting" function would still have value.

How would it have value if it was never used?

comment:26 Changed 10 years ago by deryni

You are assuming that the only time anyone ever uses it is when the formatting is incorrectly persisted. I've used it on more than one occasion when I've accidentally hit keys and turned formatting on, or when I've started formatting something and then decided I didn't want to format it, I've used it to remove the auto-linkification of urls I've pasted, I've used it to remove formatting from formatted text I've pasted (when I've forgotten to Paste as Plain Text), and I'm sure there are other cases where it may be of use to someone.

comment:27 Changed 10 years ago by deryni

From #5879:

The reason is simple : most often I don't do formatting as I type, but after I type the text I look it over and add some formatting, that is for messages that contain text with mixed formatting.

If I end the text with a different then default formatting, then is the only time I might expect to continue the next message with that formatting. Now I have to either type "End" for cursor to go to end of text, or use "Reset formatting" as a mandatory step almost every time I do some mixed formatting.

Also I must say, a paste operation is the most confusing regarding formatting.

It is unclear to me whether post-insertion formatting should be persisted or not, even with a policy of persist-from-last. The more consistent and obvious the policy is the less confusing it is going to be for people to understand. Unfortunately that makes persist-from-last the least suitable as both persist-from-cursor and persist-from-eol are likely more readily obviously consistent.

I will admit that for your usage (enter all text and then format bits) the current system is sub-optimal and that persist-from-last is likely better (unless of course you format the last word in which case you are in exactly the same boat), I'm just not sure that overall a persist-from-last policy is going to be better.

I fully agree that by far the largest time people get confused is when pasting persists formatting, and that shouldn't happen (and is in fact #1198).

comment:28 Changed 9 years ago by darkrain42

Ticket #10794 has been marked as a duplicate of this ticket.

comment:29 Changed 9 years ago by Oo.et.oO

this is not fixed for me in 2.6.5

  Arguments to ./configure:   '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--disable-consoleui' '--disable-nls' '--enable-gtkui' '--enable-sm' '--enable-startup-notification' '--enable-screensaver' '--enable-cap' '--disable-gevolution' '--enable-gtkspell' '--enable-perl' '--disable-tk' '--disable-tcl' '--disable-debug' '--enable-dbus' '--enable-meanwhile' '--enable-gstreamer' '--enable-farsight' '--enable-vv' '--disable-cyrus-sasl' '--disable-doxygen' '--disable-nm' '--without-krb4' '--disable-avahi' '--disable-idn' '--with-dynamic-prpls=irc,jabber,oscar,yahoo,simple,msn,myspace,sametime' '--disable-mono' '--x-includes=/usr/include/X11' '--enable-gnutls=no' '--enable-nss=yes' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=nocona -O2 -pipe' 'LDFLAGS=-Wl,-O1' 'CXXFLAGS=-march=nocona -O2 -pipe' 'FFLAGS='
  Print debugging messages: No
  Plugins: Enabled
  SSL: SSL support is present.

  Library Support
    Cyrus SASL: Disabled
    D-Bus: Enabled
    Evolution Addressbook: Disabled
    Gadu-Gadu library (libgadu): Internal
    GtkSpell: Enabled
    GnuTLS: Disabled
    GStreamer: Enabled
    Mono: Disabled
    NetworkManager: Disabled
    Network Security Services (NSS): Enabled
    Perl: Enabled
    Startup Notification: Enabled
    Tcl: Disabled
    Tk: Disabled
    UTF-8 DNS (IDN): Disabled
    Voice and Video: Enabled
    X Session Management: Enabled
    XScreenSaver: Enabled
    Zephyr library (libzephyr): Internal
    Zephyr uses Kerberos: No

comment:30 Changed 9 years ago by leeor_net

This continues to be an issue as of 2.7.3. Why? This was reported three years ago. It continues to be a serious usability issue and serves only to waste my time and annoy me to no end.

Are patches to this issue welcome because if so I'll go in and fix this myself? I'm tired of waiting.

comment:31 Changed 9 years ago by rageboy

Patches are always welcome for any ticket, but I don't see this anymore, at least...

comment:32 Changed 9 years ago by leeor_net

Definitely contuing to experience this problem. I'll see what I can do in the mean-time to figure out what's going on.

As a side note, I do have a default formatting set in the options so I don't understand why it would be constantly changing.

comment:33 follow-up: Changed 9 years ago by SineSwiper

This is still a problem on my side. The default behavior should be to reset the formatting after sending the message. Obviously, this is a problem that a majority of the people agree is a problem, giving the ticket history and repeat duplicate tickets. Giving out this "it's a feature, not a bug" BS is not helping matters.

So far, hitting Ctrl+R is a workaround, so it's not as annoying. But, the fact this has been going on for 3+ years for a fairly noticeable bug with a potentially easy fix is inexcusable.

Just create a patch to call the Ctrl+R sub after the message is sent. That's all. It's easy. Just do it and get it into production, and we can all be happy and close this bug.

comment:34 in reply to: ↑ 33 Changed 6 years ago by Ouizardus

#6881 may also be a duplicate.

As with the point I made in #6881, I agree with SineSwiper; several years is a ghastly long time for this kind of defect to persist. I'm also surprised there haven't been more people here encouraging its resolution.

comment:35 Changed 2 years ago by Daviot

I've noticed and grumbled over this issue for years and found that it still persists on 2.12.0, both on Windows and on Linux.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!