Home About Archive RSS

Teacher resources about the USA

I used to be an English teacher. During that time, I made a number of texts, tasks, question, oral assignments and so forth about different topics within the competence aims of the subject. In this blog post, I share texts related to the United States of America. I will make other blog posts later on other topics. I thought it might be useful to share these so other teachers can save some time by reusing them. I share these teaching materials in formats that are open standards since that ensures that these will always be possible to open and use. If the formatting is off when you open them i MS Word, you might consider using LibreOffice instead. To download the files, right-click with a mouse or click with two fingers on a trackpad and choose Save link as…

As everything on this blog that isn't code, I share under the terms of the Creative Commons Attribution ShareAlike-license. That means you can freely use, modify and share your modifications as long as I am attributed and you share under the same license. The point of the ShareAlike part of these terms is to ensure that materials shared under a Creative Commons license or their derivatives will always be shared under those terms, ie perpetually give people the right to freely use, modify and share. This is called a copyleft license.

Links to files with a short description:

More on Emacs on Windows

Today, I spent some time configuring (native) Emacs on Windows again. I needed to clean up some configuration around kalender.el, my Norwegian Bokmål calendar. Once I was working on it, I also improved my configuration around a few other issues plaguing native Emacs on Windows.

One thing I looked at was dictionary mode. (Notice that Emacs uses different facilities for dictionary-lookup and spell-checking.) On my GNU/Linux systems, I install a dictd server and some dictionaries so I don't need to be connected to the internet to use dictionary-lookup-definition. Since there is no dictd server package for Windows, I first tried to use dict.org to look up words. When I tried dictionary-lookup-definition, Emacs just froze. It did not use a lot of CPU, but it just did not respond do anything, including C-g. I had to kill it with the three-finger salute (C-M-d).

The main network at work is very locked down, so blocked ports could be the reason it doesn't work. Since I teach programming and basic IT, we need a network where we can do things like SSH which we cannot on the main network, so IT has supplied another network for that purpose, but I only have access to that network in the classrooms I teach, not at my desk, so I could not test doing it on another network. I don't have time to lookup word definitions when I am in a classroom, so either it works on the main network, or I consider it a feature I cannot use on Windows, which is what I do in my config now. Maybe I could add some code to check if the relevant network ports are open before trying a dictionary-lookup by advising the function that does the lookup or using a hook and keep the feature enabled so I can potentially use it when I am on other networks if I find out that the network is the problem? I would have to look a bit further into it.

I have previously determined that there is no aspell-no available on chocolatey or msys2 that I can install, and that makes spell checking also non-functional for me on Windows. My working language is Norwegian Bokmål, so even if I also write some English from time to time, and could use aspell-en and just set it to English on Windows, that would give me a lot of false positives most of the time. On GNU/Linux, I set it to nb (Norwegian Bokmål) and change manually to british (English) when needed. Maybe I could make a toggle function that would toggle language on GNU/Linux and toggle on/off on Windows? This needs a bit more investigation.

