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 741609 - Adding the ability to not quote previous emails
Adding the ability to not quote previous emails
Status: RESOLVED FIXED
Product: geary
Classification: Other
Component: composer
master
Other Linux
: Normal minor
: ---
Assigned To: Geary Maintainers
Geary Maintainers
review
Depends on:
Blocks:
 
 
Reported: 2014-12-16 17:09 UTC by Pétur
Modified: 2015-01-27 02:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Allow full-message quote to be deleted with backspace (7.35 KB, patch)
2015-01-25 03:27 UTC, Robert Schroll
committed Details | Review

Description Pétur 2014-12-16 17:09:24 UTC
With the conversation view, it seems rather useless to quote whole messages after your answer (which is the default beahviour of Geary). If you want to consult a old email, it's easier to see the thread than to look at the bottom of your email.

For the sake of simplification, I recommend to add the ability (by an option in settings) to do quote message after emails. If someone who activate this option does want to quote one message, it could do it be selecting text (https://bugzilla.gnome.org/show_bug.cgi?id=712912)
Comment 1 Jim Nelson 2014-12-16 18:11:07 UTC
That's something worth considering.  The questions that pop into my head are:

* Are there any alternatives to adding a Preference?  I can think of a couple (a button on the composer to "remove quoting", using modifier keys when clicking on Reply/Reply All), but they all open up more questions.

* Does it make sense not to quote the email when forwarding?  Reply/Reply All I understand, but forwarding seems to demand including the email.

* If a Preference is used, is there any way in the UI to reverse the setting (without using text selection)?  Here a modifier key when pressing the button might make sense.

I'm adding Robert Schroll to the ticket, he might have some thoughts on this.
Comment 2 Robert Schroll 2014-12-17 06:01:46 UTC
When Geary takes over the world, this would be reasonable behavior.  Until then, quoting the previous message is something of a courtesy to your less enlightened correspondents who aren't using threading email clients.  Since threading email clients tend to hide quoted text, this shouldn't bother your more with-it friends.

I'm not really opposed to this behavior, but we'd have to find a way to put it in unobtrusively.  I don't see any obvious way to do this, but I guess we could set up another shortcut.

One option I had mentioned before was to have the composer open with the text selected.  This would make it easy to top post (press up), bottom post (press down), or reply without quote (press delete).  I think the new select-to-quote mechanism solves the bottom-posting conundrum, but this mechanism could be useful here.
Comment 3 Pétur 2014-12-17 13:39:19 UTC
@Jim Nelson: about 2, yes It makes no sense to forward emails without quoting them. So I don't recommend to apply my request when forwarding emails.

@Robert Schroll: I understand your point and your solution seems perfect for me. Indeed, the new select-to-quote feature solves a lot of issues here. But I still have no way to answer without quoting. Today we have two shortcuts for "answer" action and two for "answer to all" action. I suggest to use one for the "not quoting" choice.

That is to say:

R : (default behavior) answer with quote (if selecting text: quote only the selected text)
Ctrl+R : answer without quote

Shift+R : (default behavior) answer to all with quote (possibility to select text to narrow the quotation)
Ctrl+Shift+R : answer to all without quote.

What do you think about this solution?
Comment 4 Robert Schroll 2014-12-17 18:42:12 UTC
The R and Shift+R shortcuts will not be available when focus is in the composer.  Granted, you'll not often be wanting to add a quote in this case (generally, you'd just be switching from reply to reply all), but it'd hurt my little brain to remember R outside of the composer and Ctrl+R inside it.

Also, Ctrl+R is currently taken by the color chooser in the composer, but see bug #741628.

My vote would be for using a different key.  Near to R on a US keyboard, T, 4, and 5 all seem to be unused.  We could also use Alt to trigger this, although many of these chords may be grabbed by the window manager.
Comment 5 Jim Nelson 2014-12-18 22:13:08 UTC
I like the idea of selecting the quoted text, but I think that's going to be a major re-learning for users who like to just start typing when the composer pops up.  (I count myself in this group.)  If I see where you're going with this, Robert, if I just start typing the entire quoted text will be replaced by the first character, meaning if I do want to quote some or all of the text, I have to Ctrl+Z (or close and re-reply).  I really, really like how our composer lets us just start typing.

Alt could trigger this, I'd even consider the under-used Super key, although that might be playing with fire too.

Or Ctrl+K (Klean Reply), Shift+Ctrl+K (Klean Reply All).  I guess I'm saying that since there's a variety of intl keyboard layouts, just bite the bullet and treat this as a full-blooded shortcut with a mnemonic name.

Could we add a button with a composer shortcut that removes all quoting?  In other words, Reply All -> Removing quoting -> Start typing.  If the button is "stupid" and simply removes all quoted text, that could be a bit dangerous if the user is doing a point-by-point reply.  Maybe it's "Remove original quoting" and is unavailable if any quoted material is edited / split up ... but now it's starting to sound complicated.
Comment 6 Robert Schroll 2014-12-18 23:03:16 UTC
Yes, the selected text method would break the reply-and-start-typing behavior.  Before we had solved the bottom-posting problem, I thought that it'd be worth it.  Now, I don't think so.

I think Super is very dangerous.  Gnome Shell, by default, tends to want to control that.

