unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "T.V Raman" <raman@google.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Óscar Fuentes" <ofv@wanadoo.es>, emacs-devel@gnu.org
Subject: Re: Changing line widths in the Emacs source code
Date: Sun, 13 Sep 2020 19:28:04 -0700	[thread overview]
Message-ID: <p915z8hdrd7.fsf@google.com> (raw)
In-Reply-To: <jwvk0wx3y2w.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Sun, 13 Sep 2020 22:23:32 -0400")

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1966 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

This could also be language specific. Languages like Java and perhaps
also C++ end up with unduely long identifiers when you have a complex
package/module  system in use --- that then makes 80 columns hard.

Emacs C codebase doesn't suffer this, though elisp does to an extent
given that identifier names can get long if one isn't careful to choose
a succint package prefix in lieu of a namespace 

>> Keeping track of indentation level adds to cognitive load, so we can't
>> dismiss leading unused columns as irrelevant.
>
> I don't think we was saying they're irrelevant.  But just that the 55-60
> "optimum" has to do with the difficulty for your visual system to jump
> from the end of one line to the beginning of the next and that it was in
> a context of "plain text", so it doesn't necessarily carry over to code
> because of the indentation.
>
> The indentation could both help (in the sense that a text indented by 40
> columns should be able to use a fill-column of about 95-100 and result
> in an "optimal" legibility) and hinder (in the sense that it might be
> harder for the visual system to find the beginning of the line when
> every line starts at a different indentation level, tho I don't know if
> that's the case, nor even if it has been studied).
>
> In any case, my experience is that regardless of issues of legibility it
> is usually easy to make code fit within 80 columns so I don't see
> a strong reason to increase that number (given that such an increase
> would likely result in a decrease of visual code density, i.e. less
> efficient use of screen real estate, and may encourage nesting code more
> deeply which would be detrimental to the readability of the code).
>
> I don't think there's anything magical about 80, but experience just
> seems to show that it works well.
>
>
>         Stefan
>
>

-- 
7©4 Id: kg:/m/0285kf1  •0Ü8



  reply	other threads:[~2020-09-14  2:28 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-13 13:45 Changing line widths in the Emacs source code Lars Ingebrigtsen
2020-09-13 13:58 ` Stefan Kangas
2020-09-13 14:09   ` Lars Ingebrigtsen
2020-09-13 15:53     ` Stefan Kangas
2020-09-13 16:21       ` Lars Ingebrigtsen
2020-09-13 16:51         ` Yuan Fu
2020-09-13 16:58           ` Lars Ingebrigtsen
2020-09-13 17:55             ` Stephen Leake
2020-09-13 18:04             ` arthur miller
2020-09-13 17:34           ` Eric Abrahamsen
2020-09-13 17:54         ` Stephen Leake
2020-09-13 14:22 ` Alan Mackenzie
2020-09-13 18:38   ` Vladimir Sedach
2020-09-13 20:13     ` Göktuğ Kayaalp
2020-09-13 20:52       ` Stefan Monnier
2020-09-13 21:23         ` Göktuğ Kayaalp
2020-09-14  0:08           ` Tim Cross
2020-09-13 23:45       ` Óscar Fuentes
2020-09-14  2:23         ` Stefan Monnier
2020-09-14  2:28           ` T.V Raman [this message]
2020-09-14  7:42             ` tomas
2020-09-14  9:59             ` Alan Third
2020-09-15  7:25     ` Stefan Kangas
2020-09-13 14:53 ` Daniel Martín
2020-09-13 15:01   ` Lars Ingebrigtsen
2020-09-13 17:23     ` Andy Moreton
2020-09-13 17:29       ` Lars Ingebrigtsen
2020-09-13 18:07         ` Göktuğ Kayaalp
2020-09-13 15:09   ` Stefan Kangas
2020-09-13 14:54 ` Eli Zaretskii
2020-09-13 14:57   ` Lars Ingebrigtsen
2020-09-13 15:13     ` Eli Zaretskii
2020-09-13 17:15       ` Lars Ingebrigtsen
2020-09-13 15:27 ` Stefan Monnier
2020-09-13 17:31   ` Dmitry Gutov
2020-09-13 17:34   ` Andrea Corallo via Emacs development discussions.
2020-09-16  6:42   ` jeremyb
2020-09-13 15:28 ` Göktuğ Kayaalp
2020-09-13 15:43 ` Óscar Fuentes
2020-09-13 17:07   ` Amin Bandali
2020-09-13 18:01   ` Stephen Leake
2020-09-13 18:17     ` Göktuğ Kayaalp
2020-09-14  3:50 ` Richard Stallman
2020-09-14 19:25 ` David Koppelman
2020-09-15  8:53 ` Lars Brinkhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=p915z8hdrd7.fsf@google.com \
    --to=raman@google.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=ofv@wanadoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).