Bug 2341 - Reply Quotation must have a character, space or otherwise.
Summary: Reply Quotation must have a character, space or otherwise.
Status: NEW
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI/Compose Window (show other bugs)
Version: 3.7.8
Hardware: PC Windows XP
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2011-01-06 16:09 CET by Anson Maddock
Modified: 2016-03-17 19:51 CET (History)
1 user (show)

See Also:


Attachments
reply quote patch (1.28 KB, patch)
2016-03-17 17:48 CET, Rene Maurer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anson Maddock 2011-01-06 16:09:34 CET
I recently tried to set claws mail to have a non-character reply quotation however it will always default to "> " without a character in the quotation mark field. I am able to set it to many other characters just not a blank option.
Comment 1 Charles A Edwards 2011-01-09 01:56:43 CET
All you need to if you wish to use this " " rather than this ">" is to use to
the space key as a character and then apply the change when setting the reply template.

I know this works in linux and it should do the same in Windows

Charles
Comment 2 Anson Maddock 2011-01-09 21:54:48 CET
Thanks but it doesn't quite do what I'm looking for as when replying in the windows build it inserts a space before the whole quotation so after four or five back and forth emails it builds up. I've been using forward as a replacement to reply temporarily.

Anson
Comment 3 ml 2013-10-01 10:29:15 CEST
When quote character is set to '> ' resulting second-level quotation looks like this:

 '> > quoted text'

While I'd like it look like that:

 '>> quoted text'

As I was advised on IRC, there's no easy way to achieve what I want. I belive it's pretty natural way of quoting. At list it is the default way in many other mail agents.
Comment 4 Marcel van der Boom 2013-10-01 11:24:42 CEST
I have resolved this issue (at least the one mentioned in the last comments, not sure what the first comments are about) by applying this patch:

https://gist.github.com/6775872

and setting my quote character to '>' 

I have suggested this patch in the past and put up a message to the dev list if I recall correctly for merging this in, but there was no interest in it apparently.
Comment 5 Paul 2013-10-02 10:06:50 CEST
(In reply to comment #4)
> I have resolved this issue (at least the one mentioned in the last comments,
> not sure what the first comments are about) by applying this patch:
> 
> https://gist.github.com/6775872
> 
> and setting my quote character to '>' 
> 
> I have suggested this patch in the past and put up a message to the dev list
> if I recall correctly for merging this in, but there was no interest in it
> apparently.

Hi Marcel,

Your patch works well if we start and stick with '>', but it doesn't work quite so well for all those users who are using with '> '. In the case of '> ', which will be almost everyone, it adds an extra space to each quoted line, '>  ', unless the quoted line is wrapped, and then the wrapped part gets just one space, '> '. So, in my opinion, it needs a little more work on dealing better with the space(s) between quote marker and quoted text.
Comment 6 Marcel van der Boom 2013-10-02 10:40:13 CEST
Agreed, it can be a lot smarter.
Comment 7 Rene Maurer 2016-03-17 17:48:05 CET
Created attachment 1634 [details]
reply quote patch

Apply minimal magic to the reply quote handling for the case the quote mark is longer than one character and the quote mark ends with a space.

The last space of the quote mark is stripped and the result used as quote mark.

Special case: the quote mark has only one space at the end and the text to be quoted doesn't start with ">" and the quote mark. For this case a space is inserted to separate the quote marks from the text.

Doing like this, the desired behavior (separate quote marks from text, but don't separate quote mark from existing quote marks) can be reached with a quote string like "> ", "@ ", ": ", ...

A behavior similar to the old behavior can be reached with a quote string containing two spaces ">  ", "@  ", ":  ", ...

As said, the patch doesn't change the behavior for quote strings not ending with a space or not longer than one character.