From grog at lemis.com Sun Jul 20 10:36:09 2025 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 20 Jul 2025 10:36:09 +1000 Subject: [COFF] Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: [Somewhat off-topic for TUHS; please follow up at COFF] On Saturday, 19 July 2025 at 17:37:34 -0600, Warner Losh wrote: > > Also, there are no GUI emacs versions I like.. You have me curious. How many do you know? And what don't you like about them, when you clearly use Emacs? Greg -- Sent from my desktop computer. Finger grog at 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From imp at bsdimp.com Sun Jul 20 11:27:40 2025 From: imp at bsdimp.com (Warner Losh) Date: Sat, 19 Jul 2025 19:27:40 -0600 Subject: [COFF] Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: On Sat, Jul 19, 2025 at 6:36 PM Greg 'groggy' Lehey wrote: > > [Somewhat off-topic for TUHS; please follow up at COFF] > > On Saturday, 19 July 2025 at 17:37:34 -0600, Warner Losh wrote: > > > > Also, there are no GUI emacs versions I like.. > > You have me curious. How many do you know? And what don't you like > about them, when you clearly use Emacs? Most of the emacs GUI adaptations assume that it's THE instance of the editor. With multiple terminals, I can have multiple editors with different contexts. With the GUI, it all gets dumped together. It may just be an odd quirk of when I grew up and always having job control and just always using that all the way back to the 4.2BSD Vax 11/750 days. Warner > Greg > -- > Sent from my desktop computer. > Finger grog at 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.php From will.senn at gmail.com Sun Jul 20 23:52:09 2025 From: will.senn at gmail.com (Will Senn) Date: Sun, 20 Jul 2025 08:52:09 -0500 Subject: [COFF] editor wars Message-ID: I remember having discussions about vi vs emacs in the mid 1990's. I'm curious if those were the first public wars about editors, or if y'all remember earlier flamewars on the subject? Maybe KEDIT vs EDIT?  I grew up on DOS, so edlin vs edit was quite the battle ground in discussions, but I don't remember flames... I find the vi/emacs divide quite insurmountable. As a vi guy, I cannot even understand emac's appeal. I've tried countless times, even going emacs only for a while... when I went back to vi, it was like old shoes, very comfortable. I didn't get the flamewar at all - you do you... but I did and still do find the passion on either side endlessly fascinating. Two other debates are quite similar - one to do with spaces vs tabs, the other top-posting vs bottom-posting have provided me with hours of entertainment... I prefer tabs over spaces and top-posting, but I get the other points of view on these... Will From clemc at ccc.com Mon Jul 21 01:25:25 2025 From: clemc at ccc.com (Clem Cole) Date: Sun, 20 Jul 2025 11:25:25 -0400 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: On Sun, Jul 20, 2025 at 9:52 AM Will Senn wrote: > I remember having discussions about vi vs emacs in the mid 1990's. I'm > curious if those were the first public wars about editors, or if y'all > remember earlier flamewars on the subject? Maybe KEDIT vs EDIT? > Hmm I don't think it was really a new thing, as I think the UNIX and VMS editor wars occurred long after earlier conflicts. Hey, even UNIX had way more than just ex/vi and emacs. There was the Rand Editor and Fred, to name two others, who were popular in the early PDP-11 UNIX days. Also, remember that for the early DEC PDPs 1/6/10 machines, there were Stopgap, SonOfStopgap (*a.k.a.* SOS - which became DEC's EDIT), Teco, and eventually EMACS [remember UNIX emacs is a clone of the original TOPS-10/ITS EMACS]; and probably others that I am forgetting - those the ones I used in PDP-10 days. In fact, I learned Emacs on the PDP-10, but neither Gosling nor Zimmerman had yet written their C versions. I used Fred as my first video editor on UNIX and did not learn ex(1) until a few years later, when I was at Tektronix, as it was not available on the CMU systems. By the time EMACS arrived (and required a 32-bit system), I was fluent with it and never bothered to go back. I'll also note that the PDP-8 and PDP-11 families had their own set of editors, and that was just in the DEC world. The IBM world was really not any different. Any interactive system needs an editor. In all cases, the line editors were first because that was what you could use with a Teletype Model 28 and later Model 33 ASR or a Friden (Singer/Link) Flexowriter. With the advent of the "glass tty," the editor wars took on new life as several editors emerged on different systems.. As I said, UNIX had a number before ex/vi. The Rand Editor was the most widely used in the UNIX world early on. [ I don't remember why we used Cornell's Fred over the Rand Editor at CMU in those days, but I know we had both]. To make matters worse, until UNIX came along, the concept of file types and "access methods" was fairly well ingrained in those systems. So features like embedded line numbers (or not) would get into the war. The DEC PDP 1/6/10 Stopgap family added line numbers that compilers and other tools were aware of. IBM ISAM files did the same thing, which is how we sometimes prepared our source code TSS, as you could create card images from ISAM file easily. At the time, I remember there were arguments about needing line numbers or not. A dirty secret about me, I turn on line numbers in vi, because I often find it faster to refer to things that way. That is probably because I learned the TSS editor first on the IBM 360 and then used SOS on TOPS, all before I started using Unix. So when I did, I learned to use ed(1) with its dynamic line numbering and never stopped, even when vi mode showed up in ex(1). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Mon Jul 21 01:43:10 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 20 Jul 2025 11:43:10 -0400 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: On Sun, Jul 20, 2025 at 10:02 AM Will Senn wrote: > I remember having discussions about vi vs emacs in the mid 1990's. I'm > curious if those were the first public wars about editors, or if y'all > remember earlier flamewars on the subject? > I recall the editor flame wars going on in the Usenet and ARPAnet world during the 1980s. Mainly in the Human Factors Usenet group. Within DEC's software engineering groups the debate (not a flame war) was between TECO and EDT. I remember one amusing (to me) incident in the vi vs. emacs flame wars. Jerry Pournelle, the science fiction author, was one of the early adopters of the home PC. He wrote a column on PCs for Byte magazine and set himself up as a computer pundit. We professional software engineers, who worked on "real" computers, not those feeble PC toys, held him in polite contempt. Then came the tragic day when AOL started carrying Usenet newsgroups. I say tragic because there was a major culture clash between the AOL user community and the Usenet community. Usenet messages were propagated for the most part over low-speed dial-up connections between the various servers. Terseness and brevity were therefore highly valued. AOl, on the other hand, had centralized servers and, since they charged their customers based on connect time, encouraged verbosity and garrulous writing style. So Pournelle got Usenet access. His professional scientific training was in operations research and human factors, so it wasn't long before he discovered the Human Factors Usenet group. The HF group was in the middle of a particularly viscous vi vs. emacs flame war at the time. Pournelle stuck his nose in and posted that his editor of preference was Electric Pencil. This triggered a discussion about Pournelle, along the lines of: "Who is this bozo?" "He's Jerry Pournelle, the lousy SF writer who thinks he knows something about computers." Both sides of the editor flame war dropped their differences and started flaming Pournelle. I don't recall ever seeing Pournelle post on Usenet again. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Jul 21 01:48:50 2025 From: imp at bsdimp.com (Warner Losh) Date: Sun, 20 Jul 2025 09:48:50 -0600 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: On Sun, Jul 20, 2025 at 9:43 AM Paul Winalski wrote: > So Pournelle got Usenet access. His professional scientific training was in operations research and human factors, so it wasn't long before he discovered the Human Factors Usenet group. The HF group was in the middle of a particularly viscous vi vs. emacs flame war at the time. Pournelle stuck his nose in and posted that his editor of preference was Electric Pencil. This triggered a discussion about Pournelle, along the lines of: "Who is this bozo?" "He's Jerry Pournelle, the lousy SF writer who thinks he knows something about computers." Both sides of the editor flame war dropped their differences and started flaming Pournelle. I don't recall ever seeing Pournelle post on Usenet again. The more things change... You could tell the same store today about Discord, forums, etc. Warner From paul.winalski at gmail.com Mon Jul 21 04:27:42 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 20 Jul 2025 14:27:42 -0400 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: On Sun, Jul 20, 2025 at 1:52 PM Clem Cole wrote: > > Also, remember that for the early DEC PDPs 1/6/10 machines, there were > Stopgap, SonOfStopgap (*a.k.a.* SOS - which became DEC's EDIT), Teco, and > eventually EMACS [remember UNIX emacs is a clone of the original > TOPS-10/ITS EMACS]; and probably others that I am forgetting - those the > ones I used in PDP-10 days. > TECO (Text Editor and COrrector) was interesting in a couple of ways. All of its commands were a single character. It was also programmable in a very powerful way. EMACS was first implemented as a set of TECO macros (the name EMACS is an acronym for Editor MACroS). -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Mon Jul 21 04:29:18 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 20 Jul 2025 18:29:18 +0000 Subject: [COFF] editor wars In-Reply-To: (Clem Cole's message of "Sun, 20 Jul 2025 11:25:25 -0400") References: Message-ID: <7wo6tepvgh.fsf@junk.nocrew.org> Clem Cole wrote: > Teco, and eventually EMACS [remember UNIX emacs is a clone of the > original TOPS-10/ITS EMACS] EMACS ran on ITS, TOPS-20, and TENEX, but not TOPS-10. TOPS-10 had Emacs-likes FINE and AMIS. From lars at nocrew.org Mon Jul 21 04:31:38 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 20 Jul 2025 18:31:38 +0000 Subject: [COFF] editor wars In-Reply-To: (Paul Winalski's message of "Sun, 20 Jul 2025 11:43:10 -0400") References: Message-ID: <7wjz42pvcl.fsf@junk.nocrew.org> Paul Winalski writes: > Both sides of the editor flame war dropped their differences and > started flaming Pournelle. I don't recall ever seeing Pournelle post > on Usenet again. He was also kicked off ARPANET. http://www.art.net/~hopkins/Don/text/pourne-smut.html From paul.winalski at gmail.com Mon Jul 21 04:35:19 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 20 Jul 2025 14:35:19 -0400 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: On Sun, Jul 20, 2025 at 1:52 PM Clem Cole wrote: > > So features like embedded line numbers (or not) would get into the war. > Line numbers of course were critically important in the punch card days. Card columns 73-80 were reserved for line sequence numbers. Some of the fancier keypunches could read a card deck and put the line sequence numbers in for you. A sequenced deck was a godsend if you happened to drop the deck on the floor. Just put the deck in a card sorter and sort on cols. 73-80 and you're back in business. In editors for non-screen terminals the line numbers provided an easy way to reposition the editor within the text stream. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Jul 21 04:43:53 2025 From: clemc at ccc.com (Clem Cole) Date: Sun, 20 Jul 2025 14:43:53 -0400 Subject: [COFF] editor wars In-Reply-To: <7wo6tepvgh.fsf@junk.nocrew.org> References: <7wo6tepvgh.fsf@junk.nocrew.org> Message-ID: On Sun, Jul 20, 2025 at 2:29 PM Lars Brinkhoff wrote: > > EMACS ran on ITS, TOPS-20, and TENEX, but not TOPS-10. TOPS-10 had > Emacs-likes FINE and AMIS. > Thanks -- you're right. FINE was what we had on the PDP-10s, not pure EMACS, which we did not get until we started running TOPS-20. As I said, i used it for such a short time and never really mastered it but the time I switched to UNIX. Which set me on a path to ex/vi and by the time Gosling EMACS was available, I had never went back as ex/vi was getting the job done and ran on both PDP-11s and Vaxen. It was just not worth re-learning it as vi was by the, everywhere from MS-DOS to the Cray 1 and EMACS wasn't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuff at riddermarkfarm.ca Mon Jul 21 05:21:46 2025 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sun, 20 Jul 2025 15:21:46 -0400 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: <624db07c-7b3e-6ee3-91c5-7fd99cc846d3@riddermarkfarm.ca> On 2025-07-20 11:43, Paul Winalski wrote (in part): > I remember one amusing (to me) incident in the vi vs. emacs flame wars. > Jerry Pournelle, the science fiction author, was one of the early > adopters of the home PC.  He wrote a column on PCs for Byte magazine and > set himself up as a computer pundit.  We professional software > engineers, who worked on "real" computers, not those feeble PC toys, > held him in polite contempt. I recall one of his "Chaos Manor" columns about a UNIX-PC sent to him by ATT. The first thing inside the box was a very thick licensing agreement that he declined to sign. I use both vi and emacs. One day, I was modifying my .emacs file with vi -- I do not remember why. A colleague, walking by, asked what I was doing. When I told him, he fixed me with a cold stare, said "Scurrilous", and walked away. S. From g.branden.robinson at gmail.com Mon Jul 21 05:26:07 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 20 Jul 2025 14:26:07 -0500 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: <20250720192607.igasgoagnwks65my@illithid> At 2025-07-20T11:43:10-0400, Paul Winalski wrote: > The HF group was in the middle of a particularly viscous vi vs. emacs > flame war at the time. The world needs a formula to compute the Reynolds number of an online discussion. :D Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From crossd at gmail.com Mon Jul 21 06:26:52 2025 From: crossd at gmail.com (Dan Cross) Date: Sun, 20 Jul 2025 16:26:52 -0400 Subject: [COFF] Personal Preference vs Group Productivity (was Re: [TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: References: <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> Message-ID: [TUHS to Bcc; Cc'ed to COFF to redirect for follow-ups] On Sun, Jul 20, 2025 at 8:24 AM Christian Hopps wrote: > Larry McVoy writes: > > I wasn't trying to tell Will he can't use whatever editor he wants, I was > > trying to tell Will I wouldn't tolerate this much back and forth about his > > personal preferences distracting us from shipping product. My team had > > emacs people and vi people, nobody cared so long as you got your job done. > > > > What we didn't have is editor arguments clogging up our thinking. > > To jump in here before everyone poo poos this thread too much. I agree with this sentiment when it's time to get work done. > > That said, I've enjoyed this thread b/c I like getting other peoples perspectives, especially from folks that I think have some clue. Sometimes I learn something new or a new perspective and I end up adapting new tools or practices b/c of it -- even now that my beard/hair is grey. > > I find these are actually fun conversations to have occasionally -- maybe in a cafe/bar or even on a mailing list. Maybe not everyday or all the time, but sometimes. :) I think some folks may have interpreted Larry's statements as stating that, if you worked for him, you used the tools he mandated. But I don't think that's what he meant (at least not about text editors), and I think that your interpretation is correct: use whatever works for you, but don't waste a bunch of other people's time pushing the virtunes of your preferred tools on those who already have things that work for them. I think that's fair. That said, there is a qualitative difference between the sort of banter people may bat around over lunch, and someone seriously trying to get everyone else to use their preferred editor (editors are just one example, though interesting in this regard because choosing them seems to be such a deeply personal thing). I think the discussions on these mailing lists are closer to the former than the latter, and as long as it remains friendly, I really don't see any harm in that. But this got me thinking that surely there are decisions made on a project basis, where individual preference by itself is not, and cannot be, the deciding factor for use. Perhaps the most obvious is code-formatting styles, but others may be choice of build tool, revision control system, implementation language, and so on. Where does one draw the line between the tools an individual chooses for their own use, and those mandated by the group? I suspect there is no one, good, universal answer. Take implementation language as an example: "I'll write my part in C, you write yours in FORTRAN..." sounds highly suspect at first, but _might_ make sense if "I'm" tasked with writing the IO part and "you're" taking on the numerical bits and have to interface with a numerical library written in Fortran. Indeed, I've found that when people try to define some kind of general rule for deciding this or that, they tend to be trying to simplify really complex things in a very superficial way that's not reflective of actual practice. But maybe there is some utility in thinking about this generally. Perhaps a reasonable first-order approximation for finding a dividing line might be taken from the answer to the question, "is this something that really only impacts me, or is it going to have an impact on my peers, as well?" Editors sort of make sense here; by and large, as long as I can use the tools effectively, my peers aren't going to be impacted if I use tool A to enter text versus tool B. Similarly with whether I prefer light text on a darker background, or dark text on a lighter background, what font I use, type size, what window manager I use, and so on. But on the other hand, if I demanded that I be able to use My preferred code formatting style regardless of what the rest of the code used, then that _does_ have an impact on those around me, so deserves more thought. And _that's_ the kind of thing that people can argue about endlessly until finally someone just makes a decision. I've said this before, but Google's style guides were a great case in point here. To be honest, I didn't like them and thought that the resulting code was ugly. But after a few weeks, I just stopped noticing that, and I had to admit that they were a great aid in being able to approach a codebase with billions of LOC in it. When `clang-format` came along and took out a lot of the tedium of making your code conform to the style guide, it really freed up a lot of mental capacity to start thinking about real problems, design, and so on, and not just where the braces went. But that was all predicated on someone just Making a Decision. > FWIW for coding/email/organizing/scheduling I now use some franken-setup project called "spacemacs" which is emacs, but the UI of vi, launching much faster, that uses a meta-configuration that makes it simple to enable all those features (and yes I still write lisp when needed but that's almost never to get what I want anymore). > > For quick editing I still just type `vi` and use ^Z, even though I also use tmux and long running disconnected remote sessions. Personally, I've found it very helpful to maintain some level of proficiency in a variety of different text editors, using different tools for different things. Part of this is the whole, "when in Rome, do as Romans do..." sort of thing: I'm not looking for `vi` on VMS or Multics or VM/CMS or something, but I'll also happily use emacs to write Lisp, and on plan 9, I'll use sam or acme for C or troff or whatever. On my Mac, Zed or VSCode work pretty well. On remote Unix machines, a lot of the kids are hip on this "Helix" thing these days. Speaking of plan 9.... One nice thing about a system that embraces true resource sharing is that, when one can construct an environment that contains the set of all the resources one needs to work with and then one can bring one's local toolset to bear on those resources. Plan 9, where resources are represented by files in mutable namespaces, really exemplifies this, which is distinct from a more "remote access" model, where I use something like ssh or mosh or telnet to login to a remote system. In the remote access model, I'm constrained by whatever tools are available on a remote system. So if I'm logging into some remote server over SSH or something, it's handy to know whatever editor may be on the distant end. It's a shame more systems aren't like plan 9 in this way, but they aren't, and for better or worse, I've still got to use them, and it's so much less personally aggravating to care deeply about what tools are available in that context. - Dan C. From will.senn at gmail.com Mon Jul 21 07:10:07 2025 From: will.senn at gmail.com (Will Senn) Date: Sun, 20 Jul 2025 16:10:07 -0500 Subject: [COFF] COFF Digest, Vol 78, Issue 1 In-Reply-To: <175303653734.8534.10147645064913926007@minnie.tuhs.org> References: <175303653734.8534.10147645064913926007@minnie.tuhs.org> Message-ID: <2A1DE60C-71A3-40A7-9378-317FCBBABABD@gmail.com> Reminds me of one of my favorite editors - wordstar 3… George R.R. Martin used it to write the great bulk of his works! We still carry around more baggage from this editor (arguably word processor) than most folks know . Sent from my iPhone > On Jul 20, 2025, at 1:35 PM, coff-request at tuhs.org wrote: > > Send COFF mailing list submissions to > coff at tuhs.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > coff-request at tuhs.org > > You can reach the person managing the list at > coff-owner at tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of COFF digest..." > > Today's Topics: > > 1. Re: editor wars (Paul Winalski) > 2. Re: editor wars (Warner Losh) > 3. Re: editor wars (Paul Winalski) > 4. Re: editor wars (Lars Brinkhoff) > 5. Re: editor wars (Lars Brinkhoff) > 6. Re: editor wars (Paul Winalski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 20 Jul 2025 11:43:10 -0400 > From: Paul Winalski > Subject: [COFF] Re: editor wars > To: coff at tuhs.org > Message-ID: > > Content-Type: multipart/alternative; > boundary="000000000000095b69063a5e382b" > >> On Sun, Jul 20, 2025 at 10:02 AM Will Senn wrote: >> >> I remember having discussions about vi vs emacs in the mid 1990's. I'm >> curious if those were the first public wars about editors, or if y'all >> remember earlier flamewars on the subject? >> > > I recall the editor flame wars going on in the Usenet and ARPAnet world > during the 1980s. Mainly in the Human Factors Usenet group. Within DEC's > software engineering groups the debate (not a flame war) was between TECO > and EDT. > > I remember one amusing (to me) incident in the vi vs. emacs flame wars. > Jerry Pournelle, the science fiction author, was one of the early adopters > of the home PC. He wrote a column on PCs for Byte magazine and set himself > up as a computer pundit. We professional software engineers, who worked on > "real" computers, not those feeble PC toys, held him in polite contempt. > > Then came the tragic day when AOL started carrying Usenet newsgroups. I > say tragic because there was a major culture clash between the AOL user > community and the Usenet community. Usenet messages were propagated for > the most part over low-speed dial-up connections between the various > servers. Terseness and brevity were therefore highly valued. AOl, on the > other hand, had centralized servers and, since they charged their customers > based on connect time, encouraged verbosity and garrulous writing style. > > So Pournelle got Usenet access. His professional scientific training was > in operations research and human factors, so it wasn't long before he > discovered the Human Factors Usenet group. The HF group was in the middle > of a particularly viscous vi vs. emacs flame war at the time. Pournelle > stuck his nose in and posted that his editor of preference was Electric > Pencil. This triggered a discussion about Pournelle, along the lines of: > "Who is this bozo?" "He's Jerry Pournelle, the lousy SF writer who thinks > he knows something about computers." Both sides of the editor flame war > dropped their differences and started flaming Pournelle. I don't recall > ever seeing Pournelle post on Usenet again. > > -Paul W. > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 2579 bytes > Desc: not available > > ------------------------------ > > Message: 2 > Date: Sun, 20 Jul 2025 09:48:50 -0600 > From: Warner Losh > Subject: [COFF] Re: editor wars > To: Paul Winalski > Cc: coff at tuhs.org > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > >> On Sun, Jul 20, 2025 at 9:43 AM Paul Winalski wrote: >> So Pournelle got Usenet access. His professional scientific training was in operations research and human factors, so it wasn't long before he discovered the Human Factors Usenet group. The HF group was in the middle of a particularly viscous vi vs. emacs flame war at the time. Pournelle stuck his nose in and posted that his editor of preference was Electric Pencil. This triggered a discussion about Pournelle, along the lines of: "Who is this bozo?" "He's Jerry Pournelle, the lousy SF writer who thinks he knows something about computers." Both sides of the editor flame war dropped their differences and started flaming Pournelle. I don't recall ever seeing Pournelle post on Usenet again. > > The more things change... You could tell the same store today about > Discord, forums, etc. > > Warner > > ------------------------------ > > Message: 3 > Date: Sun, 20 Jul 2025 14:27:42 -0400 > From: Paul Winalski > Subject: [COFF] Re: editor wars > To: coff at tuhs.org > Message-ID: > > Content-Type: multipart/alternative; > boundary="00000000000083cc2d063a6084b5" > >> On Sun, Jul 20, 2025 at 1:52 PM Clem Cole wrote: >> >> >> Also, remember that for the early DEC PDPs 1/6/10 machines, there were >> Stopgap, SonOfStopgap (*a.k.a.* SOS - which became DEC's EDIT), Teco, and >> eventually EMACS [remember UNIX emacs is a clone of the original >> TOPS-10/ITS EMACS]; and probably others that I am forgetting - those the >> ones I used in PDP-10 days. >> > > TECO (Text Editor and COrrector) was interesting in a couple of ways. All > of its commands were a single character. It was also programmable in a > very powerful way. EMACS was first implemented as a set of TECO macros > (the name EMACS is an acronym for Editor MACroS). > > -Paul W. > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 1147 bytes > Desc: not available > > ------------------------------ > > Message: 4 > Date: Sun, 20 Jul 2025 18:29:18 +0000 > From: Lars Brinkhoff > Subject: [COFF] Re: editor wars > To: Clem Cole > Cc: Will Senn , coff at tuhs.org > Message-ID: <7wo6tepvgh.fsf at junk.nocrew.org> > Content-Type: text/plain > > Clem Cole wrote: >> Teco, and eventually EMACS [remember UNIX emacs is a clone of the >> original TOPS-10/ITS EMACS] > > EMACS ran on ITS, TOPS-20, and TENEX, but not TOPS-10. TOPS-10 had > Emacs-likes FINE and AMIS. > > ------------------------------ > > Message: 5 > Date: Sun, 20 Jul 2025 18:31:38 +0000 > From: Lars Brinkhoff > Subject: [COFF] Re: editor wars > To: Paul Winalski > Cc: coff at tuhs.org > Message-ID: <7wjz42pvcl.fsf at junk.nocrew.org> > Content-Type: text/plain > > Paul Winalski writes: >> Both sides of the editor flame war dropped their differences and >> started flaming Pournelle. I don't recall ever seeing Pournelle post >> on Usenet again. > > He was also kicked off ARPANET. > http://www.art.net/~hopkins/Don/text/pourne-smut.html > > ------------------------------ > > Message: 6 > Date: Sun, 20 Jul 2025 14:35:19 -0400 > From: Paul Winalski > Subject: [COFF] Re: editor wars > To: coff at tuhs.org > Message-ID: > > Content-Type: multipart/alternative; > boundary="000000000000ba9551063a609f1a" > >> On Sun, Jul 20, 2025 at 1:52 PM Clem Cole wrote: >> >> >> So features like embedded line numbers (or not) would get into the war. >> > > Line numbers of course were critically important in the punch card days. > Card columns 73-80 were reserved for line sequence numbers. Some of the > fancier keypunches could read a card deck and put the line sequence numbers > in for you. A sequenced deck was a godsend if you happened to drop the > deck on the floor. Just put the deck in a card sorter and sort on cols. > 73-80 and you're back in business. > > In editors for non-screen terminals the line numbers provided an easy way > to reposition the editor within the text stream. > > -Paul W. > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 1442 bytes > Desc: not available > > End of COFF Digest, Vol 78, Issue 1 > *********************************** From coff at tuhs.org Mon Jul 21 07:26:07 2025 From: coff at tuhs.org (Warren Toomey via COFF) Date: Mon, 21 Jul 2025 07:26:07 +1000 Subject: [COFF] Code/comment Ratios Style Message-ID: I've written my fair share of code and also taught several languages. I'd estimate my comment to total LOC ratio as about 1/4 to 1/3. But I keep coming across code bases where the ratio is closer to 1/100 and it really bugs me! I just can't read the codebase and work out the nuances of what it is doing. So this isn't a rant so much as a request for alternate perspectives. If you have a spartan commenting style, why? Can you read your code and see all the implications, or do you dislike lots of comments, or do you write more external documentation etc.? When I taught, I had two mantras about comments: Code explains how, comments explain why. Code as if the person who takes over your codebase is a crazed psychopath who knows where you live. Thanks! Warren From lm at mcvoy.com Mon Jul 21 07:46:37 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 20 Jul 2025 14:46:37 -0700 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: <20250720214637.GU15357@mcvoy.com> On Mon, Jul 21, 2025 at 07:26:07AM +1000, Warren Toomey via COFF wrote: > So this isn't a rant so much as a request for alternate perspectives. If > you have a spartan commenting style, why? Can you read your code and see > all the implications, or do you dislike lots of comments, or do you write > more external documentation etc.? Well, in a long lived code base, comments can rot. I'd much rather have to read the code and figure it out than have a comment that is no longer true send me down a wild goose chase (it's happened more than I care to think about). I tend to comment structures quite a bit, globals and locals, have a block comment above the function saying what it is and it gets sparse from there. There may be inline comments but they need to do something a lot more useful than i++; // increment i <-- this sort of comment is worse than useless I also have a style that is int *p = 0; char *foo = 0; int ret = 0; // lots of code err: ret = -1; out: if (p) free(p); if (foo) free(foo); return (ret); } Most of the BitKeeper code follows that style, no unitialized pointers, we did use a lot of unless (p = malloc(whatever)) goto err; style of programming. Memory management in C is primitive so you have to adopt some consistent style to avoid errors just because someone did something different. > When I taught, I had two mantras about comments: > > Code explains how, comments explain why. > > Code as if the person who takes over your codebase > is a crazed psychopath who knows where you live. I always said "optimize for reading, not writing". I've also said "anything that you wrote 6 months ago, you will approach it as if it is someone else's code". From milovelimirovic at gmail.com Mon Jul 21 08:14:15 2025 From: milovelimirovic at gmail.com (=?utf-8?Q?Milo_Velimirovi=C4=87?=) Date: Sun, 20 Jul 2025 17:14:15 -0500 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: <5C33D23C-F676-4FCD-A6C1-2FB9FBE44D47@gmail.com> And nobody’s even mentioned TECO. (Where’s my asbestous suit?) > On Jul 20, 2025, at 8:52 AM, Will Senn wrote: > > I remember having discussions about vi vs emacs in the mid 1990's. I'm curious if those were the first public wars about editors, or if y'all remember earlier flamewars on the subject? Maybe KEDIT vs EDIT? I grew up on DOS, so edlin vs edit was quite the battle ground in discussions, but I don't remember flames... I find the vi/emacs divide quite insurmountable. As a vi guy, I cannot even understand emac's appeal. I've tried countless times, even going emacs only for a while... when I went back to vi, it was like old shoes, very comfortable. I didn't get the flamewar at all - you do you... but I did and still do find the passion on either side endlessly fascinating. > > Two other debates are quite similar - one to do with spaces vs tabs, the other top-posting vs bottom-posting have provided me with hours of entertainment... I prefer tabs over spaces and top-posting, but I get the other points of view on these... > > Will > From jpl.jpl at gmail.com Mon Jul 21 10:21:58 2025 From: jpl.jpl at gmail.com (John P. Linderman) Date: Sun, 20 Jul 2025 20:21:58 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: <20250720214637.GU15357@mcvoy.com> References: <20250720214637.GU15357@mcvoy.com> Message-ID: Norm Schryer used to say "If the code and comments disagree, both are probably wrong." On Sun, Jul 20, 2025 at 7:42 PM Larry McVoy wrote: > On Mon, Jul 21, 2025 at 07:26:07AM +1000, Warren Toomey via COFF wrote: > > So this isn't a rant so much as a request for alternate perspectives. If > > you have a spartan commenting style, why? Can you read your code and see > > all the implications, or do you dislike lots of comments, or do you write > > more external documentation etc.? > > Well, in a long lived code base, comments can rot. I'd much rather have > to read the code and figure it out than have a comment that is no longer > true send me down a wild goose chase (it's happened more than I care to > think about). > > I tend to comment structures quite a bit, globals and locals, > have a block comment above the function saying what it is and it > gets sparse from there. There may be inline comments but they need > to do something a lot more useful than > > i++; // increment i <-- this sort of comment is worse than > useless > > I also have a style that is > > int *p = 0; > char *foo = 0; > int ret = 0; > > // lots of code > err: ret = -1; > out: if (p) free(p); > if (foo) free(foo); > return (ret); > } > > Most of the BitKeeper code follows that style, no unitialized pointers, > we did use a lot of > > unless (p = malloc(whatever)) goto err; > > style of programming. Memory management in C is primitive so you have to > adopt some consistent style to avoid errors just because someone did > something different. > > > When I taught, I had two mantras about comments: > > > > Code explains how, comments explain why. > > > > Code as if the person who takes over your codebase > > is a crazed psychopath who knows where you live. > > I always said "optimize for reading, not writing". I've also said > "anything > that you wrote 6 months ago, you will approach it as if it is someone > else's > code". > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Mon Jul 21 10:30:45 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 20 Jul 2025 20:30:45 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: I just posted the most heavily commented code I have ever written. It's a radical (mis?)application of m4, which is about as inscrutable as any language short of APL. The ratio of comments to code is more than 3:1. It's at www.cs.dartmouth.edu/~doug/barem4.m4. 3:1 may be overkill, but I think 2:1 would not be unreasonable. Doug On Sun, Jul 20, 2025 at 5:26 PM Warren Toomey via COFF wrote: > > I've written my fair share of code and also taught several languages. I'd > estimate my comment to total LOC ratio as about 1/4 to 1/3. But I keep > coming across code bases where the ratio is closer to 1/100 and it really > bugs me! I just can't read the codebase and work out the nuances of what > it is doing. > > So this isn't a rant so much as a request for alternate perspectives. If > you have a spartan commenting style, why? Can you read your code and see > all the implications, or do you dislike lots of comments, or do you write > more external documentation etc.? > > When I taught, I had two mantras about comments: > > Code explains how, comments explain why. > > Code as if the person who takes over your codebase > is a crazed psychopath who knows where you live. > > Thanks! > Warren From coff at tuhs.org Mon Jul 21 10:58:19 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Sun, 20 Jul 2025 20:58:19 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: On 7/20/25 5:26 PM, Warren Toomey via COFF wrote: > So this isn't a rant so much as a request for alternate perspectives. If > you have a spartan commenting style, why? Can you read your code and see > all the implications, or do you dislike lots of comments, or do you write > more external documentation etc.? I think the age of my code base stacks up pretty well, and I find myself commenting what I think are the complex parts and changes very heavily. Above all, I want to be able to answer this question from my future self: what the hell were you thinking? I find that I'm not nearly as clever as my younger self. Detailed change log entries are essential as well. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From sauer at technologists.com Mon Jul 21 10:58:25 2025 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Sun, 20 Jul 2025 19:58:25 -0500 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: <41ca5ec4-929e-4317-b083-754df5944b2b@technologists.com> Thanks for doing this. I added dnl https://www.cs.dartmouth.edu/~doug/barem4.m4 to the top of my copy... On 7/20/2025 7:30 PM, Douglas McIlroy wrote: > I just posted the most heavily commented code I have ever written. > It's a radical (mis?)application of m4, which is about as inscrutable > as any language short of APL. The ratio of comments to code is more > than 3:1. > It's at www.cs.dartmouth.edu/~doug/barem4.m4. 3:1 may be > overkill, but I think 2:1 would not be unreasonable. > > Doug > > On Sun, Jul 20, 2025 at 5:26 PM Warren Toomey via COFF wrote: >> >> I've written my fair share of code and also taught several languages. I'd >> estimate my comment to total LOC ratio as about 1/4 to 1/3. But I keep >> coming across code bases where the ratio is closer to 1/100 and it really >> bugs me! I just can't read the codebase and work out the nuances of what >> it is doing. >> >> So this isn't a rant so much as a request for alternate perspectives. If >> you have a spartan commenting style, why? Can you read your code and see >> all the implications, or do you dislike lots of comments, or do you write >> more external documentation etc.? >> >> When I taught, I had two mantras about comments: >> >> Code explains how, comments explain why. >> >> Code as if the person who takes over your codebase >> is a crazed psychopath who knows where you live. >> >> Thanks! >> Warren -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From stuff at riddermarkfarm.ca Mon Jul 21 11:07:11 2025 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sun, 20 Jul 2025 21:07:11 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: <9cb88691-bdae-be41-de1b-fb562154b853@riddermarkfarm.ca> On 2025-07-20 20:58, Chet Ramey via COFF wrote: > On 7/20/25 5:26 PM, Warren Toomey via COFF wrote: > >> So this isn't a rant so much as a request for alternate perspectives. If >> you have a spartan commenting style, why? Can you read your code and see >> all the implications, or do you dislike lots of comments, or do you write >> more external documentation etc.? > > I think the age of my code base stacks up pretty well, and I find myself > commenting what I think are the complex parts and changes very heavily. > Above all, I want to be able to answer this question from my future self: > what the hell were you thinking? I concur with this. Some of the code we wrote was highly optimized mathematical code that was far from easy to understand. Separate documents helped but methinks our former use of noweb was better. > I find that I'm not nearly as clever as my younger self. +1 S. > Detailed change log entries are essential as well. > > Chet > From lm at mcvoy.com Mon Jul 21 12:01:18 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 20 Jul 2025 19:01:18 -0700 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: <20250721020118.GZ15357@mcvoy.com> Take the "." off the end of Dougs url. On Sun, Jul 20, 2025 at 08:30:45PM -0400, Douglas McIlroy wrote: > I just posted the most heavily commented code I have ever written. > It's a radical (mis?)application of m4, which is about as inscrutable > as any language short of APL. The ratio of comments to code is more > than 3:1. > It's at www.cs.dartmouth.edu/~doug/barem4.m4. 3:1 may be > overkill, but I think 2:1 would not be unreasonable. > > Doug > > On Sun, Jul 20, 2025 at 5:26???PM Warren Toomey via COFF wrote: > > > > I've written my fair share of code and also taught several languages. I'd > > estimate my comment to total LOC ratio as about 1/4 to 1/3. But I keep > > coming across code bases where the ratio is closer to 1/100 and it really > > bugs me! I just can't read the codebase and work out the nuances of what > > it is doing. > > > > So this isn't a rant so much as a request for alternate perspectives. If > > you have a spartan commenting style, why? Can you read your code and see > > all the implications, or do you dislike lots of comments, or do you write > > more external documentation etc.? > > > > When I taught, I had two mantras about comments: > > > > Code explains how, comments explain why. > > > > Code as if the person who takes over your codebase > > is a crazed psychopath who knows where you live. > > > > Thanks! > > Warren -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Mon Jul 21 12:06:38 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 20 Jul 2025 19:06:38 -0700 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: <20250721020638.GA15357@mcvoy.com> On Sun, Jul 20, 2025 at 08:30:45PM -0400, Douglas McIlroy wrote: > I just posted the most heavily commented code I have ever written. > It's a radical (mis?)application of m4, which is about as inscrutable > as any language short of APL. The ratio of comments to code is more > than 3:1. > It's at www.cs.dartmouth.edu/~doug/barem4.m4. 3:1 may be > overkill, but I think 2:1 would not be unreasonable. > > Doug Whenever I see something like this, it reminds me of one of my engineers who said you couldn't make BK produce json out put. Hold my beer. http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt It's a lot less miserable than the m4 (and I'm a fan of m4). From lm at mcvoy.com Mon Jul 21 12:18:43 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 20 Jul 2025 19:18:43 -0700 Subject: [COFF] Code/comment Ratios Style In-Reply-To: <20250721020638.GA15357@mcvoy.com> References: <20250721020638.GA15357@mcvoy.com> Message-ID: <20250721021843.GB15357@mcvoy.com> On Sun, Jul 20, 2025 at 07:06:38PM -0700, Larry McVoy wrote: > On Sun, Jul 20, 2025 at 08:30:45PM -0400, Douglas McIlroy wrote: > > I just posted the most heavily commented code I have ever written. > > It's a radical (mis?)application of m4, which is about as inscrutable > > as any language short of APL. The ratio of comments to code is more > > than 3:1. > > It's at www.cs.dartmouth.edu/~doug/barem4.m4. 3:1 may be > > overkill, but I think 2:1 would not be unreasonable. > > > > Doug > > Whenever I see something like this, it reminds me of one of my engineers > who said you couldn't make BK produce json out put. > > Hold my beer. > > http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt > > It's a lot less miserable than the m4 (and I'm a fan of m4). It's pretty awk inspired. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From grog at lemis.com Mon Jul 21 14:03:38 2025 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 21 Jul 2025 14:03:38 +1000 Subject: [COFF] [TUHS] Re: Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: On Saturday, 19 July 2025 at 19:27:40 -0600, Warner Losh wrote: > On Sat, Jul 19, 2025 at 6:36 PM Greg 'groggy' Lehey wrote: >> >> [Somewhat off-topic for TUHS; please follow up at COFF] >> >> On Saturday, 19 July 2025 at 17:37:34 -0600, Warner Losh wrote: >>> >>> Also, there are no GUI emacs versions I like.. >> >> You have me curious. How many do you know? And what don't you like >> about them, when you clearly use Emacs? > > Most of the emacs GUI adaptations assume that it's THE instance of the > editor. You don't say which. I only know GNU Emacs. Looking at the FreeBSD Ports Collection, not even xemacs seems to have survived. > With multiple terminals, I can have multiple editors with different > contexts. With the GUI, it all gets dumped together. Not in my experience (GNU Emacs 29.4 (build 1, amd64-portbld-freebsd13.3, GTK+ Version 3.24.43, cairo version 1.17.4). I have four displays on my server 0, and also 4 instances of Emacs: one on :0.1 and three on :0.2. You need to start them individually, of course, but that's what shells are for. Each Emacs can open windows on other displays, and that's useful if they're on other machines, but it's not the only way. Can it be that your negative experience was with another version that has since died? What you describe sounds like my pain with web browsers. Greg -- Sent from my desktop computer. Finger grog at 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From douglas.mcilroy at dartmouth.edu Mon Jul 21 21:13:50 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 21 Jul 2025 07:13:50 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: <20250721021843.GB15357@mcvoy.com> References: <20250721020638.GA15357@mcvoy.com> <20250721021843.GB15357@mcvoy.com> Message-ID: No awk at all. Much imitation of Lisp and Haskell On Sunday, July 20, 2025, Larry McVoy wrote: > On Sun, Jul 20, 2025 at 07:06:38PM -0700, Larry McVoy wrote: > > On Sun, Jul 20, 2025 at 08:30:45PM -0400, Douglas McIlroy wrote: > > > I just posted the most heavily commented code I have ever written. > > > It's a radical (mis?)application of m4, which is about as inscrutable > > > as any language short of APL. The ratio of comments to code is more > > > than 3:1. > > > It's at www.cs.dartmouth.edu/~doug/barem4.m4. 3:1 may be > > > overkill, but I think 2:1 would not be unreasonable. > > > > > > Doug > > > > Whenever I see something like this, it reminds me of one of my engineers > > who said you couldn't make BK produce json out put. > > > > Hold my beer. > > > > http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt > > > > It's a lot less miserable than the m4 (and I'm a fan of m4). > > It's pretty awk inspired. > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Mon Jul 21 21:19:00 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 21 Jul 2025 07:19:00 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: <20250721021843.GB15357@mcvoy.com> References: <20250721020638.GA15357@mcvoy.com> <20250721021843.GB15357@mcvoy.com> Message-ID: No awk at all. Much imitation of On Sunday, July 20, 2025, Larry McVoy wrote: > On Sun, Jul 20, 2025 at 07:06:38PM -0700, Larry McVoy wrote: > > On Sun, Jul 20, 2025 at 08:30:45PM -0400, Douglas McIlroy wrote: > > > I just posted the most heavily commented code I have ever written. > > > It's a radical (mis?)application of m4, which is about as inscrutable > > > as any language short of APL. The ratio of comments to code is more > > > than 3:1. > > > It's at www.cs.dartmouth.edu/~doug/barem4.m4. 3:1 may be > > > overkill, but I think 2:1 would not be unreasonable. > > > > > > Doug > > > > Whenever I see something like this, it reminds me of one of my engineers > > who said you couldn't make BK produce json out put. > > > > Hold my beer. > > > > http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt > > > > It's a lot less miserable than the m4 (and I'm a fan of m4). > > It's pretty awk inspired. > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Mon Jul 21 21:52:32 2025 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 21 Jul 2025 07:52:32 -0400 Subject: [COFF] [TUHS] Re: Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: <20250721115232.GC231115@mit.edu> On Mon, Jul 21, 2025 at 02:03:38PM +1000, Greg 'groggy' Lehey wrote: > > With multiple terminals, I can have multiple editors with different > > contexts. With the GUI, it all gets dumped together. > > Not in my experience (GNU Emacs 29.4 (build 1, > amd64-portbld-freebsd13.3, GTK+ Version 3.24.43, cairo version > 1.17.4). I have four displays on my server 0, and also 4 instances of > Emacs: one on :0.1 and three on :0.2. Yeah, it doesn't work that way for me using GNU emacs on Debian either. Many decades ago I did force the behaviour that you describe; it involved setting EDITOR to emacsclient, and then running (server-start) in my ~/.emacs.el. This was a feature back when I was running emacs on BSD 4.3 with a Vaxstation II/RC with 2 MiB of memory (Digital had put epoxy into the backplane so you couldn't add more memory to their memory-starved inexpensive model), but now that I buy my own desktops with 64 GiB of memory, I really don't care that emacs is "eight megabytes and constantly swapping" (well, not swapping; I don't configure swap any more :-) and emacsclient is more annoying than it's worth. - Ted From lars at nocrew.org Mon Jul 21 21:55:49 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 21 Jul 2025 11:55:49 +0000 Subject: [COFF] editor wars In-Reply-To: (Paul Winalski's message of "Sun, 20 Jul 2025 14:43:26 -0400") References: <7wo6tepvgh.fsf@junk.nocrew.org> Message-ID: <7wy0shoj0a.fsf@junk.nocrew.org> Paul Winalski writes: > The original version of EMACS was a set ot TECO macros. Yes, but not any TECO. The macros make heavy use of ITS TECO particulars. > TECO ran on TOPS-10, so the TECO macro version of EMACS ought to have > been able to run there, too. No, because TOPS-10 TECO was another flavor. > Or did EMACS depend on features of TECO not implemented on TOPS-10? Yes. Maybe a short history of TECO is in order. TECO started on the MIT RLE PDP-1. It was ported to the AI lab PDP-1, and made to use its display. When the AI lab traded the PDP-1 for a PDP-6, TECO was quickly rewritten for that machine. DEC engineer Bob Clements brought a copy of this PDP-6 TECO to Stanford when overseeing the installation of a PDP-6 here. He ported TECO to run on the PDP-6 Monitor and removed display features. He then brought this version of TECO back to DEC, where it because a popular editor across all of DEC's machines. This flavor of TECO was called Standard TECO. Since it developed from an an early and lobotimized TECO, it doesn't have a rich set of features. Meanwhile back at MIT, PDP-6 TECO was moved to ITS, still keeping the original display features. It developed quickly and acquired many features that never made it to DEC. EMACS eventually appeared as the culmination and merging of many display-oriented TECO macros. The combination of TECO and EMACS was ported to TOPS-20 and TENEX. By the way, there is an "EMACS-11" that runs on TECO-11, and I suppose that is a flavor of Standard TECO. From coff at tuhs.org Mon Jul 21 23:59:54 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Mon, 21 Jul 2025 09:59:54 -0400 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: On 7/20/25 9:52 AM, Will Senn wrote: > As a vi guy, I cannot even understand emac's appeal. I've tried countless > times, even going emacs only for a while... when I went back to vi, it was > like old shoes, very comfortable. Because familiarity is very powerful. Lots of people mistake it for intuitiveness. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From lm at mcvoy.com Tue Jul 22 00:12:57 2025 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 21 Jul 2025 07:12:57 -0700 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: <20250721141257.GF15357@mcvoy.com> On Mon, Jul 21, 2025 at 09:59:54AM -0400, Chet Ramey via COFF wrote: > On 7/20/25 9:52 AM, Will Senn wrote: > > >As a vi guy, I cannot even understand emac's appeal. I've tried countless > >times, even going emacs only for a while... when I went back to vi, it was > >like old shoes, very comfortable. > > Because familiarity is very powerful. Lots of people mistake it for > intuitiveness. So many smart people I know love emacs. I forced myself to live in it for a year, not the emacs vi mode stuff, just straigth emacs. I never got to the point that I liked it. I think it's the lisp aspect, if you don't love lisp, I don't think you'll love emacs. vi just works for me. And when I tried to get my kid to try emacs, his comment was "I've watched you in vi, it's magic, I want that". I do some simple stuff, here are the maps I use a lot: # :.,$ , !}fmt @ :1,. So I can be on a paragraph and hit "," and it is reformatted to fit in 80 columns. I can be anywhere and do "#d" and that deletes to the bottom, same thing "@d" and that deletes to the top. Apparently that is "magic" :-) From coff at tuhs.org Tue Jul 22 00:15:51 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Mon, 21 Jul 2025 10:15:51 -0400 Subject: [COFF] editor wars In-Reply-To: <20250721141257.GF15357@mcvoy.com> References: <20250721141257.GF15357@mcvoy.com> Message-ID: <5aa82876-b245-4ab6-bede-80260fa53fbc@case.edu> On 7/21/25 10:12 AM, Larry McVoy wrote: > On Mon, Jul 21, 2025 at 09:59:54AM -0400, Chet Ramey via COFF wrote: >> On 7/20/25 9:52 AM, Will Senn wrote: >> >>> As a vi guy, I cannot even understand emac's appeal. I've tried countless >>> times, even going emacs only for a while... when I went back to vi, it was >>> like old shoes, very comfortable. >> >> Because familiarity is very powerful. Lots of people mistake it for >> intuitiveness. > > So many smart people I know love emacs. I forced myself to live in it > for a year, not the emacs vi mode stuff, just straigth emacs. > > I never got to the point that I liked it. I think it's the lisp aspect, > if you don't love lisp, I don't think you'll love emacs. I think it depends. You have to have a passing familiarity with lisp to really take advantage of GNU emacs, but there are plenty of emacs-like editors out there (I maintain one, based on microemacs from way back) that have emacs-style key bindings and similar functionality. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From coff at tuhs.org Tue Jul 22 00:18:19 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Mon, 21 Jul 2025 10:18:19 -0400 Subject: [COFF] editor wars In-Reply-To: <20250721141257.GF15357@mcvoy.com> References: <20250721141257.GF15357@mcvoy.com> Message-ID: <8009339f-09ac-4c58-8f68-df9b048272cc@case.edu> On 7/21/25 10:12 AM, Larry McVoy wrote: > I do some simple stuff, here are the maps I use a lot: > > # :.,$ > , !}fmt > @ :1,. > > So I can be on a paragraph and hit "," and it is reformatted to fit > in 80 columns. My editor does that with M-Q, using a user-settable fill column. It's second nature to me. Six of one... -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From paul.winalski at gmail.com Tue Jul 22 00:24:22 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 21 Jul 2025 10:24:22 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: <20250720214637.GU15357@mcvoy.com> References: <20250720214637.GU15357@mcvoy.com> Message-ID: IMO the skill of writing and maintaining good, useful comments is one of the things that distinguishes software engineering from mere programming. I learned early in my software engineering career that sometimes even after a few months away from the code I wrote I couldn't remember all the fine details of the design. So I wrote comments for my own self-preservation, let alone giving another developer a fighting chance of knowing what's going on if they had to change my code. On Sun, Jul 20, 2025 at 7:42 PM Larry McVoy wrote: > > Well, in a long lived code base, comments can rot. I'd much rather have > to read the code and figure it out than have a comment that is no longer > true send me down a wild goose chase (it's happened more than I care to > think about). > > True, and that is why I've always considered the comments to be an integral part of the code, and when doing code reviews I've refused to approve code changes where the comments are too sparse or where the comments don't match the code. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jul 22 00:24:28 2025 From: imp at bsdimp.com (Warner Losh) Date: Mon, 21 Jul 2025 08:24:28 -0600 Subject: [COFF] editor wars In-Reply-To: <7wy0shoj0a.fsf@junk.nocrew.org> References: <7wo6tepvgh.fsf@junk.nocrew.org> <7wy0shoj0a.fsf@junk.nocrew.org> Message-ID: On Mon, Jul 21, 2025, 5:55 AM Lars Brinkhoff wrote: > By the way, there is an "EMACS-11" that runs on TECO-11, and I suppose > that is a flavor of Standard TECO. > TECO-11 was, but it had didplay features. We had a screen oriented editor written in TECO that I hacked on. But it has .TES files that was TECO written with comments and whitespace. Those comment and whitespace where removed with MUNGE. There is some connection to make (which make have been part of it). There was a 60s joke burried in 'make love' where it would print 'not war' that I added to FreeBSD make for a number of years. The TECO-11 macros like this were nothing at all like EMACS. And IIIRC, many of the TOPS20 Emacs macros had migrated to assembler, at least that's what I recall seeing when I used the display macro source feature back in school. Many were still in teco and made my head spin. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Tue Jul 22 00:27:57 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Mon, 21 Jul 2025 10:27:57 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: <20250720214637.GU15357@mcvoy.com> Message-ID: <81b42620-212e-48be-af67-0d1207323c7a@case.edu> On 7/21/25 10:24 AM, Paul Winalski wrote: > IMO the skill of writing and maintaining good, useful comments is one of > the things that distinguishes software engineering from mere programming. > > I learned early in my software engineering career that sometimes even after > a few months away from the code I wrote I couldn't remember all the fine > details of the design.  So I wrote comments for my own self-preservation, > let alone giving another developer a fighting chance of knowing what's > going on if they had to change my code. To answer the eternal question: what the hell were you thinking? :-) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From crossd at gmail.com Tue Jul 22 00:28:02 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 21 Jul 2025 10:28:02 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: On Sun, Jul 20, 2025 at 5:26 PM Warren Toomey via COFF wrote: > I've written my fair share of code and also taught several languages. I'd > estimate my comment to total LOC ratio as about 1/4 to 1/3. But I keep > coming across code bases where the ratio is closer to 1/100 and it really > bugs me! I just can't read the codebase and work out the nuances of what > it is doing. > > So this isn't a rant so much as a request for alternate perspectives. If > you have a spartan commenting style, why? Can you read your code and see > all the implications, or do you dislike lots of comments, or do you write > more external documentation etc.? My major gripes about comments are that people tend to write them poorly, and they aren't generally checked by the compiler/interpreter: a poor, out of date, comment can be worse than no comments. But comments also have issues around discoverability and locality; I have found that they are not good as a means for system-level documentation, serving best to explain rationale at some very local level of code. Crucially, those comments are only really useful when I already know where to look for them, and while they may explain a particular quirk of some code, they often don't help me understand the system/interface/tool as a whole. However, the "not checked by the compiler" thing has some exceptions these days. Some languages have the notion of "documentation tests", in which one can write unit tests in a comment, flanked by special syntax so that they are checked by the compiler and are executed as tests when invoked a certain way; this is useful for keeping code examples up to date as interfaces change. Rust is a good example here: https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html > When I taught, I had two mantras about comments: > > Code explains how, comments explain why. An issue is that people try to go beyond this and use comments for more general documentary purposes, for which they are not well suited; at least not without significant additional tooling. Google mandated that C++ header files all contain comments that described classes _and how to use them_ at length; this was useful, but sometimes really do want an external document of some kind that describes things at a higher level. But comments are just one way of introducing documentation into a system, even at the source code level. Python and many dialects of Lisp both have a notion of "docstrings", for example, that are accessible from the REPL, and serve an overlapping purpose, but are semantically different objects than comments at the language level. "Doc comments", used for automatically generating system-level documentation, are increasingly common, whether part of the language or its canonical toolchain itself, or retrofitted with external tooling. > Code as if the person who takes over your codebase > is a crazed psychopath who knows where you live. Ah, this old saw. :-) For me personally, I try to minimize my _need_ for comments, to whatever extent that I can. This may take the form of introducing a named, but perhaps otherwise unnecessary, intermediate variable to hold some part of a computation, where the alternative is to make the computation itself part of a larger expression that would then be less obvious. Similarly, I may introduce a function returning a boolean to encapsulate some predicate behind a descriptive name. If a well-aimed type can make a comment superfluous, say by encapsulating some invariant of the data, and the language supports it, then by all means introduce a new type. If this sort of technique can make a comment entirely redundant with the code, then I favor removing the comment. On a related note, John Ousterhout recently had a long-running online "debate" with Robert Martin, the agile influencer. They recorded the results of this in a text file that was then uploaded to Github; I heard about it when John wrote to the mailing list for his book, "A Philosophy of Software Design". The subject of comments featured heavily in this discussion, as Martin is infamously averse to them and Ousterhout views them as essential. You may find it interesting: https://github.com/johnousterhout/aposd-vs-clean-code I'm not sure why Ousterhout, who has a long track record of building real systems, chose to give Martin, who does not have a track record of building real systems and further displays all the trappings of a charlatan, a platform for these topics, but he did. Sadly, when Ousterhout mentioned it on the mailing list, it failed to generate very much discussion. I had my own response, much of which I cleaned up and consolidated in my own response to their Java prime number generator example, and that I pushed to Github here: https://github.com/dancrossnyc/literateprimes/ - Dan C. From clemc at ccc.com Tue Jul 22 00:36:49 2025 From: clemc at ccc.com (Clem Cole) Date: Mon, 21 Jul 2025 10:36:49 -0400 Subject: [COFF] editor wars In-Reply-To: <20250721141257.GF15357@mcvoy.com> References: <20250721141257.GF15357@mcvoy.com> Message-ID: On Mon, Jul 21, 2025 at 10:13 AM Larry McVoy wrote: > > So many smart people I know love emacs. ditto. > > > I... I think it's the lisp aspect, if you don't love lisp, I don't think > you'll love emacs. > You might have a hit on something here. I learn TECO and then, as Lars pointed out, FINE on the PDP-10s before I saw UNIX. At the same time, I had been introduced to LISP in our comparative languages course (I wrote a mancala game, and Alpha/Beta solved using it). But I was never a LISP hacker on the PDP-10s. We primarily used SAIL and BLISS, so I suspect that's why, when I finally had the chance to switch to UNIX and learned EX, I decided it was too much trouble. There were just too many commands and weird sequences to learn again; I wasn't as good with it, so I gave up. I also suspect that since >>UCB<< original version of ex/vi was ubiquitous (and had been ported to PCs and eventually TOPS-20 but my PDP-10/20 days were long gone). The fact was that Emacs was not in those days (yes, there were lots of flavors, but each was different for the pc's, but it was not on other UNIX systems for a while), so that may have tainted my thinking. But when it did show up, Gosling EMACS (which begat Gnu) != Zimmerman Emacs [similar to the nvi/cim war of today]. However, I suspect that if I had grown up in the Lisp world, the comfort of having that would have been a strong drive to want it everywhere. But without that, the (re)learning curve was just too high and I >>was<< comfortable. It got the job done. BTW, I feel the same way about troff and LaTeX. I gave up Scribe from the PDP-10s/20s when I went to UNIX. The tool I had was nroff/troff. I became very proficient with it - better than I had ever been with Scribe. Scribe became unobtainium and Tex became the standard in PDP-10 and VMS land. Then folks tried to import a lot of Scribe into Tex, creating Latex, but by the time I had access to it, it was just too different; it was not worth the effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jul 22 00:45:49 2025 From: will.senn at gmail.com (Will Senn) Date: Mon, 21 Jul 2025 09:45:49 -0500 Subject: [COFF] editor wars In-Reply-To: <5aa82876-b245-4ab6-bede-80260fa53fbc@case.edu> References: <5aa82876-b245-4ab6-bede-80260fa53fbc@case.edu> Message-ID: I love lisp, but emacs, not so much. I do a lot of different operating systems and I found vi to be much more consistent, but I’m not knocking emacs, just not my cup of tea. Will Sent from my iPhone > On Jul 21, 2025, at 9:15 AM, Chet Ramey wrote: > > On 7/21/25 10:12 AM, Larry McVoy wrote: >>> On Mon, Jul 21, 2025 at 09:59:54AM -0400, Chet Ramey via COFF wrote: >>>> On 7/20/25 9:52 AM, Will Senn wrote: >>> >>>> As a vi guy, I cannot even understand emac's appeal. I've tried countless >>>> times, even going emacs only for a while... when I went back to vi, it was >>>> like old shoes, very comfortable. >>> >>> Because familiarity is very powerful. Lots of people mistake it for >>> intuitiveness. >> So many smart people I know love emacs. I forced myself to live in it >> for a year, not the emacs vi mode stuff, just straigth emacs. >> I never got to the point that I liked it. I think it's the lisp aspect, >> if you don't love lisp, I don't think you'll love emacs. > > I think it depends. You have to have a passing familiarity with lisp to > really take advantage of GNU emacs, but there are plenty of emacs-like > editors out there (I maintain one, based on microemacs from way back) > that have emacs-style key bindings and similar functionality. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > From lm at mcvoy.com Tue Jul 22 01:00:54 2025 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 21 Jul 2025 08:00:54 -0700 Subject: [COFF] editor wars In-Reply-To: References: <20250721141257.GF15357@mcvoy.com> Message-ID: <20250721150054.GG15357@mcvoy.com> On Mon, Jul 21, 2025 at 10:36:49AM -0400, Clem Cole wrote: > On Mon, Jul 21, 2025 at 10:13???AM Larry McVoy wrote: > But I was never a LISP hacker on the PDP-10s. We primarily used SAIL and > BLISS, so I suspect that's why, when I finally had the chance to switch to > UNIX and learned EX, I decided it was too much trouble. There were just > too many commands and weird sequences to learn again; I wasn't as good with > it, so I gave up. Please don't take this as an insult, Clem, you know I respect the heck out of you. And we've shown to have similar approaches to a lot of stuff, so in my view, maybe we have similar brains. At least in my case, I don't consider myself to be as smart as most of the really smart people I've worked with. In order to keep up, I had to work harder than they appeared to work. I'm wondering if maybe us "less smart" people, just don't have the extra cycles it takes to love emacs? Is it possible that if we had cycles to spare, we'd like emacs too? Is it possible that it takes more cycles to run emacs effortlessly? Maybe we like vi because it takes less of our brain so there is more left over for the actual work we are trying to do? And I don't consider myself or Clem to be not smart, we've both done a lot that shows intelligence. But I absolutely do not consider myself to be the smartest of the smart, not even close. On the last team I built, all of the core of that team were crazy smart, way, way ahead of me. It was hard work to keep up with them and I didn't always keep up. One of them read string theory papers in his spare time "for fun" he said. Bigger brain than mine for sure. --lm From clemc at ccc.com Tue Jul 22 01:05:56 2025 From: clemc at ccc.com (Clem Cole) Date: Mon, 21 Jul 2025 11:05:56 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: <20250720214637.GU15357@mcvoy.com> Message-ID: On Mon, Jul 21, 2025 at 10:24 AM Paul Winalski wrote: > .. that is why I've always considered the comments to be an integral > part of the code, and when doing code reviews I've refused to approve code > changes where the comments are too sparse or where the comments don't match > the code. > Amen. I've mentioned this to Paul before, but Mary Shaw's trick from the old CMU sophomore software engineering course was spot on. You were 3-4 person teams, and the entire class was working on the same project [when I took it, we were building an airline ticketing and equipment reservation system]. The first part required each team to write a specification for the project (which was collected and compared/graded against one that TAs had written). Then the TA gave everyone their "common" spec, which your team started to program for the first part of their spec. Then, two weeks later, the TA handed over your codebase to another team (and you were given the code from another team still). This process was repeated over the 12 weeks, 4 or 5 times as each part of the project was completed. You were not allowed to use your code base; instead, you had to build on the base provided by the TA for each section. [There was an escape clause of going to the TA if the code you got was a disaster, but then you got a different group's code, and you just lost time working on the earlier version - so it was easier/faster to fix any bugs you found]. People never wanted to be cursed by their classmates. The first thing you always did was do a code review and then run both the tests you had been given and your own against the base to see what you had. As a result, the students learned to write code that was clean, well-tested, and properly commented and documented, because their peers would be reviewing and depending on it. If you were serious, you certainly did not want to get a reputation for writing crap. The sad part is that I believe CMU discontinued that course a few years ago, because the graduate student TAs hated it. It could be a tremendous amount of work for them. BTW: IIRC that course was when I had a future Turning Award winner as well as someone else who would make a name in the Multics community as programming partners. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Tue Jul 22 01:20:34 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Mon, 21 Jul 2025 11:20:34 -0400 Subject: [COFF] editor wars In-Reply-To: <20250721150054.GG15357@mcvoy.com> References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> Message-ID: <5353f976-7043-40c2-ab63-fc7279e263a7@case.edu> On 7/21/25 11:00 AM, Larry McVoy wrote: > I'm wondering if maybe us "less smart" people, just don't have the extra > cycles it takes to love emacs? I don't think it's that. I think it's simpler: you put the time in to master something -- or at least become familiar with it. Mastery breeds familiarity breeds comfort. Even if after the fact you try to `spend time' with another tool or editor, you're bucking the already-established comfort level you've obtained. I have a working knowledge of vi -- readline has vi key bindings, and POSIX specifies them -- but I wouldn't say I have a comfort level there. Just enough to get around. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From paul.winalski at gmail.com Tue Jul 22 01:27:56 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 21 Jul 2025 11:27:56 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: When writing all but the most trivial bug fixes I always put in a comment referring to the bug report number. This helps with what can otherwise be a perplexing problem: "why is this bit of code there?" Good and copius comments were especially important in the days of handwritten assembly code. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Tue Jul 22 01:35:26 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Mon, 21 Jul 2025 11:35:26 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: On 7/21/25 11:27 AM, Paul Winalski wrote: > When writing all but the most trivial bug fixes I always put in a comment > referring to the bug report number.  This helps with what can otherwise be > a perplexing problem:  "why is this bit of code there?" I put those in the change log entries. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From imp at bsdimp.com Tue Jul 22 01:40:06 2025 From: imp at bsdimp.com (Warner Losh) Date: Mon, 21 Jul 2025 09:40:06 -0600 Subject: [COFF] editor wars In-Reply-To: <5353f976-7043-40c2-ab63-fc7279e263a7@case.edu> References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> <5353f976-7043-40c2-ab63-fc7279e263a7@case.edu> Message-ID: On Mon, Jul 21, 2025 at 9:20 AM Chet Ramey via COFF wrote: > > On 7/21/25 11:00 AM, Larry McVoy wrote: > > > I'm wondering if maybe us "less smart" people, just don't have the extra > > cycles it takes to love emacs? > > I don't think it's that. I think it's simpler: you put the time in to > master something -- or at least become familiar with it. Mastery breeds > familiarity breeds comfort. Even if after the fact you try to `spend > time' with another tool or editor, you're bucking the already-established > comfort level you've obtained. I learned emacs first because 'vi' was deemed too heavy-weight for or poor VAX 11/750. I'd used other non-modal editors prior to that (WordStar, EDT, and a raft of variants built on top of TECO-11 visual mode). It's modal vs non-modal for me that's the deal killer for having vi be my 'daily driver'. So it's not smart or not. It's what's familiar. non-modal editors are what I learned first, and I'm never going to outgrow that. Coupled with LISP that's LISPy enough for my editing needs, and I'm good to go. I can use the bits other folks have done to expand it, I can expand what I need and fix annoying bits of c-mode or whatever. > I have a working knowledge of vi -- readline has vi key bindings, and POSIX > specifies them -- but I wouldn't say I have a comfort level there. Just > enough to get around. Same. What do you mean I can't just type... Oh! Right! I gotta get into insert mode, there, ok, I can change my nameserver line in /etc/resolv.conf that DHCP got wrong (and now, to go debug that setup), or whatever the simple task is. It's an extra step for me to get into the swing of things. It also goes back to "do we use the extra keys on the keyboard or not" debate that was raging in the 80s. Were you an alt-meta-super fan, or a alt-meta-coke-bottle critic? Is F6 more natural (since you have 'paste' on it) or control-v? Emacs lives in the in between where it uses control and meta characters to get the job done, not just simple ASCII (and maybe the arrow keys) like vi traditionally fit into. It's far less than things like EDT, TPU, WordStar, etc in its use of function keys than they are, but assumes a wider interface than just hjkl or wasd. At one point I used to say "I know vi just well enough to get emacs working" though these days I can do a bit more than that. But in all the decades at this point of discussion on emacs vs vi, I've never shaken the feeling it's modal vs non-modal and 'fat' key set vs thin. The 'mine is bigger' feature set competitions just didn't ever ring really true. It was always 'my brain types and edits like this' at the end of the day, it seems.[*] Warner [*] Since this is my impression from hundreds of such conversations and debates, I'll grant that it's likely a gross simplification and some people chose vim because of syntax highlighting or emacs could analyze pinhead (or you, if you wanted the original ai-chat-bot Eliza). From coff at tuhs.org Tue Jul 22 01:44:47 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Mon, 21 Jul 2025 11:44:47 -0400 Subject: [COFF] editor wars In-Reply-To: References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> <5353f976-7043-40c2-ab63-fc7279e263a7@case.edu> Message-ID: <1aaa3aa2-5163-43e5-ad94-6ac38632bcdb@case.edu> On 7/21/25 11:40 AM, Warner Losh wrote: > On Mon, Jul 21, 2025 at 9:20 AM Chet Ramey via COFF wrote: >> >> On 7/21/25 11:00 AM, Larry McVoy wrote: >> >>> I'm wondering if maybe us "less smart" people, just don't have the extra >>> cycles it takes to love emacs? >> >> I don't think it's that. I think it's simpler: you put the time in to >> master something -- or at least become familiar with it. Mastery breeds >> familiarity breeds comfort. Even if after the fact you try to `spend >> time' with another tool or editor, you're bucking the already-established >> comfort level you've obtained. > > I learned emacs first because 'vi' was deemed too heavy-weight for or > poor VAX 11/750. I learned emacs first because I started on TOPS-20 first. Then when I moved to 4.2 BSD, emacs was there. There was no reason to learn vi then. > So it's not smart or not. It's what's familiar. Exactly. Everyone here is smart. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From clemc at ccc.com Tue Jul 22 01:47:56 2025 From: clemc at ccc.com (Clem Cole) Date: Mon, 21 Jul 2025 11:47:56 -0400 Subject: [COFF] editor wars In-Reply-To: <20250721150054.GG15357@mcvoy.com> References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> Message-ID: On Mon, Jul 21, 2025 at 11:00 AM Larry McVoy wrote: > > Please don't take this as an insult, Clem, No worries. > I'm wondering if maybe us "less smart" people, just don't have the extra cycles > it takes to love emacs? Maybe, but I've known a lot of smart people who stayed with ex/vi over Emacs. I never found Emacs any more intuitive than ex/vi - just a different learning curve. Since I came to UNIX from TSS and TOPS-10, I found that UNIX presented a steep learning curve. I was accustomed to having a programmable command system, editors, and specialized tools/programs to do specific things. Yes, the 10's had things like SUDS and ISPS, which we did not (yet) have in Unix land. And clearly, BLISS generated better code than C, so why would I give all that up? I was getting paid to program UNIX, so I learned to use it. The original value was that I was getting paid. But the idea of things like standard I/O, the pipeline, and >>small<< tools that I could reuse was intuitive. Yup, the command had strange names, but I learned to >>love<< find scripts and grep. I quickly discovered that, even on a small 11/40, I could accomplish a lot. I quickly became more effective than I was on the PDP-10 - the 10 forced every program to be its subsystem, and while what was there was excellent, I could not make it up -- i.e., I liked the tools approach way more than the give a man a fish approach. That said, given the capabilities I had in PDP-10 land, I still had an account on them to run SUDS when I needed to create a schematic as an example (CMU did not obtain UCDS for EE-CAD until my Senior year). FWIW: Ted Kowalski's PhD was in developing ISPS for UNIX, although by the time he finished, I had long since left. So the "special" tools that the PDP-10s had became less and less critical, but the >>value<< I received for learning UNIX was immense. I suspect that if I had been forced to use Emacs and found its value (like using m-lisp), like my UNIX investment, it might have been worth it. Indeed, many intelligent people I know share this view. But the key is I looked at what people did with Emacs and never thought, I want/need that feature. As I said, I was not a LISP person, so things like m-lisp were not valued. They liked it, but I could do everything they could that >>I desired<< to do. The mode/non-mode argument never bothered me before, so again, its value was not seen as necessary. > Is it possible that if we had cycles to spare, we'd like emacs too? Maybe - but (I think) it's a value proposition. If the cost is high and you don't see a return on investment. If it had been available, I might have even used it. We toyed with bringing RT-11 TECO from the Harvard tape up on our V6++ systems, but never did, as we were fluent with ed(1) and by then, fred(1) had shown up from Cornell [funny we did bring up the ddt as the early debuggers for V5 and V6v were weak and adb did not yet exist]. > On the last team I built, all of the core of that team were crazy smart, > way, way ahead of me. > Amen, brother - I always want people smarter than me on the team, and I can say that I have been thrilled to have that occur with most of the major projects I have been a part of. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Jul 22 03:58:02 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 21 Jul 2025 19:58:02 +0200 Subject: [COFF] editor wars In-Reply-To: <1aaa3aa2-5163-43e5-ad94-6ac38632bcdb@case.edu> References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> <5353f976-7043-40c2-ab63-fc7279e263a7@case.edu> <1aaa3aa2-5163-43e5-ad94-6ac38632bcdb@case.edu> Message-ID: <20250721175802.8tXuqnaM@steffen%sdaoden.eu> Chet Ramey via COFF wrote in <1aaa3aa2-5163-43e5-ad94-6ac38632bcdb at case.edu>: ... |Exactly. Everyone here is smart. idiot(ic) complains at this point --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From paul.winalski at gmail.com Tue Jul 22 05:46:24 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 21 Jul 2025 15:46:24 -0400 Subject: [COFF] editor wars In-Reply-To: References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> Message-ID: My beef with EMACS is that it's too finger-busy. All that ctrl-x prefix business. I'm not fond of vi either. The only vi command I ever learned was ESC-:q! so that I could get out of vi if I accidentally got into it. I was involved in developing products for both Linux and Windows. I did all my text editing on Windows and copied the files to Linux for building and testing. I like the joke about EMACS being an acronym for Escape-Meta-Alt-Ctrl-Shift. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Jul 22 06:53:40 2025 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 22 Jul 2025 06:53:40 +1000 (EST) Subject: [COFF] editor wars In-Reply-To: <5353f976-7043-40c2-ab63-fc7279e263a7@case.edu> References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> <5353f976-7043-40c2-ab63-fc7279e263a7@case.edu> Message-ID: On Mon, 21 Jul 2025, Chet Ramey via COFF wrote: > I have a working knowledge of vi -- readline has vi key bindings, and > POSIX specifies them -- but I wouldn't say I have a comfort level there. > Just enough to get around. I must be weird: I use VI, but EMACS key bindings in my shells. And I've never understood why EMACS doesn't end a file with a newline; I was forever cleaning up a former cow-orker's work. I guess it depends on whether you consider "\n" to be a line terminator (VI) or a line separator (EMACS). -- Dave, another Word*Star lover From coff at tuhs.org Tue Jul 22 06:57:43 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Mon, 21 Jul 2025 16:57:43 -0400 Subject: [COFF] editor wars In-Reply-To: References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> <5353f976-7043-40c2-ab63-fc7279e263a7@case.edu> Message-ID: <2f8dd646-1917-42fc-8c27-8534554ab3ab@case.edu> On 7/21/25 4:53 PM, Dave Horsfall wrote: > On Mon, 21 Jul 2025, Chet Ramey via COFF wrote: > >> I have a working knowledge of vi -- readline has vi key bindings, and >> POSIX specifies them -- but I wouldn't say I have a comfort level there. >> Just enough to get around. > > I must be weird: I use VI, but EMACS key bindings in my shells. They're usually the shell default, even though POSIX doesn't specify them. I have to say that the emacs bindings and bindable commands get the most attention, at least in bash/readline. The vi mode bindings are mostly what POSIX specifies plus some other useful ones from standalone vi. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From dave at horsfall.org Tue Jul 22 07:42:48 2025 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 22 Jul 2025 07:42:48 +1000 (EST) Subject: [COFF] editor wars In-Reply-To: References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> Message-ID: On Mon, 21 Jul 2025, Paul Winalski wrote: > I like the joke about EMACS being an acronym for Escape-Meta-Alt-Ctrl-Shift. Mine, I think (and I hadn't seen it before). -- Dave From mike.ab3ap at gmail.com Tue Jul 22 08:21:45 2025 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 21 Jul 2025 18:21:45 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: I work in an RF lab where coding is focused on DSP with radio signals sampled as I/Q, in-phase/quadrature, streams.  I'd guess our source code is about 50/50 code/comment.  It certainly isn't assembly, which I do remember having trouble reading my own code afterward.  But it's similar to commenting assembly in that complex math (as in real/imag rather than 'complicated') is not very clear to look at as code.  It never looks like the equations on paper, so comments try to bridge the gap - sometimes gulf. Because IQ sigs are bundled up as exp(j theta), python with its builtin support for complex numbers is amazing for quick efforts. When there is a real need for speed, well, I admit there's still the ol' grand daddy of formula translation... :-)  But C is there as well in our lab! Mike M On 7/21/25 11:27 AM, Paul Winalski wrote: > When writing all but the most trivial bug fixes I always put in a > comment referring to the bug report number.  This helps with what can > otherwise be a perplexing problem:  "why is this bit of code there?" > > Good and copius comments were especially important in the days of > handwritten assembly code. > > -Paul W. From joshnatis0 at gmail.com Tue Jul 22 08:26:56 2025 From: joshnatis0 at gmail.com (josh) Date: Mon, 21 Jul 2025 18:26:56 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: On Monday, July 21, 2025, Chet Ramey via COFF wrote: > On 7/21/25 11:27 AM, Paul Winalski wrote: > >> When writing all but the most trivial bug fixes I always put in a comment >> referring to the bug report number. This helps with what can otherwise be >> a perplexing problem: "why is this bit of code there?" >> > > I put those in the change log entries. > Does anyone else feel like this is still an unsolved problem? It seems git blame continues to be the state of the art for connecting a section of code to the “commit” (or analogous concept) in which it was added, which is where one would include context about why the change was made and connect it to the wider world (bug tracker, etc). There is a lot to say about a change which would be extraneous to include in the code as comments — real-world context (as mentioned), trade-offs considered / why specific implementation decisions were made, explanation and annotation, potential future steps, testing/validation, and even rich media demonstrating things that may be hard to express in text.[1] This all goes in the “pull request” UI on GitHub, or the email thread discussing a patch. Now why does all this only have a tenuous connection to the actual code once it’s merged? Any little nudge will override the git blame. Shouldn’t there be a more formal connection between the code and its history? (Not to mention one doesn’t always think to check the history when reading code, that only becomes necessary when something isn’t clear. Let’s be honest, how often do we go out of our way to do this?). Maybe this is a fundamental trade-off of code being plain text rather than being stored as some rich/structured representation. Now that I wrote this all out, I’m starting to feel like I’ve heard flame wars about git blame before, so I’m sorry if I ended up beating a dead horse on accident :-P. Josh [1] I can see how having an outlet for all these things can remove incentives to make the code itself understandable without external reference, which is pretty problematic... -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Tue Jul 22 08:44:41 2025 From: coff at tuhs.org (segaloco via COFF) Date: Mon, 21 Jul 2025 22:44:41 +0000 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: On Monday, July 21st, 2025 at 3:27 PM, josh wrote: > On Monday, July 21, 2025, Chet Ramey via COFF wrote: > > > On 7/21/25 11:27 AM, Paul Winalski wrote: > > > > > When writing all but the most trivial bug fixes I always put in a comment referring to the bug report number. This helps with what can otherwise be a perplexing problem: "why is this bit of code there?" > > > > > > I put those in the change log entries. > > > Does anyone else feel like this is still an unsolved problem? > > It seems git blame continues to be the state of the art for connecting a section of code to the “commit” (or analogous concept) in which it was added, which is where one would include context about why the change was made and connect it to the wider world (bug tracker, etc). > > There is a lot to say about a change which would be extraneous to include in the code as comments — real-world context (as mentioned), trade-offs considered / why specific implementation decisions were made, explanation and annotation, potential future steps, testing/validation, and even rich media demonstrating things that may be hard to express in text.[1] > > This all goes in the “pull request” UI on GitHub, or the email thread discussing a patch. Now why does all this only have a tenuous connection to the actual code once it’s merged? Any little nudge will override the git blame. Shouldn’t there be a more formal connection between the code and its history? (Not to mention one doesn’t always think to check the history when reading code, that only becomes necessary when something isn’t clear. Let’s be honest, how often do we go out of our way to do this?). > > Maybe this is a fundamental trade-off of code being plain text rather than being stored as some rich/structured representation. > > Now that I wrote this all out, I’m starting to feel like I’ve heard flame wars about git blame before, so I’m sorry if I ended up beating a dead horse on accident :-P. > > Josh > > [1] I can see how having an outlet for all these things can remove incentives to make the code itself understandable without external reference, which is pretty problematic... Something I've taken to in disassembly analysis that has then crept into my assembly coding as well is placing C-like flow control/conditional operations in comments and using indentation to denote loops and such. For instance (the naked : and :- in ca65 syntax are like cheap local labels e.g. 1: and 1b in AT&T-like assemblers): ldx #(player_lives_b-player_lives)-1 : ; for (value of per_player_values) { lda player_lives, x pha lda player_lives_b, x sta player_lives, x pla sta player_lives_b, x dex bpl :- ; } This is a loop that swaps player stats when switching from player 1 to player 2 in Super Mario Bros. (6502 assembly) and here I've used indentation and a for-of loop (not C, JavaScript, but still visually comparable) so that way it's a little more obvious on first inspection this is a loop over the per-player-values array for each member. Granted it is literally just commentary, but I can't tell you how many times this sort of thing has helped me narrow down exactly where something is happening. I've also found it nice in some graphical editors as they'll automatically offer to "roll up" code between two semicolons from other languages, so I can similarly shutter bits of an assembly file based on how deeply nested in the control flow they are, ignoring loops/conditions I don't care about when reading through something. Also when writing my own code, it sometimes helps me ensure I'm keeping things relatively sensible, I've more than once rewritten something to be clearer when I tried to wrap it in comments like this and just couldn't make heads or tails of the segregation of the different conditions. Of course, the final code is the assembly, not the commentary, so it's important to recognize that. I prefer it to the no-indentation and comments on every line approach I see in some assembly stuff. Of course ymmv depending on the assembler in use, but this has been quite helpful in my 6502 stuff with the cc65 suite. - Matt G. From sjenkin at canb.auug.org.au Tue Jul 22 09:01:35 2025 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Tue, 22 Jul 2025 09:01:35 +1000 Subject: [COFF] editor wars In-Reply-To: References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> Message-ID: I heard about RMS acquiring RSI of the left wrist, presumably from the ‘ctrl-x’ plus other keys. 1. Is this a ’thing’ or blown out of proportion? 2. Since Function keys & they were programmable, I gather ‘gun’ emacs users don’t have the RSI problem. Is this correct? 3. I’ve never heard of people with RSI from using ‘vi’/‘vim’. Is this right? > On 22 Jul 2025, at 05:46, Paul Winalski wrote: > > My beef with EMACS is that it's too finger-busy. All that ctrl-x prefix business. I'm not fond of vi either. The only vi command I ever learned was ESC-:q! so that I could get out of vi if I accidentally got into it. I was involved in developing products for both Linux and Windows. I did all my text editing on Windows and copied the files to Linux for building and testing. > > I like the joke about EMACS being an acronym for Escape-Meta-Alt-Ctrl-Shift. > > -Paul W. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Tue Jul 22 09:30:23 2025 From: davida at pobox.com (David Arnold) Date: Tue, 22 Jul 2025 09:30:23 +1000 Subject: [COFF] editor wars In-Reply-To: References: Message-ID: <5BCBCE7F-7E0A-44F1-B46C-F4A659E9DD7D@pobox.com> > On 22 Jul 2025, at 09:02, sjenkin at canb.auug.org.au wrote: <…> > 3. I’ve never heard of people with RSI from using ‘vi’/‘vim’. Is this right? The Xahlee article you cited mentioned that John Ousterhout was both an RSI sufferer and a vi user. d From imp at bsdimp.com Tue Jul 22 09:47:02 2025 From: imp at bsdimp.com (Warner Losh) Date: Mon, 21 Jul 2025 17:47:02 -0600 Subject: [COFF] editor wars In-Reply-To: <5BCBCE7F-7E0A-44F1-B46C-F4A659E9DD7D@pobox.com> References: <5BCBCE7F-7E0A-44F1-B46C-F4A659E9DD7D@pobox.com> Message-ID: On Mon, Jul 21, 2025 at 5:30 PM David Arnold wrote: > > > On 22 Jul 2025, at 09:02, sjenkin at canb.auug.org.au wrote: > > <…> > > > 3. I’ve never heard of people with RSI from using ‘vi’/‘vim’. Is this right? > > The Xahlee article you cited mentioned that John Ousterhout was both an RSI sufferer and a vi user. I've know several RSI suffers that used vi. Several that used emacs. No good data, that I've seen, on which one is better or worse. I did have a conversation with my doctor that told me that hands between keyboard and mouse make it worse, but I don't know where he got that idea: just from his patience or some study. I know I do better with a real mouse and keeping my hands off it as much as possible. Warner From lm at mcvoy.com Tue Jul 22 10:08:16 2025 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 21 Jul 2025 17:08:16 -0700 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: <20250722000816.GN15357@mcvoy.com> On Mon, Jul 21, 2025 at 06:26:56PM -0400, josh wrote: > On Monday, July 21, 2025, Chet Ramey via COFF wrote: > > > On 7/21/25 11:27 AM, Paul Winalski wrote: > > > >> When writing all but the most trivial bug fixes I always put in a comment > >> referring to the bug report number. This helps with what can otherwise be > >> a perplexing problem: "why is this bit of code there?" > >> > > > > I put those in the change log entries. > > > > Does anyone else feel like this is still an unsolved problem? > > It seems git blame continues to be the state of the art for connecting a > section of code to the ???commit??? (or analogous concept) in which it was > added, which is where one would include context about why the change was > made and connect it to the wider world (bug tracker, etc). This is the place where I find git most lacking. BitKeeper did this quite differently, we have a graph per file plus the repository graph, git just has the latter. When debugging in BitKeeper, we had a GUI called revtool that gave you the graph in the top and diffs or file in the bottom. So you find the version that you want to look around, hit d for diffs, wander around, as you hover over each line you see the checkin comments (instantly), and eventually you find the suspect line. double click on it and it warps you out to the commit in csettool. So you go inside out. Git goes outside in. Drives me crazy so I still use BitKeeper. But I digress, the combination of git blame and git log is going to get you there, I agree it is painful. From grog at lemis.com Tue Jul 22 12:01:13 2025 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 22 Jul 2025 12:01:13 +1000 Subject: [COFF] LISP (was: editor wars) In-Reply-To: <20250721141257.GF15357@mcvoy.com> References: <20250721141257.GF15357@mcvoy.com> Message-ID: On Monday, 21 July 2025 at 7:12:57 -0700, Larry McVoy wrote: > So many smart people I know love emacs. I forced myself to live in it > for a year, not the emacs vi mode stuff, just straigth emacs. > > I never got to the point that I liked it. I think it's the lisp > aspect, if you don't love lisp, I don't think you'll love emacs. Not that I don't like LISP, but it's not necessary for Emacs. The first Emacs-like editors that I used didn't have any LISP support. I don't think that LISP really influences a normal user's interaction with Emacs. Greg -- Sent from my desktop computer. Finger grog at 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From grog at lemis.com Tue Jul 22 12:31:03 2025 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 22 Jul 2025 12:31:03 +1000 Subject: [COFF] [TUHS] Re: Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: <20250721100308061059.819cdc08@Espresso.Rhein-Neckar.DE> References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> <20250721100308061059.819cdc08@Espresso.Rhein-Neckar.DE> Message-ID: [removing TUHS] On Monday, 21 July 2025 at 10:03:08 +0200, Hauke Fath wrote: > On Mon, 21 Jul 2025 14:03:38 +1000, "Greg 'groggy' Lehey" wrote: >>> >>> Most of the emacs GUI adaptations assume that it's THE instance of the >>> editor. >> >> You don't say which. I only know GNU Emacs. Looking at the FreeBSD >> Ports Collection, not even xemacs seems to have survived. > > That would be more a problem of the FreeBSD ports collection than of > xemacs, if I may say so as the pkgsrc xemacs* package maintainer. Some > Linuxen ship xemacs packages, too - Gentoo, Debian come to mind. Yes, agreed. It was there in the CVS days, and I was rather surprised to find that it was no longer there. Greg -- Sent from my desktop computer. Finger grog at 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From grog at lemis.com Tue Jul 22 12:23:31 2025 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 22 Jul 2025 12:23:31 +1000 Subject: [COFF] GUIs: There can only be one (was: Not really Emacs wars ...) In-Reply-To: <20250721115232.GC231115@mit.edu> References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> <20250721115232.GC231115@mit.edu> Message-ID: [Removing TUHS again] On Monday, 21 July 2025 at 7:52:32 -0400, Theodore Ts'o wrote: > On Mon, Jul 21, 2025 at 02:03:38PM +1000, Greg 'groggy' Lehey wrote: >>> With multiple terminals, I can have multiple editors with different >>> contexts. With the GUI, it all gets dumped together. >> >> Not in my experience (GNU Emacs 29.4 (build 1, >> amd64-portbld-freebsd13.3, GTK+ Version 3.24.43, cairo version >> 1.17.4). I have four displays on my server 0, and also 4 instances of >> Emacs: one on :0.1 and three on :0.2. > > Yeah, it doesn't work that way for me using GNU emacs on Debian > either. The way I describe, or the way Warner describes? > Many decades ago I did force the behaviour that you describe; it > involved setting EDITOR to emacsclient, and then running > (server-start) in my ~/.emacs.el. That's a painful way to work around the issue. Nothing against emacslient; I'm using it to write this message. But it's not necessary. I didn't have any problems with Emacs in my Linux days. > This was a feature back when I was running emacs on BSD 4.3 with a > Vaxstation II/RC with 2 MiB of memory (Digital had put epoxy into > the backplane so you couldn't add more memory to their > memory-starved inexpensive model), but now that I buy my own > desktops with 64 GiB of memory, I really don't care that emacs is > "eight megabytes and constantly swapping" (well, not swapping; I > don't configure swap any more :-) Eight megabytes? Nowadays that fits into L2 cache :-) But why do we have this disconnect? My guess is our different interpretation and use of "GUI". I assume that most of us are using X, though presumably some (you?) might be using Wayland. There's nothing in X (nor, I think, in Wayland) that precludes running multiple instances of the same program. But programs like firefox refuse to do so, connecting to instances already running, even if they're on different displays, or even on different machines. Emacs, like most programs, doesn't do that. So could your window manager (GNOME?) be to blame? How do you start Emacs? I do it via a window manager (fvwm3) that just runs the program. Could it be that your window manager tries to be cleverer? Greg -- Sent from my desktop computer. Finger grog at 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From coff at tuhs.org Tue Jul 22 23:33:43 2025 From: coff at tuhs.org (Chet Ramey via COFF) Date: Tue, 22 Jul 2025 09:33:43 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: <66b970bc-d456-45e4-965f-fecea73f63cb@case.edu> On 7/21/25 6:26 PM, josh wrote: > On Monday, July 21, 2025, Chet Ramey via COFF > wrote: > > On 7/21/25 11:27 AM, Paul Winalski wrote: > > When writing all but the most trivial bug fixes I always put in a > comment referring to the bug report number.  This helps with what > can otherwise be a perplexing problem:  "why is this bit of code > there?" > > > I put those in the change log entries. > > > Does anyone else feel like this is still an unsolved problem? > > It seems git blame continues to be the state of the art for connecting a > section of code to the “commit” (or analogous concept) in which it was > added, which is where one would include context about why the change was > made and connect it to the wider world (bug tracker, etc). I don't like commit messages that are paragraph length. That seems more appropriate for a separate change log. > Maybe this is a fundamental trade-off of code being plain text rather than > being stored as some rich/structured representation. This sounds like some of the `literate programming' strategies, which interleave the code and its documentation. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From imp at bsdimp.com Wed Jul 23 00:44:48 2025 From: imp at bsdimp.com (Warner Losh) Date: Tue, 22 Jul 2025 08:44:48 -0600 Subject: [COFF] Code/comment Ratios Style In-Reply-To: <66b970bc-d456-45e4-965f-fecea73f63cb@case.edu> References: <66b970bc-d456-45e4-965f-fecea73f63cb@case.edu> Message-ID: On Tue, Jul 22, 2025 at 7:33 AM Chet Ramey via COFF wrote: > > On 7/21/25 6:26 PM, josh wrote: > > On Monday, July 21, 2025, Chet Ramey via COFF > > wrote: > > > > On 7/21/25 11:27 AM, Paul Winalski wrote: > > > > When writing all but the most trivial bug fixes I always put in a > > comment referring to the bug report number. This helps with what > > can otherwise be a perplexing problem: "why is this bit of code > > there?" > > > > > > I put those in the change log entries. > > > > > > Does anyone else feel like this is still an unsolved problem? > > > > It seems git blame continues to be the state of the art for connecting a > > section of code to the “commit” (or analogous concept) in which it was > > added, which is where one would include context about why the change was > > made and connect it to the wider world (bug tracker, etc). > > I don't like commit messages that are paragraph length. That seems more > appropriate for a separate change log. As someone who has been on a project for the last 30 years (FreeBSD) that's encouraged long, complete commit messages, I have to strongly disagree. Separate change log are useless in comparison. If I go to the gnu binutils and find a changelog entry that says something about fixing some mips symbol type thing, even with specifics, I don't know the code that it affected. With that same information in the commit log, when I git-blame the code, I can find why a line of code changed over time, and even the other changes associated with it. That metadata is quite useful to understanding how we got here with the code. Having had to look at projects that only added it to the commit log, it's a night and day difference. When I've looked at other projects and see messages like 'fix, ok deraat' I find myself angry. Why was it a bug? why was it the right fix? etc. For example, how do you put this into a change log such that someone could find it years from now: commit 73e1bd71427794ee5496fdeb2bdaa04b05b0c35b Author: Warner Losh Date: Mon Jul 21 20:50:50 2025 -0600 cam/mmc: Remove stray xpt_path_inq Turns out, we don't use the results of xpt_path_inq here at all. And it also causes problems. Since it calls xpt_cam_inq to do this useless XPT_PATH_INQ, it loses the original priority we had for the CCB. This priority should be CAM_PRIORITY_XPT, but was originally set to CAM_PRIORITY_NORMAL. This worked to enumerate the device because no normal priority CCBs were queued by anything doing the enumeration. However, when I changed xpt_path_inq to use the more proper PRIORITY_NONE, it exposed this bug because queued CCBs with PRIORITY_NONE sometimes won't run. This caused the probe device to stop after its first operation. Removing the xpt_path_inq means we no longer step on the important fields we get from xpt_schedule, allowing probing to work correctly. Noticed by: bz@ Sponsored by: Netflix I'll admit I could have worded parts of that a little better. Now git blame will show that I removed this call, and give a good background for why (and yes, this condition was turned into an KASSERT after fixing the other bugs that the KASSERT found). I could have made my future self or future colleges mad by just saying 'remove xpt_path_inq call' since they'd have no idea why, or the background. How the heck would I have found this in a changelog in 5 or 10 years time? Especially if I was looking for all commits that touched xpt_path_inq because I suspected one elsewhere in the code of causing problems too? Warner From paul.winalski at gmail.com Wed Jul 23 01:00:13 2025 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 22 Jul 2025 11:00:13 -0400 Subject: [COFF] Code/comment Ratios Style In-Reply-To: References: Message-ID: On Mon, Jul 21, 2025 at 6:26 PM josh wrote: > On Monday, July 21, 2025, Chet Ramey via COFF wrote: > >> On 7/21/25 11:27 AM, Paul Winalski wrote: >> >>> When writing all but the most trivial bug fixes I always put in a >>> comment referring to the bug report number. This helps with what can >>> otherwise be a perplexing problem: "why is this bit of code there?" >>> >> >> I put those in the change log entries. >> > > Does anyone else feel like this is still an unsolved problem? > > Yes. Change tracking is just one facet of the larger problem of source code control and configuration management. The first change tracking programs such as SCCS and DEC CMS tracked changes on a per-file basis. If a change set involved more than one file, you had to track that information elsewhere. Later change tracking systems added the concept of a change set. > There is a lot to say about a change which would be extraneous to include > in the code as comments — real-world context (as mentioned), trade-offs > considered / why specific implementation decisions were made, explanation > and annotation, potential future steps, testing/validation, and even rich > media demonstrating things that may be hard to express in text.[1] > > In the shops I've worked at we used our bug-tracking system for that. At DEC we created pseudo-"bugs" in the tracking system for new development. That way all of the information about what was changed and why was in one place. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Jul 23 10:57:24 2025 From: athornton at gmail.com (Adam Thornton) Date: Tue, 22 Jul 2025 17:57:24 -0700 Subject: [COFF] editor wars In-Reply-To: References: <20250721141257.GF15357@mcvoy.com> <20250721150054.GG15357@mcvoy.com> Message-ID: I am definitely not one of the brighter people on this list, but I am an Emacs user. The reason why is very simple. I was introduced to Unix systems the summer I was 17, when I was working in a physics lab at UT Austin. There were computers there I needed to use. One of the other people in the lab, when I was like, "how do I write a program?" was like, "OK, type 'emacs' and hit return, then type Ctrl-h then t". So I did. Decades later, here I still am. Adam On Tue, Jul 22, 2025 at 12:12 AM Dave Horsfall wrote: > On Mon, 21 Jul 2025, Paul Winalski wrote: > > > I like the joke about EMACS being an acronym for > Escape-Meta-Alt-Ctrl-Shift. > > Mine, I think (and I hadn't seen it before). > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Wed Jul 23 22:54:26 2025 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Wed, 23 Jul 2025 08:54:26 -0400 Subject: [COFF] editor wars In-Reply-To: <5C33D23C-F676-4FCD-A6C1-2FB9FBE44D47@gmail.com> References: <5C33D23C-F676-4FCD-A6C1-2FB9FBE44D47@gmail.com> Message-ID: >From the DEC TECO manual: Mung - A recursive acronym for “Mung Until No Good”; an act applied by novice TECO users to their source files. Yup, I did that. -Mike Markowski On Tue, Jul 22, 2025 at 9:42 PM Milo Velimirović wrote: > And nobody’s even mentioned TECO. (Where’s my asbestous suit?) > -------------- next part -------------- An HTML attachment was scrubbed... URL: