[TUHS] tabs vs spaces - entab, detab

[TUHS] tabs vs spaces - entab, detab

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

OK. So, I've been trying to decide (for the last time, I swear) whether 
to use tabs or spaces in my code... I did a quick pulse-check on the 
state of argument and it appears to be alive and well in 2021. My 
question for y'all is, was there a preference in the very early days or 
not? I saw an article talking about the 20 year feud, but that's not my 
recollection. In 1994, nobody agreed on this, but I'm sure it predates 
my entree into the field. I'm thinking the history of entab and detab 
are somehow related, but I've been wrong on these sorts of thoughts 
before. What say you?

Will

[-- Attachment #2: Type: text/html, Size: 850 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

Oh boy, you do want to pour muddy water on the table.   I generally
believed in tabs set every 4 spaces.  That's Steven's used in all his UNIX
books.  Have to ask Rob what and bwk used but I sort of think it was pretty
similar.  A problem is a lot of people had tabs set at 8 spaces.

Clem
ᐧ

On Thu, Mar 4, 2021 at 11:53 AM Will Senn <will.senn@gmail.com> wrote:

> OK. So, I've been trying to decide (for the last time, I swear) whether to
> use tabs or spaces in my code... I did a quick pulse-check on the state of
> argument and it appears to be alive and well in 2021. My question for y'all
> is, was there a preference in the very early days or not? I saw an article
> talking about the 20 year feud, but that's not my recollection. In 1994,
> nobody agreed on this, but I'm sure it predates my entree into the field.
> I'm thinking the history of entab and detab are somehow related, but I've
> been wrong on these sorts of thoughts before. What say you?
>
> Will
>

[-- Attachment #2: Type: text/html, Size: 2002 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[arnold]

First, no discussion of this issue would be complete without
this video: https://www.youtube.com/watch?v=SsoOG6ZeyUI

Secondly, there are two issues, only partially related.

1. Do I use real tab characters in my code, or just spaces?

2. How many spaces do I want my editor/IDE to use to (a) display tab
characters or (b) expand tabs into, depending upon my answer to (1)
above?

All *nix systems use a "tab stop" of eight characters when printing
tab characters on a terminal or a line printer.  That is pretty hard
to change.

Traditionalists (or at least, I, speaking for myself) use tabs in
their C, C++, and shell code and *must* use tabs in their Makefiles.

Doing so "saved bytes" on the small machines of yesteryear; that
argument is irrelevant today.

I got used to a tab stop of 8 characters for most code and that's
still my personal preference for the C, C++, awk and shell that I write.

The Python world is different; there the use of spaces and a tab stop
of 4 characters is common.  Fortunately, modern editors / IDEs let
you choose the settings to use based on the language you're editing.

I've used a tab stop of 4 spaces for C++ as well and I find that readable
and pleasant. I find anything less than that to be cramped and unpleasant.

I don't remember the details of entab and detab programs on Unix
(other than the expand command) but "Software Tools" from 1976 had
programs to do those exact two jobs, so the issue of going back and
forth between spaces and tabs has been around for a long time.

The short answer is that what you should do boils down to your
preference(s) and the tools you use to edit code.

HTH,

Arnold


Clem Cole <clemc@ccc.com> wrote:

> Oh boy, you do want to pour muddy water on the table.   I generally
> believed in tabs set every 4 spaces.  That's Steven's used in all his UNIX
> books.  Have to ask Rob what and bwk used but I sort of think it was pretty
> similar.  A problem is a lot of people had tabs set at 8 spaces.
>
> Clem
> ᐧ
>
> On Thu, Mar 4, 2021 at 11:53 AM Will Senn <will.senn@gmail.com> wrote:
>
> > OK. So, I've been trying to decide (for the last time, I swear) whether to
> > use tabs or spaces in my code... I did a quick pulse-check on the state of
> > argument and it appears to be alive and well in 2021. My question for y'all
> > is, was there a preference in the very early days or not? I saw an article
> > talking about the 20 year feud, but that's not my recollection. In 1994,
> > nobody agreed on this, but I'm sure it predates my entree into the field.
> > I'm thinking the history of entab and detab are somehow related, but I've
> > been wrong on these sorts of thoughts before. What say you?
> >
> > Will
> >

Re: [TUHS] tabs vs spaces - entab, detab

[Nemo Nusquam]

On 04/03/2021 13:31, arnold@skeeve.com wrote (in part):
> Traditionalists (or at least, I, speaking for myself) use tabs in
> their C, C++, and shell code and *must* use tabs in their Makefiles.
Yes in Makefiles, otherwise I prefer 4 spaces per stop.

> The Python world is different; there the use of spaces and a tab stop
> of 4 characters is common.
I recall two colleagues working on the same Python-based project.  One 
used a 3-column tab; the other used 8-column spaces.  Few fireworks as 
the other simply filtered.

> I don't remember the details of entab and detab programs on Unix
> (other than the expand command)
This begs a question from me.  My Solaris boxes have expand/unexpand but 
no entab/detab.  What is the history there?

N.

Re: [TUHS] tabs vs spaces - entab, detab

[Steve Nickolas]

On Thu, 4 Mar 2021, Nemo Nusquam wrote:

> On 04/03/2021 13:31, arnold@skeeve.com wrote (in part):
>> Traditionalists (or at least, I, speaking for myself) use tabs in
>> their C, C++, and shell code and *must* use tabs in their Makefiles.
> Yes in Makefiles, otherwise I prefer 4 spaces per stop.
>
>> The Python world is different; there the use of spaces and a tab stop
>> of 4 characters is common.
> I recall two colleagues working on the same Python-based project.  One used a 
> 3-column tab; the other used 8-column spaces.  Few fireworks as the other 
> simply filtered.

<snip>

For what it's worth, I tend to use space-tabbing, indent of 1 for C, 
indent of 10 for assembler (I do some stuff in 65C02 assembler).

-uso.

Re: [TUHS] tabs vs spaces - entab, detab

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 115 bytes --]

https://www.youtube.com/watch?v=sln-gJaURzk&feature=player_detailpage#t=1734s&utm_source=buffer&buffer_share=c7676

[-- Attachment #2: Type: text/html, Size: 320 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Robert Clausecker]

Am Fri, Mar 05, 2021 at 06:50:08AM +1100 schrieb Rob Pike:
> https://www.youtube.com/watch?v=sln-gJaURzk&feature=player_detailpage#t=1734s&utm_source=buffer&buffer_share=c7676

Is it true that you started the Go project so you would be allowed
to indent your code with tabs at Google?

Yours,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

Re: [TUHS] tabs vs spaces - entab, detab

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

On 3/4/21 1:50 PM, Rob Pike wrote:
> https://www.youtube.com/watch?v=sln-gJaURzk&feature=player_detailpage#t=1734s&utm_source=buffer&buffer_share=c7676 
> <https://www.youtube.com/watch?v=sln-gJaURzk&feature=player_detailpage#t=1734s&utm_source=buffer&buffer_share=c7676> 
>
>
>
Thanks for the link into the video. If only every language were as 
helpful on the formatting code front :). I work with random folks who 
have differing opinions on the subject - this becomes apparent as soon 
as we try to integrate, with the notorious "inconsistent use of tabs and 
spaces in indentation" error. Python drives me nuts with it's 
finickiness on this, all without providing a helpful way to resolve the 
issue. It's left up to the developer to fix. Go addresses this by 
normalizing the format. It's not just Python, I'm currently reading a 
C17 C++ book, at the moment, and the authors spend several pages on 
coding style. They eventually boil it down to "whatever you do, be 
consistent" - but the amount of time spent on this shows us why go's 
approach is vastly superior. No raging debate about braces on the same 
line or even tabs and spaces - just code it, let go sort out the style 
issues.

Will



[-- Attachment #2: Type: text/html, Size: 2023 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[John Gilmore]

Will Senn <will.senn@gmail.com> wrote:
>                         the notorious "inconsistent use of tabs and 
> spaces in indentation" error. Python drives me nuts with it's 
> finickiness on this...

The one that got me was make(1).  Being used to text editors that used
"tab" as a command rather than a literal character, I proposed a fix
early on at Sun that would allow leading spaces as well as tabs in
Makefiles.  (I think this was in the Unisoft Unix days, pre-BSD.)  Bill
Shannon actually put it into their source tree.  But in a few days or
weeks, he took it back out, because he realized that Makefiles built on
Suns using leading spaces wouldn't work anywhere else.

Compatibility with the rest of the UNIX(tm) world was more important
than eliminating the software's foolish distinction between two
characters you can't see.

	John
	

Re: [TUHS] tabs vs spaces - entab, detab

[Dave Horsfall]

(Straying into COFF territory here)

On Fri, 5 Mar 2021, John Gilmore wrote:

> The one that got me was make(1).  Being used to text editors that used 
> "tab" as a command rather than a literal character, I proposed a fix 
> early on at Sun that would allow leading spaces as well as tabs in 
> Makefiles.  (I think this was in the Unisoft Unix days, pre-BSD.)  Bill 
> Shannon actually put it into their source tree.  But in a few days or 
> weeks, he took it back out, because he realized that Makefiles built on 
> Suns using leading spaces wouldn't work anywhere else.

I loathe make's distinguishment between tabs and spaces; they look the 
same on the screen, and last I looked computers are supposed to serve 
humans and not the other way around.

-- Dave

Re: [TUHS] tabs vs spaces - entab, detab

[Larry McVoy]

On Sun, Mar 07, 2021 at 08:31:57AM +1100, Dave Horsfall wrote:
> (Straying into COFF territory here)
> 
> On Fri, 5 Mar 2021, John Gilmore wrote:
> 
> >The one that got me was make(1).  Being used to text editors that used
> >"tab" as a command rather than a literal character, I proposed a fix early
> >on at Sun that would allow leading spaces as well as tabs in Makefiles.
> >(I think this was in the Unisoft Unix days, pre-BSD.)  Bill Shannon
> >actually put it into their source tree.  But in a few days or weeks, he
> >took it back out, because he realized that Makefiles built on Suns using
> >leading spaces wouldn't work anywhere else.
> 
> I loathe make's distinguishment between tabs and spaces; they look the same
> on the screen, and last I looked computers are supposed to serve humans and
> not the other way around.

Has anyone asked Stu Feldman why make wanted a tab?  Or does anyone know?
I have to believe there was a better reason than it was one tab vs
8 spaces.

Re: [TUHS] tabs vs spaces - entab, detab

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

On Sat, Mar 6, 2021 at 4:38 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Sun, Mar 07, 2021 at 08:31:57AM +1100, Dave Horsfall wrote:
> > (Straying into COFF territory here)
> >
> > On Fri, 5 Mar 2021, John Gilmore wrote:
> >
> > >The one that got me was make(1).  Being used to text editors that used
> > >"tab" as a command rather than a literal character, I proposed a fix
> early
> > >on at Sun that would allow leading spaces as well as tabs in Makefiles.
> > >(I think this was in the Unisoft Unix days, pre-BSD.)  Bill Shannon
> > >actually put it into their source tree.  But in a few days or weeks, he
> > >took it back out, because he realized that Makefiles built on Suns using
> > >leading spaces wouldn't work anywhere else.
> >
> > I loathe make's distinguishment between tabs and spaces; they look the
> same
> > on the screen, and last I looked computers are supposed to serve humans
> and
> > not the other way around.
>
> Has anyone asked Stu Feldman why make wanted a tab?  Or does anyone know?
> I have to believe there was a better reason than it was one tab vs
> 8 spaces.
>
According to Eric Raymond in Chapter 15. Tools: make: Automating Your
Recipes", *The Art of Unix Programming*

*Why the tab in column 1? Yacc <https://en.wikipedia.org/wiki/Yacc> was
new, Lex <https://en.wikipedia.org/wiki/Lex_(software)> was brand new. I
hadn't tried either, so I figured this would be a good excuse to learn.
After getting myself snarled up with my first stab at Lex, I just did
something simple with the pattern newline-tab. It worked, it stayed. And
then a few weeks later I had a user population of about a dozen, most of
them friends, and I didn't want to screw up my embedded base. The rest,
sadly, is history.*
*— Stuart Feldman*

ᐧ

[-- Attachment #2: Type: text/html, Size: 3534 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Sat, Mar 6, 2021 at 5:06 PM Clem Cole <clemc@ccc.com> wrote:


> *And then a few weeks later I had a user population of about a dozen, most
> of them friends, and I didn't want to screw up my embedded base. The rest,
> sadly, is history.*
> *— Stuart Feldman*
>
>
Consequently, when he arrived at Google for his new job there, he was
initially supplied with a keyboard from which the Tab key had been removed
(at least according to various Googlers while I was there).


John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
The experiences of the past show that there has always been a discrepancy
between plans and performance.        --Emperor Hirohito, August 1945

ᐧ
>

[-- Attachment #2: Type: text/html, Size: 2735 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Steffen Nurpmeso]

John Cowan wrote in
 <CAD2gp_SBTSLOgwz1=SXGWP7g8-kgunPzdgHxwxkP5=7xcRweyg@mail.gmail.com>:
 |On Sat, Mar 6, 2021 at 5:06 PM Clem Cole <clemc@ccc.com> wrote:
 |> *And then a few weeks later I had a user population of about a dozen, \
 |> most
 |> of them friends, and I didn't want to screw up my embedded base. \
 |> The rest,
 |> sadly, is history.*
 |> *— Stuart Feldman*
 |>
 |Consequently, when he arrived at Google for his new job there, he was
 |initially supplied with a keyboard from which the Tab key had been removed
 |(at least according to various Googlers while I was there).

Reminds me of members of the outgoing Clinton administration
removing the "W" key from white house keyboards.
Leads to nothing good, such...

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] tabs vs spaces - entab, detab

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

> On Mar 15, 2021, at 11:16 AM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> 
> Reminds me of members of the outgoing Clinton administration
> removing the "W" key from white house keyboards.
> Leads to nothing good, such...

From https://www.govexec.com/management/2016/02/must-presidential-transitions-end-sabotaged-white-house-keyboards/126061/

Several veterans of tense transitions weighed in on the oft-told tale of the 2000-01 transition during which departing Clinton staffers were reported to have removed the “W” keys from the White House keyboards being inherited by employees of George W. Bush. When she moved in on Jan. 20, McBride said, she recalled no sabotaged keyboards but did encounter some messy offices and the empty hallways filled with trash and boxes from the departing employees. Sharon Fawcett, the retired assistant archivist for presidential libraries at the National Archives, told later investigators she said couldn’t account for any missing W keys, but could account for missing hard drives—which were taken by her agency according to records law.

Kumar said the keyboard story appeared to be “overblown,” with a Government Accountability Office probe having found some problems but “nothing organized.” Problems included a few broken pieces of furniture and strewn pizza boxes that a janitor failed to remove.

[-- Attachment #2: Type: text/html, Size: 2565 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Steffen Nurpmeso]

Bakul Shah wrote in
 <01BE1B3F-8745-4465-93EF-95AA83EFD494@iitbombay.org>:

Wonderful, i can re-answer in public, too, leaving something off.

--- Forwarded from Bakul Shah <bakul@iitbombay.org> ---

Maybe because alternate processing rips myself off.  Sigh.

  ...
 |Oh. Hm. I heard this on American Forces
 |Network, told by Tony Scott, to which i listened from at least
 |Monday to Thursday 00am to 04am (German Time).  When such things
 |were still possible, and thus in the first days, maybe the day it
 |happened.  (Before "Max" was taken offline after Tony Scott issued
 |several "You can't say that on the radio", for sure.)

He surely did for years before that.  But i mean, hey, just an
observation, i have no idea of american sensitivities.

 |But thanks for the pointer.  Haven't we had this already in the
 |past?  The above sounds dark and ugly to my ears, hmmmm.

Yeah i mean, this arose by the beginning of the 90s, right.
If the first examination does not reveal the desired result (but
maybe the truth even, heh), then just perform a second .. a third
one, until the result is absolutely what was wanted.  Gulf war
illness, Barschel's death, W keys on the keyboard .. you name it.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] tabs vs spaces - entab, detab

[Earl Baugh]

One of the times I was lucky enough to be able to hire and set up what I thought would be the place I’d want to work (  design and code ), at the beginning I did the best I could to solve the “religious” code issues, tool issues, etc. 

Code Formatting wise — we came up with a “checked-in-standard”.  All code went thru a code formatter when checking in.   When it came out, we build a couple templates that translated to formats for things that different folks wanted ( and gave folks the option of tweaking their own ).  They could use the default ( I did ).   Any thing was fair game, as long as it got checked in “in the checked in standard”.   We also came up with a set of rules for complexity, nesting.   The entire team actually was able to come to agreement — if your code didn’t violated the limit of minor or misc things ( critical and major things had to be addressed ) it was fine. We set a limit of 1000 for minor and I think 5000 for misc.    I was surprised how far from the standard stuff looked on various folks workstations but during code reviews we had a “common language format” we all could read without much fuss. 

We did go with a line length of <132 so if necessary we could print stuff out landscape.

Tool wise, if it got in the way more than 50% it was gone and we’d find a new one.   Preference was for every editor, etc. to have at least two users on the team. ( so you’d have someone to ask questions of ) And you could use an IDE as long as code had standard makefiles when checked in.  

Surprisingly this worked out quite well with a team of around 20...

Earl  

Sent from my iPhone

> On Mar 15, 2021, at 7:48 PM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> 
> Bakul Shah wrote in
> <01BE1B3F-8745-4465-93EF-95AA83EFD494@iitbombay.org>:
> 
> Wonderful, i can re-answer in public, too, leaving something off.
> 
> --- Forwarded from Bakul Shah <bakul@iitbombay.org> ---
> 
> Maybe because alternate processing rips myself off.  Sigh.
> 
>  ...
> |Oh. Hm. I heard this on American Forces
> |Network, told by Tony Scott, to which i listened from at least
> |Monday to Thursday 00am to 04am (German Time).  When such things
> |were still possible, and thus in the first days, maybe the day it
> |happened.  (Before "Max" was taken offline after Tony Scott issued
> |several "You can't say that on the radio", for sure.)
> 
> He surely did for years before that.  But i mean, hey, just an
> observation, i have no idea of american sensitivities.
> 
> |But thanks for the pointer.  Haven't we had this already in the
> |past?  The above sounds dark and ugly to my ears, hmmmm.
> 
> Yeah i mean, this arose by the beginning of the 90s, right.
> If the first examination does not reveal the desired result (but
> maybe the truth even, heh), then just perform a second .. a third
> one, until the result is absolutely what was wanted.  Gulf war
> illness, Barschel's death, W keys on the keyboard .. you name it.
> 
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)

Re: [TUHS] tabs vs spaces - entab, detab

[Dave Horsfall]

On Sun, 14 Mar 2021, John Cowan wrote:

> Consequently, when he arrived at Google for his new job there, he was 
> initially supplied with a keyboard from which the Tab key had been 
> removed (at least according to various Googlers while I was there).

That's a bit extreme...  Although I confess to removing the CAPS LOCK and 
the Windoze keys on all of mine, as I can't think of a use for them and I 
tend to hit them by mistake.

-- Dave, a hopeless typist

Re: [TUHS] tabs vs spaces - entab, detab

[Steve Nickolas]

On Tue, 16 Mar 2021, Dave Horsfall wrote:

> On Sun, 14 Mar 2021, John Cowan wrote:
>
>> Consequently, when he arrived at Google for his new job there, he was 
>> initially supplied with a keyboard from which the Tab key had been removed 
>> (at least according to various Googlers while I was there).
>
> That's a bit extreme...  Although I confess to removing the CAPS LOCK and the 
> Windoze keys on all of mine, as I can't think of a use for them and I tend to 
> hit them by mistake.

I repurpose the Windows keys as something actually useful to me: compose 
keys.

-uso.

Re: [TUHS] tabs vs spaces - entab, detab

[Dave Horsfall]

On Mon, 15 Mar 2021, Steve Nickolas wrote:

> I repurpose the Windows keys as something actually useful to me: compose 
> keys.

I thought about remapping them, but couldn't think of anything useful to 
me.

Anyway, my current keyboard is a MacBook, and the last time I prised out 
the CAPS LOCK I damaged the keyboard so I merely ignore it in Keyboard 
Preferences.  I still can't think of a use for it these days, but I guess 
it's for compatibility with those mechanical things.

At least there's no damned Windoze key to get in the way...

-- Dave

Re: [TUHS] tabs vs spaces - entab, detab

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

I use Karabiner to remap Caps Lock to Control globally.  Since my daily
driver is a 1989 Model M, I also use it to remap Left Alt to Command and
Right Ctrl to Fn (but I run with function keys as function keys, with
held-down Fn to access the media and screen controls).

Adam



On Mon, Mar 15, 2021 at 2:24 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Mon, 15 Mar 2021, Steve Nickolas wrote:
>
> > I repurpose the Windows keys as something actually useful to me: compose
> > keys.
>
> I thought about remapping them, but couldn't think of anything useful to
> me.
>
> Anyway, my current keyboard is a MacBook, and the last time I prised out
> the CAPS LOCK I damaged the keyboard so I merely ignore it in Keyboard
> Preferences.  I still can't think of a use for it these days, but I guess
> it's for compatibility with those mechanical things.
>
> At least there's no damned Windoze key to get in the way...
>
> -- Dave
>

[-- Attachment #2: Type: text/html, Size: 1353 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[arnold]

Dave Horsfall <dave@horsfall.org> wrote:

> On Mon, 15 Mar 2021, Steve Nickolas wrote:
>
> > I repurpose the Windows keys as something actually useful to me: compose 
> > keys.
>
> I thought about remapping them, but couldn't think of anything useful to 
> me.
>
> Anyway, my current keyboard is a MacBook, and the last time I prised out 
> the CAPS LOCK I damaged the keyboard so I merely ignore it in Keyboard 
> Preferences.  I still can't think of a use for it these days, but I guess 
> it's for compatibility with those mechanical things.
>
> At least there's no damned Windoze key to get in the way...
>
> -- Dave

Come now people. Caps-lock keys are a requirement for your AOL account!

;-)

Arnold

Re: [TUHS] tabs vs spaces - entab, detab

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Sunday, 14 March 2021 at 23:02:58 -0400, John Cowan wrote:
> On Sat, Mar 6, 2021 at 5:06 PM Clem Cole <clemc@ccc.com> wrote:
>
>
>> *And then a few weeks later I had a user population of about a dozen, most
>> of them friends, and I didn't want to screw up my embedded base. The rest,
>> sadly, is history.*
>> *??? Stuart Feldman*
>>
> Consequently, when he arrived at Google for his new job there, he was
> initially supplied with a keyboard from which the Tab key had been removed
> (at least according to various Googlers while I was there).

But he had a Ctrl key, right?  So he had c-i.  I have used that on
keyboards where the TAB key is inconveniently placed.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Steve Nickolas]

On Sun, 7 Mar 2021, Dave Horsfall wrote:

> (Straying into COFF territory here)
>
> On Fri, 5 Mar 2021, John Gilmore wrote:
>
>> The one that got me was make(1).  Being used to text editors that used 
>> "tab" as a command rather than a literal character, I proposed a fix early 
>> on at Sun that would allow leading spaces as well as tabs in Makefiles.  (I 
>> think this was in the Unisoft Unix days, pre-BSD.)  Bill Shannon actually 
>> put it into their source tree.  But in a few days or weeks, he took it back 
>> out, because he realized that Makefiles built on Suns using leading spaces 
>> wouldn't work anywhere else.
>
> I loathe make's distinguishment between tabs and spaces; they look the same 
> on the screen, and last I looked computers are supposed to serve humans and 
> not the other way around.
>
> -- Dave
>

I used to have my own system for doing "make"-like builds which was a lot 
more primitive and just relied on a tool that returned an errorlevel based 
on whether a file needed to be rebuilt.

Of course, that was because I used an editor that destroyed tabs. :/ Damn 
it, M$...

-uso.

Re: [TUHS] tabs vs spaces - entab, detab

[emanuel stiebler]

On 2021-03-04 11:59, Clem Cole wrote:
> Oh boy, you do want to pour muddy water on the table.   I generally
> believed in tabs set every 4 spaces.  That's Steven's used in all his
> UNIX books.  Have to ask Rob what and bwk used but I sort of think it
> was pretty similar.  A problem is a lot of people had tabs set at 8
> spaces.  

Does it help, if we differentiate with the type of text ?

Assembler : Tabs = 8 spaces
(c, c++, pascal, java, etc.) : tabs = 4 spaces

;-)

Re: [TUHS] tabs vs spaces - entab, detab

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

On Thu, Mar 4, 2021 at 2:10 PM emanuel stiebler <emu@e-bbes.com> wrote:

Does it help, if we differentiate with the type of text ?
>
> Assembler : Tabs = 8 spaces
> (c, c++, pascal, java, etc.) : tabs = 4 spaces
>

The Lisp community long ago standardized on 2-space indentation.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Income tax, if I may be pardoned for saying so, is a tax on income.
                --Lord Macnaghten (1901)

[-- Attachment #2: Type: text/html, Size: 1556 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Larry McVoy]

On Thu, Mar 04, 2021 at 07:44:12PM -0500, John Cowan wrote:
> On Thu, Mar 4, 2021 at 2:10 PM emanuel stiebler <emu@e-bbes.com> wrote:
> 
> Does it help, if we differentiate with the type of text ?
> >
> > Assembler : Tabs = 8 spaces
> > (c, c++, pascal, java, etc.) : tabs = 4 spaces
> >
> 
> The Lisp community long ago standardized on 2-space indentation.

I used to be a 4 spaces are tabs guy but Sun beat that out of me.
Tabs are tabs and they are for a reason, though that reason is pretty
dead.  The reason was pretty printing listings, anything but tabs got
all screwed up.  But it has probably been a decade or more since I've
pretty printed anything, maybe two.  Old habits...

I developed my own use of 4 spaces, those are "continuation lines"

	if (some_stupidly_long_expression_that_goes_on_forever >=
	    this_never_happens_but_it_does_happen_when_deeply_nested) {
	    	statement;
		statement2;
		etc;
	}

But I'm weird, I hate

	if (expr) 
		statement;

I do

	if (expr) statement;

Curly braces are for more than one statement or I do do

	if (expr) {
		statement;
	} else {
		statement2;
	}

I also like perl so I do 

#define	unless(x) if (!(x))

because I think this reads better:

	FILE	*f;

	unless (f = fopen(argv[1], "r")) {
		perror(argv[1]);
		exit(1);
	}

Re: [TUHS] tabs vs spaces - entab, detab

[George Michaelson]

I use them incoherently, depending on context, time, and adherence to
something approximating to xNF for some X, normal-form. Other peoples
rules.

What I found interesting, is the divergence in strategy in managing.

strategy a: I shall show these as if they were 8 space indents. You
maybe can change this. Its columns on the screen.
strategy b: I shall, in a fit of lunacy, actually change these to
align to the 8 space indent column implications. your source is now
different
strategy c: You ran some tool like tr over these, and now, Its your
fault not mine. Good luck.

I usually wound up in strategy c but some editors of the day did
strategy b. I harbour a belief, this amongst other things, is why
patch -l was invented.

I know its heresy to contradict wiser people, but I think the number
of circumstances where space/tab actually did affect baud- or data-
rate was minimal. It was an effect more apparent and believed than
real. Sure, if you used an ASR33 the head positioning was better. That
experience set against being in a Vt52 or ADM5 world, by the time you
were in a vdu display of 80x24 I think it was gone.  I never
consciously thought about it and I used both. It wasn't very material
for the circumstances but I wasn't trying to cram source into a 2k
memory to put into a rocket or a telephone switch or anything. It's a
bit like steam-engine enthusiasts arguing about boiler tube design:
most shunters don't care.

People mostly hated me mucking around with their code. I can't blame
them. It would be horrid to live in a really nicely laid out world in
either tab or space-land and have a hooligan come and scribble over
your art with a texta.  Aside from simply coding bad answers to
problems, I do note that sending people who demanded KNF non-KNF
formatted code usually led to rapid rejection.

The US is a place where people still use fixed-width fonts and
specific spacing to file paper on the law courts, although I note
Sydney Powell didn't bother spell checking before she sent in the
incredibly weird conforming style of text. I should complain: the IETF
idnit checker is feral.

-G

On Fri, Mar 5, 2021 at 10:55 AM Larry McVoy <lm@mcvoy.com> wrote:
>
> On Thu, Mar 04, 2021 at 07:44:12PM -0500, John Cowan wrote:
> > On Thu, Mar 4, 2021 at 2:10 PM emanuel stiebler <emu@e-bbes.com> wrote:
> >
> > Does it help, if we differentiate with the type of text ?
> > >
> > > Assembler : Tabs = 8 spaces
> > > (c, c++, pascal, java, etc.) : tabs = 4 spaces
> > >
> >
> > The Lisp community long ago standardized on 2-space indentation.
>
> I used to be a 4 spaces are tabs guy but Sun beat that out of me.
> Tabs are tabs and they are for a reason, though that reason is pretty
> dead.  The reason was pretty printing listings, anything but tabs got
> all screwed up.  But it has probably been a decade or more since I've
> pretty printed anything, maybe two.  Old habits...
>
> I developed my own use of 4 spaces, those are "continuation lines"
>
>         if (some_stupidly_long_expression_that_goes_on_forever >=
>             this_never_happens_but_it_does_happen_when_deeply_nested) {
>                 statement;
>                 statement2;
>                 etc;
>         }
>
> But I'm weird, I hate
>
>         if (expr)
>                 statement;
>
> I do
>
>         if (expr) statement;
>
> Curly braces are for more than one statement or I do do
>
>         if (expr) {
>                 statement;
>         } else {
>                 statement2;
>         }
>
> I also like perl so I do
>
> #define unless(x) if (!(x))
>
> because I think this reads better:
>
>         FILE    *f;
>
>         unless (f = fopen(argv[1], "r")) {
>                 perror(argv[1]);
>                 exit(1);
>         }

Re: [TUHS] tabs vs spaces - entab, detab

[Larry McVoy]

On Fri, Mar 05, 2021 at 11:09:16AM +1000, George Michaelson wrote:
> People mostly hated me mucking around with their code. I can't blame
> them. It would be horrid to live in a really nicely laid out world in
> either tab or space-land and have a hooligan come and scribble over
> your art with a texta.  

I'm with ya there.  I *hate* GNU coding style, just hate it.  But when 
I submit a patch, it is in whatever style the code had.  I've run into
people that don't do that, and in 95% or more of the cases, their patches
don't get in.  If they are important, the maintainer applys the patch,
fixes the style, and then commits.

My opinion does not trump the source base.  Source base wins.  It's just
being polite.

Re: [TUHS] tabs vs spaces - entab, detab

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 104 bytes --]

>
> My opinion does not trump the source base.  Source base wins.  It's just
> being polite.
>

Preach!

[-- Attachment #2: Type: text/html, Size: 533 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[John P. Linderman]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

In my first days as a UNIX user (mid 70's), operating at 110 baud,
mechanical tabs were much faster than multiple spaces. And with
now-laughably small disks, saving space in files was a consideration, too.
Neither should matter now, but early training can be difficult to overcome.

I find it easier to read code when statements aren't split across
multiple lines (and therefore sometimes across pages). So I'm now inclined
to favor smaller tab-stops.

On Thu, Mar 4, 2021 at 11:53 AM Will Senn <will.senn@gmail.com> wrote:

> OK. So, I've been trying to decide (for the last time, I swear) whether to
> use tabs or spaces in my code... I did a quick pulse-check on the state of
> argument and it appears to be alive and well in 2021. My question for y'all
> is, was there a preference in the very early days or not? I saw an article
> talking about the 20 year feud, but that's not my recollection. In 1994,
> nobody agreed on this, but I'm sure it predates my entree into the field.
> I'm thinking the history of entab and detab are somehow related, but I've
> been wrong on these sorts of thoughts before. What say you?
>
> Will
>

[-- Attachment #2: Type: text/html, Size: 1790 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

On Thursday,  4 March 2021 at 10:52:30 -0600, Will Senn wrote:
> OK. So, I've been trying to decide (for the last time, I swear) whether
> to use tabs or spaces in my code... I did a quick pulse-check on the
> state of argument and it appears to be alive and well in 2021.

FWIW, FreeBSD's style(9) man page
(https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html)
includes:

   Indentation is an 8 character tab.  Second level indents are four
   spaces.

I've always used 8 character tabs (though in my own code I don't stick
to style(9)).  As others have commented, it's the Unix standard, and
the confusion between tabs and spaces is bad enough without changing
the relationship.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Will Senn]

On 3/4/21 3:24 PM, Greg 'groggy' Lehey wrote:
> FWIW, FreeBSD's style(9) man page
> (https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html)
> includes:
>
>     Indentation is an 8 character tab.  Second level indents are four
>     spaces.
>
> I've always used 8 character tabs (though in my own code I don't stick
> to style(9)).  As others have commented, it's the Unix standard, and
> the confusion between tabs and spaces is bad enough without changing
> the relationship.
>
> Greg
Wow, mixed tabs and spaces? On purpose? That's nuts :).

Re: [TUHS] tabs vs spaces - entab, detab

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

On Thursday,  4 March 2021 at 15:27:27 -0600, Will Senn wrote:
> On 3/4/21 3:24 PM, Greg 'groggy' Lehey wrote:
>> FWIW, FreeBSD's style(9) man page
>> (https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html)
>> includes:
>>
>>     Indentation is an 8 character tab.  Second level indents are four
>>     spaces.
>>
>> I've always used 8 character tabs (though in my own code I don't stick
>> to style(9)).  As others have commented, it's the Unix standard, and
>> the confusion between tabs and spaces is bad enough without changing
>> the relationship.
>
> Wow, mixed tabs and spaces? On purpose? That's nuts :).

