* [TUHS] tabs vs spaces - entab, detab @ 2021-03-04 16:52 Will Senn 2021-03-04 16:59 ` Clem Cole ` (6 more replies) 0 siblings, 7 replies; 78+ messages in thread From: Will Senn @ 2021-03-04 16:52 UTC (permalink / raw) To: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 16:52 [TUHS] tabs vs spaces - entab, detab Will Senn @ 2021-03-04 16:59 ` Clem Cole 2021-03-04 18:31 ` arnold 2021-03-04 18:48 ` emanuel stiebler 2021-03-04 18:33 ` John P. Linderman ` (5 subsequent siblings) 6 siblings, 2 replies; 78+ messages in thread From: Clem Cole @ 2021-03-04 16:59 UTC (permalink / raw) To: Will Senn; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 16:59 ` Clem Cole @ 2021-03-04 18:31 ` arnold 2021-03-04 19:23 ` Nemo Nusquam 2021-03-04 18:48 ` emanuel stiebler 1 sibling, 1 reply; 78+ messages in thread From: arnold @ 2021-03-04 18:31 UTC (permalink / raw) To: will.senn, clemc; +Cc: tuhs 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 > > ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 18:31 ` arnold @ 2021-03-04 19:23 ` Nemo Nusquam 2021-03-04 19:37 ` Steve Nickolas 0 siblings, 1 reply; 78+ messages in thread From: Nemo Nusquam @ 2021-03-04 19:23 UTC (permalink / raw) To: tuhs 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 19:23 ` Nemo Nusquam @ 2021-03-04 19:37 ` Steve Nickolas 2021-03-04 19:50 ` Rob Pike 0 siblings, 1 reply; 78+ messages in thread From: Steve Nickolas @ 2021-03-04 19:37 UTC (permalink / raw) To: tuhs 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 19:37 ` Steve Nickolas @ 2021-03-04 19:50 ` Rob Pike 2021-03-04 21:20 ` Robert Clausecker 2021-03-04 21:25 ` Will Senn 0 siblings, 2 replies; 78+ messages in thread From: Rob Pike @ 2021-03-04 19:50 UTC (permalink / raw) To: Steve Nickolas; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 19:50 ` Rob Pike @ 2021-03-04 21:20 ` Robert Clausecker 2021-03-04 21:25 ` Will Senn 1 sibling, 0 replies; 78+ messages in thread From: Robert Clausecker @ 2021-03-04 21:20 UTC (permalink / raw) To: tuhs 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 19:50 ` Rob Pike 2021-03-04 21:20 ` Robert Clausecker @ 2021-03-04 21:25 ` Will Senn 2021-03-05 9:58 ` John Gilmore 1 sibling, 1 reply; 78+ messages in thread From: Will Senn @ 2021-03-04 21:25 UTC (permalink / raw) To: Rob Pike, Steve Nickolas; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 21:25 ` Will Senn @ 2021-03-05 9:58 ` John Gilmore 2021-03-06 21:31 ` Dave Horsfall 0 siblings, 1 reply; 78+ messages in thread From: John Gilmore @ 2021-03-05 9:58 UTC (permalink / raw) To: Will Senn; +Cc: TUHS main list 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 9:58 ` John Gilmore @ 2021-03-06 21:31 ` Dave Horsfall 2021-03-06 21:38 ` Larry McVoy 2021-03-06 21:40 ` Steve Nickolas 0 siblings, 2 replies; 78+ messages in thread From: Dave Horsfall @ 2021-03-06 21:31 UTC (permalink / raw) To: The Eunuchs Hysterical Society (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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 21:31 ` Dave Horsfall @ 2021-03-06 21:38 ` Larry McVoy 2021-03-06 22:05 ` Clem Cole 2021-03-06 21:40 ` Steve Nickolas 1 sibling, 1 reply; 78+ messages in thread From: Larry McVoy @ 2021-03-06 21:38 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 21:38 ` Larry McVoy @ 2021-03-06 22:05 ` Clem Cole 2021-03-15 3:02 ` John Cowan 0 siblings, 1 reply; 78+ messages in thread From: Clem Cole @ 2021-03-06 22:05 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 22:05 ` Clem Cole @ 2021-03-15 3:02 ` John Cowan 2021-03-15 18:15 ` Steffen Nurpmeso ` (2 more replies) 0 siblings, 3 replies; 78+ messages in thread From: John Cowan @ 2021-03-15 3:02 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 3:02 ` John Cowan @ 2021-03-15 18:15 ` Steffen Nurpmeso 2021-03-15 21:19 ` Bakul Shah 2021-03-15 21:08 ` Dave Horsfall 2021-03-17 5:10 ` Greg 'groggy' Lehey 2 siblings, 1 reply; 78+ messages in thread From: Steffen Nurpmeso @ 2021-03-15 18:15 UTC (permalink / raw) To: John Cowan; +Cc: The Eunuchs Hysterical Society 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) ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 18:15 ` Steffen Nurpmeso @ 2021-03-15 21:19 ` Bakul Shah 2021-03-15 23:47 ` Steffen Nurpmeso 0 siblings, 1 reply; 78+ messages in thread From: Bakul Shah @ 2021-03-15 21:19 UTC (permalink / raw) To: Steffen Nurpmeso; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 21:19 ` Bakul Shah @ 2021-03-15 23:47 ` Steffen Nurpmeso 2021-03-16 3:10 ` Earl Baugh 0 siblings, 1 reply; 78+ messages in thread From: Steffen Nurpmeso @ 2021-03-15 23:47 UTC (permalink / raw) To: Bakul Shah; +Cc: The Eunuchs Hysterical Society 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) ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 23:47 ` Steffen Nurpmeso @ 2021-03-16 3:10 ` Earl Baugh 0 siblings, 0 replies; 78+ messages in thread From: Earl Baugh @ 2021-03-16 3:10 UTC (permalink / raw) To: Steffen Nurpmeso; +Cc: The Eunuchs Hysterical Society, Bakul Shah 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) ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 3:02 ` John Cowan 2021-03-15 18:15 ` Steffen Nurpmeso @ 2021-03-15 21:08 ` Dave Horsfall 2021-03-15 21:12 ` Steve Nickolas 2021-03-17 5:10 ` Greg 'groggy' Lehey 2 siblings, 1 reply; 78+ messages in thread From: Dave Horsfall @ 2021-03-15 21:08 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 21:08 ` Dave Horsfall @ 2021-03-15 21:12 ` Steve Nickolas 2021-03-15 21:24 ` Dave Horsfall 0 siblings, 1 reply; 78+ messages in thread From: Steve Nickolas @ 2021-03-15 21:12 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 21:12 ` Steve Nickolas @ 2021-03-15 21:24 ` Dave Horsfall 2021-03-15 22:06 ` Adam Thornton 2021-03-16 13:25 ` arnold 0 siblings, 2 replies; 78+ messages in thread From: Dave Horsfall @ 2021-03-15 21:24 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 21:24 ` Dave Horsfall @ 2021-03-15 22:06 ` Adam Thornton 2021-03-16 13:25 ` arnold 1 sibling, 0 replies; 78+ messages in thread From: Adam Thornton @ 2021-03-15 22:06 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 21:24 ` Dave Horsfall 2021-03-15 22:06 ` Adam Thornton @ 2021-03-16 13:25 ` arnold 1 sibling, 0 replies; 78+ messages in thread From: arnold @ 2021-03-16 13:25 UTC (permalink / raw) To: tuhs, dave 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-15 3:02 ` John Cowan 2021-03-15 18:15 ` Steffen Nurpmeso 2021-03-15 21:08 ` Dave Horsfall @ 2021-03-17 5:10 ` Greg 'groggy' Lehey 2 siblings, 0 replies; 78+ messages in thread From: Greg 'groggy' Lehey @ 2021-03-17 5:10 UTC (permalink / raw) To: John Cowan; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 21:31 ` Dave Horsfall 2021-03-06 21:38 ` Larry McVoy @ 2021-03-06 21:40 ` Steve Nickolas 1 sibling, 0 replies; 78+ messages in thread From: Steve Nickolas @ 2021-03-06 21:40 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 16:59 ` Clem Cole 2021-03-04 18:31 ` arnold @ 2021-03-04 18:48 ` emanuel stiebler 2021-03-05 0:44 ` John Cowan 1 sibling, 1 reply; 78+ messages in thread From: emanuel stiebler @ 2021-03-04 18:48 UTC (permalink / raw) To: Clem Cole, Will Senn; +Cc: TUHS main list 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 ;-) ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 18:48 ` emanuel stiebler @ 2021-03-05 0:44 ` John Cowan 2021-03-05 0:55 ` Larry McVoy 0 siblings, 1 reply; 78+ messages in thread From: John Cowan @ 2021-03-05 0:44 UTC (permalink / raw) To: emanuel stiebler; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 0:44 ` John Cowan @ 2021-03-05 0:55 ` Larry McVoy 2021-03-05 1:09 ` George Michaelson 0 siblings, 1 reply; 78+ messages in thread From: Larry McVoy @ 2021-03-05 0:55 UTC (permalink / raw) To: John Cowan; +Cc: TUHS main list 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); } ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 0:55 ` Larry McVoy @ 2021-03-05 1:09 ` George Michaelson 2021-03-05 1:21 ` Larry McVoy 0 siblings, 1 reply; 78+ messages in thread From: George Michaelson @ 2021-03-05 1:09 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list 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); > } ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 1:09 ` George Michaelson @ 2021-03-05 1:21 ` Larry McVoy 2021-03-05 1:29 ` Richard Salz 0 siblings, 1 reply; 78+ messages in thread From: Larry McVoy @ 2021-03-05 1:21 UTC (permalink / raw) To: George Michaelson; +Cc: TUHS main list 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 1:21 ` Larry McVoy @ 2021-03-05 1:29 ` Richard Salz 0 siblings, 0 replies; 78+ messages in thread From: Richard Salz @ 2021-03-05 1:29 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 16:52 [TUHS] tabs vs spaces - entab, detab Will Senn 2021-03-04 16:59 ` Clem Cole @ 2021-03-04 18:33 ` John P. Linderman 2021-03-04 21:24 ` Greg 'groggy' Lehey ` (4 subsequent siblings) 6 siblings, 0 replies; 78+ messages in thread From: John P. Linderman @ 2021-03-04 18:33 UTC (permalink / raw) To: Will Senn; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 16:52 [TUHS] tabs vs spaces - entab, detab Will Senn 2021-03-04 16:59 ` Clem Cole 2021-03-04 18:33 ` John P. Linderman @ 2021-03-04 21:24 ` Greg 'groggy' Lehey 2021-03-04 21:27 ` Will Senn 2021-03-05 1:41 ` alan ` (3 subsequent siblings) 6 siblings, 1 reply; 78+ messages in thread From: Greg 'groggy' Lehey @ 2021-03-04 21:24 UTC (permalink / raw) To: Will Senn; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 21:24 ` Greg 'groggy' Lehey @ 2021-03-04 21:27 ` Will Senn 2021-03-04 21:29 ` Greg 'groggy' Lehey 2021-03-04 22:10 ` [TUHS] tabs vs spaces - entab, detab Greg A. Woods 0 siblings, 2 replies; 78+ messages in thread From: Will Senn @ 2021-03-04 21:27 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: TUHS main list 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 :). ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 21:27 ` Will Senn @ 2021-03-04 21:29 ` Greg 'groggy' Lehey 2021-03-04 21:42 ` Will Senn 2021-03-04 21:48 ` John P. Linderman 2021-03-04 22:10 ` [TUHS] tabs vs spaces - entab, detab Greg A. Woods 1 sibling, 2 replies; 78+ messages in thread From: Greg 'groggy' Lehey @ 2021-03-04 21:29 UTC (permalink / raw) To: Will Senn; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 21:29 ` Greg 'groggy' Lehey @ 2021-03-04 21:42 ` Will Senn 2021-03-04 21:48 ` John P. Linderman 1 sibling, 0 replies; 78+ messages in thread From: Will Senn @ 2021-03-04 21:42 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: TUHS main list 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 21:29 ` Greg 'groggy' Lehey 2021-03-04 21:42 ` Will Senn @ 2021-03-04 21:48 ` John P. Linderman 2021-03-04 22:08 ` Andy Kosela 2021-03-05 9:50 ` [TUHS] tunefs -m 5% John Gilmore 1 sibling, 2 replies; 78+ messages in thread From: John P. Linderman @ 2021-03-04 21:48 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 21:48 ` John P. Linderman @ 2021-03-04 22:08 ` Andy Kosela 2021-03-04 22:12 ` Greg 'groggy' Lehey ` (2 more replies) 2021-03-05 9:50 ` [TUHS] tunefs -m 5% John Gilmore 1 sibling, 3 replies; 78+ messages in thread From: Andy Kosela @ 2021-03-04 22:08 UTC (permalink / raw) To: John P. Linderman; +Cc: TUHS main list 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 22:08 ` Andy Kosela @ 2021-03-04 22:12 ` Greg 'groggy' Lehey 2021-03-05 14:13 ` Steffen Nurpmeso 2021-03-05 0:15 ` Jon Steinhart 2021-03-06 21:22 ` Dave Horsfall 2 siblings, 1 reply; 78+ messages in thread From: Greg 'groggy' Lehey @ 2021-03-04 22:12 UTC (permalink / raw) To: Andy Kosela; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 22:12 ` Greg 'groggy' Lehey @ 2021-03-05 14:13 ` Steffen Nurpmeso 2021-03-05 20:24 ` John Cowan 0 siblings, 1 reply; 78+ messages in thread From: Steffen Nurpmeso @ 2021-03-05 14:13 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: TUHS main list 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) ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 14:13 ` Steffen Nurpmeso @ 2021-03-05 20:24 ` John Cowan 2021-03-05 21:51 ` Bakul Shah 2021-03-06 23:43 ` Steffen Nurpmeso 0 siblings, 2 replies; 78+ messages in thread From: John Cowan @ 2021-03-05 20:24 UTC (permalink / raw) To: Greg 'groggy' Lehey, Andy Kosela, TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 20:24 ` John Cowan @ 2021-03-05 21:51 ` Bakul Shah 2021-03-06 23:43 ` Steffen Nurpmeso 1 sibling, 0 replies; 78+ messages in thread From: Bakul Shah @ 2021-03-05 21:51 UTC (permalink / raw) To: John Cowan; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 20:24 ` John Cowan 2021-03-05 21:51 ` Bakul Shah @ 2021-03-06 23:43 ` Steffen Nurpmeso 1 sibling, 0 replies; 78+ messages in thread From: Steffen Nurpmeso @ 2021-03-06 23:43 UTC (permalink / raw) To: John Cowan; +Cc: TUHS main list 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) ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 22:08 ` Andy Kosela 2021-03-04 22:12 ` Greg 'groggy' Lehey @ 2021-03-05 0:15 ` Jon Steinhart 2021-03-06 21:22 ` Dave Horsfall 2 siblings, 0 replies; 78+ messages in thread From: Jon Steinhart @ 2021-03-05 0:15 UTC (permalink / raw) To: TUHS main list 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 22:08 ` Andy Kosela 2021-03-04 22:12 ` Greg 'groggy' Lehey 2021-03-05 0:15 ` Jon Steinhart @ 2021-03-06 21:22 ` Dave Horsfall 2021-03-06 23:58 ` Bakul Shah 2 siblings, 1 reply; 78+ messages in thread From: Dave Horsfall @ 2021-03-06 21:22 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 21:22 ` Dave Horsfall @ 2021-03-06 23:58 ` Bakul Shah 2021-03-07 0:03 ` Jon Steinhart ` (2 more replies) 0 siblings, 3 replies; 78+ messages in thread From: Bakul Shah @ 2021-03-06 23:58 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 23:58 ` Bakul Shah @ 2021-03-07 0:03 ` Jon Steinhart 2021-03-07 0:25 ` Steve Nickolas 2021-03-07 9:16 ` Brantley Coile 2 siblings, 0 replies; 78+ messages in thread From: Jon Steinhart @ 2021-03-07 0:03 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 23:58 ` Bakul Shah 2021-03-07 0:03 ` Jon Steinhart @ 2021-03-07 0:25 ` Steve Nickolas 2021-03-07 9:16 ` Brantley Coile 2 siblings, 0 replies; 78+ messages in thread From: Steve Nickolas @ 2021-03-07 0:25 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 23:58 ` Bakul Shah 2021-03-07 0:03 ` Jon Steinhart 2021-03-07 0:25 ` Steve Nickolas @ 2021-03-07 9:16 ` Brantley Coile 2 siblings, 0 replies; 78+ messages in thread From: Brantley Coile @ 2021-03-07 9:16 UTC (permalink / raw) To: Bakul Shah; +Cc: The Eunuchs Hysterical Society 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? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-04 21:48 ` John P. Linderman 2021-03-04 22:08 ` Andy Kosela @ 2021-03-05 9:50 ` John Gilmore 2021-03-05 15:01 ` Grant Taylor via TUHS ` (2 more replies) 1 sibling, 3 replies; 78+ messages in thread From: John Gilmore @ 2021-03-05 9:50 UTC (permalink / raw) To: John P. Linderman; +Cc: TUHS main list 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-05 9:50 ` [TUHS] tunefs -m 5% John Gilmore @ 2021-03-05 15:01 ` Grant Taylor via TUHS 2021-03-05 15:32 ` Theodore Ts'o 2021-03-06 1:16 ` Greg 'groggy' Lehey 2 siblings, 0 replies; 78+ messages in thread From: Grant Taylor via TUHS @ 2021-03-05 15:01 UTC (permalink / raw) To: 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-05 9:50 ` [TUHS] tunefs -m 5% John Gilmore 2021-03-05 15:01 ` Grant Taylor via TUHS @ 2021-03-05 15:32 ` Theodore Ts'o 2021-03-06 1:18 ` Greg 'groggy' Lehey 2021-03-06 1:16 ` Greg 'groggy' Lehey 2 siblings, 1 reply; 78+ messages in thread From: Theodore Ts'o @ 2021-03-05 15:32 UTC (permalink / raw) To: John Gilmore; +Cc: TUHS main list 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-05 15:32 ` Theodore Ts'o @ 2021-03-06 1:18 ` Greg 'groggy' Lehey 2021-03-06 1:52 ` Warner Losh 0 siblings, 1 reply; 78+ messages in thread From: Greg 'groggy' Lehey @ 2021-03-06 1:18 UTC (permalink / raw) To: Theodore Ts'o; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-06 1:18 ` Greg 'groggy' Lehey @ 2021-03-06 1:52 ` Warner Losh 2021-03-06 21:45 ` Dave Horsfall 0 siblings, 1 reply; 78+ messages in thread From: Warner Losh @ 2021-03-06 1:52 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-06 1:52 ` Warner Losh @ 2021-03-06 21:45 ` Dave Horsfall 2021-03-06 22:03 ` Larry McVoy 2021-03-06 23:52 ` David Barto 0 siblings, 2 replies; 78+ messages in thread From: Dave Horsfall @ 2021-03-06 21:45 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-06 21:45 ` Dave Horsfall @ 2021-03-06 22:03 ` Larry McVoy 2021-03-09 4:59 ` Greg 'groggy' Lehey 2021-03-06 23:52 ` David Barto 1 sibling, 1 reply; 78+ messages in thread From: Larry McVoy @ 2021-03-06 22:03 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-06 22:03 ` Larry McVoy @ 2021-03-09 4:59 ` Greg 'groggy' Lehey 0 siblings, 0 replies; 78+ messages in thread From: Greg 'groggy' Lehey @ 2021-03-09 4:59 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-06 21:45 ` Dave Horsfall 2021-03-06 22:03 ` Larry McVoy @ 2021-03-06 23:52 ` David Barto 1 sibling, 0 replies; 78+ messages in thread From: David Barto @ 2021-03-06 23:52 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society > 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tunefs -m 5% 2021-03-05 9:50 ` [TUHS] tunefs -m 5% John Gilmore 2021-03-05 15:01 ` Grant Taylor via TUHS 2021-03-05 15:32 ` Theodore Ts'o @ 2021-03-06 1:16 ` Greg 'groggy' Lehey 2 siblings, 0 replies; 78+ messages in thread From: Greg 'groggy' Lehey @ 2021-03-06 1:16 UTC (permalink / raw) To: John Gilmore; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 21:27 ` Will Senn 2021-03-04 21:29 ` Greg 'groggy' Lehey @ 2021-03-04 22:10 ` Greg A. Woods 1 sibling, 0 replies; 78+ messages in thread From: Greg A. Woods @ 2021-03-04 22:10 UTC (permalink / raw) To: The Unix Heritage Society mailing list 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 16:52 [TUHS] tabs vs spaces - entab, detab Will Senn ` (2 preceding siblings ...) 2021-03-04 21:24 ` Greg 'groggy' Lehey @ 2021-03-05 1:41 ` alan 2021-03-05 1:55 ` alan ` (2 subsequent siblings) 6 siblings, 0 replies; 78+ messages in thread From: alan @ 2021-03-05 1:41 UTC (permalink / raw) To: Will Senn; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 16:52 [TUHS] tabs vs spaces - entab, detab Will Senn ` (3 preceding siblings ...) 2021-03-05 1:41 ` alan @ 2021-03-05 1:55 ` alan 2021-03-05 2:06 ` Will Senn 2021-03-05 16:43 ` Scot Jenkins via TUHS 2021-03-06 20:51 ` Dave Horsfall 6 siblings, 1 reply; 78+ messages in thread From: alan @ 2021-03-05 1:55 UTC (permalink / raw) To: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 1:55 ` alan @ 2021-03-05 2:06 ` Will Senn 2021-03-05 17:08 ` Clem Cole 0 siblings, 1 reply; 78+ messages in thread From: Will Senn @ 2021-03-05 2:06 UTC (permalink / raw) To: alan; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 2:06 ` Will Senn @ 2021-03-05 17:08 ` Clem Cole 2021-03-05 17:19 ` Richard Salz 2021-03-08 1:52 ` Will Senn 0 siblings, 2 replies; 78+ messages in thread From: Clem Cole @ 2021-03-05 17:08 UTC (permalink / raw) To: Will Senn; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 17:08 ` Clem Cole @ 2021-03-05 17:19 ` Richard Salz 2021-03-05 19:39 ` Lawrence Stewart 2021-03-08 1:52 ` Will Senn 1 sibling, 1 reply; 78+ messages in thread From: Richard Salz @ 2021-03-05 17:19 UTC (permalink / raw) To: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 17:19 ` Richard Salz @ 2021-03-05 19:39 ` Lawrence Stewart 2021-03-05 19:51 ` Dan Halbert 0 siblings, 1 reply; 78+ messages in thread From: Lawrence Stewart @ 2021-03-05 19:39 UTC (permalink / raw) To: Richard Salz; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 19:39 ` Lawrence Stewart @ 2021-03-05 19:51 ` Dan Halbert 0 siblings, 0 replies; 78+ messages in thread From: Dan Halbert @ 2021-03-05 19:51 UTC (permalink / raw) To: tuhs 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 17:08 ` Clem Cole 2021-03-05 17:19 ` Richard Salz @ 2021-03-08 1:52 ` Will Senn 1 sibling, 0 replies; 78+ messages in thread From: Will Senn @ 2021-03-08 1:52 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 16:52 [TUHS] tabs vs spaces - entab, detab Will Senn ` (4 preceding siblings ...) 2021-03-05 1:55 ` alan @ 2021-03-05 16:43 ` Scot Jenkins via TUHS 2021-03-05 22:23 ` Bakul Shah 2021-03-06 20:51 ` Dave Horsfall 6 siblings, 1 reply; 78+ messages in thread From: Scot Jenkins via TUHS @ 2021-03-05 16:43 UTC (permalink / raw) To: will.senn, 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 16:43 ` Scot Jenkins via TUHS @ 2021-03-05 22:23 ` Bakul Shah 0 siblings, 0 replies; 78+ messages in thread From: Bakul Shah @ 2021-03-05 22:23 UTC (permalink / raw) To: Scot Jenkins; +Cc: TUHS main list 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! ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-04 16:52 [TUHS] tabs vs spaces - entab, detab Will Senn ` (5 preceding siblings ...) 2021-03-05 16:43 ` Scot Jenkins via TUHS @ 2021-03-06 20:51 ` Dave Horsfall 2021-03-06 21:01 ` Jon Steinhart 6 siblings, 1 reply; 78+ messages in thread From: Dave Horsfall @ 2021-03-06 20:51 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 20:51 ` Dave Horsfall @ 2021-03-06 21:01 ` Jon Steinhart 2021-03-06 21:19 ` Larry McVoy 0 siblings, 1 reply; 78+ messages in thread From: Jon Steinhart @ 2021-03-06 21:01 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 21:01 ` Jon Steinhart @ 2021-03-06 21:19 ` Larry McVoy 2021-03-06 22:01 ` Clem Cole 0 siblings, 1 reply; 78+ messages in thread From: Larry McVoy @ 2021-03-06 21:19 UTC (permalink / raw) To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-06 21:19 ` Larry McVoy @ 2021-03-06 22:01 ` Clem Cole 0 siblings, 0 replies; 78+ messages in thread From: Clem Cole @ 2021-03-06 22:01 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* [TUHS] tabs vs spaces - entab, detab
@ 2021-03-05 16:44 M Douglas McIlroy
2021-03-05 19:29 ` Greg A. Woods
0 siblings, 1 reply; 78+ messages in thread
From: M Douglas McIlroy @ 2021-03-05 16:44 UTC (permalink / raw)
To: tuhs
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 16:44 M Douglas McIlroy @ 2021-03-05 19:29 ` Greg A. Woods 2021-03-06 23:21 ` Steffen Nurpmeso 0 siblings, 1 reply; 78+ messages in thread From: Greg A. Woods @ 2021-03-05 19:29 UTC (permalink / raw) To: The Unix Heritage Society mailing list 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab 2021-03-05 19:29 ` Greg A. Woods @ 2021-03-06 23:21 ` Steffen Nurpmeso 0 siblings, 0 replies; 78+ messages in thread From: Steffen Nurpmeso @ 2021-03-06 23:21 UTC (permalink / raw) To: The Unix Heritage Society mailing list 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) ^ permalink raw reply [flat|nested] 78+ messages in thread
* [TUHS] tabs vs spaces - entab, detab @ 2021-03-05 22:50 Norman Wilson 0 siblings, 0 replies; 78+ messages in thread From: Norman Wilson @ 2021-03-05 22:50 UTC (permalink / raw) To: tuhs 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [TUHS] tabs vs spaces - entab, detab @ 2021-03-07 2:53 Nelson H. F. Beebe 0 siblings, 0 replies; 78+ messages in thread From: Nelson H. F. Beebe @ 2021-03-07 2:53 UTC (permalink / raw) To: tuhs 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/ - ------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 78+ messages in thread
end of thread, other threads:[~2021-03-17 5:11 UTC | newest] Thread overview: 78+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-04 16:52 [TUHS] tabs vs spaces - entab, detab Will Senn 2021-03-04 16:59 ` Clem Cole 2021-03-04 18:31 ` arnold 2021-03-04 19:23 ` Nemo Nusquam 2021-03-04 19:37 ` Steve Nickolas 2021-03-04 19:50 ` Rob Pike 2021-03-04 21:20 ` Robert Clausecker 2021-03-04 21:25 ` Will Senn 2021-03-05 9:58 ` John Gilmore 2021-03-06 21:31 ` Dave Horsfall 2021-03-06 21:38 ` Larry McVoy 2021-03-06 22:05 ` Clem Cole 2021-03-15 3:02 ` John Cowan 2021-03-15 18:15 ` Steffen Nurpmeso 2021-03-15 21:19 ` Bakul Shah 2021-03-15 23:47 ` Steffen Nurpmeso 2021-03-16 3:10 ` Earl Baugh 2021-03-15 21:08 ` Dave Horsfall 2021-03-15 21:12 ` Steve Nickolas 2021-03-15 21:24 ` Dave Horsfall 2021-03-15 22:06 ` Adam Thornton 2021-03-16 13:25 ` arnold 2021-03-17 5:10 ` Greg 'groggy' Lehey 2021-03-06 21:40 ` Steve Nickolas 2021-03-04 18:48 ` emanuel stiebler 2021-03-05 0:44 ` John Cowan 2021-03-05 0:55 ` Larry McVoy 2021-03-05 1:09 ` George Michaelson 2021-03-05 1:21 ` Larry McVoy 2021-03-05 1:29 ` Richard Salz 2021-03-04 18:33 ` John P. Linderman 2021-03-04 21:24 ` Greg 'groggy' Lehey 2021-03-04 21:27 ` Will Senn 2021-03-04 21:29 ` Greg 'groggy' Lehey 2021-03-04 21:42 ` Will Senn 2021-03-04 21:48 ` John P. Linderman 2021-03-04 22:08 ` Andy Kosela 2021-03-04 22:12 ` Greg 'groggy' Lehey 2021-03-05 14:13 ` Steffen Nurpmeso 2021-03-05 20:24 ` John Cowan 2021-03-05 21:51 ` Bakul Shah 2021-03-06 23:43 ` Steffen Nurpmeso 2021-03-05 0:15 ` Jon Steinhart 2021-03-06 21:22 ` Dave Horsfall 2021-03-06 23:58 ` Bakul Shah 2021-03-07 0:03 ` Jon Steinhart 2021-03-07 0:25 ` Steve Nickolas 2021-03-07 9:16 ` Brantley Coile 2021-03-05 9:50 ` [TUHS] tunefs -m 5% John Gilmore 2021-03-05 15:01 ` Grant Taylor via TUHS 2021-03-05 15:32 ` Theodore Ts'o 2021-03-06 1:18 ` Greg 'groggy' Lehey 2021-03-06 1:52 ` Warner Losh 2021-03-06 21:45 ` Dave Horsfall 2021-03-06 22:03 ` Larry McVoy 2021-03-09 4:59 ` Greg 'groggy' Lehey 2021-03-06 23:52 ` David Barto 2021-03-06 1:16 ` Greg 'groggy' Lehey 2021-03-04 22:10 ` [TUHS] tabs vs spaces - entab, detab Greg A. Woods 2021-03-05 1:41 ` alan 2021-03-05 1:55 ` alan 2021-03-05 2:06 ` Will Senn 2021-03-05 17:08 ` Clem Cole 2021-03-05 17:19 ` Richard Salz 2021-03-05 19:39 ` Lawrence Stewart 2021-03-05 19:51 ` Dan Halbert 2021-03-08 1:52 ` Will Senn 2021-03-05 16:43 ` Scot Jenkins via TUHS 2021-03-05 22:23 ` Bakul Shah 2021-03-06 20:51 ` Dave Horsfall 2021-03-06 21:01 ` Jon Steinhart 2021-03-06 21:19 ` Larry McVoy 2021-03-06 22:01 ` Clem Cole 2021-03-05 16:44 M Douglas McIlroy 2021-03-05 19:29 ` Greg A. Woods 2021-03-06 23:21 ` Steffen Nurpmeso 2021-03-05 22:50 Norman Wilson 2021-03-07 2:53 Nelson H. F. Beebe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).