In February of 2020 two of the NGender principles, Keith & Greg, switched to Spacemacs. The NGender Emacs Framework needs to be either converted to, or generalized to include, Spacemacs.
- Creation of an NGender Layer
- The contents of the old NGender MOdules Directory moved there
- Under the same Git control
- This file is part of that direcrtory
- Creation of a layer for each user
- The contents of the old user’s User-Me directory moved to that layer
- Under the same Git control
- We’ll refer to the logged-in user’s layer directory as User-Me
- Customizing the ~/.spacemacs file
- Uncommenting a few commented-out packages
- Moved to and linked from the NGender Layer directory
- Go through old init files
- .emacs, init.el
- Pull anything we like out and into NGender/ngender.el
- Otherwise leave alone for use by non-spacemacs
- ngender.el
- Can we consolidate here the NGender stuff that was in
- .emacs, init.el ??
- if so, pull that stuff out of old init files??
- Weave fundamental customizations in User-Me
- Maybe rename as ngender-init.el
- Module system should ignore these files!
- Can we consolidate here the NGender stuff that was in
- .spacemacs
- Have it pull in NGender/ngender.el
- .emacs, init.el
spacemacs is apparently very close to a new release. In the new release packages are versioned and come from a git repository.
Currently, a change in org-projectile causes trouble when spacemacs tries to build it.
Gory details: syl20bnr/spacemacs#10434
tl;dr: Either exclude org-projectile or switch to development branch
I tried switching to the devel build and
- encountered a problem with font-lock+
- reports an invalid version number of 0 saying that 0 is not a number!
- tried changing the version number but spacemacs keeps downloading it again
tl;dr: went back to master, deleted org-projectile from package-selected-packages list. Seems to fix the problem.
WTF is package-selected-packages list doing in .spacemacs?? How in general is user supposed to edit things in .spacemacs and step around other stuff??
- Some modules are good enough for now.
- Many modules are unreliable
- ngender-example needs to show the way
Something is not correctly setting up package archives when starting things from scratch. Running list-packages once interactively seems to fix the problem.
It would be nice to have a flexible and fault-tolerant shell script which could test the environment and do most of this setup work better than the current Makefile - please feel free to submit one!
make install is correctly echoing the steps to create the symbolic links yet they are not happening. When I copy/paste them they work just fine. WTF!!!
$ make install
mkdir -p ~/.emacs.d # ensure EMACSHOME dir
mkdir -p ~/.emacs.d/User-Me # ensure USER_ME dir
touch ~/.emacs.d/User-Me/init-me.el # ensure INIT_ME file
mkdir -p Limbo # ensure Limbo dir
for f in ~/.emacs ~/.emacs.d/init.el ~/.emacs.d/README.org; do test -L $f || ! test -e $f || mv -if
As ngender-example gets close to completion, examine what we can add to ngender.el to make it simpler. All of the management of packages and features should be made much simpler. To make list filtering easier it will be useful to define a flatten function to run after any filtering which is producing an output list not in a 1-to-1 correspondence with the input list.
Let’s deprecate package cl-lib functions in favor of the
more modern package seq functions. Both of these are now
“built-in” to the default Emacs installation. Let’s not
pull in package dash despite its beauty as it’s not quite
worth its extra overhead.
What other now “built-in” packages would be helpful?
We should be using Xref instead of directly using tag commands!
Which project-management package(s) should we provide? There’s a new built-in package “project” - let’s evaluate it.
Recursive load: “/usr/share/emacs/24.5/lisp/jka-compr.el.gz”, “/usr/share/emacs/24.5/lisp/jka-compr.el.gz”, “/usr/share/emacs/24.5/lisp/jka-compr.el.gz”, “/usr/share/emacs/24.5/lisp/jka-com pr.el.gz”, “/usr/share/emacs/24.5/lisp/jka-compr.el.gz”, “/usr/share/emacs/24.5/lisp/emacs-lisp/warnings.el.gz”
showed up as soon as I wrapped load inside of (let ( (load-prefer-newer t) )
apparently because the .elc files were older so emacs tried to use the compressed .el files but to do so it needed jka-compr so …
Solution: I (1) gunziped usr/share/emacs/24.5/lisp/jka-compr.el.gz AND I (2) I touched all of the .elc files under /usr/share/emacs/24.5/lisp
Now I’m getting some issue with (require ‘overlay) not finding package overlay - hmmm.
After installing Emacs from source, it says:
Assuming /var/mail is really the mail spool directory, you should run lib-src/blessmail /usr/local/SW.d/libexec/emacs/25.3/x86_64-pc-linux-gnu/movemail as root, to give movemail appropriate permissions. Do that after running make install.
Warning (type): Expected directory, got usr/share/texmf/doc/info Warning (type): Expected directory, got home/greg.emacs.d/themes [2 times]
Some nasty bugs were caused by the let form not creating
lexical bindings despite being inside of a module which
specified -*- lexical-binding: t; -*- on line one.
In particular, (let ( (features ...) ) ...package download
code...) led to the bizarre error Emacs was compiled
without network access because the install-package
function uses a global variable called features which was
being dynamically rebound by let.
Ugly patch of making sql buffer global; seemingly a personal problem on the Mac
Also need to sql-connect twice to accomplish the task…