Re: org-store/insert-link truncating the full subject of mails

["Garreau\, Alexandre" <galex-713@galex-713.eu>]

Le 28/10/2018 à 10h05, Amin Bandali a écrit :
> Hi,
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> I don't know. This is why I agree it is safer to limit length to an
>> arbitrary number instead of allowing any size.
>
> Hoping to find an actual answer, I did a =git blame lisp/org.el=
> and found the commit that introduced it,
> 2c16f092e64915a7e3d0b2dda82f3978a0f42dea, by Carsten Dominik,
> the creator of Org mode himself.
>
> I emailed Carsten yesterday and asked if he recalls why he
> introduced that variable and that behvaiour.  He said that he
> doesn’t recall exactly, but that either it was aesthetic (he
> didn’t find extremely long link descriptions pretty), or that
> long lines slowed down some regular expressions that ran in the
> buffer.  He said it was most likely the first one (aesthetic),
> and that he wouldn’t object to lifting the restriction.

Thank you so much!  That was the Right Thing to do imho.  I really have
to learn git.  I wish a knew it here.

> On a side note, I’d like to point out that I use C-h k, C-h f,
> and C-h v many times a day, especially when encountering new
> functions or variables.  But I don’t know if I’m the minority, or
> if most other Emacs users check the docs frequently as well.

I’m an heavy user of them as well, and find them way easier and more
friendly than the manual, as they usually, don’t require me to read more
than a paragraph of a few lines (or it’s me doing it repetedly then),
while a manual requires to prepare to read a text of an indefinite
length (before to have found) which is way less predictable and hence
more tiring.

The problem is, ideally identifiers should be easily named so that you
easily find them with correct prefixes and autocompletion, but you don’t
always know/think to the right keywords, and the words are not always in
the most practical order.  Most of time it works, so it stays awesome
and extremely useful, but it stays imperfect, and henc is not a
substitute for better defaults.

> 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.

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.