- COFF - www.tuhs.org

by Warren Toomey

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

4 hours, 48 minutes

14
24
0 0

Re: [TUHS] Re: Not really Emacs wars (was: foreground/background vs. Windowing)

by Greg 'groggy' Lehey

[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(a)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

17 hours, 17 minutes

1
0
0 0

Not really Emacs wars (was: foreground/background vs. Windowing)

by Greg 'groggy' Lehey

[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(a)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

17 hours, 25 minutes

3
4
0 0

editor wars

by Will Senn

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

17 hours, 47 minutes

15
31
0 0

Re: editor wars

by Lars Brinkhoff

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.

1 day, 5 hours

2
1
0 0

Re: COFF Digest, Vol 78, Issue 1

by Will Senn

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(a)tuhs.org wrote: > > Send COFF mailing list submissions to > coff(a)tuhs.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > coff-request(a)tuhs.org > > You can reach the person managing the list at > coff-owner(a)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 <paul.winalski(a)gmail.com> > Subject: [COFF] Re: editor wars > To: coff(a)tuhs.org > Message-ID: > <CABH=_VSdx+ySq5VKrRY5d-dzdVfQ1PgBh0J4A4mFS+t-R0MX1w(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="000000000000095b69063a5e382b" > >> On Sun, Jul 20, 2025 at 10:02 AM Will Senn <will.senn(a)gmail.com> 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. >

1 day, 22 hours

1
0
0 0

Personal Preference vs Group Productivity (was Re: [TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference))

by Dan Cross

[TUHS to Bcc; Cc'ed to COFF to redirect for follow-ups] On Sun, Jul 20, 2025 at 8:24 AM Christian Hopps <chopps(a)chopps.org> wrote: > Larry McVoy <lm(a)mcvoy.com> 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.

1 day, 23 hours

1
0
0 0

Re: C with Improvements :-)

by Douglas McIlroy

> Overloading bit shifting operators to implement stream I/O was a repellent choice Without commenting on this judgement, I can tell how the convention came about in a casual conversation. I was perhaps the earliest serious experimenter with C++ overloading, for a constructive solid geometry package in which arithmetic operators were overloaded for matrices and vectors, and boolean operators were overloaded for union and intersection of geometric objects. I've forgotten how object subtraction (e.g. to drill a hole) was represented. Sadly, the symbol vocabulary for overloading was fixed, which meant that two vector products (dot and cross) vied for one operator. Joe Condon put me onto an interesting analog of quotient and remainder in 3D. The quotient. of two vectors, q=a/b is the ratio of the projection of a onto b to b and the remainder r=a%b is the component of a perpendicular to b, The usual quotient-remainder formula holds::a = q*b + r. Once, while discussing some detail of overloading, Bjarne remarked that he'd like to find an attractive notation for stream IO, which printf certainly is not. << and >> immediately popped into my mind. They've been in the language ever since. Equally casually, there was no discussion about the set of operator symbols, so C++ did not come up with a convention for symbol syntax, such as that of Haskell. Doug

4 weeks

3
2
0 0

[TUHS] Texas UNIX Users Conference 1981

by norman＠oclsc.org

This note gets a bit COFF-y; please redirect any replies to that list. USENIX Summer 1981, in Austin TX. First USENIX conference I ever attended, and the first to which I travelled by train-- mostly. I was somewhat shy about travelling in those days, but my Caltech colleague Mark Bartelt talked me into going, and suggested going by train. Except by the time I booked the trip there was space available only from Los Angeles to San Antonio and back, not onward from San Antonio to Austin. But in those days I did a bit of cycle touring, often in the company of my friend Brian Foster. Brian was also a co-worker at the time, and was interested in attending too. So we decided to travel together by train (in coach) to San Antonio, arriving around 05h30, and spent the rest of that day cycling, mostly up the frontage roads beside I-35, to Austin. After the conference we cycled back, mostly at night, which was somewhat spooky (I remember seeing a thunderstorm off on the horizon but we didn't get rained on) but saved us a second dose of sunburn. They checked into a motel for a day and a night until the return train came through at 02h55. I have gone by train to nearly every other conference I've attended since, but never again have I cycled. It was a fun ride but a harder one than expected. In those days of paper mapes, we visited the Caltech geography department and plotted out what looked like a fairly smooth route, with a slow but steady climb. The topo map we used had a resolution of 50' altitude. Evidently the constant, sometimes steep hills between San Antonio and Austin are all no more than 49' tall. It was a good conference too. One memory that sticks in my head was Jim Joyce using Tinker Toys as a metaphor for connecting Unix tools together. Norman Wilson Toronto ON

4 weeks

1
0
0 0

Re: C with Improvements :-)

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > This will probably get me tarred and feathered, but I have a couple of > gripes about C Your points are not about C's semantics, and only sort of about C's syntax; they are more formatting. In fact, it would be really easy to write something to switch a module betweeen your preferred formatting, and 'standard' (for the local value of 'standard') formatting. A minor comment about your first point. I was just reading some old code of mine, and ran across a procedure declaration of the form: foo(string, special) char *string, special; Your preferred form (_without_ changing C's _formal_ syntax) that puts the indirection level with the type has the problems that i) it would make the declaration above potentially confusing (unless one mentally edits the line back to 'classic' C formatting as one reads it; is 'special' a 'char', or a 'pointer to char'; the 'classic' form is quite clear about that); ii) one can only list a single variable per line without changing C's syntax. E.g. (in standard C) if you want to have two pointers declared on one line one would have to say (in standard C): char* ptra, *ptrb; In short, there are good reasons to associate the indirection level with the variable (standard C), and not with the type (yours). Although I gather that you'd probably like to change C's formal syntax, to associate the indirection level with the type, not with the variable. So one could say: char* ptra, ptrb; One could no longer, though, say: char *string, special; One change I would have made to C, in the past, was to add valof/resultis (from BCPL; lacking in C). That's because C macros that return values _have_ to use _only_ expressions (e.g. ((expr0) ? expr1 : expr2)), not more complex code like 'case' (which valof/resultis would let you do). Of course, modern compilers do optimizations that make that a lot less necessary. The thing I would still add to C is condition handling (although I have written assembler packages that added a very efficient one to C without changing the C language; and JTW and someone did a less capable one entirely in C - mine had unwind protects). Explaining why condition handlers are a good thing I don't have the time/energy to do right now, but I can explain it if people want to hear it. Noel

4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF