Re: Changing line widths in the Emacs source code

[T.V Raman]

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