Hugo -- gohugo.io
Emacs on
The Neo-Babbage Files2019-09-06T12:31:26+00:00Benjamin Sladeslade@jnanam.nethttps://babbagefiles.xyz/categories/emacs/https://babbagefiles.xyz/beautiful-and-free-typefaces/Benjamin Slade2019-08-04T02:25:00-06:002019-08-04T15:33:19-06:00For my academic papers, I often need a typeface with a wide range of
characters and diacritic combinations. Basic diacritics are supported
by a wide range of fonts, but more specialised diacritics and
particularly combinations of diacritics only work well in a handful of
typefaces. I write my papers in TeX, which has two components: the
typeface used to set the paper in (La)TeX and the typeface/font used
inside Emacs, where I write the papers.

Generally reasons given for preferring Latin Modern include the fact
that Latin Modern involves handmade vectorisation, with revised
metrics, and additional glyph coverage, including particularly
diacritic characters; whereas the Computer Modern Unicode fonts were
converted from METAFONT sources using mftrace with autotrace backend
and fontforge (former pfaedit) automatically.

Some of the revised metrics of Latin Modern include arguably better
positioning of acute and grave accents, more appropriately-sized
umlauts, and (here tastes may vary) a better looking Eszett (ß).

[Note that throughout this post, you can right-click on the images and
select “View Image” to see a larger/zoomable version of the image.]

However, in my tests, Computer Modern Unicode actually performs better
at least with respect to handling diacritics. In fact, Computer Modern
Unicode is one of a handful of typefaces which actually properly
handle a large range of diacritics and combinations of diacritics, as
can be seen in the image below, showing a variety of serif, sans
serif, and monospace typefaces, respectively, typeset in XeLaTeX:

[The source file from which all of these samples were generated is
included below in this footnote: 1.]

Note that in many typefaces, including all of the Latin Modern faces,
combinations of acute accents and macrons (e.g. the first character in
the tests: ā́, also not handled well by IM Fell Great Primer, the font
used by this blog) are very poorly handled, often with the accent and
macron being overlaid, rather than the accent properly stacking on top
of the macron.

Even fonts that properly handle this often fail for other diacritics:
note that EB Garamond and Liberation Serif don’t seem to properly
handle underrings (e.g. R̥r̥, also not handled that well by IM Fell Great
Primer).

Thus the only serif faces which handle the full range of
characters/diacritics are the didone (a style arising in the
late 18th-century, popular in the 19th-c.) Computer Modern Unicode;
Junicode (based on a 17th-century font used for George Hickes’s
Linguarum Vett. Septentrionalium Thesaurus); and the early
20th-century styled Times New Romanesque Noto Serif.

For the sans serif faces, in addition to the Computer Modern Unicode
Sans Serif face (in some ways a ‘skeletal’, un-didone-ised version of
Computer Modern Roman), Mozilla’s Fira Sans (here represented by
FiraGO, an updated/extended version), and Noto Sans – the latter two
both being vaguely ‘humanist’ sans serifs, though Noto Sans perhaps
has some ‘american gothic/grotesque’ features – also manage the full
range of characters/diacritics, but doesn’t have an italic face.

For the monospace faces, again the Computer Modern Typewriter face (an
‘Egyptian’ typewriter face, not unlike Courier) manages the full range
of characters/diacritics, as do Noto Sans Mono and the Iosevka faces
(here represented by my own customised version, Iosevka Oak Vise).

Not all of these typefaces are of equal beauty. Here are some examples
of running text, single sentences first:

And full paragraphs (for a subset of the typefaces; only including
those that manage at least a majority of the characters and diacritic
combinations):2

Only a few typefaces handle the full range of characters and diacritic
combinations. For the serif faces:

CMU Serif

Noto Serif

Junicode

For the sans faces:

CMU Sans Serif

Noto Sans

Fira Sans (FiraGO)

For the monospaced faces:

CMU Typewriter

Noto Sans Mono

Iosevka

Here is a comparison only of these “winners” (and Noto Sans Mono
perhaps is not a winner, lacking an italic face):

So, if you want to use a font family with good performance across the
full range of fonts, Computer Modern Unicode (CMU) or Noto seem like
the best bets, and the former is much more aesthetically-pleasing than
the latter (in my opinion), which also lacks an italic font for its
mono version. Junicode is also a beautiful and very functional serif
face, which I often use.

The Latin Modern faces turn out, despite the received wisdom, to be
inferior in terms of diacritic coverage, and switching from Latin
Modern to Computer Modern Unicode (CMU) has significantly reduced the
amount of frustration I have in trying to typeset my papers.

Editor typefaces

The editor font is the one I spend most of my time staring at, so I
also want something good here too.

Despite DejaVu Sans Mono apparently not properly rendering all
character/diacritic combinations in LaTeX, it handles all of these
perfectly well when used as the default font in Emacs:

CMU Typewriter, despite rendering well in LaTeX, has problems with
certain combination when used as the Emacs font, and anyway doesn’t
look as good as the other choices as an editor font for whatever
reason:3

These days, I prefer to use a customised version of Iosevka, which
also handles all of the characters/diacritic combinations perfectly:

I plan to write more extensively about Iosevka in another post.

Summary: Best Bets

For typesetting papers requiring a full-range of unicode roman
characters and diacritics (for non-roman, the Noto fonts are great),
the Computer Modern Unicode (CMU) faces4
are the best bets, along with Junicode.

For editor work requiring a full-range of unicode roman
characters and diacritics, use a DejaVu Sans Mono font or derivative,
or one of the Iosevka variants.

I’m not sure why Latin Modern Typewriter ends up with a ragged right margin.
[return]

Ubuntu Mono, when I tried setting it as the default font in Emacs and opening the .tex file from which the pdf screenshots shown here were taken, caused Emacs to crash!
[return]

E.g., CMU Serif, CMU Sans Serif, CMU Typewriter; there are a number of others, including also CMU Concrete Roman, used below for the non-title text (the title text is set in Latin Modern Dunhill):
[return]

]]>https://babbagefiles.xyz/intfic-top-50-2019/Benjamin Slade2019-07-30T11:32:00-06:002019-08-03T12:20:51-06:00Emily Short wrote a blog post a fortnight ago or so discussing her
nominees for Victor Gijsbers’ Top 50 Interactive Fiction Games of All
Time list, 2019 edition. The contest closes on the 31st of July 2019
(i.e. in 2 days, as of the day I write this), and I was thinking about
what games would be on my list. This has also resulted, perhaps more
importantly, with me having a list of games I still need to play.

Both lists below have the games hyperlinked to their Interactive
Fiction Database page, which generally includes reviews and game files
to download (or links/suggestions of where to get the game).

First, my personal list of favourites/best text adventures/interactive
fiction that I’ve completed or at least played most (er, at least
half?) of, ordered roughly in the order I encountered them:

Some of these may be being boosted by nostalgia, but I think they all
pretty much hold up and are interesting/innovative in some fashion.

Looking over the author names, I remember when playing Infocom games
back in the 80s suspecting that “Marc Blank” was a
pseudonym….i.e. Last Name: [blank].

Dunnet is an interesting entry also in that it was originally written
in Maclisp for the DECSYSTEM-20, then ported to Emacs Lisp in 1992,
and it is the Emacs version (M-x dunnet) that I’m familiar with.

A list of games I still need to play (never played before) or finish
(haven’t made significant progress, though I spent a pretty long time
with the Silicon Dreams games, Anchorhead, and Varicella, but don’t
think I’ve made much progress (or I’ve forgotten what progress I
made)), roughly in order of precedence (i.e. how soon I plan to play):

All of the games listed here, in either list, are playable in either
Malyon or Gargoyle (with the exception, I think, of Hadean Lands), an admittedly
rather arbitrary criterion.

]]>https://babbagefiles.xyz/auto-gen-hyperref-auctex-yasnippet/Benjamin Slade2019-05-29T22:59:00-06:002019-05-29T22:59:56-06:00After struggling with some poorly-handled, apparently “reset” proofs
introducing heaps of errors (despite my providing a .tex source) for
the past few days,1 I thought about providing automated pdf-tags
indicating creation tools used for my TeX-produced documents. Real,
professionally-typeset documents deserve to have the tools used to
produce them properly recognised in their metadata. So here’s a
yasnippet which generates auto-populated hyperref options to
generate a pdf-creator tag indicating the version of Emacs, AUCTeX,
and distro used:

Snippets can execute elisp code placed between `...`. The version of
Emacs (with some of the additional less-relevant information removed
via substring combined with cl-search (for “(”, the beginning of
the additional information)), and AUCTeX can easily be done using
Emacs-internal functions, (emacs-version) and
(pkg-info-version-info 'auctex), respectively.

For the operating-system information, we rely on external calls to the
shell via Emacs’s shell-command-to-string function. Many distros
will have lsb_release application (from the Linux Standard Base
project) available (and presumably usually part of the
base-install). Running lsb_release --help reveals a helpful set of
options:

SYNOPSIS
lsb_release [OPTION]...
OPTIONS
−v, −−version
Display the version of the LSB specification against which the distribution is compliant.
−i, −−id
Display the string id of the distributor.
−d, −−description
Display the single line text description of the distribution.
−r, −−release
Display the release number of the distribution.
−c, −−codename
Display the codename according to the distribution release.
−a, −−all
Display all of the above information.
−s, −−short
Display all of the above information in short output format.
−h, −−help
Display this message.
LSB Version: 1.0

And we can get various bits of information about the distribution out
via passing different flags to lsb_release (combined with the -s
“short description” flag).

Some distros don’t use the lsb_release, and looking at various
methods neofetch employs to manage to suss out the distro was
instructive. I added a method to allow for detecting the version of
Guix System distribution, and it could be easily extended (in
neofetch-style) to employ other methods for additional distros. (But
the lsb_release method should handle the majority of distros.)

Finally, we get can the kernel version out via the ubiquitous uname
application, via uname -r.

Thus calling this snippet on Void Linux results in a TeX block like this:

(The hyperref option pdfusetitle will make use of the values of
the TeX-defined \author{...} and \title={...} commands to populate
the author and title pdf metadata. If you do anything funky with these
fields (like adding a \thanks{...} command to your title), you may
need to take out the pdfusetitle option and manually specify these
tags via pdfauthor={...} etc.)

An amusing side-discovery of putting this snippet together is that
Arch Linux multiply – and insistently – reminds the uname caller of
the distro the kernel belongs to. I.e., using this snippet on my Arch
machine resulted in:

The horrifying reality of “professional” desktop publishing software stands in contrast to real professional documents produced in (La)TeX; and any resulting professionalism in the output of the former results from squeezing additional unpaid labour from researchers who have to correct the errors of “professional” typesetters.
[return]

]]>https://babbagefiles.xyz/equake-in-stumpwm/Benjamin Slade2019-05-22T22:26:00-06:002019-05-27T22:29:57-06:00I’ve been alternatively using both KDE Plasma 5 and StumpWM on various
machines and have got a working model for using the Equake drop-down
in StumpWM.

The StumpWM #'invoke-equake command hides (using StumpWM native
hide-window, rather than Emacs’s make-frame-invisible as the
latter creates various issues in finding and fetching the Equake
window) the Equake frame if it’s the currently active window; it
searches through all windows in all groups on the current
screen/monitor, and calls emacsclient -n -e '(equake-invoke)' to
create an Equake frame if no extant Equake window is found; and if an
Equake window does already exist for the current screen, it is yanked
into the current group, pulled into the current frame, and unhidden (if
necessary).

This seems to work pretty well, though I haven’t figured out how to
have StumpWM ‘skip’ the Equake frame when cycling through Emacs
windows. (And, of course, having a proper partial height floating
Equake window would be ideal.)

EDIT: Here’s a better, more Quake-like set-up, which actually makes
use of recently added partial-height floating windows in non-floating
groups:

(defuncalc-equake-width()(let((screen-width(caddr(with-input-from-stringp(s(run-shell-command"emacsclient -n -e '(equake-find-workarea-of-current-screen (equake-calculate-mouse-location (display-monitor-attributes-list)) (display-monitor-attributes-list))'"t))(reads))))(desired-width-perc(read-from-string(run-shell-command"emacsclient -n -e 'equake-size-width'"t))))(truncate(*screen-widthdesired-width-perc))))(defuncalc-equake-height()(let((screen-height(cadddr(with-input-from-string(s(run-shell-command"emacsclient -n -e '(equake-find-workarea-of-current-screen (equake-calculate-mouse-location (display-monitor-attributes-list)) (display-monitor-attributes-list))'"t))(reads))))(desired-height-perc(read-from-string(run-shell-command"emacsclient -n -e 'equake-size-height'"t))))(truncate(*screen-heightdesired-height-perc))))(setq*equake-width*1368); TODO: programmatically get screen dimensions before Emacs starts(setq*equake-height*768)(defcommandinvoke-equake()()(let*((on-top-windows(group-on-top-windows(current-group)))(equake-on-top(find-equake-in-groupon-top-windows)))(ifequake-on-top(progn(setf(group-on-top-windows(current-group))(removeequake-on-topon-top-windows))(unfloat-windowequake-on-top(current-group))(hide-windowequake-on-top));; then hide Equake window via native Stumpwm method.)(let((found-equake(find-equake-globally(screen-groups(current-screen))))); Otherwise, search all groups of current screen for Equake window:(if(notfound-equake); If Equake cannot be found,(progn(run-shell-command"emacsclient -n -e '(equake-invoke)'"); then invoke Equake via emacs function.(setq*equake-height*(calc-equake-height)); delay calculation of height & width setting until 1st time equake invoked(setq*equake-width*(calc-equake-width))); (otherwise Emacs may not be fully loaded)(progn(raise-windowfound-equake)(move-window-to-groupfound-equake(current-group)); But if Equake window is found, move it to the current group,(unhide-windowfound-equake); unhide window, in case hidden(float-windowfound-equake(current-group)); float window(float-window-move-resize(find-equake-globally(screen-groups(current-screen))):width*equake-width*:height*equake-height*); set size(focus-windowfound-equake)(toggle-always-on-top))))))); make on top(defunfind-equake-in-group(windows-list)"Search through WINDOWS-LIST, i.e. all windows of a group, for an Equake window. Sub-component of '#find-equake-globally."(let((current-searched-window(carwindows-list)))(if(equalcurrent-searched-window'nil)'nil(if(search"*EQUAKE*["(window-namecurrent-searched-window))current-searched-window(find-equake-in-group(cdrwindows-list))))))(defunfind-equake-globally(group-list)"Recursively search through GROUP-LIST, a list of all groups on current screen, for an Equake window."(if(equal(cargroup-list)'nil)'nil(let((equake-window(find-equake-in-group(list-windows(cargroup-list)))))(ifequake-windowequake-window; stop if found and return window(find-equake-globally(cdrgroup-list))))));; Set the mouse focus policy; - :click is best for proper Equake functioning(setf*mouse-focus-policy*:click);; also StumpWM default (I think);; Keybindings;; bind to an appropriate key(define-key*top-map*(kbd"F12")"invoke-equake")

]]>https://babbagefiles.xyz/equake-elisp-console/Benjamin Slade2019-01-03T19:06:00-07:002019-06-17T16:20:58-06:00Over the holiday break I’ve been working on developing a Quake-style
drop-down console, dubbed Equake / equake. It is not yet on Melpa,
but is accessible at
https://gitlab.com/emacsomancer/equake.1

equake, written fully in Emacs Lisp, is designed as a ‘classic’
drop-down console interface like Yakuake, inspired by ‘cheat’ consoles
in games like Quake. It provides access to various ‘shells’
implemented in Emacs, including shell (an Emacs wrapper around the
current system shell), term and ansi-term, (both terminal
emulators, emulating VT100-style ANSI escape codes, like xterm
does), and eshell (a shell written entirely in Emacs Lisp). equake
allows for multiple ‘tabs’ (which can be running different shells),
and allows tabs to be re-ordered and renamed.

My impetus for creating equake was to hijack my own workflow into
using John Wiegley’s fantastic eshell, an Emacs module which
‘translates “shell-like” syntax into Lisp in order to exercise the
kernel in the same manner as typical system shells’, allowing for a
similar working environment even in hostile, alien OSes like w32.

equake has been successful in my personal goal of using eshell for
99% of my terminal work, and I am looking forward to making further
using of a shell which can handle Lisp syntax as well.

Most of the equake code is keeping track of tabs, and frames for
multi-monitor set-ups. This is trickier than it would seem at first,
especially as each screen/monitor can have it own set of tabs (this
allows me to recreate at least a part of AwesomeWM’s
screen-independence in other environments). In theory equake should
work fairly well across platforms, as it makes use of the frame.el,
which includes code for MacOS and Windows (but I haven’t test either
platform). Probably more work needs to be done to get equake to work
properly on tiling window managers like AwesomeWM or StumpWM. But it
seems to currently work fine in KDE Plasma and Gnome Shell (both X11
and Wayland).2

I learned a good deal about how Emacs manages frames. I originally
used Emacs’ make-frame-(in)visible functions to hide/show the
equake frames. However, the implementation of these is very
odd. Applying make-frame-invisible to a frame once appears to render
it invisible, but Emacs still considers it to be visible, which means
that, for instance, frame-visible-p will still report the frame as
being visible and, worse, functions like make-frame-visible and
raise-frame will have no effect whatsoever upon the frame in
question, because Emacs treats it as ‘visible’. Only a second
application of make-frame-invisible will register the frame as
reportably invisible to Emacs. This is easily enough worked around
simply by using a ‘double tap’ of make-frame-invisible to the
relevant frame. However, I ran into numerous other issues in the use
of make-frame-(in)visible, including the fact that frames set at
less than 100% width end up re-appearing in a position other than
their original position, and frames sometimes spontaneously resize
when re-appearing or being un-fullscreened. I tried for a long time to
work around these issues, but found that even trying to force the
frames into doing what I wanted them to do via applications of
set-frame-position was a non-starter, as application of this
function to malpositioned frames resulted in significant lag – which
defeated the purpose of using make-frame-(in)visible in the first
place, which was to gain a slight performance improvement over
destroying and recreating frames. In the end, using destroy-frame
and make-frame to ‘hide’ and ‘show’ the drop-down console ended up
being the most performent solution.

Destroying and recreating frames means also worrying about remembering
the last buffer used in a frame as well as the window-history for the
frame, so these also make up a decent part of the equake code.

On single-screen set-ups, equake, once installed, is designed to
have a equake console frame toggled to drop down or be rolled up by
executing a command which invokes the (equake-invoke) function bound
to a key like F12 via:

emacsclient -n -e '(equake-invoke)'

Getting equake to work well on multi-monitor setups ended up being
rather challenging, since Emacs doesn’t know exactly which screen is
‘active’ unless that screen also has an active Emacs frame. The
solution, which I managed to get to be nearly as fast as the simpler
non-multi-monitor solution, is to launch ‘Emacs probes’ which are used
to determine which monitor is ‘active’ and are then destroyed, invoked
via:

(The title is important as it’s the key to being able to quickly
destroy these ‘Emacs-probes’, and the other frame-settings are there
to minimise the visibility of the probe-frame during its brief
existence.)

If you’re looking for a drop-down for things other than
shells/terminals, alphapapa has a similar Emacs package designed as a
general-purpose drop-down (e.g. for Org mode buffers etc.); yequake;
and a specialised version for org-capture.

I hope to add a few more features to equake, but at this point it
seems stable and is usable for what I wanted to use it for, being a
Lisp console for a Lisp shell. Comments and suggestions are, of
course, most welcome.

Where installation via quelpa-use-package is described. This method is nearly as easy using the plain use-package package to pull from Melpa.
[return]

Another part of the impetus for equake is wanting to increase my machines’ ‘Lisp quotient’ after moving a number of machines from AwesomeWM to KDE Plasma, rather than to StumpWM as I had originally planned. Of course, I could replace Kwin with StumpWM, and I plan to experiment with this, but I rather like some the eye-candy Kwin provides.
[return]

]]>https://babbagefiles.xyz/emacs_etymologies/Benjamin Slade2018-08-26T21:49:00-06:002018-08-26T21:50:27-06:00On Xah Lee’s blog I noticed an entry on linking to word etymologies
from Emacs (2018-08-16: “emacs, create link of word etymology”). What
his function does is create a html link to the Etymonline.com page on
the currently selected word.

But I thought: it would be great to have a quick way of pulling up
etymological information within Emacs itself. So, with a little help
from Links (i.e. you’ll need to have Links installed), here is a first
attempt at such a function:

(defunslade/etymonbuf()"Look up word etymology notes from http://www.etymonline.com. Requires [[http://links.twibright.com/][links] to be installed."(interactive)(let($p1$p2$input$result);; lifted from Xah Lee's 2018-08-16: "emacs, create link of word etymology"(if(use-region-p)(progn(setq$p1(region-beginning))(setq$p2(region-end)))(progn(setq$p1(line-beginning-position))(setq$p2(line-end-position))))(setq$input(buffer-substring-no-properties$p1$p2));;(generate-new-buffer$input); generate new buffer titled with entry word(switch-to-buffer(last-buffer)); switch to that new buffer(insert(shell-command-to-string(concat"links -dump http://www.etymonline.com/word/"$input))); dump text via links from etymonline(goto-char(point-min)); go to beginning(if(re-search-forward"Error 404 (Not Found)"nilt); for non-word or words with no etymonline entry(slade/word-not-found); if 404, kill buffer and display minibuffer message(slade/trim-etymonbuf)))); otherwise trim off unneeded text from header and footer(defunslade/trim-etymonbuf()"Trim off unneeded text from top and bottom."(goto-char(point-min)); goto beginning of buffer(search-forward"[\s\s]"); the text output of links always delivers text with a "[ ]" right before the text we want(let((begdel(point)))(delete-region1begdel)); delete from beginning of buffer until "[ ]"(goto-char(point-max)); goto end of buffer(search-backward-regexp"Share[[:space:]]*Share on FacebookShare"); the unneeded text at the bottom starts with a "Share" section(let((enddel(point)))(delete-region(point-max)enddel)); delete from end of buffer until Share section(goto-char(point-min))); move point back to beginning(defunslade/word-not-found()"Delete buffer and display minibuffer message."(kill-buffer)(message"Sorry, word not found."))

After eval‘ing the above, one day, if you have an idle fancy to know
the etymology of a word, you can select it and call slade/etymonbuf
and have a quick peek at what Etymonline has to say. Here’s what you
get if you try this on “lisp”:

lisp (n.)
"act or habit of lisping," 1620s, from lisp (v.).
lisp (v.)
sometimes lipse, late 14c. alteration of wlisp, from late Old English
awlyspian "to lisp, to pronounce 's' and 'z' imperfectly," from wlisp
(adj.) "lisping," which is probably imitative (compare Middle Dutch, Old
High German lispen, Danish læspe, Swedish läspa). General sense "speak
imperfectly or childishly" is from 17c. Transitive sense from 1610s.
Related: Lisped; lisping. Suggestive of effeminacy from 14c.

Probably not the lisp you were looking for, but interesting none the
less.

Of course it would be nice to retain italics and not to have to depend
on an external application, so there’s more that can be done.

]]>https://babbagefiles.xyz/emacs_windows_stumpwm/Benjamin Slade2018-08-18T21:36:00-06:002018-09-18T19:01:51-06:00I’m still working on getting my GuixSD machine configured, including
working on getting familiar with StumpWM – a windows manager written
in Common Lisp – which is the desktop paradigm I’ve decided upon for
this Lisp-centric machine.

I’m somewhat habituated to (my) AwesomeWM keybindings, which involve
the Super key in combination with various other keys, including say
s-1 for tag/workspace 1, s-3 for tag/workspace 3, &c., and
s-E (i.e. hold Super and Shift and press e) to launch an
emacsclient (see below on the Emacs client/daemon
configuration). StumpWM could be configured in a somewhat similar
fashion (though it doesn’t seem to quite use tag/workspaces in the
same fashion), but the ‘tradition’ seems to be to use a prefix, which
is by default C-t (that is, hold Control and press t), which
is then released and followed with another key or key combination. I
don’t really like using Control for windows management since it tends
to conflict with bindings in Emacs and elsewhere, so I’m testing out
s-F (hold Super, press f) as a prefix (though whether I’ll
stick with prefixed bindings or go back to single action bindings, I’m
not yet certain).

From browsing other stumpwm configs, I came across a useful bit of
configuration:

(defunrun-or-raise-prefer-group(cmdwin-cls)"If there are windows in the same class, cycle in those. Otherwise call
run-or-raise with group search t."(let((windows(group-windows(current-group))))(if(memberwin-cls(mapcar#'window-classwindows):test#'string-equal)(run-or-raisecmd`(:class,win-cls)nilT)(run-or-raisecmd`(:class,win-cls)TT))))

The above function leverages run-or-raise-prefer-group to either
launch Icecat, if it is not already running, or else focus the Icecat
window, and successive calls will cycle through multiple Icecat
windows/windows if more than one Icecat window exists. This is extremely
useful as it’s much less cognitively-tasking than figuring out which
window number Icecat currently is associated with.

This means that one first presses the prefix (s-f for me) followed
by either W or C-W or s-W (that is, Shift+w,
Control-Shift+w or Super-Shift+w) to either launch Icecat or
focus/cycle through existing Icecat windows/windows.

Now, the way I typically use Emacs is to invoke it as a daemon
(i.e. emacs --daemon) and then connect Emacsclients to this daemon
(i.e. emacsclient -c for the ‘windowed’ gtk-application,
emacsclient -t in the terminal). However, if we define a parallel
function for Emacs, a particular edge-case arises:

This works rather like the Icecat one as long as at least one
Emacsclient window exists (so if there are multiple window,
successive calls of run-or-raise-emacsclient will cycle through
them). However, if no emacsclient is currently open, it will launch an
undaemon’ed Emacs (requiring loading the entire init.el), even
if/though an Emacs daemon is currently running and thus could be
attached to.

At least one solution to this is the following function (with
relevant keybindings):

The above function executes the shell-command pgrep "emacsclient"
and evaluates whether the output of that shell-command is equal to the
empty string (which will be the case only when no emacsclient is
running). Where at least one emacsclient is running, it executes the
run-or-raise-emacsclient function defined earlier,
focussing/cycling through running emacsclients. Where no emacsclient
is currently running, it executes instead emacsclient -c, opening
a windowed emacsclient. And the bindings let me press the prefix and
then either Super+e, Control+e or simply e to execute this
new function.

So that if I want to launch a new emacsclient window instead of switching to an
existing one, I can do so using one of series of keybindings parallel
to the previous set, but with a capital E rather than a lowercase
one.

This is working well for me, and is a nice example of the power of
using Lisp-based ‘desktop environment’.

]]>https://babbagefiles.xyz/guix_maze_of_lispy_little_passages/Benjamin Slade2018-08-04T21:47:00-06:002019-06-17T16:35:31-06:00So I finally made a serious go of running GuixSD, a GNU Linux distro
which is largely built on GNU Guile Scheme (a dialect of Lisp) on one
of my machines (one I had actually put together with GuixSD in mind:
an X200 Thinkpad, which I Libreboot‘ed and put a Atheros Wi-Fi card
in), and, to increase both the quantity and variety of Lisps involved,
am trying to use with StumpWM (which is written in Common Lisp).

It’s a fascinating distro, modelled on Nix, but implemented in
Guile. It’s not been exactly easy to get running (one of the videos on
GuixSD from Fosdem 2017 included the line “[GuixSD] is like Gentoo for
grown ups”), in part because its architecture is rather different from what
I’ve experienced with other Linux distros, which use different package
managers perhaps and sometimes even different libc’s, but generally
follow a similar design philosophy. Rather than spreading out
configuration across lots of different pieces, GuixSD seems to largely
try to concentrate it in specific configuration files which are
transactional in that they can be rolled back (and thus the system can
be rolled back to known working states).

It is a GNU-blessed distro, and does take the FSF’s hard line (and to
my eyes sometimes weird line) approach to software. So no proprietary
software is included in the Guix repos, including firmware (and it
runs on the linux-libre kernel). That by itself is fine, but it means
the state of affairs for Guix-packaged browsers is pretty poor. No
Chromium, no Firefox. IceCat 52 is essentially what’s currently
available (if IceCat were up to the latest Firefox ESR 60, it might be
easier) in terms of browsers which might be considered secure.

