On 2018-10-28 at 10:05, Amin Bandali wrote: > That said, I still find the default a bit obtuse and frankly > unexpected. I don’t know, maybe a nice middle ground between the > current behaviour and completely removing the limit would be to > increase the limit from 30 to 78 characters, the recommended > maximum number of characters in a line according to RFC 2822 [0]. > That somehow feels less arbitrary, and would cover a larger > portion of subjects. > > [0]: https://tools.ietf.org/html/rfc2822#section-2.1.1
Okay, so I did not read carefully enough: this is a per line limit, however Gnus already include this limitation in fill-column so that to fold subject line in several lines that will be no more than 78 characters, there’s no need to limit to 78 characters, and indeed I sometimes end with subject lines of more than one line, and wouldn’t like to see my normal subject line truncated. The same way, org-mode will naturally see its paragraphs filled if wanted by the user (otherise there are no problems in long lines, except, afaik, by default, it disable truncating lines). On 2018-10-28 at 18:01, Garreau, Alexandre wrote: > Rather cutting it, I’d rather try to find the gnus function that cut > subject lines so it does more semantically (like, removing the entire > Was: part if it doesn’t fit, rather than cutting it in the middle), but > 78 seems totally more reasonable, at worse, indeed: but maybe that > aforementioned gnus function does something related to it (maybe it does > cut when it exceed 78 chars?)? > > However I was unable to find it by el-searching for "was:?", so I’ll ask > them directly, hoping they know and answer. So the function I was searching is `message-strip-subject-trailing-was', and only strip the was part, it doesn’t conditionally strip “Was” if there were several, or if the subject line was too long. Yet it can be used for org-mode as the “Was:” trailing part is likely not to be interesting at all for refering to a particular message, as anyway it will be found again when visiting the said article. What’s more interesting is it’s used in a function `message-simplify-subject', calling a customizable list of functions (`message-simplify-subject-functions'), that will simplify deeply the subject, removing also the “Re:”, the mailing-list part, encoded parts, etc. Yet, as it currently only used for replying, it seems to, wrongly imo, add a “Re:” to the subject line (while this should be its scope, imo). So this one is not usable as is. But `message-strip-subject-re' might be used per se itself, otherwise, as it seems to me the “Re:” might not be interesting as well, though mailing-list part may be useful, as in `org-email-link-description-format' there is nothing to refer to the group (either the group name in gnus, or either content of “Newsgroups” header or mailing-list (content of “List-id” or “List-post”, either address or human-readable part)), but not all mailing-list embed one, so it might bring inconsistency, and adding a said new format-specifier to `org-email-link-description-format' seems to me preferable (why not “%g” for “group”?). So may I suggest to change `org-email-link-description' and update `org-email-link-description-format', so that to support a "%g" specifier, to refer to the content of :group (or should we add something to refer List-ID/List-Post?), and a %S that’d return the subject, simplified by `message-strip-subject-trailing-was', `message-strip-subject-trailing-re', or, maybe rather, by all the functions inside `message-simplify-subject-functions' (waiting for `message-simplify-subject' to be corrected).
