Jeff Kowalski added code for a “close Equake frame on loss of focus feature” (similar to the Tilda feature) and a number of bug fixes and code-cleanup.

Further: I’m (half-)jokingly calling this the Geas on Gnomish Smiths release as I’ve finally figured out how to make it behave properly under GNOME Shell Wayland.

To my knowledge, the only other currently working drop-down terminal for GNOME Shell Wayland is the JavaScript GNOME extension ddterm. Wayland (at least GNOME Shell’s Wayland) seems very restrictive in how non-user-initiated events can affect window properties. E.g., it is difficult to programmatically affect window focus in GNOME Shell under Wayland. The default “hide window” behaviour of Equake doesn’t work.

However, I did have a legacy feature where closing/hiding Equake involved destroying the frame rather than hiding it. This is somewhat complicated, as re-invoking Equake then involves creating a new frame and restoring the tabs and buffer history. This is how Equake originally worked, but it is simpler (and slightly faster) just to hide the frame on “close” and then unhide it on “re-open”, and this became the default behaviour for Equake some time ago. But I left the old code in place as another option.

However, various changes apparently ended up with the restoration behaviour not working quite properly. I have fixed this (more or less, see https://gitlab.com/emacsomancer/equake/-/issues/26). With that fix in place, we can then trick GNOME Shell under Wayland into behaving properly. Rather than hiding the Equake frame on “close”, we destroy it and then recreate it on “open”. This involves quite a bit of trickery behind the scenes. Essentially, opening a new window under GNOME Shell Wayland can result in that window being placed on top of any existing windows (though to do it properly, employing a it of Elisp (select-frame-set-input-focus (selected-frame)) seems to result in the new Emacs client frame being on top (and focussed) [this is a potentially useful trick for opening regular new Emacsclient frames as well].

But, the usual way that Equake frames are created internally is via Emacs make-frame, which doesn’t automatically focus the new frame. So rather than doing this, we need to have the user call emacsclient -c and then transform that frame into an Equake frame. A new Equake function equake--transform-existing-frame-into-equake-frame takes care of this. The transformation and the old code restoring tabs and history doesn’t quite take care of everything though as the point/cursor is left by default at the top of the frame, which is not the user-expected behaviour. So an addition bit of elisp (goto-char (1- (point-max))) generally moves the point/cursor to the end of the buffer where the user might expect it.

So I have a bit of shell script as a helper function which is what one should create a keybinding for in GNOME Shell Wayland:

#!/bin/sh

equakestatus=$(emacsclient -n -e '(frame-live-p (alist-get (equake--get-monitor) equake--frame))')

if [ "$equakestatus" = "nil" ]; then
    emacsclient -c -e "(progn (select-frame-set-input-focus (selected-frame))
                              (equake--transform-existing-frame-into-equake-frame)
                              (goto-char (1- (point-max))))"
else
    emacsclient -n -e '(progn (setq equake-use-frame-hide nil)
                              (equake-invoke))'
fi

This checks if there is a live Equake frame; if there is, it is hidden; otherwise a new frame is created and transformed.

Finally, in order to be able to get the “Always on Top” behaviour, the new Equake frame transmutation function calls (shell-command "wmctrl -r :ACTIVE: -b toggle,above") (so one needs wmctrl installed), which seems to trigger the “Always on Top” feature at least for Xwayland windows.

And, presto, change-o, voilà, we have a version of Equake which exhibits its normal X11 behaviour in GNOME Shell Wayland.

(As long as Emacs is run as an Xwayland application; otherwise the “always on top” behaviour doesn’t work properly.)

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.

eshell is somewhat sparsely documented, but some useful resources exist, including a fairly extensive video overview done by Howard Abrams which I highly recommend. It has a number of great features, either inherently or via additional Emacs packages, including features from Plan 9‘s terminal, as well as Fish shell-like auto-suggestions.

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

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:

emacsclient -n -c -e '(equake-invoke)' -F '((title . "*transient*") (alpha . (0 . 0)) (width . (text-pixels . 0)) (height . (text-pixels . 0)) (left . 0) (top . 0))'

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

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:

(defun slade/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)" nil t)   ; 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

(defun slade/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-region 1 begdel))		; 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

(defun slade/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.