FWIW, I do this in my own code too.  Once you know about it, it's not
an issue.  It helps to have an editor that highlights tab characters.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Will Senn]

Sent from my iPhone

> On Mar 4, 2021, at 3:29 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
> 
>> On Thursday,  4 March 2021 at 15:27:27 -0600, Will Senn wrote:
>>> On 3/4/21 3:24 PM, Greg 'groggy' Lehey wrote:
>>> FWIW, FreeBSD's style(9) man page
>>> (https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html)
>>> includes:
>>> 
>>>    Indentation is an 8 character tab.  Second level indents are four
>>>    spaces.
>>> 
>>> I've always used 8 character tabs (though in my own code I don't stick
>>> to style(9)).  As others have commented, it's the Unix standard, and
>>> the confusion between tabs and spaces is bad enough without changing
>>> the relationship.
>> 
>> Wow, mixed tabs and spaces? On purpose? That's nuts :).
> 
> FWIW, I do this in my own code too.  Once you know about it, it's not
> an issue.  It helps to have an editor that highlights tab characters.
> 
> Greg
> --
> 
There’s a thought, highlight the pesky things. I usually hunt for them after they become an issue, but turning on a highlight is way better than my editor’s “show invisibles” function that puts a funky dash where tabs are... not invisible, just obfuscated.

