aboutsummaryrefslogtreecommitdiffstats
path: root/java/res
diff options
context:
space:
mode:
authorStefan Kangas2024-02-02 12:28:54 +0100
committerStefan Kangas2024-02-02 13:33:35 +0100
commit72b1379f0795a5e2e9c57615c0b1d78c0b97cd1f (patch)
treec6554da237c86b8044bd2ead6a6a97f049dc1791 /java/res
parentd89e427852a63dbeed3d5e03d9deb2ae9a8e3e1b (diff)
downloademacs-72b1379f0795a5e2e9c57615c0b1d78c0b97cd1f.tar.gz
emacs-72b1379f0795a5e2e9c57615c0b1d78c0b97cd1f.zip
Increase `emacs-lisp-docstring-fill-column` to 72
Monitors are wider now than when these defaults were first set, and it is useful to take better advantage of that, to fit text on fewer lines. Yet, it has repeatedly been shown that overly long lines reduce readability: "A reasonable guideline would be 55 to 75 characters per line."[1] We also don't want to disfavor narrow displays, like mobile phones; a more promising direction here might be to automatically word wrap docstrings and make their maximum width customizable. That might require a new docstring format, however. Bumping it by 7 characters, from 65 to 72, seems a reasonable compromise for now. Consideration was given to increasing it to 70 or 75, but 72 happens to be a commonly recommended maximum line width elsewhere (see Fortran 66, Python docstrings, commit message recommendations, etc.), and we might as well do the same. This change was discussed in: https://lists.gnu.org/r/emacs-devel/2022-07/msg00217.html [1] "Optimal Line Length in Reading — A Literature Review", Nanavati and Bias, Visible Language, Vol. 39 No. 2 (2005). https://journals.uc.edu/index.php/vl/article/view/5765 * lisp/emacs-lisp/lisp-mode.el (emacs-lisp-docstring-fill-column): * .dir-locals.el (fill-column, emacs-lisp-docstring-fill-column): Bump default to 72.
Diffstat (limited to 'java/res')
0 files changed, 0 insertions, 0 deletions