[-- 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 --]
[-- 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 --]
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 > >
[-- 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 --]
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
;-)
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.
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.
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
[-- 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 --]
[-- 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 --]
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 :).
[-- 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 --]
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.
[-- 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 --]
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
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>
[-- 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 --]
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
[-- 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 --]
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);
}
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);
> }
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.
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
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
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)
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
> 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
[-- 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 --]
[-- 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 --]
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>
[-- 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 --]
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.
[-- 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 --]
[-- 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 --]
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!
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
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
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
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.
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
(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
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.
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.
[-- 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 --]
[-- 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 --]
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)
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)
[-- 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 --]
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.
[-- 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.
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/ - -------------------------------------------------------------------------------
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?
[-- 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 --]
[-- 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 --]
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)
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
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.
[-- 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 --]
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 #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 --]
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)
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)
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
[-- 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 --]