Le 28/10/2018 à 10h05, Amin Bandali a écrit : > Hi, > > Nicolas Goaziou <m...@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.
