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

[Garreau\, Alexandre]

Le 27/10/2018 à 13h55, Nicolas Goaziou a écrit :
> "Garreau, Alexandre" <address@hidden> writes:
>
>> Without justification, that’d look like “argument from ignorance”,
>
> I'm not arguing for truncating subjects.
>
> However, I'm arguing against changing a 10 years old default value
> without a strong reason. Default value annoys some users. Point taken.
> But changing it might also annoy some users, possibly, at least, the
> person that chose it in the first place, or users that do not like
> arbitrary long links.

This is an argument in favor of immobility.  The reason could also be
ridden in old capabilities, bugs or slowyness not relevant nowadays.  If
anything, we should find back who introduced this default, and ask them.

Especially, this is a end-user thing.  Not a programming-language API.
This can be seen by the user.  So it’s not a problem.

What could be done, if you want, is to rely on external software: for
instance, sometimes, when answering, Gnus takes away the “Was: ...”
subject line ending, if too long: that might be used to shorten it, if
believed useful.  That would be acceptable, as it would stay semantic,
and wouldn’t break in the middle of a sentence.

>> so unless a real reason is found, I believe it would be better to
>> remove a truncation that will very certainly in fact bother at least
>> some users (while there’s still 0 data point on how non-truncation
>> might be bothering, and that’s what being asked).
>
> Truncation, an its related variable, are now documented in the manual.
> The bothering is somewhat very limited.

Yes, if only each user of each piece of software took the time to read
the integrality of documentation each time they used something: I don’t
and only did partially for org, yet… but for instance I did for Gnus, a
long time ago, and never did it again: as example, did you?.

Default are an important thing, they should fit what the most common,
unspecific, and ignorant about the software in question, person.
Documentation should be there only to adapt to more specific, and less
common, cases (and, when possible, software should be made so that to
conditionally do the right thing depending of the context so that
changing the default behavior is less and less needed).  Not the other
way around.