One other way would be to allow the user to hit Delete or Backspace when the composer first opens to delete the quoted text.  That is, it would behave as if the text had been selected, but only if the user's first move is to delete it.  It'd be one more step than a dedicated shortcut, but you'd get to avoid strange chords.  It wouldn't be particularly discoverable, though.
Comment 7 Jim Nelson 2014-12-19 01:12:12 UTC
(In reply to comment #6)
> One other way would be to allow the user to hit Delete or Backspace when the
> composer first opens to delete the quoted text.  That is, it would behave as if
> the text had been selected, but only if the user's first move is to delete it. 

That's kind of in line with what I was suggesting, but better in the sense it doesn't add a button that goes insensitive once you start typing (and is useless thereafter).

What if we placed a bit of help text on the composer toolbar between the Remove Formatting button and the drop-down menu, something like

Press Delete or Backspace to remove quoted text

It could be the same shade as the Saving/Saved text, and perhaps italicized to emphasize that it's a helpful hint from Heloise.  The text is hidden as soon as the user starts typing.  (In fact, we could use the Saving/Saved GtkLabel for this purpose, since it is by definition hidden until the user types something.)

This would make it discoverable and we don't need a new shortcut key.
Comment 8 Robert Schroll 2014-12-19 05:33:40 UTC
Yeah, the existing label would be a good place for a hint.

Pétur, would this work for you?
Comment 9 Pétur 2014-12-19 12:56:58 UTC
(In reply to comment #8)
> Yeah, the existing label would be a good place for a hint.
> 
> Pétur, would this work for you?

Yes! I think this solution is very efficient (I can reply without quote by pressing R (or Ctrl+R) and <delete> (or Backspace). It even easier than to learn a complicated and new shortcut).

And it is easy to discover indeed.

Between <backspace> or <delete> keys, I don't know what key is the best one.
Comment 10 Jim Nelson 2014-12-19 21:00:50 UTC
I'd be fine with both performing the action -- their purpose is very similar.
Comment 11 Robert Schroll 2014-12-19 22:38:34 UTC
My original idea was to do this both for backspace and delete.  However delete does have a legitimate use on open.  If you decided after opening the composer that you want to bottom-post, you might hit delete twice to remove the extra lines before the quote.  Having everything disappear when you did this would be surprising.  In contrast, the backspace key does nothing in this situation, so it's fine to use.  Right now, I'm leaning towards only enabling this for backspace.

A few other implementation notes:

- We should leave the signature in place, shouldn't we?  It may be easier to wipe everything and reconstruct it again.

- In addition to keystrokes, this should be disabled by any mouse action that moves the cursor.  If the user highlights some text and hits backspace, they expect only that text to disappear.

- Should this be active for forwards?  I don't see the point in allowing that, but it wouldn't take any more work to support.
Comment 12 Jim Nelson 2014-12-19 22:57:56 UTC
(In reply to comment #11)
> However delete does have a legitimate use on open.

Good point.  Backspace 'tis.

The nice thing about this approach is we can easily change the key(s) later without much work.  In fact, it occurs to me that with the combination of the help text and the first-keystroke-on-edit approach, we're kind of free to pick any unreserved key we want.  But I like the intuitiveness Backspace approach, so let's stick with that.

> - We should leave the signature in place, shouldn't we?  It may be easier to
> wipe everything and reconstruct it again.

Yeah, the signature should remain.  How that happens is up to the implementation, but that's how it should look to the user.

> - In addition to keystrokes, this should be disabled by any mouse action that
> moves the cursor.  If the user highlights some text and hits backspace, they
> expect only that text to disappear.

Good point.  Yes, the user gets one shot to make this happen.

> 
> - Should this be active for forwards?  I don't see the point in allowing that,
> but it wouldn't take any more work to support.

Let's hold off on implementing this for forwarding.  If we want to change this later, we can do that.
Comment 13 Robert Schroll 2015-01-25 03:27:49 UTC
Created attachment 295351 [details] [review]
Allow full-message quote to be deleted with backspace

This should implement what was discussed.  Quite a lot of it is 
rearranging how we set the text in the toolbar, so we can use it for 
multiple purposes.

The bind_property calls originally had anonymous closures, but I 
realized they were the same.  I've moved it into a single named closure 
used twice.  I don't know how you feel about this; I could change this 
to a private method easily if that seems better.

Right now, I set can_delete_quote = false each time the selection 
changes and each time there is a keypress.  I don't know if this 
triggers that whole chain of linked properties, or if the fact that the 
property isn't actually changed stops this from happening.  If it's the 
former, we may want to check before setting it to save some cycles.  I 
don't notice any performance issues, though.
Comment 14 Jim Nelson 2015-01-26 23:43:20 UTC
Review of attachment 295351 [details] [review]:

Creating the transformation function (vs. using an instance method) is unusual, but I think we've reached the stage in Vala where such things are acceptable.

GObject (and Vala-generated code) will fire a "notify" signal with each set, regardless if the value changed; something to be aware of, as it's bitten me many times.  I don't see any real performance problems, but it's real easy to check if the value is true before setting it false, so please do that Just In Case.  You should only need to do this in the keypress code.

Do that and commit!
Comment 15 Robert Schroll 2015-01-27 02:56:25 UTC
Attachment 295351 [details] pushed as aafc7ae - Allow full-message quote to be deleted with backspace