Per_Bothner

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).

Comment · 1 year ago

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.

Comment · 2 years ago

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.

Comment · 2 years ago

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,

Comment · 2 years ago

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.

Comment · 2 years ago

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".

Comment · 2 years ago

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

Comment · 2 years ago

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.

Comment · 2 years ago

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.