I have had a change of heart concerning which shell to use in Shell Mode. Even though Bash from Git Bash in Shell mode works, sometimes I actually need to use PowerShell to configure WSL2, Hyper-V or the like. Since I like to have as few windows open as possible since Windows ironically is terrible at handling windows, it makes more sense to use PowerShell in shell mode and stay within Emacs instead of launching a new window. (Some people think window snapping solves the inefficiencies of a floating window manager or desktop environment, but it doesn't since you have to do it manually with a keyboard shortcut or even more inefficiently by mousing around and dragging the windows to the edges. A tiling WM does it automatically which saves time and interruptions from flow. With very conservative numbers, I have calculated that I could save 3 work days during a 190 day school year if I used a tiler at work instead of the floater in Windows 11. I have dual-booted to get both the efficiencies of a tiler and access to all free software (development) tools I use for months, but since I need some tools inside Windows to do parts of my work, it makes sense to try to solve the problems in Windows instead of fighting it. WSLg would be sweet if it actually worked…)

Another reason is that Eshell provides a good shell experience that just works on any operating system, and I have thought that I would look into it more for some time, so I decided to use Eshell for everything I would use shell mode for up to this point and have PowerShell in shell mode in Windows for Windows-specific tasks. Eshell is nice because it, like shell mode, is an Emacs buffer that behaves like a normal buffer. Both Eshell and Shell mode have trouble with ncurses and other TUI programs, but Eshell is a bit cleverer than shell mode in that it can use a terminal package like ansi-term or eat to draw up those programs without leaving Eshell, so it is a better solution for all kinds of shell programs than shell mode which only does non-TUI CLI programs. It is also a better solution than ansi-term or other terminal packages that behaves like standalone terminal emulators and not ordinary Emacs buffers, with all the extra context-switching that adds, like Shift-Insert instead of C-y and C-c M-x instead of just M-x etc. It also integrates well with the rest of Emacs and you can use Elisp functions as well as traditional Unix shell commands (which are implemented in Elisp in Eshell so no external shell is needed). I am looking forward to getting to know Eshell better.

Another thing I looked into today was killing and yanking (or copying and pasting) on Windows. I have set Emacs to use UTF-8 and Unix line endings, but Windows still uses a 90s style non-UTF-8 text encoding based on its locale, so when I copied some Norwegian text today, all Æ, Ø, Å, æ, ø, å charcters got other glyphs once yanked into Emacs. I found out that I could just give the function set-clipboard-coding-system a text-encoding as a parameter and this problem would disappear. The documentation I found was out of date and said I should use utf-16le which did not work at all. After a bit of trial and error with the config file, I found that iso-latin-1 worked. I set this in the same section of my config as I set UTF-8 with Unix line ending to be default.

Skype and Microsoft

Skype was brilliant. It was end to end encrypted when video chatting with another Skype user and you could send SMS and call phones with cheap rates from it. Then Microsoft bought it and ruined the encryption. Skype was still good for calling cheaply from one country to another. Back in 2009, I bought a Skype feature phone with a "3 Vänner" subscription. At the time I lived in Malmö, spent my days at the Danish Royal Academy of Music in Copenhagen, worked evenings and nights at Kone elevators and freelanced as a baroque cellist, mainly in western and southern Jutland and Scania. Skype and the skype-phone was brilliant to call friends, colleagues and family in Norway, Denmark, Sweden, Finland or anywhere else with my own phone number from anywhere at cheap rates. Most of my fellow musicians also used Skype, so I also chatted in text, voice and video a lot. My parents started using Skype as well, so I could video chat with them from wherever I was.

Gradually, Microsoft did what the American tech giants always do when they buy brilliant (European) companies, which is to ruin their software. They did numerous overhauls of the user interface and every time, it got worse, not better. The amount of bots and scams also skyrocketed under Microsoft's ownership. Microsoft also tried to appeal to a younger crowd by adding stickers and ruin the user interface further. To confuse people, they also used the Skype name for their incompatible Link product which became Skype for business. Microsoft always makes a lot of versions of every product, or uses the same name for a lot of different products, to confuse their users and get businesses to pay more than consumers for the same thing, but with a few bonus features turned on. Market segmentation is their bread and butter, but it is confusing and annoying for their users.

Over time, my use of Skype has decreased with the Microsoftification of the once brilliant Nordic instant messenger, phone and video chat program. A few weeks ago, I found out Microsoft is going to kill this good brand and instead try to get consumers to use Teams which is obviously a business tool not well suited for users of Skype. The video chat in Teams uses the same technology as Skype, so this is probably all about trying to promote the Teams brand and maybe also share the code base between free Teams for consumers and Teams for business which you get with a MS365 subscription.

Skype will stop working on May 5th 2025. My personal Microsoft account only exists because of Skype, so I am now in the process of exporting all my data from Skype and afterwards, I will delete my Microsoft account. If you have a Skype/Microsoft account, it might be a good idea to export your data before it is to late, and if you don't need that account for anything else, you may as well delete it. I have been curious about the free software decentralised platform Matrix for a while, so I think I will see if I can find a Matrix server that is open for new users or set one up myself. I have tried the Matrix app Element in the past, and it was rather good. There is also an Emacs package called ement.el that seemed good when David Wilson of SystemCrafters had a look at it a while back in one of his live streams.

Bash from Git Bash in Shell mode in Emacs on Windows

Lately, I have been using PowerShell in Shell Mode in native Emacs on Windows. PowerShell isn't bad, especially not for automating tasks in Windows, but it's not the interactive shell I am used to. The small differences between PowerShell and Bash with GNU coreutils when it comes to day-to-day interactive use, even if many things are aliased to their Posix equivalents in PowerShell, are constant minor annoyances. For example, ls works in PowerShell since it is aliased to dir, but when I type ls -lah I get an error and realise I have to use dir \p since only the command without any flags are aliased. Since I use git from the command line and not vc-mode or magit (haven't had the time or energy to learn those yet), I use Shell mode enough that it is somewhat annoying to have to use PowerShell. It also feels foreign in GNU Emacs whereas GNU Bash doesn't.

I will of course use PowerShell when I demonstrate for instance git on the command line for my students since they would use PowerShell, but then I would use the blue PowerShell window and not Shell mode in Emacs. That also makes me more cognisant of the fact that I am not using Bash, but PowerShell. On Emacs on GNU/Linux, I am used to using Bash in Shell mode, so the muscle memory kicks in when I am in Shell mode even on Windows. I might even use PowerShell in a terminal in VSCode for demonstration purposes. But for my own use in Shell mode, a cosy and familiar Shell is better.

Today, I looked into switching to Bash from Git Bash. I am still trying to use Windows-native tools from MSYS2, chocholatey and win-get together with Windows-native Emacs since I need GUI Emacs for presentations in class when I use my laptop (I have a desktop with GNU/Linux in another classroom) and since WSLg's Wayland stack doesn't really work, especially not after locking the screen. If I just used Emacs to work on code, I could have used terminal Emacs with WSL2 which does work, but I need GUI Emacs for interactive presentations.

The solution is simple:

(use-package shell
  :config
  (add-hook 'shell-mode-hook 'ansi-color-for-comint-mode-on)
  (add-to-list 'comint-output-filter-functions 'ansi-color-process-output)
  (add-hook 'comint-output-filter-functions 'comint-osc-process-output)
  (add-hook 'shell-mode-hook (lambda() (company-mode 0)))
  (when (eq system-type 'windows-nt)
    (setq explicit-shell-file-name "C:/Program Files/Git/bin/bash.exe")
    (setq explicit-bash.exe-args '("--login" "-i")))
  (when (eq system-type 'gnu/linux)
     (setq explicit-shell-file-name "/bin/bash")
     (setq system-uses-terminfo t)
     (setq comint-terminfo-terminal "xterm")))

The windows-specific part of the code above is the first when-statement where I say that when the system-type is equal to windows-nt, set the shell to the path to bash.exe from within the Git folder. I got the bash arguments to use from a SuperUser post online and haven't experimented with it since it works. The only slight annoyance is that I get a small complaint every time I launch the shell in the first two lines. I searched for solutions, but couldn't find any, so I guess I have to live with that. Otherwise, Bash from Git Bash works great in Shell mode and it feels good to have a familiar Shell even on Windows. Emacs is kind of my home away from home on Windows and with Bash in Shell mode, it feels even more like home than with PowerShell.

Use the Python Shell or REPL from VSCode

Today, one of my students asked how to use the Python shell from VSCode. It is possible to do manually by navigating to the directory of the python file you are working with, writing python and pressing return to enter the shell, then write import filename (without .py extension) and then you may interact with the code. If you import this way, you have to use filename.function() or filename.variable to interact with the code. The other way is to specify what you want to import, for example, from oblig23 import alder. It is doable, but as I wrote in an earlier blog post, the Python shell integration in other IDEs and text editors are much more convenient to work with since you don't have to manually load the python shell from another shell inside a terminal.

So I used some time today to look into if there is better integration with the Python Shell hidden somewhere in VSCode or the Python Extension. After a rather long looking around, I concluded that there isn't. (Later on, I found out that if you don't mind using another implementation of Python than CPython, there is an ability to use a Jupyter kernel interactively.) There is, however, a slightly more convenient way to do this with the python interpreter in a terminal than first entering the shell and then importing. If you write python -i filename (with .py) when you are in the directory where the file is (or write the full path if you are not), you get the python shell with all the classes, functions and variables defined in the file imported. If you change the code, then you have to save and import again, either by leaving the shell and using python -i filename again or by staying in the shell and writing from x import y.

© Einar Mostad 2010 - 2025. Content is licensed under the terms of CC BY SA except code which is GNU GPL v3 or later.