This led me to try to use the Nix installer by itself* to try to
install Firefox and Chromium. Sadly, I can’t get Nix’s Chromium to
work at all on GuixSD, and while Firefox works fine, I can’t get it to
see my locally installed fonts (or other fonts I’ve installed via
Nix).

Hopefully at some point Next Browser will be packaged for Guix, to
bring in another major component written in (Common) Lisp. And when
(if?) IceCat 60 comes out, that will alleviate the pain somewhat. (I
was a long-time Conkeror user, and I briefly tried it again in GuixSD,
but I’m not certain of its security and uBlock Origin no long works
with it, which I believe is why I stopped using it in the first
place).

Other interesting Lispy pieces include mcron, a cron which accepts (as
well as Vixie cron style, I think) Guile config files. The examples in
Guix manual I couldn’t really get to work. But via the help-guix
listserv I found that one can put simple guile scripts in
~/.config/cron/job.guile. Working out how to do a ‘run this every N
minutes’ was not immediately obvious, but I figured out how to do it,
e.g.:

One of the other great things about GuixSD is that its init manager,
GNU Shepherd, is also written in Guile Scheme. I’ve only had a chance
to play with it a little bit, but it seems very nice and it’s good to
find other innovative init managers (I would mention here also runit
and s6) which take very different approaches to systemd (another
innovative init, or perhaps init+, but one that creates more problems
than it solves in the end, in my experience).

On the Guix package manager itself: I learned the hard way that
searching for packages in Guix is really only comfortable within
Emacs: so do guix package -i guix-emacs and then do everything else
from guix-emacs within Emacs ( M-x guix-search-by-name to search
package names by regex; and M-x guix-search-by-regex to search
names+descriptions by regex). The results returned by guix package -s
.... in a terminal are not very browseable (though I tried valiantly
for some time). But if you’re interested in Guix, you’ll likely
interested in Emacs anyway.

What I’m trying to build on this machine is something with lots of
Lisp. Of course the kernel is still a kernel written in C, as are lots
of the other pieces like the terminal &c., but much of the user-facing
things: the package manager, the windows manager, the init, the job
scheduler (=cron), and (most importantly perhaps) the ‘text editor’
(read: document composer, email interface, irc interface, twitter
interface, blog post interface, code editor …) are all largely
written in and interacted with using some form of Lisp (Guile Scheme,
Common Lisp, Emacs Lisp).

Guix is a bit like Emacs, I think. It’s an incredibly powerful tool
with lots of interesting possibilities, but when you start using it
you’re presented with an empty screen with little indication of what
you can do. I’ll be sticking with it, I think. Now I’ve got to get to
grips with StumpWM and figure out how to configure polybar…

* As well as being the package managers of both of their
respective distros, both the Nix and Guix package managers can be used
on top of other distros. Nix doesn’t have quite the same hard line
approach to software licences as Guix.

]]>https://babbagefiles.xyz/new-blog/Benjamin Slade2018-06-07T20:26:00-06:002018-06-07T23:00:25-06:00I’ve been wanting to have an Emacs-powered blog for some
time. Finally, thanks largely to the yeoman’s work put in by Kaushal
Modi on ox-hugo, an exporter from native Org mode format to
Hugo-ready markdown files, as well his theme/configuration for Hugo,
hugo-refined (which the theme used here is largely based on), I
finally have an ideal Emacs-centric blogging environment, though I’m
sure I’ll continue to tweak things a bit.

Hugo itself is a static website generator, which interprets markdown
files. It’s written in Go, a language developed at Google, which is
notable for including Ken Thompson and Rob Pike among its creators.

This is more or less a continuation of my old blog, of a similar name,
and will largely address Emacs/elisp and other lispy things, and
Linux/UNIX/*nix and free/open source software and operating systems,
but, like my old blog, probably also occasionally games and pre-20th
century technology, as well as whatever else catches my interest
(other than natural language things, which I’ll keep on my
professional site).