Readonly Characters Are a Big Deal

Postedabout 2 months agoActiveabout 1 month ago

vinhnx

43 points

5 comments

matklad.github.ioTechstory

calmpositive

Debate

0/100

ProgrammingText EncodingSoftware Development

Key topics

Programming

Text Encoding

Software Development

The article discusses the importance of readonly characters in programming, particularly in text encoding, and its implications for software development, though there is no community discussion to provide additional context.

Snapshot generated from the HN discussion

Discussion Activity

Light discussion

First comment

Peak period

Day 9

Avg / period

Key moments

01Story posted
Nov 12, 2025 at 12:04 AM EST
about 2 months ago
Step 01
02First comment
Nov 20, 2025 at 6:35 PM EST
9d after posting
Step 02
03Peak activity
5 comments in Day 9
Hottest window of the conversation
Step 03
04Latest activity
Nov 20, 2025 at 8:53 PM EST
about 1 month ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (5 comments)

Showing 5 comments

tdeck

about 1 month ago

2 replies

This reminds me of how this 3270 terminal worked. You sent the terminal a bunch of text to display, and a list of editable regions on the screen. Then only when you edited some things and hit enter were the editable regions sent back. It led to some interesting UIs compared to a typical terminal.

somat

about 1 month ago

1 reply

And it was bad at other use cases, having used both (3270 and vt) you can do 3270 workloads on a vt(granted less efficiently) but vt style asynchronous updates were very hard on a 3270.

If I had to pick one I would pick the vt.

And footnote, while technically I have worked with 3270's, my experience was using rexx on vse/cms. That is to say my use of the 3270 was hampered by about 5 levels of application framework, perhaps if I used them more directly I would be more charitable.

kragen

about 1 month ago

Right, the great advantage of the 3270-style block-mode model was that your 0.5-MIPS mainframe didn't have to handle an interrupt for every keystroke, so it could serve, I don't know, 100 terminals. Same as HTML <form> and half-duplex line-mode terminals with local echo.

An in-between version is how csh and vi would set eol2 (I think?) to ^[ so that most user interaction could be done in "cooked mode" until you hit ESC or ^D. This still required an interrupt for every keystroke on your 1-MIPS PDP-11, but at least it didn't require a context switch to the shell or editor process in order to echo normal printing characters. The kernel would handle echoing characters back to the terminal, deleting characters with ^? or ^H, and deleting words with ^W.

(As I understand it. I used csh and vi, but never on a PDP-11.)

actionfromafar

about 1 month ago

And it had on device buffering, so you could punch in a bunch of commands and be sure they would be received.

CGamesPlay

about 1 month ago

Neovim and vim both support different APIs for something similar that seems like it isn't quite as useful as Emacs version for this use case. Vim has textprops and Neovim has extmarks, and while you could implement something that made these read-only, it doesn't seem like there is just an option to make it so. Both features seem mostly designed to support virtual text / compiler diagnostics, rather than enabling Magit-style interfaces.

I would love to see more buffer-centric interfaces in vim (fugitive, oil) and less popup-centric interfaces (lazy, mason).

View full discussion on Hacker News

ID: 45896554Type: storyLast synced: 11/21/2025, 5:22:03 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN