Customizing the Agenda

If you’re an Org-mode user you’ve probably seen some of the custom Agenda displays that enterprising users have created. They can be useful for those who like to organize their activities and use the Agenda as a portal into that organization. Daniel Gopar gives us a pointer to how it’s done:

The link in the tweet takes you to the section of the Emacs manual that describes the default sorting of Agenda items. If you want to build a richer, customized display, you should check the section of the Org manual on Custom Agenda Views or you could take a look at Alphapapa’s org-super-agenda package.

Posted in General | Tagged , | Leave a comment

Maintainers and Expectations

I’ve written things like this before but apparently the right people weren’t paying attention. The free/open software movement depends substantially on volunteers. Yes, some companies contribute by paying their employees to work on projects they’re interested in and, of course, there are companies like Red Hat that make significant contributions. But without those volunteers, open source would die and we’d all be suffering under Windows and complaining about how much we hate Word.

That’s especially true of the maintainers who not only contribute code but take on a significant managerial role as well. As any manager will tell you, any decision they make will annoy someone. Sometimes the annoyed will complain vigorously. That’s not necessarily bad. You see it a lot on the Emacs devel list but by and large the discussions are polite and largely restricted to the matter at hand.

But not always. Sometimes a certain type of people can come to feel entitled and complain that the maintainers are not doing what they want. Often, as in the discussion I linked, the complainant doesn’t really understand the situation or know what’s going on. I pay only casual attention to the Emacs devel list but even I know that Eli, far from “not feeling like it,” was actually working behind the scenes to resolve some real problems with merging gccemacs to the main branch and that the process of merging is ongoing.

Eli and the others ARE VOLUNTEERS. They contribute their efforts and even though most of us know them only as maintainers, they have lives, families, and real jobs to attend to. They deserve our gratitude, not our abuse. Note that I’m explicitly not talking about people like Andrea and Yuuki. They’re making their own contributions and are entitle to query the maintainers on why those contributions aren’t being merged as fast as they like. Also note that their posts were polite and constructive.

I get that not having things move as fast as you’d like can be frustrating but all of us need to remember that guys like Eli are doing a great job for free and they deserve our gratitude. If we’re not going to pay them, at least we can throw an attaboy or two their way.

Posted in General | Leave a comment

Designing with Finite State Machines

I’ve written before (see here and here for example) of my enthusiasm for using finite state machines (FSMs) in my design and coding. I had a C-based template that I used over and over. To implement a new state machine I just filled in a table that mapped the current state and input to a transition routine and, of course, wrote the transition routines. It was fast and easy. More importantly, I found that the software was always more reliable than if I used some other method. That’s because once you write your state transition diagram, almost everything else is mechanical

Alfonso de la Rocha has an excellent post on designing and coding with FSMs. He echoes my opinion that developing with FSMs results in simpler more reliable programs. He also shows how drawing the state diagram helps to understand the problem better, which also improves the implementation.

In his discussion de la Rocha mentions some advanced tools that can help with the design of FSMs. First is mermaid, a tool that lets you specify your state diagram in a markup language and produces a nice state diagram from it. Often, it’s possible to take that idea a bit further and produce both the diagram and the code from the same specification. I wrote about an example of this in Eric Raymond’s UPSide project.

Next he gives some examples of frameworks (in Go) to help produce an FSM implementation. They’re similar to my template that I discussed above. Finally, he mentions TLA+, a system to formally verify that your FSM is correct.

It’s a good post with lots of useful information. It’s definitely worth your time to give it a read.

Posted in Programming | Tagged | Leave a comment

Configuring Mbsync to Work with Gmail

I long ago gave up using Gmail due to privacy concerns. Still, lots of folks—and companies—still use it because, among other things, it does have the advantage of portability that doesn’t depend on your current ISP or your OS. Gmail is easy to use as long as you use their Web UI.

If you’re an Emacs user who’d like to deal with email from within Emacs, however, things are bit more difficult. The hard part is retrieving mail from Gmail’s IMAP server. You’d think you could just use your usual credentials but that doesn’t work.

Jakub Kadlčík has a post that explains how to configure mbsync to deal with Gmail. The difficulties mostly involve generating and using a special password. I’d like to beat up on Google for making things so difficult but they’re simply trying to make the process a bit more secure and, truth by told, setting things up for Apple Mail is similar.

I’ve never configured mbsync for Gmail but I did for Apple Mail and found it difficult because I couldn’t find any write-ups on how to do it. As with Gmail, the difficulty is not the mbsync configuration file, it’s generating the special app password you use. It’s the same with Gmail: the tricky part is knowing that you need an app password and finding out how to get one. That’s where Kadlčík’s post comes in handy. If you’d like to retrieve Gmail with mbsync—or, really, any of the IMAP downloaders—take a look at his post.

Posted in General | Tagged | Leave a comment

Managing Window Placement

One of the tropes of Emacs use is the idea that there’s always something new to learn about the editor. I know that to be true but today it was brought home to me by a new video from Protesilaos Stavrou. The video is nominally about managing window placement but part of that is the notion of “side window.”

I had never heard of them before or even the concept that they implement. It’s no wonder. While I was preparing to write this I looked them up in the documentation but couldn’t find anything at all about them in the Emacs manual. I had to consult the Elisp manual to find any information about them.

The problem that Stavrou is seeking to solve is the inconsistent placement of the windows that pop up for things like HELP. Sometimes a new window is created; other times an existing window is reused. If you’re like me, you probably suspected that the behavior is configurable but haven’t seen or used the mechanism to do it. Window placement configuration is fairly fine-grained so you can pretty much have it anyway you like.

Unless you’re very particular about window placement or want to implement something like emacs-dir-treeview, you probably won’t need to deal with side windows or the other functionality that Stavrou discusses but his video does show how the configuration is possible if you need it. The video is just short of 19 minutes long so plan accordingly.

Posted in General | Tagged | Leave a comment

Red Meat Friday: Word

And rendering. Don’t forget rendering. Yes, yes. I know. The rendering’s gotten better but it’s still not a good as a real typesetter like LaTeX or Troff.

Using Word is just another way of saying, “I don’t care what my content looks like.”

Posted in General | Tagged , | Leave a comment

Some Z Shell Tricks

A lot of Linux people have been singing the praises of Zsh for a long time and even as a Mac user it was always an option but I never bothered. Part of that is that I mostly stay in Emacs and don’t use the shell as much as I used to and I was happy with Bash so it never seemed worth the effort to upgrade.

Then, of course, Apple made up my mind for me by making Zsh the default shell in macOS. A useful way of thinking about Zsh is as a superset of Bash so I mostly haven’t noticed any changes except for fixing the prompt string.

Over at the Twilio Blog Lizzie Siegle has a nice post on some Zsh tricks that show some of its benefits. There’s no point in me relisting those tricks but if you’re a Zsh user you should definitely take a look. In particular, if you’re on a Mac and got (more or less) force changed into Zsh, you probably haven’t explored all it has to offer so you should definitely read the post.

Siegle’s post by no means exhausts all the additional goodies you get with Zsh. You can even get Oh My Zsh, a whole package of additional plugins. The post has links to a cheat sheet and list of Zsh plugins if you want more information.

Posted in General | Tagged | Leave a comment

Exporting Org to HTML

Jake B has a helpful video on exporting Org files to HTML. Irreal readers almost certainly knows how to do this so why am I writing about it? As you know, you can tweak your Org file to pull in CSS files that alter what the exported HTML will look like when you export it with org-export-dispatch (Ctrl+c Ctrl+e) so that it will appear nicer than the default plain HTML output. The video shows how easy this is.

Jake B starts with getting rid of section numbering and the Table of Contents. That’s simply a matter of a couple of options but the real win comes with using Fabrice Niessen’s readtheorg CSS files that provide a really beautiful layout. I always thought that using Niessen’s themes involved a bunch of cloning and configuration but that’s not true. As Jake B shows, all you need do is add the line

where NAME is either readtheorg or bigblow.

Finally, Jake B shows how to add your own CSS. With the exception of the CSS file itself, that’s also a one-liner:

#+HTML_HEAD: <link rel="stylesheet" type="text/css" href="styles.css"/>

assuming your CSS file is styles.css.

I started by saying Jake B’s post is helpful because it shows how easy it is to improve the default HTML exported from an Org file. If you use one of Niessen’s templates, it’s a matter of adding a single line. Use one of those templates or your own CSS and increase the beauty in the world.

Posted in General | Tagged , | Leave a comment

Paul Graham: What I Worked On

By any reckoning, Paul Graham has had a pretty successful life. He’s recognized as an expert on Lisp and has written a couple of books on the subject. In addition to his accomplishments in computer science, he also trained as a painter, founded and ran Y Combinator, a very successful early stage venture capital fund, and is currently enjoying a career as an essayist.

His latest essay, What I worked On, is the story of how it all happened. It’s a bit over 14,000 words so it’s a long read but definitely worth your time. The essay traces his life from high school to the current time. He learned a lot of lessons along the way and shares some of them in his story.

To my mind, the most compelling was to work on whatever you want. He doesn’t put it that way; he says to not be afraid to work on non-prestigious projects. He says that, mostly by happenstance, that’s what he’s done and that it’s worked out well for him.

One amusing anecdote was that one day while he was struggling as an artist he heard a radio report about a fund manager who was “super rich” and asked himself, “Why don’t I become rich?” That question led him to form Viaweb, which he later sold to Yahoo! and which, did indeed, make him rich.

His whole life seems like that. He followed what he wanted to do and managed to turn it into a success. Of course, Graham is an exceptional intellect but there is, I think, a lesson in his story for all of us.

Posted in General | Tagged | Leave a comment

Sleeping in Unfamiliar Places

npr has an interesting article on some recent research about what happens when humans sleep in an unfamiliar place. It’s long been known that humans don’t sleep well in an unfamiliar place. The effect is so common it even has a name: “first-night effect.” Sleep studies have long thrown out data from subjects during their first night in the sleep lab. The new research explains why this happens.

It turns out that half our brains are standing guard. This is completely understandable on evolutionary terms: when in a new place our ancestors were unfamiliar with the predator risks so only half their brains went to sleep. The other half, the left half, stayed alert and watchful. This happens with many birds and mammals but has never before been documented in humans.

The npr article is short and worth reading just for the details. The actual paper goes into more detail, of course, but seems well tracked by the npr story. The npr story describes the experiments the researchers performed to reveal the effect. The takeaway is that you can expect to sleep less well your first night in a new place and that the effect is involuntary and can’t be avoided.

Posted in General | Tagged | Leave a comment