Interactive presentations
I often present new material for my students in class. I teach programming and information technology at a vocational school, so I often need to run code as examples of what I am presenting about. Sometimes, I also want to tweak the code slightly and rerun it within the flow of my presentation. Another thing I like to do is to make my presentations interactive. I might ask my students something and write down their answers in my presentation or I might hand out individual tasks, collect the answers and use the presentation to share the results with everyone on the screen. (We have large 4k touch screens that also have whiteboard functionality in every classroom.)
We have MS365 (formerly known as MS Office) at the school and most of my colleagues use PowerPoint for their presentations. But PowerPoint cannot be used for interactive presentations. Either you create the presentation or you present it. There is no mode for presenting it while adding text or editing code blocks. It is also unable to run code when I am presenting. The workaround would be to run the code in some other tool like the python shell, node.js, the developer tools in a web browser or whatever REPL or compiler is available for the language you present about and take a screenshot and put that into your presentation. But I want to run the code after I have explained the concepts I am trying to get through so my students can see that it actually works the way I told them. I also like to tweak the code if they need an additional explanation or to try out different approaches (for instance in JavaScript: myObject["key"] or myObject.key) PowerPoint has the same problems with interactivity as LibreOffice Present, Google Docs whatever it is called this week, Apple Keynote and all the other standard presentation software. They are all unsuitable for presentations if there is any kind of interactivity. And when you are in a classroom, you want interactivity to keep your audience engaged.
Emacs Org mode is a tool for outlining ideas (and a lot of other stuff like calendaring, todos and project planning) and there is support for inline images and code blocks in almost any programming language that you can run when you want (or tangle out to a separate code file a la literate programming which is how I make my literate Emacs config, but that is another blog post for another day). It is not presentation software, but Emacs is extendable and hackable enough that it can be made to work as presentation software. Ric Lister has made an Emacs package called org-present that does exactly what I need. I make my presentation in org mode as an org file (org markup is similar to markdown), add the images and code blocks directly within the text with the markup. When I am in class, I just run org-present with M-x. (Alt-x or Meta-x as it is called in Emacs for historical reasons lets you run any interactive function). Each top level heading becomes a slide. I can write directly into the slides while I present them since they are just text files in org markup displayed with larger font sizes and nicer headlines etc, which makes it possible to do things like ask my students something and write down their answers. I can also run code blocks by hitting Ctrl-C Ctrl-C with the pointer above the code block and the results pop up underneath in a separate Results block within the text of my presentation. Another advantage is that if I alt-tab into another program like Firefox, my presentation within Emacs does not switch out of presentation mode like most presentation software like PowerPoint tends to do. I can come back to my presentation after showing a Youtube video with Firefox and continue where I left off.
Since org-present allows interactivity, running code blocks and switching back and forth from other software, I tend to use presentations as outlines for whole classes now, not just for the parts that includes a traditional presentation where I present some new information, but I also put in headings for tasks that I put on our learning platform (it's learning). When I get to the tasks, I can alt-tab to Firefox and show the students where they are and tell them how to work on them, and then after we have spent whatever time I set aside for the tasks, I can continue with my presentation and maybe give them some new information from the bullet points, pictures or code blocks in the presentation or I can get their feedback on what they learned from the tasks and write that into the presentation.
After class, I export the org file of the presentation to a PDF and put it on our learning platform to make it easy for students not present to see what was happening or for later review before a test or an exam. I have set up org-present to work the way I like with a bit of code in my Emacs config. I turn off the menu bar, turn on display of inline images and sets a standard width that usually works (that I can easily change with some metadata above an image) and use org-present-big to make everything large. I then hook my configuration into the start of org-present and also have a function that resets my configuration that I hook in when org-present is quit. I highly recommend org-present if you want interactivity within your presentations, especially if you already use Emacs and Org mode.
Emacs on Windows
I have to use Windows at work. At home, I use GNU/Linux and Emacs thrives, but using Emacs on Windows is different. There is an Emacs port that installs fine and the editor runs well enough, but the problem is that there are a lot of free software tools that integrate with Emacs that are either hard to set up or not available at all on Windows. Some are available through chocolatey, winget or msys2, and that helps. In addition to installing tools like pandoc, latex (texlive), imagemagick, unoconv (for docx and odt in doc-view mode), aspell, mupdf… you also have to add each individual programmme's path to the exec path when running Windows, unlike on GNU/Linux. It is very cumbersome, especially since the path you need vary from package to package and is unpredictable even if installed with the same tool. You also have to reverse every slash when you do that, which makes it even more annoying. You cannot just copy the path from File Explorer. LSP servers can be installed with npm which you can get by installing node.js with chocolatey. Git is available through msys2. There is a good video on the Emacs Elements Youtube channel about setting up Emacs on Windows that helps you get the basics installed and configured.
Even after doing all that work, I found a lot of papercuts everywhere. On my other machines, I am used to using Ansi-term in Emacs as my terminal. On Windows, Bash is not available, but you can use shell-mode and configure it to use PowerShell. It lets you get to node, npm and git, so it is rather nice to have even if it is not a POSIX-compliant shell. Fair enough, I guess, but then I open up a python file and hit C-c C-p to start an interactive shell, but no, that doesn't work, even if I have python installed through chocolatey. In addition to things not working even after a lot of setup and me having to adjust to another workflow since tools like Bash that I take for granted are not available, the amount of extra configuration compared to my normal config also meant that either I would have to have two separate configs, or I would have to pollute my normal config with a lot of code only useful on Windows and with code to run either this or that depending on the OS. It is doable, but it is cumbersome.
Luckily, there is another way. WSL2 comes with WSLg which let you run GUI programs with the Weston Wayland compositor. I find that there are a million papercuts in WSL2 since the distros you get are not actually those distros, but their WSL2 versions which behave slightly differently, but it is still the best experience you can get on Windows if you want to use good free software tools like Emacs. In the newest Ubuntu LTS (24.04), WSL2 was smart enough to start Emacs as a deamon and only surface Emacsclient (not Emacs) to the start menu on the Windows side. I pinned it to my task bar so I can launch Emacsclient with Super - 1. By using lxappearance and installing my standard icon and widget themes (breeze-gtk-theme, which lets me use breeze-dark and papirus-icon-theme) and cloning down my config which sets modus-vivendi as my theme I got Emacs to look like I am used to. Unfortunately, every WSLg window gets an ugly Windows7-style window border that doesn't respect the dark mode I have set in Windows. It looks ugly and wastes space. (At home, I have no window border when there is only one window on a workspace and otherwise use 2 pixels that show me which window is active by colour. The joys of a good tiler and the freedom to choose your own WM or DE is only available on GNU/Linux.) In Windows 10, when I resumed from screen locking or sleep, WSLg windows would disappear, but they seem to not do so in Windows 11, so that is a nice improvement. I tend to fullscreen Emacs with Super - up arrow after launch and alt-tab if I need to get to another window.
The big advantage of using Emacs on WSL2 is that all the free software tools I know and love are there and integrates with Emacs normally. I don't need to set paths or do any other non-standard extra configuration. I can use the same config as everywhere else, cloned down with git. There is almost no context switching, and I enjoy the same efficiency as I am used to, which are two of the main points of the somewhat all-inclusive Emacs lifestyle. To avoid Windows' inefficient window handling (I calculated that with a conservative estimate, using it instead of a tiling WM steals 3 whole work days out of every work year.), I try to do as much as possible within a web browser to limit the number of windows I need to handle. We have MS365, but instead of using the standalone Windows apps, I use Outlook, Teams and OneNote in Firefox. That way, I only have a couple of full screen windows to alt-tab between instead of a lot of them. After living in tilers for half a decade on my home machines, the inefficiency of floaters annoy me, so anything that brings me closer to a sane setup helps.
There is discussion going on in the Emacs community about the Windows and Mac ports of Emacs. Since there are no contributors to the Windows port, there is discussion about closing it down unless someone from the community steps up to help. After trying (for half a year) to use Emacs on Windows and still ending up using Emacs on WSL2 instead since it works a lot better, my thoughts are that there is no longer a need for the Windows port. You get Emacs the way it is meant to work on WSL2. On Windows, Emacs works, but a lot of the functionality that depends on external programs do not, and it is cumbersome and time-consuming to set up. If you are used to the real thing, it is too hard to adopt to a lesser experience in my opinion.
For new users trying it out, the Windows version would seem to be lacking features that are actually there if the user installs the external programs that are needed and is able to configure it to use those features. And it would seem very cumbersome to set up. It might dissuade new users trying Emacs out on Windows from delving deeper and finding the true power of the editor. Since WSL2 works rather well on Windows 11, if I were to recommend a Windows user to try out Emacs, I would recommend doing it through WSL2 instead of the native way. So if no one steps up to maintain the Windows port of Emacs, I am not certain that Windows users loose out on the Emacs experience. Instead, they get the better experience by using WSL2 in my opinion. If the Windows port is dropped, it might also make it possible to clean out some legacy code.
I would guess most Emacs users are on GNU/Linux with a minority on MacOS. Emacs users know good tools. That is why they use Emacs. When they have a choice, they choose good operating systems, hence the limited interest in the Windows port. My guess is that the people that use the Windows port are people who have to use Windows at work and have done so for long enough that WSL2 was not available at the time they setup their config and they have learned to live with the Windows port after having spent a lot of time setting it up even if some functionality we take for granted on GNU/Linux is just missing. If someone steps up and does a lot of work on the Windows port to make it less cumbersome to use, that is great, but my guess is that nobody will do that and that the Windows port will die. As long as Microsoft keeps WSL2 around, Windows users are better served with GNU/Linux Emacs than the Windows port. Spending the extra effort on the Windows port seems like wasted effort for the main development team driving Emacs forward. I think the idea floated by the Emacs maintainers of letting the Windows port die if no one takes on the responsibility to maintain it is the right choice.
Setting the background wallpaper for Sway and managing music with Emacs
I just watched an old video by Luke Smith which gave me the idea that it would be cool to change background in Sway from Emacs. I thought I would use dired and either open an image to see how it looks directly or use image-dired to get a preview of all the images in a folder. I would probably have to make a shell script to do the work and launch it with async-shell-command from an elisp function. It turns out I don't have to do anything. The functionality is already built into Emacs and it even gets which window manager or desktop environment is in use and selects the correct command to change the background for that WM or DE. The documentation tells me this functionality came with Emacs 29.1, at the same time a lot of other improvements were made to image-dired and opening images in general. I used image-dired in 28.2 and the improvements with 29.1 were many and greatly appreciated!
A few months ago I did the same type of discovery. I was looking for a way to interact with mpd, the music player daemon, possibly through the command line tool mpc from within Emacs. EMMS and Bongo are often mentioned by people in the Emacs community and I have tried both, but they are both unable to list albums with many artists and/or many recording years as one album. All other mpd players I have tried, both TUI and GUI-based have the same problem, so this is not a unique shortcoming in these packages. Maybe mpd has some shortcomings when it comes to listing albums. So, until recently, I have relied on a shell script I wrote that lists all the albums in the mpd database with fzf and lets me select the one I want to play. However, sometimes I don't want to play a whole album, but I still want my music sorted by album since I have been carefully tagging my files so I can easily find music by album.
(I kind of had to make a system for album names since having 11 albums named "Bach cello suites" doesn't really help me find the one I like to listen to when I have six different recordings, they span two albums and two recordings are by the same artist at different times. Another example is that Bach: Keyboard Concertos is too vague for me to know which Bach (J. C., J. S. and C. Ph. E. are in my database), which concertos (I have some of J.S.' and some of C. Ph. E.'s) and which performers (I have at least one of them in two recordings with different artists). Hence, I have made a system that is fine grained enough for me to find the right album without being too detailed to avoid too long album names, for instance, I don't include first name initials of the composer in the album name when I only have one composer with that last name in my database and I don't list artist when I have only one recording of a work. Every time I ripped an album, I manually changed the tags to match my system even if MusicBraniz through Rhythmbox and earlier, iTunes, often gave me terrible album names for classical albums when I ripped them, otherwise I would not be able to find anything.)
A few months ago, I discovered a built-in mpc mode in Emacs that gave me exactly what I wanted. I could continue to use mpd and mpc to manage my music playback and use mpc mode which looks very much like Rhythmbox, but has the advantage of having all of Emacs' superior keyboard centricity and text handling. I can easily search with C-s for an album name, add it to the playlist and start playing it and then q to quit out of that mode with the music still playing and I am back at whatever I was doing in Emacs before, all without having to lift my hands from the keyboard. It is really convenient. In mpc mode, the albums are correctly listed even when there are many artist and/or years on the same album. Since I can sort my music by album, I can easily also find a single track if I am so inclined.
These kinds of discoveries make me love Emacs and the Emacs community. Emacs is hackable enough that if you want some functionality, you can get it. And since the project wasn't started yesterday, someone has often already thought of my use-cases and spent some of their spare time to code up that functionality and often also even gone to the trouble to include it in the editor itself. Thank you!
Rapid Photo Downloader Error on Wayland on Arch
If you try to run rapid-photo-downloader on Arch on Wayland, you get this error message:
qt.qpa.plugin: Could not find the Qt platform plugin "wayland-egl" in "" This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.
Fatal Python error: Aborted
Current thread 0x00007fa0cd669740 (most recent call first): File "/usr/lib/python3.11/site-packages/raphodo/ui/viewutils.py", line 975 in anyscreenscaledqt File "/usr/lib/python3.11/site-packages/raphodo/ui/viewutils.py", line 991 in anyscreenscaled File "/usr/lib/python3.11/site-packages/raphodo/rapid.py", line 7489 in main File "/usr/bin/rapid-photo-downloader", line 33 in <module>
Extension modules: PyQt5.QtCore, gi.gi, zmq.backend.cython.context, zmq.backend.cython.message, zmq.backend.cython.socket, zmq.backend.cython.device, zmq.backend.cython.poll, zmq.backend.cython.proxysteerable, zmq.backend.cython.version, zmq.backend.cython.error, zmq.backend.cython.utils, psutil.psutillinux, psutil.psutilposix, gphoto2.widget, gphoto2.version, gphoto2.result, gphoto2.portlog, gphoto2.portinfolist, gphoto2.list, gphoto2.filesys, gphoto2.file, gphoto2.context, gphoto2.camera, gphoto2.abilitieslist, PyQt5.QtGui, PyQt5.QtWidgets, PyQt5.QtNetwork, tornado.speedups, PyQt5.QtXml, PyQt5.QtX11Extras, PyQt5.QtWebChannel, PyQt5.QtTest, PyQt5.QtSvg, PyQt5.QtSql, PyQt5.QtQml, PyQt5.QtQuick, PyQt5.QtQuickWidgets, PyQt5.QtPrintSupport, PyQt5.QtPositioning, PyQt5.QtLocation, PyQt5.QtOpenGL, PyQt5.QtDBus (total: 42) Avbrutt (SIGABRT) (kjerne lagret i fil)
Reinstalling the program does nothing. It turns out that there is a missing dependency. I have spent a lot of time trying to figure this out, but finding the information is hard, so I thought I would help my future self and maybe some others by supplying the fix I have found. It is not, as many suggest online, enough to install Python-PyQt5. It is already a dependency and installed. You need to install qt5-wayland to get it to work. On some distros, you also need to install egl-wayland, while on others, it comes as a dependency of qt5-wayland.
This is not just a problem with rapid-photo-downloader. There is a lot of discussion online about this error message with other Qt5 and Qt6 packages from different distros like Debian, Ubuntu and Arch. qt5-wayland is a dependency only if you run Wayland, so maybe that is why it does not come with the package as a dependency even if I think it should. Now that the larger desktop environments are all Wayland by default, I would guess X11 users are the minority of GNU/Linux users. Therefore, Wayland dependencies should come with all packages that need them. Legacy X11 users would probably not worry too much if a small extra package they do not need is installed. If they really worried about bloat, they would not have used X11 in the first place since it is a baroque collection of legacy cruft.
Update August 6th, 2023: I have experienced the same issue with Kdenlive on GNU Guix as well. It turns out that both Qt5-wayland (qtwayland@5.15.8 on Guix) and egl-wayland are missing dependencies for Kdenlive for Wayland users. I tried installing both qtwayland (qt6-wayland on other distros) and qtwayland@5.15.8, but Guix complained and only let me have one of them. This makes it impossible to mix and match Qt5 and Qt6 apps on Wayland on Guix. Guix should have two sets of packages like other distros (qt5-wayland and Qt6-wayland) even if it is simple to make a clean environment since users expect to be able to mix and match packages from different versions of the same toolkit as on any other distro without going through extra hoops. It is not the users' choice if the devs of their favourite packages use the older version of the Qt toolkit instead of the newest one. We need both Qt5-wayland and Qt6-wayland, just as we still need both GTK2, GTK3 and GTK4.
Maximize screen real estate
Real estate is expensive. Bad room layout can make a large flat seem small and a small flat seem large. A space with too much furniture can seem small even if it is large and a place with just a few select pieces of furniture can seem large even if it is small. All of this also applies to screen real estate. Especially with smaller laptops with lower resolution displays, it is nice to get as much space as possible for the actual content and waste as little as possible on distracting UI elements that makes the screen seems smaller than it is. By having more space for the actual content, you also minimize scrolling.
I achieve max pixel efficiency by using the tiling Window Manager Sway. Since it is a tiler, it automatically places windows in a tiled layout. Compared to working in a floating WM or Desktop Environment, I save a lot of mousing around to move my windows. I have a nice wallpaper, but no icons that clutter up my desktop. I have set up Sway to have 2 pixels of border around each window and no title bar on top to get as much space as possible for the programs I work in. The two pixels are needed to see where one window ends and another starts and also to distinguish between the active window with a red border and the inactive window(s) with a blue border. One pixel was hard to see, so I went for the somewhat wasteful setting of two pixels in stead.
I have also set smart_borders on which means that if I have only one window on a virtual desktop, it is without any border at all. This saves four pixels in both directions and looks nicer. I use a small 12 inch Thinkpad X230 with an internal 1366 x 768 pixel display as my main machine and usually just one program per virtual desktop, so the smart_borders make a difference. On my external 2560 x 1440 pixel 25 inch wall mounted screen behind my standing desk, I am more inclined to have two programs side by side if I am actively working on something in one window and just need to look something up or do a related task in another window. Humans are generally worse at multitasking than we think, so I like to separate different tasks on different virtual desktops even on large screens to not get distracted.
I do not use a panel on the top or bottom of my screen since this wastes pixels in the directions most screens have the fewest (height). I have set up the built-in Swaybar to autohide. I use scripts launched with keyboard shortcuts for the few things I need that most people keep in their bar or panel, like getting battery status in a notification or turning wifi or bluetooth on or off. A benefit of using scripts launched by the keyboard in stead of a bar with lots of information or system tray applets is that I save mousing around in submenus of my system tray or clicking on my panel to get things done. Since Sway implements the system tray of Swaybar in an xdg standards compliant way, but most programs still use a legacy Gnome implementation, most tray applets do not work anyway and this is what forced me to think closer at what functionality from the system tray I actually needed in the first place.
Over time, I have gradually switched out some of the larger GUI programs I used with smaller, simpler, more customizable and easily scriptable tools. Some of them are terminal programs, some are Emacs packages and some are small GUI programs. Many of the small GUI programs also have a minimal GUI that only present a few very useful elements and is otherwise controlled through keyboard shortcuts, like zathura or mpv. By having very few user interface elements, these programs give more room to the actual content you read or watch. The same applies to the TUI programs and Emacs packages I use.
Since switching from vim to Emacs, I have integrated some of the tasks I used to do in separate programs into it. Emacs is very efficient since it is so keyboard and text centric and by having fewer programs, I save the cycles my brain would use for context switching with different keyboard shortcuts for different programs. Emacs also has the ability to run both in a GUI which is what I normally use (since it adds support for different fonts in different contexts, pictures and PDFs), but can also be used in a terminal emulator or the tty with most of the same functionality. An example of how I gradually have integrated my workflows into Emacs is that I recently stopped using PCManFM as my file manager and instead now use Emacs' dired and the GNU coreutils in a terminal (inside or outside Emacs).
To save space in Emacs, I turn the menubar, toolbar and scrollbar off which saves some pixels on the top and right side of every window. I instead use F10 for the occasional dive into the menu and keyboard shortcuts like C-v and M-v to scroll down or up and M-< and M-> to go the the start or end of a document. I also turn on showing column and line numbers in the modeline and do not turn on line numbers on the start of every line since I can easily find the right line with the modeline if I am debugging something with an error on a specific line. It looks a bit cleaner and saves some space on the left of the screen. Usually, this does not matter much since screens are generally wider than they are tall, but when having three windows with code side by side on a small laptop screen, it can be the difference between having to scroll horizontally or not.
All in all, by saving some pixels here and there, I get more space for the content I work with, watch or read while also reaping the efficiency benefits of a more text and keyboard-centric workflow that came as a consequence of having fewer visual clues on screen and using the mouse less. A lot of functionality is not obvious at first sight, but since I have set this up myself and know my keybindings and the available functionality, it works well for me. Sometimes less really is more.