Per_Bothner

I haven't figured out how to flag a comment as offense - but the term "zog soldier" is anti-semitic and does not belong on HN.

"Defenestrate" was not in my list, but it's a word I would have gotten, as I know it from: (1) An A.C. Clarke short story ("The Defenestration of Ermintrude Inch", in "Tales from the White Hart", if I remember correctly); and (2) The Defenstration of Prague (I have visited Prague Castle - there were apparently multiple defenestrations there). It's an interestingly (amusingly?) macabre word. (It also helps that I know high-school French and German plus understand Swedish as being very close to Norwegian.)

"Frugal" most definitely does not mean "rather over the top" unless that is some new slang meaning I've never heard of.

Not always, but in this case the superior product (i.e. VHS) won. At initial release, Beta could only record an hour of content, while VHS could record 2 hours. Huge difference in functionality. The quality difference was there, but pretty modest.

Kawa predates Clojure by a decade. (Kawa work started 1996; Clojure's initial release was 2007.) Also, Clojure isn't really focused on high performance, while that has always been a priority for Kawa, which generates bytecode similar to Java, especially if you include suitable type annotations. (It is likely Clojure have have improved in this respect - they have a lot more people working on it.)

What a blast from the past! I too remember with pleasure the days working with Anthony Green (and others) at Cygnus. I like to boast that (apart from Java) Kawa Scheme is the oldest compiler-based language implementation still available for the JVM.

"COBOL uses a fixed width character format for all data (yes even for COMP). If you want a four digit number, then you have to use 4 character positions."

That is incorrect. USAGE COMP will use binary, with the number number of bytes depending on the number of digits in the PIC. COMP-1 specifically takes 4 bytes. COMP-3 uses packed decimal (4 bits per digits).

For me Tauri/Wry starts up pretty instantaneous. This is using Wry as the renderer for the DomTerm terminal emulator (https://domterm.org), invoked with 'domterm -Bwry'. This is on Fedora Linux 41 x64. Admittedly using a rather old version of Wry (0.43.1) with webkitgtk 2.46.5 - I haven't had time to update.

The libwebsockets server (https://libwebsockets.org) supports serving directly from zip archives. Furthermore, if a URL is mapped to a compressed archive member, and assuming the browser can accept gzip-compressed files (as most can), then the compressed data is copied from archive over http to the browser, without de-compressing or conversion by the server. The server does a little bit of header fiddling but otherwise sends the raw bytes to the browser, which automatically decompresses it.

Completion for program P should be written and maintained by the "owner" of program P - and installed with program P. This is of course difficult when there are many different "shells" that each have their own "language" for specifying completions. A multi-shell completion library can help with this problem.

To me it make sense that completion for program P should be handled by program P itself. That way, completions are unlikely to get out of sync with the application, and the completion handler can use the same option parser as the application. A way to do this is to use a special "hidden" switch to request completion.

Specifically the DomTerm terminal emulator (https://domterm.org) handles its own completions. Bash allows you to register a command that handles completions for some other command. The following tells bash that to handle completions for the domterm command it should call domterm with the magic "#complete-for-bash" option followed by the existing line and position.

    complete -o nospace -C 'domterm "#complete-for-bash" "$COMP_LINE" "$COMP_POINT"' domterm

When domterm is run with "#complete-for-bash" as the first argument (chosen to avoids accidental use) it processes the remaining arguments, and prints out the completion suggestions to bash.

I don't know how to do something similar for other shells; suggestions welcome. Some other shells (such as Fish) include help text as part of the suggested completions. Handling that would require a more complex protocol. Perhaps one that returs a result in JSON format?

If a such a protocol were standardized (perhaps invoked by a "#completions-as-json" option?), we just need to solve a final piece of the puzzle: How does a shell know if a command understands the "#completions-as-json" option? My suggestion is that we define a new keyword-value pair in the "desktop" file specification; the shell would search for a P.desktop file,

On Gnome, the Super (Windows) key does an Expose (show windows reduced-size and non-overlapping) and lets you launch applications (and more). On KDE 5, the Super key brings up the Application Launcher, which is nice. And Super+W (which isn't too painful to type) does an Expose. But it would be nice if there was an option for Super to do an Expose and bring up Application Launcher.

And people may judge you if you don't react in the way people think "normal people" react. People have been convicted of murder because police or juries though they didn't react the way they were "supposed to".

Here is a screenshot: https://github.com/xtermjs/xterm.js/pull/4519#issue-17129655...

I am working on a re-write (https://github.com/xtermjs/xterm.js/issues/4800) of the xterm.js "BufferLine" data structures that (among other benefits) could potentially support variable-width fonts in the terminal. Instead of a 2-dimensional grid of character cells, the primary data structure will be a list of logical lines, each consisting of characters and attributes.

A rather modest enhancement to the vt100/xterm escape sequences would be a mode where screen addressing would be in terms of logical characters and logical lines. The application should not need to know the width of characters or how lines are broken into screen rows. This makes use of variable-width fonts practical - which is necessary for decent rendering of many scripts.

DomTerm's display engine (https://domterm.org) does support lines containing a mix of monospace and variable width characters, and know how to wrap such lines. I'm working on long-term replacing DomTerm's native display engine with xterm.js (for speed and other reasons) which requires making xterm.js more versatile.

The master branch of xterm.js (which will become version 5.4) has a new experimental support for grapheme clusters, combining characters, and partial support for variation selectors, based on Unicode 15. (Contributed by Your Truly.) For now it needs to be explicitly enabled (see https://github.com/xtermjs/xterm.js/tree/master/addons/addon...) but in a later release we hope to make it the default. Most of the work is handled by the browser and the font, but xterm.js does need to detect cluster boundaries - which is what the addon does.

To be pedantic: You're conflating the syntax of regular exprssions, with the (computer science) concept. Glob patterns are a kind of very resticted regular pexressions. Ksh extended the glob syntax so it has the full power of regular expressions in the computer science sense - though without all the extensions of modern regular expressions.

That is true. Elon Musk has greatly affected the stock price of the Company Formerly Known as Twitter.

Hank started out as a semi-comic blow-hard, but he evolved into someone heroic and sympathetic: While Walt "broke bad", Hank "broke good".

Huh? Using a shell interactively is a REPL. REPL means Read-Eval-Print-Loop. That's what you do when you type commands to a bach/zsh/fish/nushell/... prompt. But it also how you type commands to a gnuplot or Mathematica or APL or Python or Lisp prompt.

Some REPLs have nicer interactive features (such a completion than others). Some REPLs have nicer or more powerful syntax or different data types. But as longs as you have a Read-Eval-Print-Loop it's a REPL.

One of the issues R7RS-large ran into was in how to handle datatypes, such as collection types. Initially, Lisp-style languages had linked lists as the primary data type, but vectors were early added. So you had a "map" function (that worked on linked lists) and "vector-map" (that worked on vectors). Similarly, "length" vs "vector-length". What happens if you want to add more collection types - for example "bytevector"? Do you add "bytevector-map" and "bytevector-length"? Or do you generalize "map" and "length" so they also work on bytevectors (and also vectors)? The former is most compatible with Scheme history and tradition. The latter is IMO preferable going forward as new collection types are added - but it needs some way to talk about frameworks of types that are all sequences (linear collections). I.e. you need at least the concept of inheritance or "interfaces" as used in various languages, including Java and TypeScript.

Many languages in the Lisp/Scheme family have some kind of inheritance or interfaces, including Common Lisp, Dylan, Racket, Kawa, and many more. However, this hasn't been standardized for Scheme. R7RS-small has a mechanism to define new data types (records), but they were limited in functionality to C-like structs.

I (and others in the community) felt (and feel) that it is premature and unwise to add a bunch of new libraries for new data types until or unless we have some kind of framework for inheritance or interfaces. Others in the community (including the former chair) felt this was unnecessary and perhaps inappropriate for a language with the goals and history of Scheme.

There is no clear right answer or consensus for how to go forward, which is part of what caused things to bog down.

Or Kawa:

    (if (? p::Point obj)
      (... p:x p:y))

This succeeds if obj matches the pattern p::Point, declaring p to be the value of obj coerced to a Point. This is integrated with Kawa's static type-checking/inference.

https://www.gnu.org/software/kawa/Conditionals.html

DomTerm gets the linked test right.

I'm the author of DomTerm and the above-mentioned xterm.js PR. Both use the full UnicodeGrapheme Cluster Boundaries algorithm (https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundarie...). However, I haven't seen any specifications for how wide the resulting clusters should be in a mono-space context. So unless we enhance terminals to handle variable-width fonts (which I've been thinking about), we need to took at other terminals and make judgement calls. Generally, the width of a cluster is the width of the widest codepoint. Also, I decided that a "normal" character followed by emoji-presentation makes it 2 columns wide.

In your linked-to article, you suggest 2-em dash and 3-em dash should be 3 and 4 columns respectively. That might be reasonable, but it is explicitly contrary to the EastAsianWidths specification. You also suggest that Pictographics fullowed by text-presentation should have width 1. That seems reasonable, though I don't implement that.

The complaint was about having to sign up to (register for) yet-another website.

I believe we're talking about the equivalent of a small LED, like half your devices already have one or more of, but infrared and probably lower intensity. I.e. a teeny invisible glow. Even for animals that can see the glow, it would low enough intensity to be barely noticable.

Of course laws can be applied retroactively. As a general rule, they shouldn't be, but they certainly can be and have been. "The Constitution of the United States forbids Congress and the states to pass any ex post facto law. In 1798 it was determined that this prohibition applies only to criminal laws and is not a general restriction on retroactive legislation." (Britannica.)

Sixel has the one advantage of being mplemented in xterm and a modest number of other terminals. Otherwise, it's a pretty bad format: Inefficient. Unclear and inconsistently implemented specification. All images have to be a multiple fof 6 pixel rows, which may not align with either image height or character height.

Some terminal implement some other protocols, but attempts to specify a standard have failed. There are some tricky issues, such as: When does an image or part of an image get erased? Can you write text on top of an image and if so how are they aligned? What happens if you write an image on top of existing text? On top of an existing image? How does scrolling affect things? What happens to the image on window resize or zoom? Can you reliably update part of an image?

DomTerm (https://domterm.org) supports images in two ways: For sixels, it creates a canvas element as an "underlay". As it is earlier in he rendering order, following text can be written on top of the image.

DomTerm also supports general HTML, including IMG elements. (Of course it is safety-scrubbed.) This is quite flexible, but it doesn't overlap regular text (without some contortions). DomTerm allows different lines to have different height, which is beneficial for "printing" an image without having to pad the output to an integral number of rows.

Neither of these DomTerm protocls are suitable for a portable protocol that can be widely implemented. Two other protocols that I'm aware of are the iTerm2 protocol and the Kitty protocol. Both are bit on the complicated side, but a subset of one of those might be an acceptable "standard".

I think DomTerm (in addition handling sixels and extended emoji) does multi-plexing and remoting quite well. Remote access (https://domterm.org/Remoting-over-ssh.html) is done with a simple wrapper over ssh. Mosh-style predictive echo. No special priviliges needed: Just drop a domterm executable somewhere on the remote machine. Multiplexing with tabs and tiles that can be dragged between windows. Builtin attach/detach.

There are many places in the US where housing is a surplus. The obvious example is Detroit (as well as other "rust-belt" cities), where many functional houses have been demolished because there is no demand. Many rural areas are also losing population.

Most of Palo Alto and Menlo Park are within an easy bike ride from campus. You can mostly stay on pleasant tree-filled residential streets as you admire the multi-million-dollar cottages. Though as others have commented: few undergraduates live or party off-campus.