Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #82094 > unrolled thread

Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces? jtan <admin@grails.asia> - 2014-12-08 10:25 +0800
    Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces? sohcahtoa82@gmail.com - 2014-12-08 12:20 -0800
      Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces? Ben Finney <ben+python@benfinney.id.au> - 2014-12-09 08:41 +1100
      Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces? Dave Angel <davea@davea.name> - 2014-12-08 17:57 -0500
      Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-12-08 20:17 -0500

#82094 — Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?

[Multipart message — attachments visible in raw view] — view raw

One reason why you would want max length 79 is because of working with
terminals.  Maybe ssh to you server and check how many spaces are consumed
by a tab?  In my boxes, it is usually 1 tab = 8 spaces.  So perhaps just
use that setting in your editor?

On Mon, Dec 8, 2014 at 10:15 AM, Aahan Krish <krish@aahan.me> wrote:

> My understanding from talking to different people is that many do use
> tabs (instead of spaces) for indentation in their code.
>
> My question is to them (because I want to use tabs too) is: how do you
> maintain a line-length of 79 characters?
>
> E.g. scenario: The tab setting in your editor could be 2 or 4, and in
> other developer's browser it could be 8. The code will be longer than
> 79 chars in the latter's editor.
>
> I want to know if it's at all possible or if you use some simple and
> realistic (practical) hacks.
>
> *PS: Please avoid, "That's why you should use spaces," type of
> comments. I would like to avoid flame wars.*
>
> TY,
> Aahan
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Freelance Grails <http://grails.asia/> and Java <http://javadevnotes.com/>
 developer

[toc] | [next] | [standalone]

#82145

> On Mon, Dec 8, 2014 at 10:15 AM, Aahan Krish <kr...@aahan.me> wrote:
> My understanding from talking to different people is that many do use
> 
> tabs (instead of spaces) for indentation in their code.
> 
> 
> 
> My question is to them (because I want to use tabs too) is: how do you
> 
> maintain a line-length of 79 characters?
> 
> 
> 
> E.g. scenario: The tab setting in your editor could be 2 or 4, and in
> 
> other developer's browser it could be 8. The code will be longer than
> 
> 79 chars in the latter's editor.
> 
> 
> 
> I want to know if it's at all possible or if you use some simple and
> 
> realistic (practical) hacks.
> 
> 
> 
> *PS: Please avoid, "That's why you should use spaces," type of
> 
> comments. I would like to avoid flame wars.*
> 
> 
> 
> TY,
> 
> Aahan

On Sunday, December 7, 2014 6:26:01 PM UTC-8, jtan wrote:
> One reason why you would want max length 79 is because of working with terminals.  Maybe ssh to you server and check how many spaces are consumed by a tab?  In my boxes, it is usually 1 tab = 8 spaces.  So perhaps just use that setting in your editor?


My terminals are 120 columns wide.

Are there still people that are limiting their terminals to 80 columns?  If so, why?  I mean, I can understand if you're running on an ancient square monitor, but I see no reason to limit your terminal to 80 columns if you're running any sort of window environment on monitor with a horizontal resolution greater than 1280.

"Because that's how we've always done it!" is a pretty shitty reason to continue doing something.

[toc] | [prev] | [next] | [standalone]

#82148

sohcahtoa82@gmail.com writes:

> My terminals are 120 columns wide.

Mine are wider. So what?

> Are there still people that are limiting their terminals to 80
> columns?

I don't know. Terminal width is not the sole reason to keep code lines
within 80 columns.

-- 
 \       “The fundamental principle of science, the definition almost, |
  `\             is this: the sole test of the validity of any idea is |
_o__)                                 experiment.” —Richard P. Feynman |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#82155

On 12/08/2014 03:20 PM, sohcahtoa82@gmail.com wrote:
>>
>
> On Sunday, December 7, 2014 6:26:01 PM UTC-8, jtan wrote:
>> One reason why you would want max length 79 is because of working with terminals.  Maybe ssh to you server and check how many spaces are consumed by a tab?  In my boxes, it is usually 1 tab = 8 spaces.  So perhaps just use that setting in your editor?
>
>
> My terminals are 120 columns wide.
>
> Are there still people that are limiting their terminals to 80 columns?  If so, why?

I frequently have more than just one terminal open on my xserver.  I 
might have several terminals, or I might also have a browser or another 
application.  And I rearrange the windows so the parts I'm interested in 
are showing whatever I'd like to simultaneously see.

>  I mean, I can understand if you're running on an ancient square monitor,
>  but I see no reason to limit your terminal to 80 columns if you're running any sort of window environment on monitor with a horizontal resolution greater than 1280.

What's square got to do with anything?  I have displays ranging from 
about 3 inches across to about 29.  The size matters, not usually the 
pixel count (my cell phone has 1920 pixels across).

>
> "Because that's how we've always done it!" is a pretty **** reason to continue doing something.
>
No need to throw feces around.  There are several reasons besides history.

1) physical screen size, divided by the number of simultaneous windows 
one wants horizontally visible.

2) vision acuity.  When the print gets small enough, my elderly eyes 
can't read it reliably.

3) Human preference and ability.  Notice that large books and newspapers 
use multiple columns, or pictures & ads to break up the page.  A line 
beyond some length makes it hard to take it all in at once.

4) Other media.  Sometimes we actually make listings on paper.

If code is only going to be used by one person, then it may make sense 
for that person to make it as wide as the size he personally can handle, 
with his abilities and equipment and usage habits.

But when there are multiple people, it sometimes makes sense to 
constrain code to the most stringent of their abilities.

And one's abilities change over time, just as his equipment does.

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#82165

On Mon, 8 Dec 2014 12:20:50 -0800 (PST), sohcahtoa82@gmail.com declaimed
the following:


>
>Are there still people that are limiting their terminals to 80 columns?  If so, why?  I mean, I can understand if you're running on an ancient square monitor, but I see no reason to limit your terminal to 80 columns if you're running any sort of window environment on monitor with a horizontal resolution greater than 1280.
>
	Maybe because I don't run windows full screen -- preferring to be able
to see activity in other windows without having to resort the layers
constantly...

	I also prefer to view more vertical matter than horizontal. Two
alphabets is a common printing convention because it is just narrow enough
for the lines to be taken in as a whole visually, without excessive head or
eye rolling.

	Besides -- in most code, the crucial stuff is the leading edge of the
line <G> (keywords for structures: if/else/end if, for|while|loop/end
loop... the fine print of what is in those clauses may not be needed to get
the gist of the code)

	That said, I do tend to run 96 column (and 42 rows) {a 20% increase in
width, but 75% increase in height}
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web