Re: [TUHS] tabs vs spaces - entab, detab

[John P. Linderman]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

Appropos my "laughably small" disk space comment, here's a snippet from
mkfs.ext4:

       -m reserved-blocks-percentage
              Specify the percentage of the filesystem blocks reserved for
the
              super-user.   This  avoids  fragmentation, and allows
root-owned
              daemons, such as syslogd(8), to continue to  function
 correctly
              after non-privileged processes are prevented from writing to
the
              filesystem.  The default percentage is 5%.

I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB.
I'm pretty confident that all the spinning (no, tapes aren't spinning)
storage at all of Bell Labs in 1975 was less than the reserved space for
one of my disks. FWIW, I set "-m 0" for honker disks. -- jpl

[-- Attachment #2: Type: text/html, Size: 1183 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Andy Kosela]

I am still computing in full screen text mode on CRT monitors, so it's
80 columns and 8 character tab as indentation for me.  It is a golden
standard.

From Linux kernel coding style doc:
"Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even
2!) characters deep, and that is akin to trying to define the value of
PI to be 3."

--Andy

Re: [TUHS] tabs vs spaces - entab, detab

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Thursday,  4 March 2021 at 23:08:53 +0100, Andy Kosela wrote:
>
> From Linux kernel coding style doc:
> "Tabs are 8 characters, and thus indentations are also 8 characters.
> There are heretic movements that try to make indentations 4 (or even
> 2!) characters deep, and that is akin to trying to define the value of
> PI to be 3."

:-)

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Steffen Nurpmeso]

Greg 'groggy' Lehey wrote in
 <20210304221250.GD6303@eureka.lemis.com>:
 |On Thursday,  4 March 2021 at 23:08:53 +0100, Andy Kosela wrote:
 |>
 |> From Linux kernel coding style doc:
 |> "Tabs are 8 characters, and thus indentations are also 8 characters.
 |> There are heretic movements that try to make indentations 4 (or even
 |> 2!) characters deep, and that is akin to trying to define the value of
 |> PI to be 3."
 |
 |:-)

I for one happily left tabulators behind.  But for make files.
The reason to use tab was file size for one, and that each editor
could be used interchangeably to work easily (backspace stepping
a real level, for example), and the reason for tab/8 was that the
files looked the same everywhere, on the printer, on the terminal
via cat(1), less(1), etc., so playing with vim(1)s tabstop
etc. setting was a fruitless dead-end.

On the 80 columns that i use, that i happily use, i just read
wireguard-tools source code (i am in the process of becoming
a hundred percent Wireguard fan, someone sat down and did
something really great i think) and even though it fits my screen,
it is just terrible to see lines that long (the kernel code fits
80, yay, not that i understand where all the work happens),
tabulators just cause crowding on the right, and then .. that
cannot be right.

Even though my coding style is easy not like that Linux kernel
code where function call arguments are then aligned under the
( +1, which ... no!  Well.  I switched to spaces when working for
free.  :)
But, not important.  A real change to my coding style came when
i looked around Plan9 source code, the pragmatism to simply not
use spaces in language constructs aka statements at all, for
example "if(a){" instead of "if(a) {" or "if (a) {", and let alone
"if (a)\nALIGN{\nALIGN" and whatever else.  I like that.  You
know, FreeBSD is thinking about using that clang format thing in
commit hooks (and maybe many even use the clangd "live" ctags),
and that was written in Acme or even Sam.  And the manuals were
great and the C dialect was, too.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] tabs vs spaces - entab, detab

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 2412 bytes --]

On Fri, Mar 5, 2021 at 9:14 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:


> But, not important.  A real change to my coding style came when
> i looked around Plan9 source code, the pragmatism to simply not
> use spaces in language constructs aka statements at all, for
> example "if(a){" instead of "if(a) {" or "if (a) {", and let alone
> "if (a)\nALIGN{\nALIGN" and whatever else.
>

That way lies APL madness.  To exemplify, Kona is an open-source
interpreter for Arthur Whitney's K version 3 language, which is closely
related to APL, but crams almost all of the APL operators onto single ASCII
characters with massive overloading.  For example, monadic ! is APL "iota",
but dyadic ! is "modulo" if both arguments are numbers and "rotate" if the
right argument is a number and the left argument is a vector.  What any of
these has to do with the rest is beyond me: I had to create a set of flash
cards to help me learn them all.

Well, here's a procedure definition from the Kona source, in a file
helpfully named kc.c (almost all of the source files have 1-2 character
names):

I wds_(K*a,FILE*f,I l)
{ S s=0,t=0;  I b=0,c=0,m=0,n=0,v=0;  K z=0; PDA p=0;
  I o=isatty(STDIN)&&f==stdin;
  if(-1==(c=getline_(&s,&n,f)))GC;
  appender(&t,&m,s,n);
  while(1==(v=complete(t,m,&p,0)))
  { b=parsedepth(p);
    if(o)prompt(b+l);
    if(-1==(c=getline_(&s,&n,f)))GC;
    appender(&t,&m,s,n); }
  SW(v){CS(2,show(kerr("unmatched"));GC) CS(3,show(kerr("nest")); GC)}
  z=newK(-3,m-1);
  strncpy(kC(z),t,m-1);
 cleanup:
  free(s); free(t);
  if(p)pdafree(p);
  if((v||c==-1)&&z){cd(z); *a=0;}
  else *a=z;
  R v?-v:c; }    // -1 EOF, -2 unmatched, -3 nest

If you want that sort of thing, you can certainly have it.  Note the
single-space ident and the cuddled right braces.  Note also the label
"cleanup:"; presumably a "goto cleanup;" is hidden somewhere in the
single-letter (of course) macros.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
The peculiar excellence of comedy is its excellent fooling, and
Aristophanes's
claim to immortality is based upon one title only: he was a master maker
of comedy, he could fool excellently.  Here Gilbert stands side by side
with him.  He, too, could write the most admirable nonsense.  There has
never been better fooling than his, and a comparison with him carries
nothing derogatory to the great Athenian. --Edith Hamilton, The Greek Way

[-- Attachment #2: Type: text/html, Size: 4365 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 4334 bytes --]

> On Mar 5, 2021, at 12:24 PM, John Cowan <cowan@ccil.org> wrote:
> 
> On Fri, Mar 5, 2021 at 9:14 AM Steffen Nurpmeso <steffen@sdaoden.eu <mailto:steffen@sdaoden.eu>> wrote: 
>  
> But, not important.  A real change to my coding style came when
> i looked around Plan9 source code, the pragmatism to simply not
> use spaces in language constructs aka statements at all, for
> example "if(a){" instead of "if(a) {" or "if (a) {", and let alone
> "if (a)\nALIGN{\nALIGN" and whatever else.  
> 
> That way lies APL madness.  To exemplify, Kona is an open-source interpreter for Arthur Whitney's K version 3 language, which is closely related to APL, but crams almost all of the APL operators onto single ASCII characters with massive overloading.  For example, monadic ! is APL "iota", but dyadic ! is "modulo" if both arguments are numbers and "rotate" if the right argument is a number and the left argument is a vector.  What any of these has to do with the rest is beyond me: I had to create a set of flash cards to help me learn them all.

Not sure what this has to do with tabs but note that APL itself did a lot of punning in that unary and binary functions of the same name were related. K does something similar but perhaps not as consistently. 

> Well, here's a procedure definition from the Kona source, in a file helpfully named kc.c (almost all of the source files have 1-2 character names):

People should perhaps look at Whitney's original C code[1] that started all this (see below).

I can no longer compile this but it is worth studying. This was the genesis of both K & J languages. There is method to Whitney's madness but it takes a while to grok his style. Given that he has produced 6 or so versions of K, a specialized C compiler, as well as an OS prototype (kOS), clearly it has worked extremely well for him! Whiney once explained "It is a lot easier to find your errors in four lines of code than in four hundred." [2] Though his style is not for most people!

typedef char C;typedef long I;
typedef struct a{I t,r,d[3],p[2];}*A;
#define P printf
#define R return
#define V1(f) A f(w)A w;
#define V2(f) A f(a,w)A a,w;
#define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}}
I *ma(n){R(I*)malloc(n*4);}mv(d,s,n)I *d,*s;{DO(n,d[i]=s[i]);}
tr(r,d)I *d;{I z=1;DO(r,z=z*d[i]);R z;}
A ga(t,r,d)I *d;{A z=(A)ma(5+tr(r,d));z->t=t,z->r=r,mv(z->d,d,r);
 R z;}
V1(iota){I n=*w->p;A z=ga(0,1,&n);DO(n,z->p[i]=i);R z;}
V2(plus){I r=w->r,*d=w->d,n=tr(r,d);A z=ga(0,r,d);
 DO(n,z->p[i]=a->p[i]+w->p[i]);R z;}
V2(from){I r=w->r-1,*d=w->d+1,n=tr(r,d);
 A z=ga(w->t,r,d);mv(z->p,w->p+(n**a->p),n);R z;}
V1(box){A z=ga(1,0,0);*z->p=(I)w;R z;}
V2(cat){I an=tr(a->r,a->d),wn=tr(w->r,w->d),n=an+wn;
 A z=ga(w->t,1,&n);mv(z->p,a->p,an);mv(z->p+an,w->p,wn);R z;}
V2(find){}
V2(rsh){I r=a->r?*a->d:1,n=tr(r,a->p),wn=tr(w->r,w->d);
 A z=ga(w->t,r,a->p);mv(z->p,w->p,wn=n>wn?wn:n);
 if(n-=wn)mv(z->p+wn,z->p,n);R z;}
V1(sha){A z=ga(0,1,&w->r);mv(z->p,w->d,w->r);R z;}
V1(id){R w;}V1(size){A z=ga(0,0,0);*z->p=w->r?*w->d:1;R z;}
pi(i){P("%d ",i);}nl(){P("\n");}
pr(w)A w;{I r=w->r,*d=w->d,n=tr(r,d);DO(r,pi(d[i]));nl();
 if(w->t)DO(n,P("< ");pr(w->p[i]))else DO(n,pi(w->p[i]));nl();}

C vt[]="+{~<#,";
A(*vd[])()={0,plus,from,find,0,rsh,cat},
 (*vm[])()={0,id,size,iota,box,sha,0};
I st[26]; qp(a){R  a>='a'&&a<='z';}qv(a){R a<'a';}
A ex(e)I *e;{I a=*e;
 if(qp(a)){if(e[1]=='=')R st[a-'a']=ex(e+2);a= st[ a-'a'];}
 R qv(a)?(*vm[a])(ex(e+1)):e[1]?(*vd[e[1]])(a,ex(e+2)):(A)a;}
noun(c){A z;if(c<'0'||c>'9')R 0;z=ga(0,0,0);*z->p=c-'0';R z;}
verb(c){I i=0;for(;vt[i];)if(vt[i++]==c)R i;R 0;}
I *wd(s)C *s;{I a,n=strlen(s),*e=ma(n+1);C c;
 DO(n,e[i]=(a=noun(c=s[i]))?a:(a=verb(c))?a:c);e[n]=0;R e;}

main(){C s[99];while(gets(s))pr(ex(wd(s)));}
[1] https://code.jsoftware.com/wiki/Essays/Incunabulum
One summer weekend in 1989, Arthur Whitney visited Ken Iverson at Kiln Farm and produced—on one page and in one afternoon—an interpreter fragment on the AT&T 3B1 computer. I (Roger Hui) studied this interpreter for about a week for its organization and programming style; and on Sunday, August 27, 1989, at about four o'clock in the afternoon, wrote the first line of code that became the implementation described in this document.

[2] http://archive.vector.org.uk/art10501320

[-- Attachment #2: Type: text/html, Size: 7211 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Steffen Nurpmeso]

John Cowan wrote in
 <CAD2gp_Qv7pO6P_LyZ=5zXm78GpBK4sUE2f8_4BBfyqJP7OSAJA@mail.gmail.com>:
 |On Fri, Mar 5, 2021 at 9:14 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
 |> But, not important.  A real change to my coding style came when
 |> i looked around Plan9 source code, the pragmatism to simply not
 |> use spaces in language constructs aka statements at all, for
 |> example "if(a){" instead of "if(a) {" or "if (a) {", and let alone
 |> "if (a)\nALIGN{\nALIGN" and whatever else.
 |
 |That way lies APL madness.  To exemplify, Kona is an open-source
 |interpreter for Arthur Whitney's K version 3 language, which is closely
 |related to APL, but crams almost all of the APL operators onto single ASCII
 |characters with massive overloading.  For example, monadic ! is APL "iota",
 |but dyadic ! is "modulo" if both arguments are numbers and "rotate" if the
 |right argument is a number and the left argument is a vector.  What any of
 |these has to do with the rest is beyond me: I had to create a set of flash
 |cards to help me learn them all.
 |
 |Well, here's a procedure definition from the Kona source, in a file
 |helpfully named kc.c (almost all of the source files have 1-2 character
 |names):
 |
 |I wds_(K*a,FILE*f,I l)
 |{ S s=0,t=0;  I b=0,c=0,m=0,n=0,v=0;  K z=0; PDA p=0;
 |  I o=isatty(STDIN)&&f==stdin;
 |  if(-1==(c=getline_(&s,&n,f)))GC;
 |  appender(&t,&m,s,n);
 |  while(1==(v=complete(t,m,&p,0)))
 |  { b=parsedepth(p);
 |    if(o)prompt(b+l);
 |    if(-1==(c=getline_(&s,&n,f)))GC;
 |    appender(&t,&m,s,n); }
 |  SW(v){CS(2,show(kerr("unmatched"));GC) CS(3,show(kerr("nest")); GC)}
 |  z=newK(-3,m-1);
 |  strncpy(kC(z),t,m-1);
 | cleanup:
 |  free(s); free(t);
 |  if(p)pdafree(p);
 |  if((v||c==-1)&&z){cd(z); *a=0;}
 |  else *a=z;
 |  R v?-v:c; }    // -1 EOF, -2 unmatched, -3 nest
 |
 |If you want that sort of thing, you can certainly have it.  Note the
 |single-space ident and the cuddled right braces.  Note also the label
 |"cleanup:"; presumably a "goto cleanup;" is hidden somewhere in the
 |single-letter (of course) macros.

I do not, no.  The above has maybe the advantage that you really
really have to sit down and understand it as a whole before you
change anything, or apply patches.  This is very different to the
style that sometimes can be seen in projects with many people and
many patches, where code is packed in what-the-writer-thinks-is-a-
logical-block.  I (unfortunately) do it like that too, very
unfortunately with diverging positions of what a logical block is.
Just from a single pick, take Linux 5.10 ipc/sem.c.  You see

        sma = sem_alloc(nsems);
        if (!sma)
                return -ENOMEM;

        sma->sem_perm.mode = (semflg & S_IRWXUGO);
        sma->sem_perm.key = key;
1
        sma->sem_perm.security = NULL;
2       retval = security_sem_alloc(&sma->sem_perm);
        if (retval) {
                kvfree(sma);
                return retval;
        }

and i know that i would sometimes remove the newline 1 to finish
init of sem_perm, and instead introduce a newline before
2 instead.  I have no idea of kernel of course, here .security
depends on a special config and security_sem_alloc() just does
nothing without it (returning 0), not even setting .security to
NULL, whereas otherwise .security is definetely set by
lsm_ipc_alloc(), so maybe i understand 1, .. sometimes.  But
i would think about it.  And all of this just cannot happen with
the code above, i could use this style to fool myself into just
not thinking about just useless thoughts!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] tabs vs spaces - entab, detab

[Jon Steinhart]

Andy Kosela writes:
> I am still computing in full screen text mode on CRT monitors, so it's
> 80 columns and 8 character tab as indentation for me.  It is a golden
> standard.
>
> >From Linux kernel coding style doc:
> "Tabs are 8 characters, and thus indentations are also 8 characters.
> There are heretic movements that try to make indentations 4 (or even
> 2!) characters deep, and that is akin to trying to define the value of
> PI to be 3."
>
> --Andy

Well, I suppose that I have to weigh in here before this discussion gets shut
down.

First of all, it's a shame that there isn't a nice global way to set system
tab stops.  I have a lot of aliases that pipe through "expand -t 4".

Second, while I agree with about 90% of the linux kernel coding style the
indent and line length parts are in the other 10%.  And from looking at
kernel code, while many may agree with the style doc they don't actually
follow it so I'm not sure what agreement means.

I always thought that the 80 character line length limit (now an amazing 100)
was silly; nobody was using VT-100s by the time that linux was developed.  Most
developers were born after the last one was relegated to a museum somewhere.
In that timeframe I had changed to using 132 column; I would have gone to 160
but not everybody that I worked with thought that it was worth whatever it took
to have a great monitor.  I have UHD on both my desktop and laptop which allows
a pair of nicely readable 132 column windows with room left over.  No longer
much of a cost barrier.

The big problem that I have with the linux style is that in addition to the
tab stop and line length restrictions, there is the weird belief that one is
doing something wrong if more than three levels of indent are needed.  From
what I have seen, this is followed by unnecessarily breaking up functions
combined with zillions of macros and static inline functions in header files
to give the appearance of only three levels of indent.  Bottom line to me is
that it makes the code unreadable, and if I have to choose an ideology it's
making the code easy to read for someone who didn't write it, not some slavish
adherence to a rule that doesn't make a lot of sense to me.

I think that line breaks hurt readability as they make it harder to mentally
process the block structure of code in pre-attentive mode.  I used to have
8 character tab stops and short (traditional one character) variable names;
now I've moved to 4 character tab stops and more readable variable names.

When I do need to break a long line, I indent the continuation line(s) one
character from the starting line to preserve the block structure appearance as
much as possible.  No additional indent makes it hard to distinguish separate
statements, two character indent makes it hard to tell which level the line
belongs to since it's halfway between two levels.

I do use tabs, not spaces.  Main reason, going back decades, is that I can
find a statement by searching for "^Ifor" which is distinct from any other
use of for.  For the same reason, I put function definitions in column 1
with the type on the line above, so that I can easily search for "^foo" which
is distinct from any invocations.

Anyway, whether or not you agree with this it works for me; my goal is to
make my code comprehensible by people who aren't as smart as I am because
I want to move on, not maintain stuff.

Jon

Re: [TUHS] tabs vs spaces - entab, detab

[Dave Horsfall]

On Thu, 4 Mar 2021, Andy Kosela wrote:

> [...] and that is akin to trying to define the value of PI to be 3."

Urban myth.

-- Dave

Re: [TUHS] tabs vs spaces - entab, detab

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

On Mar 6, 2021, at 1:22 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Thu, 4 Mar 2021, Andy Kosela wrote:
> 
>> [...] and that is akin to trying to define the value of PI to be 3."
> 
> Urban myth.

From the Kings James Bible
https://quod.lib.umich.edu/cgi/k/kjv/kjv-idx?type=DIV1&byte=1392613
1 Kings 7:23 
> And he made a molten sea, ten cubits from the one brim to the other: it was round all about, and his height was five cubits: and a line of thirty cubits did compass it round about.

There seem to be various explanations for the above but perhaps it is the genesis of the common “define the value of pi to be 3” idea?

[-- Attachment #2: Type: text/html, Size: 1287 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Jon Steinhart]

Bakul Shah writes:
> From the Kings James Bible
> https://quod.lib.umich.edu/cgi/k/kjv/kjv-idx?type=DIV1&byte=1392613
> 1 Kings 7:23 
> 
>     And he made a molten sea, ten cubits from the one brim to the other: it was
>     round all about, and his height was five cubits: and a line of thirty
>     cubits did compass it round about.
> 
> 
> There seem to be various explanations for the above but perhaps it is the
> genesis of the common “define the value of pi to be 3” idea?

It could just be a translation problem - maybe
it was 30 qubits and wasn't properly observed.

Re: [TUHS] tabs vs spaces - entab, detab

[Steve Nickolas]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

On Sat, 6 Mar 2021, Bakul Shah wrote:

> On Mar 6, 2021, at 1:22 PM, Dave Horsfall <dave@horsfall.org> wrote:
>>
>> On Thu, 4 Mar 2021, Andy Kosela wrote:
>>
>>> [...] and that is akin to trying to define the value of PI to be 3."
>>
>> Urban myth.
>
> From the Kings James Bible
> https://quod.lib.umich.edu/cgi/k/kjv/kjv-idx?type=DIV1&byte=1392613
> 1 Kings 7:23
>> And he made a molten sea, ten cubits from the one brim to the other: it 
>> was round all about, and his height was five cubits: and a line of 
>> thirty cubits did compass it round about.
>
> There seem to be various explanations for the above but perhaps it is 
> the genesis of the common “define the value of pi to be 3” idea?

I believe it was - I've heard of it before.  And I run in the kind of 
circles that would be likely to say "π=3.0 because JEBUS!" or 
"geocentricity because JEBUS!" :/  (In fact, it took a second to realize I 
was reading a TUHS post.)

I worry for humanity.

-uso.

Re: [TUHS] tabs vs spaces - entab, detab

[Brantley Coile]

I'm pretty sure people knew the value of PI before 1611, when the
Authorized Version was published, and that people had a pretty good 
idea when the event described in 1 Kings 7 happened, a bit 
before 900 BC.  They used 3.1605 for the ratio in that time, I believe.

The values in the Bible are as one would explain to someone in conversation
about something else.  If I said something was 10 feet across and 30 feet around  
in normal conversation, an error of a foot and a half would be close 
enough.  When buying material, I use 4 as PI and trim to fit.

Brantley.


> On Mar 6, 2021, at 6:58 PM, Bakul Shah <bakul@iitbombay.org> wrote:
> 
> On Mar 6, 2021, at 1:22 PM, Dave Horsfall <dave@horsfall.org> wrote:
>> 
>> On Thu, 4 Mar 2021, Andy Kosela wrote:
>> 
>>> [...] and that is akin to trying to define the value of PI to be 3."
>> 
>> Urban myth.
> 
> From the Kings James Bible
> https://quod.lib.umich.edu/cgi/k/kjv/kjv-idx?type=DIV1&byte=1392613
> 1 Kings 7:23 
>> And he made a molten sea, ten cubits from the one brim to the other: it was round all about, and his height was five cubits: and a line of thirty cubits did compass it round about.
> 
> There seem to be various explanations for the above but perhaps it is the genesis of the common “define the value of pi to be 3” idea?

Re: [TUHS] tunefs -m 5%

[John Gilmore]

John P. Linderman <jpl.jpl@gmail.com> wrote:
> I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB.

At one point in hystery, ext2 performance was reported to suffer badly
if there was less than 5% of disk space available in an active
filesystem.  My naive belief, probably informed by older and wiser heads
around Sun, was that when the file system was >95% full, ext2 spent a
lot of time seeking around in free lists finding single allocatable
blocks.  And there were no built-in "defragmentation" programs that
could easily fix that.

Is that still a performance constraint in ext4, which has had a few
decades to work out those edge performance issues?

And if it's fixed, then to handle the "root needs lebensraum" argument,
perhaps the default reserved percentage should be set to 1% (or 0.1%,
which I think the tools do not currently support)?

Or perhaps it should be min(1%,10GB) reserved for root, so the calculation
works better on both large or small filesystems?

And on file systems that aren't expected to have root logfiles and such
in them, should the right default now be -m 0?

How many zettabytes of storage could we make available to users in 2030,
by improving this default from the 1980s now?

	John

Re: [TUHS] tunefs -m 5%

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On 3/5/21 2:50 AM, John Gilmore wrote:
> And there were no built-in "defragmentation" programs that could 
> easily fix that.

Sure there are!

Depending on how you look at things and if you have the file systems to 
do it....

The venerable trick of temporarily moving everything to another file 
system, thereby vacating the source file system as much as possible, 
before moving files back.  }:-)

