Where’s Gnus function cutting too-long subject lines

Where’s Gnus function cutting too-long subject lines

[Garreau, Alexandre]

Hi,

As I recently discovered that org-mode, when linking to a gnus article,
dumbly cutted it in the middle, I wanted to know if, when cutting is
needed, it couldn’t use the special gnus feature that does it.

That feature is the one that cuts the subject line when it grows too
long, for instance by (from what I noticed from now) removing
excedentary “Was: […]” parts in the end of it.

I searched in gnus-msg.el, in all gnus sources, with el-search, but was
unable to find a string with just "was:?" (maybe it is embeded in a
bigger regexp?), I found it used in a var in gnus-score.el, but nothing
related to subject lines (functions are rather long and difficult I’d
say):  do anyone know which function do that?

Re: Where’s Gnus function cutting too-long subject lines

[Adam Sjøgren]

Alexandre writes:

> do anyone know which function do that?

Perhaps message.el around L309 where the variable
message-subject-trailing-was-query is defined, and L2162 where the
function message-strip-subject-trailing-was is defined can lead you to
what you are looking for?

This, however, just strips "(was: blablabla)" from the subject - it
doesn't do any "intelligent" handling of words, as far as I can see.


  Best regards,

    Adam

-- 
 "Accept failure gracefully."                                 Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Where’s Gnus function cutting too-long subject lines

[Garreau, Alexandre]

Le 28/10/2018 à 18h48, Adam Sjøgren a écrit :
> Alexandre writes:
>
>> do anyone know which function do that?
>
> Perhaps message.el around L309 where the variable
> message-subject-trailing-was-query is defined, and L2162 where the
> function message-strip-subject-trailing-was is defined can lead you to
> what you are looking for?

Yes! Actually this one is pretty simple.  I just had no chance to find
it by grepping for string content.

Okay: so I didn’t find because `message-subject-trailing-was-ask-regexp'
("[ 	]*\\((*[Ww][Aa][Ss]:[ 	]*.*)\\)") looks a bit obfuscated: so
why not putting a “let ((case-fold-search t))” around the string-match
in `message-strip-subject-trailing-was'?

Also, I don’t understand why `message-subject-trailing-was-ask-regexp'
and `message-subject-trailing-was-regexp' are different, while their
name reflect their usage rather than their meaning: should they better
be named lax and strict (or the other way around, I’m not sure).

Btw I don’t understand very well why don’t they match parenthesis and
brackets (“foo was: bar)” has “was: bar)” removed): wouldn’t it be
acceptable behavior not to work correctly when the subject line is
mal-formed (shouldn’t it be configurable to do so)?

Why aren’t bracket matched by default?  parenthesis can be used in
normal phrasing content, while bracket are more common in mail subjects
to indicate special metadata, so they appears more useful to use with
“was:”, or is the true standard to use parenthesis?.

It would have seem more understandable to me to have something such as 
"[ 	]*\\([([]was\\(:\\|[ 	]\\)[ 	]*.*[])]\\)", imho.

Or better: wouldn’t there a non-regular extended regexp, or non-regexp
way, of removing this while matching parenthesis and brackets?  Would a
such thing be acceptable (after all this is to be used interactively, or
while composing an answer: nothing critical)?

> This, however, just strips "(was: blablabla)" from the subject - it
> doesn't do any "intelligent" handling of words, as far as I can see.

Not yet ;) and even if it doesn’t, I find interesting to reuse
functions: that way interfaces are consistent.  If org-mode used this
function, it would be consistent with, perhaps more semantical and
special-tailored, handling of mail convention by Gnus, without being
complexified by mail-specific stuff.

So if Gnus progress here, org-mode will too, and if org-mode need
something better, it will be encouraged to improve Gnus.