This is a very important machine that really deserves to get built. Anyone who cares about Free Software should consider funding this project at some level, and spreading the word to their friends. If this project succeeds, it will bootstrap a market for new, owner-controlled performant desktop machines. If it fails, no such computers will exist. The project page and updates explain the current (rather depressing) state of general purpose computing better than I could, so take a look.
I finished getting Excorporate and all its dependencies into GNU ELPA. Excorporate lets Emacs retrieve calendar items from an Exchange server.
I had to rewrite the default UI to use Org Mode, because Calfw isn’t entirely copyright-assigned to the FSF yet. The Calfw UI is still there for reference, but as a text file so that GNU ELPA’s build and publishing steps ignore it. Both UI handlers use the same updated APIs from the main
I made sure Excorporate and all its dependencies use only features available since GNU Emacs 24.1. This is pretty good coverage; Emacs 24.1 introduced the packaging system, so if an Emacs version supports packages, it supports Excorporate.
Other than DNS lookups, Excorporate is completely asynchronous, so it won’t block the Emacs main loop. And it is pure Emacs Lisp so it runs on any operating system that Emacs does.
In addition to Org Mode support, release 0.7.0 collects all the suggestions users have made on this blog and adds Exchange 2007 support.
M-x package-install RET excorporate
To get the source code:
git clone git://git.savannah.gnu.org/emacs/elpa.git
To report bugs:
I’ve always upgraded my Fedora laptop incrementally using the recommended tools (yum, preupgrade, fedup). For this reason, my initial decision to install i686 Fedora (back when 32-bit compatibility was important) has carried through, and I’ve always used i686 Fedora, even though the CPU supports x86_64.
Recently I wanted to try out Mezzano in a virtual machine, but it is x86_64-only. Obviously, virtualization tools don’t support running an x86_64 guest on an i686 host, so I shelved the experiment.
Then I found a use for Docker (testing Emacs HTTP authentication schemes), and wanted to try it out. But I ran into this surprising limitation: Docker is 64-bit only.
At this point I had two motivators to move to x86_64, but no desire to wipe my system. I discovered an interesting new term, “crossgrading”, when I found these instructions: Cross-grading from i686 to x86_64: it is possible (but unsupported). They were written for Fedora 14, but I decided to try them out on Fedora 22 (after backing up all my data).
Long story short, careful application of
dnf download and
rpm --force (and an rpm database rebuild) resulted in a still-working x86_64 Fedora 22 system, with no need to wipe the drive. I’m glad Roberto Ragusa took the time to write up those instructions, and I wanted to document that they roughly still apply, eight Fedora versions later.
I use Emacs Unified Directory Client (EUDC) for completing email addresses from LDAP and BBDB databases. It’s nice to be able to complete names from LDAP when composing emails, obviously, but it’s also nice in Org mode to
M-x eudc-expand-inline someone’s name into my notes.
When I first configured the EUDC LDAP backend for my environment — RHEL 6
ldapsearch, LDAP-over-SSL server — setup was very involved. There were lots of poor defaults, strange extra configuration files, function call requirements, and
ldapsearch incompatibilities. EmacsWiki instructions were very long just to get sane “Givenname Surname <email@address>” completion in GNUS.
I filed a bug report with configuration simplifications, bug fixes and EUDC Info manual updates, and somehow I ended up as the EUDC maintainer. I’ve committed the improvements to the Emacs master branch; they’ll be released in Emacs 25.
If you’ve tried EUDC in the past and been turned off by its arcane configuration, you might want to re-read the “LDAP Configuration” section of the Info manual, and try again. If you still can’t get it working, file a bug report at bug-gnu-emacs and I’ll try to respond to it within a few days. Mention EUDC or LDAP in the subject of the report. Likewise, if you do get it working with hacks then let me know via a bug report.
New in this release:
– Support for overriding settings autodiscovery by manually configuring an EWS URL
– A check to prevent
soap-client conflicts with other packages
– Handle email@example.com/autodiscover.domain.com autodiscovery case
– Support for Exchange 2013 (via the new API addition,
Thanks to everyone who tested autodiscovery on the 0.5.4 release and provided feedback. I’ve listed most of you in the Acknowledgements section.
Excorporate has been accepted for inclusion in GNU ELPA but I’m still waiting on copyright assignment for one dependency before releasing it there. This release still takes the form of a tarball. First download it, then install it with
I use Exchange at work for calendaring. I also use terminal-mode emacsclient when I’m logged in from another machine. In that scenario I can’t easily open a web browser to use Outlook Web Access. It annoyed me that I couldn’t check my schedule from within a terminal Emacs session. Thus, I did the only sensible thing and implemented full Exchange Web Services API support for Emacs.
The result is a library called Excorporate that has proof-of-concept Calendar integration to show today’s meetings. It’s all written in Elisp, making it cross-platform. It’s also cross-Emacs; I tested it on Emacs 24.1 through Emacs 24.4, on GNU/Linux and MS-Windows. It works on all Emacs versions that support packages.
The tricky parts were:
- extending soap-client to support all the XML Schema (XSD) datatypes required by the EWS WSDL file,
- asynchronous URL retrieval without blocking the Emacs main loop,
- autodiscovery of Exchange server settings from an email address, and,
- implementing NTLMv2 authentication in Elisp.
I’m trying to get it into GNU ELPA so that other modes can always count on its core APIs being available from a default Emacs installation. I haven’t put it on GitHub yet, to keep it hidden from the ruthless efficiency of MELPA. I was impressed and appreciative when MELPA bundled slime-volleyball shortly after I released it. But I’d prefer to keep Excorporate in GNU ELPA only for now.
Anyway, I’m publishing this mode in the hope that it’s useful to other Emacs-and-Exchange users.
At work I have cause to edit a TWiki that my team uses for internal documentation. I wanted to use Emacs for this task, so that I wouldn’t need to interact with a web browser text area widget. I couldn’t find anything that did that, so I took the closest thing I could find,
erin.el, a TWiki markup mode, and added connectivity to it via Emacs’s
The result is a fork of erin.el that supports these new operations:
|Edit a topic:||
without ever leaving Emacs. Now with EWW to see the resulting pages, there’s no need to leave Emacs at all.
This being a fork, it doesn’t qualify for MELPA, and I can’t get in touch with the original author, so it will stay in limbo as a raw repo, without ever being packaged.
A while after I did this development, emacs-twiki-mode sprang up. It looks like it has some nice advantages, like orgtbl editing. If it used Emacs’s built-in URL handling instead of an external
bash script I would probably switch to it. For now my
erin.el fork works well enough for me. I do wish there were one monster Emacs mode that would handle all Wiki server implementations, including connectivity; a sort of Gnus for Wikis. Oh well.
At work I make heavy use of the GNU Emacs mode serial-term to interface with various target boards. The boards all run U-Boot with a 5 second autoboot timeout. I often want to power-cycle a group of boards, then stop them all at the U-Boot prompt before they autoboot. It’s a race to C-x b to all the different buffers in time. I used to frequently miss some buffers; the boards would start booting, and I would have to wait to issue a software reset. It became annoying enough that I decided to create an autostop extension.
Luckily, serial-term is written in Emacs Lisp, so I can extend it to do exactly what I want. In this case I want a global “U-Boot autoboot-stop” mode. Here’s what I came up with:
First, a variable to to keep track of whether the mode is enabled or not.
;; Detect U-Boot autoboot prompt and stop it. (defvar u-boot-stop-autoboot-mode nil "Non-nil if term-mode should prevent U-Boot from autobooting. Use the function u-boot-toggle-stop-autoboot-mode to toggle.")
Then the advice itself. It jacks into the term-emulate-terminal process filter to detect the U-Boot autoboot prompt, then sends a newline in response.
(defadvice term-emulate-terminal (before u-boot-maybe-stop-autoboot activate disable) (with-current-buffer (process-buffer proc) (when (string-match "Hit any key to stop autoboot:" str) (message "U-Boot autoboot stopped in buffer %s" (buffer-name (current-buffer))) (term-send-raw-string "\n"))))
And finally a function to toggle the advice on and off.
(defun u-boot-toggle-stop-autoboot-mode () "Toggle whether or not term-mode should interrupt U-Boot autoboot." (interactive) (if u-boot-stop-autoboot-mode (progn (ad-disable-advice 'term-emulate-terminal 'before 'u-boot-maybe-stop-autoboot) (ad-update 'term-emulate-terminal) (setq u-boot-stop-autoboot-mode nil) (message "U-Boot autoboot will not be interrupted")) (progn (ad-enable-advice 'term-emulate-terminal 'before 'u-boot-maybe-stop-autoboot) (ad-activate 'term-emulate-terminal) (setq u-boot-stop-autoboot-mode t) (message "U-Boot autoboot will be interrupted"))))
Now I can enable the mode globally with
and be sure that all the boards will be interrupted in time.
It’s worth noting that developing this feature was relatively straightforward. I never left my Emacs session; I developed the code right in
~/.emacs.d/init.el, tested it quickly in a terminal buffer, and confirmed its operation in my existing serial-term buffers. Most of the development time was spent reading the Info documentation for Advice, to figure out how to enable and disable a specific piece of advice.
I bought a ThinkPenguin.com laptop for my Mom for her birthday. She’s a long time GNU/Linux user and she was ready for an upgrade from her ThinkPad T41. I decided to try ThinkPenguin.com. I’m really impressed with their service and their product.
The laptop shipped within a few days, and when it arrived it had Fedora 17 pre-installed like I had requested. The build quality is very good. It’s a slim light laptop with attractive styling, and a solid keyboard. One of ThinkPenguin’s main selling points is hardware support, and it really was great. Graphics, Wi-Fi, suspend, hibernate, resume all worked perfectly, out-of-the-box, no configuration necessary. It’s fantastic to get this smooth out-of-the-box experience with GNU/Linux instead of a proprietary operating system.
If you care about Free Software and are in the market for a laptop, check out ThinkPenguin.com.