Is it pretty?  No.
Is it fast?  No.
Does it work?  It's better than nothing.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]

Re: [TUHS] tunefs -m 5%

[Theodore Ts'o]

On Fri, Mar 05, 2021 at 01:50:32AM -0800, John Gilmore wrote:
> John P. Linderman <jpl.jpl@gmail.com> wrote:
> > I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB.
> 
> At one point in hystery, ext2 performance was reported to suffer badly
> if there was less than 5% of disk space available in an active
> filesystem.  My naive belief, probably informed by older and wiser heads
> around Sun, was that when the file system was >95% full, ext2 spent a
> lot of time seeking around in free lists finding single allocatable
> blocks.  And there were no built-in "defragmentation" programs that
> could easily fix that.

I'll point out that BSD FFS, at least in BSD 4.3, reserves 10% of the
file system for reserved blocks.  The reasoning gave was the same as
with ext2, which is performance suffers when the file system gets
really fully.  It really depends on the workload, but for the worst
case workloads, I've seen performance degradations happen earlier than
90% or 95% full.

Defragmentation is a hard problem, and it takes a *long* time, and or
chews up a lot of write cycles on flash, persistent memory, etc.  This
is especially true when the file system is very full, since there is
very little "swing space" available to copy data around, especially if
one is striving for the perfect state (e.g., a files are contiguous,
and the free space is contiguous).  Defragmentation utilities was
something that was only really popular on Windows systems, and in the
last, oh, ten years or so, even in the Windows world defrag is not
something you'll see in their disk utilities.

Ext4 has a defrag program, but it's really primitive, and it only
works by attempting to defrag *files*.  It doesn't try to defrag *free
space*, which is what you really need if you want to try to keep
performance up (and have space so as to keep files defragmented).  The
main reason why is that no one has sponsored work in this space ---
probably because it's way cheaper just to over-provision disk space.

If someone wants to try to implement it, I have a rough design about
how it might be done for ext4 --- but someone has to volunteer $$$ or
their own personal time in order to implement it.  And if it's only
for yourself, it's probably cheaper just to spend a extra few bucks to
buy a bigger disk.  I suspect it's for similar reasons that none of
the legacy Unix systems have defragmentation implemented either.  It's
not something which makes business case.

But hey, if someone is interested in working on it, I'll give the
standard open source answer --- patches gratefully accepted.  I'll
even give you a rough design as a starting point.  (And there's no
guarantee it will be a good idea for flash, given that seeks are
mostly free for flash, and write cycles are a consideration, and how
many people are still using HDD's today; newer operating systems, such
as Fuschia, have started designing for a world where they only need to
care about file systems for flash.)

Cheers,

					- Ted

Re: [TUHS] tunefs -m 5%

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

On Friday,  5 March 2021 at 10:32:15 -0500, Theodore Ts'o wrote:
> On Fri, Mar 05, 2021 at 01:50:32AM -0800, John Gilmore wrote:
>> John P. Linderman <jpl.jpl@gmail.com> wrote:
>>> I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB.
>>
>> At one point in hystery, ext2 performance was reported to suffer badly
>> if there was less than 5% of disk space available in an active
>> filesystem.  My naive belief, probably informed by older and wiser heads
>> around Sun, was that when the file system was >95% full, ext2 spent a
>> lot of time seeking around in free lists finding single allocatable
>> blocks.  And there were no built-in "defragmentation" programs that
>> could easily fix that.
>
> I'll point out that BSD FFS, at least in BSD 4.3, reserves 10% of the
> file system for reserved blocks.

Oops, that's what I get for reading messages sequentially :-(  But in
this case it's for small values of 10.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] tunefs -m 5%

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On Fri, Mar 5, 2021, 6:18 PM Greg 'groggy' Lehey <grog@lemis.com> wrote:

> On Friday,  5 March 2021 at 10:32:15 -0500, Theodore Ts'o wrote:
> > On Fri, Mar 05, 2021 at 01:50:32AM -0800, John Gilmore wrote:
> >> John P. Linderman <jpl.jpl@gmail.com> wrote:
> >>> I have several 12 TB disks scattered about my house. 5% of 12TB is
> 600GB.
> >>
> >> At one point in hystery, ext2 performance was reported to suffer badly
> >> if there was less than 5% of disk space available in an active
> >> filesystem.  My naive belief, probably informed by older and wiser heads
> >> around Sun, was that when the file system was >95% full, ext2 spent a
> >> lot of time seeking around in free lists finding single allocatable
> >> blocks.  And there were no built-in "defragmentation" programs that
> >> could easily fix that.
> >
> > I'll point out that BSD FFS, at least in BSD 4.3, reserves 10% of the
> > file system for reserved blocks.
>
> Oops, that's what I get for reading messages sequentially :-(  But in
> this case it's for small values of 10.
>

We set this to 1% at Netflix and fill to about ~98-99% full over UFS. This
works well as we don't have small files. SATA Flash we keep a bit more
empty, but that's due to its crappy FLT liking more free space...

Warner

Greg
> --
> Sent from my desktop computer.
> Finger grog@lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA
>

[-- Attachment #2: Type: text/html, Size: 2530 bytes --]

Re: [TUHS] tunefs -m 5%

[Dave Horsfall]

And that comment from FreeBSD's "tunefs" is still there:

     You can tune a file system, but you cannot tune a fish.

Funny; I could've sworn that it used to be "cannot tuna fish".

-- Dave

Re: [TUHS] tunefs -m 5%

[Larry McVoy]

On Sun, Mar 07, 2021 at 08:45:03AM +1100, Dave Horsfall wrote:
> And that comment from FreeBSD's "tunefs" is still there:
> 
>     You can tune a file system, but you cannot tune a fish.
> 
> Funny; I could've sworn that it used to be "cannot tuna fish".

I did a checkin at Sun that added

    .\" Take this out and a Unix Daemon will dog your steps from now until
    .\" the time_t's wrap around.
    .LP
    You can tune a file system, but you cannot tune a fish.

And of course, the numbnuts that ran Solaris took it back out.  Unless I'm
mistaken, I'm the dude that came up with the comment.  I believe I spelled
daemon wrong but whatever, I found that snippet in the FreeBSD sources so
someone has a sense of humor and kept my comment.

Re: [TUHS] tunefs -m 5%

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]

On Saturday,  6 March 2021 at 14:03:02 -0800, Larry McVoy wrote:
> On Sun, Mar 07, 2021 at 08:45:03AM +1100, Dave Horsfall wrote:
>> And that comment from FreeBSD's "tunefs" is still there:
>>
>>     You can tune a file system, but you cannot tune a fish.
>>
>> Funny; I could've sworn that it used to be "cannot tuna fish".

I checked the CSRG archive CDs.  The line was added, as shown, in
4.2BSD:

  --- ./4.1c.2/usr/man/man8/tunefs.8      1983-03-04 02:43:21.000000000 +1100
  +++ ./4.2/usr/man/man8/tunefs.8 1983-07-27 18:21:46.000000000 +1000
  @@ -4,7 +4,8 @@
  @@ -66,3 +67,5 @@
   Because the super-block is not kept in the buffer cache,
   the program will only take effect if it is run on dismounted file systems.
   (if run on the root file system, the system must be rebooted)
  +.PP
  +You can tune a file system, but you can't tune a fish.

> I did a checkin at Sun that added
>
>     .\" Take this out and a Unix Daemon will dog your steps from now until
>     .\" the time_t's wrap around.
>     .LP
>     You can tune a file system, but you cannot tune a fish.
>
> And of course, the numbnuts that ran Solaris took it back out.  Unless I'm
> mistaken, I'm the dude that came up with the comment.  I believe I spelled
> daemon wrong but whatever, I found that snippet in the FreeBSD sources so
> someone has a sense of humor and kept my comment.

Sadly, humour is no longer modern.  A while back I updated the
documentation to gdb(4) in FreeBSD, and added under BUGS:

  The debugging macros
  .Dq "just growed" .
  In general, the person who wrote them did so while looking for a specific
  problem, so they may not be general enough, and they may behave badly when used
  in ways for which they were not intended, even if those ways make sense.

And people took exception to "just growed" and converted it to "just
grown"!  Not just a lack of humour, but also a lack of understanding
of literature and grammar.  Somehow people take things too seriously
nowadays.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] tunefs -m 5%

[David Barto]

> On Mar 6, 2021, at 1:45 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> And that comment from FreeBSD's "tunefs" is still there:
> 
>    You can tune a file system, but you cannot tune a fish.
> 
> Funny; I could've sworn that it used to be "cannot tuna fish".
> 
> — Dave

In my copy of the BSD documentation (Unix System Manager’s Manual, with the red ring binder) the TUNEFS(8) page dated 20 February 1983 has “You can tune a file system, but you can’t tune a fish” as the last line.

Noted as the 4th Berkeley Distribution

Inside the cover it says: Printed by the USENIX Association as a service to the UNIX Community. Second Printing December 1984

Re: [TUHS] tunefs -m 5%

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]

I haven't redirected this reply to COFF, though I was considering
doing so: it

On Friday,  5 March 2021 at  1:50:32 -0800, John Gilmore wrote:
> John P. Linderman <jpl.jpl@gmail.com> wrote:
>> I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB.
>
> At one point in hystery, ext2 performance was reported to suffer badly
> if there was less than 5% of disk space available in an active
> filesystem.  My naive belief, probably informed by older and wiser heads
> around Sun, was that when the file system was >95% full, ext2 spent a
> lot of time seeking around in free lists finding single allocatable
> blocks.  And there were no built-in "defragmentation" programs that
> could easily fix that.

This appears to have been inherited from UFS.  My recollection is
pretty much the same for UFS, and even the man page entry for EXT4 is
closely related to UFS newfs(8):

Linux:

       -m reserved-blocks-percentage
              Specify the percentage of the filesystem blocks reserved for
the
              super-user.   This  avoids  fragmentation, and allows
root-owned
              daemons, such as syslogd(8), to continue to  function
 correctly
              after non-privileged processes are prevented from writing to
the
              filesystem.  The default percentage is 5%.

FreBSD:

     -m free-space
             The percentage of space reserved from normal users; the minimum
             free space threshold.  The default value used is defined by
             MINFREE from <ufs/ffs/fs.h>, currently 8%.  See tunefs(8) for
             more details on how to set this option.

And I can confirm that file systems slow down significantly after the
last 1% of free space has been used.

> Is that still a performance constraint in ext4, which has had a few
> decades to work out those edge performance issues?

Hopefully Ted will comment.  But UFS has had even more decades.  And
arguably 600 GB on a modern disk is less of a concern than 15 MB on a
300 MB disk 40 years ago.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Greg A. Woods]

At Thu, 4 Mar 2021 15:27:27 -0600, Will Senn <will.senn@gmail.com> wrote:
Subject: Re: [TUHS] tabs vs spaces - entab, detab
> 
> Wow, mixed tabs and spaces? On purpose? That's nuts :).

In code tabs are for indentation -- one tab per level of indentation.

In code spaces are for alignment -- e.g. to align comments at the end of
the line use spaces between the end of the code and the beginning of the
comment.

(for those of us who use emacs there's smart-tabs-mode -- it's not
perfect, but it helps get these things right the first time around,
i.e. when you don't have "go fmt")

-- 
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

Re: [TUHS] tabs vs spaces - entab, detab

[alan]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

Easy.  Tabs for scope, spaces for everything else - with the later kept
to a minimum.  That eliminates the spaces per tab part of the
discussion. 

For example if a printf is nested in scope, all lines of the same scope
should have the same number of tabs per line.  The continuation of text
for printf arguments on a second line should have the same number of
leading tabs as the printf - then spaces to align the second line where
you want it. 

There should never be any tabs past the initial run at the start of the
line. No exceptions! 

Anyone using spaces to align anything else in the code should be drug in
front of a firing line and shot.  Anyone using ****** ###### /////// or
any other runs of characters in code should be drug in front of a firing
line and shot. 

My $.02 

-A 

On 2021-03-04 11:52, Will Senn wrote:

> OK. So, I've been trying to decide (for the last time, I swear) whether to use tabs or spaces in my code... I did a quick pulse-check on the state of argument and it appears to be alive and well in 2021. My question for y'all is, was there a preference in the very early days or not? I saw an article talking about the 20 year feud, but that's not my recollection. In 1994, nobody agreed on this, but I'm sure it predates my entree into the field. I'm thinking the history of entab and detab are somehow related, but I've been wrong on these sorts of thoughts before. What say you?
> 
> Will

[-- Attachment #2: Type: text/html, Size: 1930 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[alan]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

Of course the sequel to this thread will be to camelCase or not to
camel_case.  Or maybe whether to prefix functions and variable with a
type abbreviation like siCounter for a signed integer counter as if 99%
of people in 2021 are not using an editor that allows quick inspection
of variables and functions.  Maybe we can get to the third act of how to
align braces and parens! 

brb, getting some peanuts, popcorn, and a comfortable seat! 

-A 

P.S. In all seriousness, keep it civil! :) 

On 2021-03-04 11:52, Will Senn wrote:

> OK. So, I've been trying to decide (for the last time, I swear) whether to use tabs or spaces in my code... I did a quick pulse-check on the state of argument and it appears to be alive and well in 2021. My question for y'all is, was there a preference in the very early days or not? I saw an article talking about the 20 year feud, but that's not my recollection. In 1994, nobody agreed on this, but I'm sure it predates my entree into the field. I'm thinking the history of entab and detab are somehow related, but I've been wrong on these sorts of thoughts before. What say you?
> 
> Will

[-- Attachment #2: Type: text/html, Size: 1607 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

Ha. I didn’t intend to reignite a flamewar. I was asking about the history. I got that and more :). But, i’m still curious about entab/detab abd expand, etc. Were they oor some of them created to help with this or what?

Will

Sent from my iPhone

> On Mar 4, 2021, at 7:55 PM, alan@alanlee.org wrote:
> 
> Of course the sequel to this thread will be to camelCase or not to camel_case.  Or maybe whether to prefix functions and variable with a type abbreviation like siCounter for a signed integer counter as if 99% of people in 2021 are not using an editor that allows quick inspection of variables and functions.  Maybe we can get to the third act of how to align braces and parens!
> 
> brb, getting some peanuts, popcorn, and a comfortable seat!
> 
> -A
> 
> P.S. In all seriousness, keep it civil! :)
> 
>> On 2021-03-04 11:52, Will Senn wrote:
>> 
>> OK. So, I've been trying to decide (for the last time, I swear) whether to use tabs or spaces in my code... I did a quick pulse-check on the state of argument and it appears to be alive and well in 2021. My question for y'all is, was there a preference in the very early days or not? I saw an article talking about the 20 year feud, but that's not my recollection. In 1994, nobody agreed on this, but I'm sure it predates my entree into the field. I'm thinking the history of entab and detab are somehow related, but I've been wrong on these sorts of thoughts before. What say you?
>> 
>> Will
> 

[-- Attachment #2: Type: text/html, Size: 2116 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2192 bytes --]

On Thu, Mar 4, 2021 at 9:07 PM Will Senn <will.senn@gmail.com> wrote:

> Ha. I didn’t intend to reignite a flamewar.
>
I warned ya ...  🤔

 But, i’m still curious about entab/detab abd expand, etc. Were they oor
> some of them created to help with this or what?
>
That's probably best for bwk, Ken, or Doug that go back to pre-UNIX times
at BTL.    As was pointed out, bwk had them the SW tools book, so the
need/use go back pretty far.

As someone else pointed out, in the days of printing terminals like the 10
cps horizontal tabs *sometimes* printed faster if they were a mechanical
scheme built into the HW.  On the other hand (and I don't feel like
finding/looking up at an ASR 33 manual), my memory is that it did not have
tabs stops and the UNIX TTY hander expanded them to spaces so even that was
not going to help.  Also as someone else said, in those days we had 132/133
column line printer listing - which again printed >>much<< faster than the
10 cps terminal.   So the 8-space = 1 tab scheme certainly >>might<< make
sense since it was enforced by the HW.

Space was always an issue in the old days, but frankly; again I have no
memory of thinking -- "better use tabs as it will save space in my file" or
that it would process faster since few characters had to be read/written.
I do remember the programs existing, but don't have any memories of ever
using them.

In my own case, I had been taught the golden rule of "use the style that is
already in use" - which I admit, was a hard lesson when I was young I
admit.   But since I was working in those says supporting (assembler) code
that existed, and I was very much the padawan to many great masters, I was
trying to learn.   At some point, I started to work with HLLS on the
PDP-10, as opposed to IBM BAL and I started to

But when I started to learn C, it was strange, since it forced me to accept
'one true bracing style' of the kernel/K&R even if it was different from
what we had been using with BLISS/SAIL/Algol/Pascal from whence I just
come.  But like many people that have finished re-education camps, came to
prefer and anything else ugly and difficult to read.
ᐧ

[-- Attachment #2: Type: text/html, Size: 4222 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

> In my own case, I had been taught the golden rule of "use the style that
> is already in use" - which I admit, was a hard lesson when I was young I
> admit.
>

In my first Unix job (roughly 40 years ago), I read the vi reference manual
and memorized the keystroke commands.  And then did
   % cd /user/include
   % vi *.h
to fix up all the indents and comments.

Later on I graduated to learning not to do control-p on a Vax console a
second time.

What were your mistakes?  ("Always mount a scratch monkey")


In

[-- Attachment #2: Type: text/html, Size: 1032 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Lawrence Stewart]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

I saw the light when my team presented me with a “Larry Stewart, Code Meddler” plaque.
I stopped editing other coders’ style on the spot.

I might have missed the discussion, but when did indent(1) come along?  The interwebs say it was 
in 4.1BSD.

I went through a period thinking that indent with the project standard rules on checkin was a 
reasonable idea, but git at least doesn’t seem very friendly towards that sort of thing.

Left to myself I use no tabs (except in Makefiles) and 2-space per level.  I think the most 
important thing is to maximize the code visible per screenful.  Lower indents permit longer 
identifiers before the dreaded line-wrapping.

> On 2021, Mar 5, at 12:19 PM, Richard Salz <rich.salz@gmail.com> wrote:
> 
> 
> In my own case, I had been taught the golden rule of "use the style that is already in use" - which I admit, was a hard lesson when I was young I admit.
> 
> In my first Unix job (roughly 40 years ago), I read the vi reference manual and memorized the keystroke commands.  And then did 
>    % cd /user/include
>    % vi *.h
> to fix up all the indents and comments.
> 
> Later on I graduated to learning not to do control-p on a Vax console a second time.
> 
> What were your mistakes?  ("Always mount a scratch monkey")
> 
> 
> In


[-- Attachment #2: Type: text/html, Size: 2675 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Dan Halbert]

On 3/5/21 2:39 PM, Lawrence Stewart wrote
> I went through a period thinking that indent with the project standard 
> rules on checkin was a
> reasonable idea, but git at least doesn’t seem very friendly towards 
> that sort of thing.
>
Check out https://pre-commit.com/, which you can use just to check to to 
force a transformation before commit.

Dan H.

Re: [TUHS] tabs vs spaces - entab, detab

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

On 3/5/21 11:08 AM, Clem Cole wrote:
>
>
> On Thu, Mar 4, 2021 at 9:07 PM Will Senn <will.senn@gmail.com 
> <mailto:will.senn@gmail.com>> wrote:
>
>     Ha. I didn’t intend to reignite a flamewar.
>
> I warned ya ... 🤔
>
>      But, i’m still curious about entab/detab abd expand, etc. Were
>     they oor some of them created to help with this or what?
>
> That's probably best for bwk, Ken, or Doug that go back to pre-UNIX 
> times at BTL. As was pointed out, bwk had them the SW tools book, so 
> the need/use go back pretty far.
>
> As someone else pointed out, in the days of printing terminals like 
> the 10 cps horizontal tabs _sometimes_ printed faster if they were a 
> mechanical scheme built into the HW.  On the other hand (and I don't 
> feel like finding/looking up at an ASR 33 manual), my memory is that 
> it did not have tabs stops and the UNIX TTY hander expanded them to 
> spaces so even that was not going to help.  Also as someone else said, 
> in those days we had 132/133 column line printer listing - which again 
> printed >>much<< faster than the 10 cps terminal.   So the 8-space = 1 
> tab scheme certainly >>might<< make sense since it was enforced by the 
> HW.
>
Interesting. I continually forget the hardware that existed back in the 
day. I vaguely remember using line printers, but then it was laser not 
too long after that, so it's pretty fuzzy. My coding days came in the 
dot matrix days, but again laser was not too long after that :). I 
definitely heart 72 character lines - but prolly cuz of email more than 
anything else except maybe the adage of, if it won't fit on screen (in a 
terminal window), it's probably too complicated, which I still think is 
reasonable.
After this thread, I think I'll probably stick to tabs because they seem 
to work better across environments.

Will

[-- Attachment #2: Type: text/html, Size: 4168 bytes --]

Re: [TUHS] tabs vs spaces - entab, detab

[Scot Jenkins via TUHS]

Will Senn <will.senn@gmail.com> wrote:

> OK. So, I've been trying to decide (for the last time, I swear) whether 
> to use tabs or spaces in my code...

Personally, I prefer:
* hard tabs, which display as 8 spaces
* 80 column wide text windows
* "if your code is marching off the right side of the screen, 
  your logic is probably too complex".

The beauty of hard tabs is that the person viewing the code can
choose how to display them in their editor.  If everyone indents
with the Tab character, the problem goes away.

SVR4 vi, BSD nvi, and vim all support the tabstop option:

   tabstop (ts) 8

   Defines number of spaces that a [TAB] indents during editing session.
   (Printer still uses system tab of 8.)

If you prefer 2 space indentation, in vi(1) do ":set ts=2".
If you prefer 4 space indentation, in vi(1) do ":set ts=4".
...
Set your preferred default in ~/.exrc, ~/.nexrc, ~/.vimrc ... 

	set ts=N

to do this automatically.

I'm sure other editors have a similar setting.
Using the Tab key also eliminates the issues in makefiles.

scot

Re: [TUHS] tabs vs spaces - entab, detab

[Bakul Shah]

On Mar 5, 2021, at 8:43 AM, Scot Jenkins via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
> The beauty of hard tabs is that the person viewing the code can
> choose how to display them in their editor.  If everyone indents
> with the Tab character, the problem goes away.

Also works well with variable width fonts. For some strange reason
this is not a popular choice!

Re: [TUHS] tabs vs spaces - entab, detab

[Dave Horsfall]

One place I worked even had their Xterms set to 4 spaces; it caused a lot 
of grief when I imported some software from a previous employer which had 
tabs every 8 spaces (don't ask).

However, I'm now a 4-space person, but with hard tabs set where they are 
supposed to be so I use a mixture of ^T/^D etc.

That said, I also have the view that if your code needs to be indented so 
much then it probably ought to be split out into functions; there's that 
old aphorism about a single page of code...

-- Dave

Re: [TUHS] tabs vs spaces - entab, detab

[Jon Steinhart]

Dave Horsfall writes:
> That said, I also have the view that if your code needs to be indented so 
> much then it probably ought to be split out into functions; there's that 
> old aphorism about a single page of code...

I prefer the aphorism of splitting code out into functions if and
only if it improves readability for people who didn't write the code.

The trouble that I have with many coding ideologies is that it seems
like the goal is some slavish adherence to a rule set instead of
improving readability.

I've coined (at least I think I did) the phrase "meatspace locality of
reference" for talking about this sort of thing.  People go through
great pains to keep executing code "on the same page", for efficiency
but take the opposite approach when making code for people instead of
machines.  Doesn't make sense to me.

Jon

Re: [TUHS] tabs vs spaces - entab, detab

[Larry McVoy]

On Sat, Mar 06, 2021 at 01:01:14PM -0800, Jon Steinhart wrote:
> The trouble that I have with many coding ideologies is that it seems
> like the goal is some slavish adherence to a rule set instead of
> improving readability.

Amen.  I told my team "Optimize for reading, it's write once (or few) and
read many".  Anything that makes the code easier to read is a win even if
it is more work for the writer.

Re: [TUHS] tabs vs spaces - entab, detab

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Sat, Mar 6, 2021 at 4:20 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Sat, Mar 06, 2021 at 01:01:14PM -0800, Jon Steinhart wrote:
> > The trouble that I have with many coding ideologies is that it seems
> > like the goal is some slavish adherence to a rule set instead of
> > improving readability.
>
> Amen.  I told my team "Optimize for reading, it's write once (or few) and
> read many".  Anything that makes the code easier to read is a win even if
> it is more work for the writer.
>
+1
ᐧ

[-- Attachment #2: Type: text/html, Size: 1311 bytes --]

[TUHS] tabs vs spaces - entab, detab

[M Douglas McIlroy]

> The reason to use tab was file size for one

This is urban legend. The percentage of 512-byte blocks that
tabs would save was never significant.

(I agree that tabs and--especially--newlines can significantly
compress fixed-field formats from  punched-card tradition, but
on the tiny Unix systems where tab conventions were
established, big tabular files were very rare.)

Tabs were a convenience for typists. Of course the tty driver
could have replaced them with spaces, but that would have
foreclosed important usage such as tab-separated fields and
run-time-adjustable tab stops tab-separated fields.

(I have run into latter-day trouble with selecting a space-substituted tab
from a screen, only to discover that I was copying or searching for spaces
instead of the tab.. That's not  an intrinsic problem, though. Editors like sam
handle it without fuss.)

Doug

Re: [TUHS] tabs vs spaces - entab, detab

[Greg A. Woods]

At Fri, 5 Mar 2021 11:44:49 -0500, M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu> wrote:
Subject: [TUHS] tabs vs spaces - entab, detab
> 
> > The reason to use tab was file size for one
> 
> This is urban legend. The percentage of 512-byte blocks that
> tabs would save was never significant.

Using tabs to save space was definitely more than an urban legend for
some of us!  (but there is a caveat below)

When I started at UofCalgary we had a PDP-11/60 running 7th Edition
(with about 16 terminals).  It had an RX-02 mounted into the terminal
room wall (the computer room was of course on the other side of the
wall, with a nice big window so we could see the blinken lights (which
are of course very few on an 11/60, but enough to tell when it was most
busy churning the disks).

Students were strongly encouraged to buy 8-1/2" disks at the books store
and off-load anything they were not directly working on at any given
time.  (And when we upgraded to a VAX 11/780 with BSD, disk quotas were
implemented as soon as possible.)

Some of us found that we could fit considerably more data on those disks
if we made sure we used tabs everywhere possible.  We also obviously
learned to have a "clean" target in our makefiles and to be sure to use
it before we archived anything!

However I think we were probably using tar, not a filesystem, on the
floppies so that would of course have been what allowed for greater
savings.  I don't remember many of the details, though I do remember
there was a program to reserve and "lock" the drive, and I think it
changed the ownership of the device file(s) to the user requesting the
reservation.

As for the size of tabs, well I seem to recall students also traded
tabstop setup files for various kinds of terminals so that each could
see code indentations at their own preferred size.  (Maybe this was done
more on the Multics system though, and/or it was in the pre-Vi days when
we used a custom full-screen editor called Fred.)

-- 
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

Re: [TUHS] tabs vs spaces - entab, detab

[Steffen Nurpmeso]

Greg A. Woods wrote in
 <m1lIG8S-0036urC@more.local>:
 |At Fri, 5 Mar 2021 11:44:49 -0500, M Douglas McIlroy <m.douglas.mcilroy@\
 |dartmouth.edu> wrote:
 |Subject: [TUHS] tabs vs spaces - entab, detab
 |> 
 |>> The reason to use tab was file size for one
 |> 
 |> This is urban legend. The percentage of 512-byte blocks that
 |> tabs would save was never significant.
 |
 |Using tabs to save space was definitely more than an urban legend for
 |some of us!  (but there is a caveat below)

That, for example if you have to use 1.44MB floppies for
incremental backups and the project is larger.

But i admit it became fashion of the day at some time.
I had times where functions were separated by two newlines,
modules ((anonymous) namespaces) by three, i had long separators
like ^#+$ for shell/perl and '// -+ //' for C++ etc etc, where the
number backing "+" was dependent upon what it separated.  What
a tremendous waste of space, and was it any clearer.

I am not such a pragmatic person when doing creative work,
especially not when starting from a white paper, well i know it is
hopeless, and did so for a long time indeed, but over and over
again you find yourself longing for the absolute clarity and
perfection (well, surely in a frisky and at the same time
blinkered way), and having a style pigeon-hole belongs to this.
It just grew like that.  There are more important things however,
and i learned (but do not adhere to the conclusion) that what is
really needed is a comment here and there, because if you have to
touch code, then you need to read and at best understand it
anyhow, and then all the above is just noise that is skipped over.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] tabs vs spaces - entab, detab

[Norman Wilson]

I could chip in with my own strong opinions about code formatting,
but I think others have already posted plenty of such boring off-topic
fluff.

A straight answer to Will's original question might be interesting,
though:

The oldest extant UNIX code samples I know are those the TUHS archive,
in Distributions/Research/Dennis_v3/nsys.tar.gz; they're a very old
kernel source tree.  There are plenty of tabs there.

This matches my memories of the V7-era source code, and of what I saw
people like ken and dmr and rob and bwk and pjw typing in the not-
so-early days of the 1980s when I worked with them.

Tabs were generally eight spaces apart.  In code, nobody worried about
the effects on long lines, because the coding style was spare and
didn't run to many deeply-nested constructs, so lines didn't get that
long.  (Maybe it was considered a feature rather than a bug that
deep nesting and deep indentation looked messy, because it wasn't
usually a good idea anyway.)

I can't speak to original motivations, but I suspect my own reasons
for using tabs aren't too different:
-- It's quicker and faster to type than multiple spaces
-- When not at the start of the line, tabs more often preserve
alignment when earlier part of the line are edited
-- Back when terminals were connected at speeds like 110 or 300 bps
(I am old enough to have experienced that, especially when working
from home), letting the system send a tab and the local terminal
expand it was a lot faster, especially when reading code (more likely
to have lots of indentation than prose).  Not every device supported
tabs, but enough did that it made a real difference.

UNIX didn't originate any of this.  I used tabs when writing in FORTRAN
and ALGOL/SIMULA and MACRO-10 on the TOPS-10 system I used before I
encountered UNIX.  So did all the other hackers I knew in the terminal
room where we all hung out.

I don't know the history of entab/detab.  Neither appears to have
been around in the Research systems; they're not in V7 and they're
not in V10.  V7 does.

As an aside, the V10 manual has a single manual page for col, [23456],
mc, fold, and expand.  It's a wonderful example of how gracefully
Doug assembled collections of related small programs onto a single
page to keep the manual size down.  Also of his gift for concise
prose: the first sentence is

These programs rearrange files for appearance's sake.

which is a spot-on but non-stodgy summary.  I wish I could write
half as well as Doug can.

And as an almost-joke, it's a wonder those programs haven't all been
made into options to cat in modern systems.

Norman Wilson
Toronto ON

Re: [TUHS] tabs vs spaces - entab, detab

[Nelson H. F. Beebe]

Here is a link to the 1897 bill of the Indiana State Legislature
that legislated a new value for $\pi$:

	https://journals.iupui.edu/index.php/ias/article/view/4753/4589

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------