tychoish emacs posts

imenu for Markdown

Sun, 25 Nov 2012 00:00:00 -0500

For a while, I've been envious of some of the project and file navigation features in emacs for browsing bigger projects/programs, things like imenu and tags have always seems awesome but given that I spend most of time editing restructured text and markdown files (I'm a technical writer), these tools have been distant and not a part of my day to day work.

It's not that it would be impossible to write interfaces for imenu or etags, for the formats I use regularly, but more that I've never gotten around to it until now.

We're still a ways away on the question of etags, but it turns out that when I wasn't looking rst mode got imenu support, and with the following little bit of elisp you can get imenu for markdown.

 (setq markdown-imenu-generic-expression
     '(("title"  "^\\(.*\\)[\n]=+$" 1)
       ("h2-"    "^\\(.*\\)[\n]-+$" 1)
       ("h1"   "^# \\(.*\\)$" 1)
       ("h2"   "^## \\(.*\\)$" 1)
       ("h3"   "^### \\(.*\\)$" 1)
       ("h4"   "^#### \\(.*\\)$" 1)
       ("h5"   "^##### \\(.*\\)$" 1)
       ("h6"   "^###### \\(.*\\)$" 1)
       ("fn"   "^\\[\\^\\(.*\\)\\]" 1)
 ))

 (add-hook 'markdown-mode-hook
           (lambda ()
             (setq imenu-generic-expression markdown-imenu-generic-expression)))

Pretty awesome! I hope it helps you make awesome things.

Emacs Thoughts + Some Lisp

Fri, 13 Jul 2012 00:00:00 -0400

In no particular order:

Org Mode Guilt and a Lisp Function

I have some guilt about having mostly forsaken org-mode,1 in particular because I was watching Sacha Chua's chat with John Wiegley, and I think both are such nifty hackers, and have done so many things that are pretty darn nifty.

I liked what I heard about johnw's org mode setup so much that I might give it a try again. But in the mean time, I wanted to make my "recompile my tasklist function" to be a bit more clean. The result is follows:

(defun tychoish-todo-compile ()
  (interactive)
  (if (get-buffer "*todo-compile*")
      (progn
        (switch-to-buffer-other-window (get-buffer "*todo-compile*"))
        (recompile))
    (progn
      (compile "make -j -k -C ~/wiki")
      (switch-to-buffer-other-window "*compilation*")
      (rename-buffer "*todo-compile*")))
  (revbufs))

Notables:

This is the first time I've used progn which is somewhat embarrassing, but it's a great thing to have in the toolkit now. Link: progn
I hadn't realized until now that there wasn't an else-if form in emacs lisp. Weird, but it makes sense.
Compilation Mode is pretty much my current favorite thing in emacs.
revbufs is this amazing thing that reverts buffers if there aren't local modifications, and also reports to you if a buffer has changed outside of emacs and there are local modifications. So basically "does everything you want without destroying anything and then tells you what you need to do manually." Smart. Simple. Perfect.

I might need to "macro-ize" this, as I have a lot of little compile processes for which I'd like to be able to trigger/maintain unique compile buffers. That's a project for another day.

Emacs Thoughts

I'm even thinking about putting together a post about how, although I'm a diehard emacs user, and I've spent a fair bit of time learning how to do really great things with emacs, there are a lot of vim-ish things in my workflow:

I read email with mutt and I've tried to get into GNUS, and I try it again every now and then, but I always find it so unbelievably gnarly. At least the transition. Same with Notmuch, which I like a lot more (in theory,) but I find the fact that Notmuch and mutt have this fundamental misunderstanding about what constitutes a "read" email, to be tragic.
I use a crazy ikiwiki + deft + makefile setup for task tracking. As (obliquely) referenced above.

I might give org another shot, and I've been looking at task warrior, but the sad truth is that what I have works incredibly well for in most cases, and switching is hard.
I tend jump to a shell window to do version control and other things, even though I'm familiar with magit and dired, my use of these tools is somewhat spotty.

It's not that I think org-mode sucks, or anything. Far from it, but how I was using org-mode was fundamentally not working for me. I'm thinking about giving it a try again, but we'll see. ↩

Assisted Editing

Thu, 09 Feb 2012 00:00:00 -0500

I learned about artbollocks-mode.el from Sacha Chua's post, and it's pretty freaking amazing.

Basically, it does some processing of your writing--while you work--to highlight passive sentences and affected jargon.1 And that's all. There are some functions for generating statistics about your writing, but I find I don't use that functionality often. You can enable it all of the time, or just turn it on when you're doing editing.

After a few weeks, I've noticed a marked improvement in the quality of my output. I leave it on all the time, but I'm pretty good at resisting the urge to edit while I'm writing. Or at least I'm pretty good at picking up again after going back to tweak a wording. In general it's hard to keep more than a few things in an editing pass at any time.

It turns out that the instant feedback on passive sentences, even though it's not perfect, is great for improving the quality of my content the first time out. And it's even better for doing editing work. It's harder to ignore a passive sentence when the editor is highlighting you see a screen full of them for you.

It's of course important to be able to ignore its suggestions from time to time, and it's no harder to ignore than "flyspell-mode" (the on-the-fly spell checker in emacs.)

This is perhaps the clumsiest part of the default distribution, as jargon is terribly specific to the kind of writing you're doing, and it turns out that one of the "art critic"/post-modern words (i.e. "node") is a word that I end up using (acceptably, I think) in a technical context when describing a clustered system. And there's a difference between a technical lexicon and a jargon, and regular expressions aren't terribly sensitive to this, so the actual list of words that you need to call yourself out on, varies a bit from person to person. But once you customize it, it's great. ↩

Persistent Emacs Daemons

Thu, 02 Feb 2012 00:00:00 -0500

I've been subject to a rather annoying emacs bug for months. Basically, when you start emacs with the --daemon switch, and the X11 session exits, and any emacs frames are open, then the emacs process dies. No warning. The whole point, to my mind, of the daemon mode is to allows emacs sessions to persist beyond the current X11 session.

This shouldn't happen. I think this is the relevant bug report, but I seem to remember that the issue has something to do with the way that GTK interacts with the X11 session and emacs's frames. It's something of a deadlock: the GTK has no real need to fix the bug (and/or it's a behavior that they rely on for other uses,) and it might not really be possible or feasible for emacs to work around this issue.1

I also think that it's probably fair to say that daemon mode represent a small minority all emacs usage.

Regardless, I've figured out the workaround:

.. don't use GTK.

Turns out, it's totally possible to build GNU emacs without GTK, by using the "Lucid" build. Which is to say, use the windowing system kit built for Lucid Emacs (i.e. XEmacs,) rather than GTK. I was able, using the code below, to get an emacs experience with the new build that seems identical2 to the one I used to get with GTK, except without the frustrating crashes every time that X11 spazzed when I decided to unplug a monitor or some such. A welcome improvement, indeed.

The following emacs-lisp covers all of the relevant configuration of the "look and feel" of my emacs session. Install the Inconsolata font if you haven't already, you'll be glad you did.

 (setq-default inhibit-startup-message 't
               initial-scratch-message 'nil
               save-place t
               scroll-bar-mode nil
               tool-bar-mode nil
               menu-bar-mode nil
               scroll-margin 0
               indent-tabs-mode nil
               flyspell-issue-message-flag 'nil
               size-indication-mode t
               scroll-conservatively 25
               scroll-preserve-screen-position 1
               cursor-in-non-selected-windows nil)

 (setq default-frame-alist '((font-backend . "xft")
                             (font . "Inconsolata-14")
                             (vertical-scroll-bars . 0)
                             (menu-bar-lines . 0)
                             (tool-bar-lines . 0)
                             (alpha 86 84)))

 (tool-bar-mode -1)
 (scroll-bar-mode -1)
 (menu-bar-mode -1)

Hope this helps you and/or anyone else that might have run into this problem.

I'd like to add the citation and more information here, but can't find it. ↩
To be fair, I mostly don't use the GUI elements in emacs, though having emacs instances outside of the terminal is nice for displaying images when using emacs-w3m, and for having a little bit of additional display flexibility for some more rich modes. ↩

Back to Basics Tasklist and Organization

Mon, 14 Nov 2011 00:00:00 -0500

I'm a huge fan of emacs' org-mode on so many levels: as an IDE for knowledge workers, as a task management system, as a note taking system, and as the ideal basic mode for so many tasks. However, I've been bucking against org-for a number of tasks recently. The end result is that I'm becoming less org-dependent. This post is a reflection on how I've changed the way I work, and how my thinking has changed regarding org-mode.

Fair warning: this is a really geeky post that has a somewhat specialized context. If you're lost or bored. check back later in the week.

The Perils of Org

The problem I keep running into with org is that I really don't prefer to work in org-mode.1 Org is great and very flexible, but I don't like that it means that all text-based work is dependent on emacs. My brain is already wired for Markdown and reStructured Text from years of blogging and work projects respectively.

And then there's this organization problem. There are two ways you can organize content in org-mode. The first is to just dump every thing in one org-mode file and use the hierarchical outlining to impose organization to organize everything. The second is to have every project inside of it's own file and use outlining incidentally as the project needs it. Content aggregation happens in the agenda.

The problem with the "large files" approach is that you end up with a small handful of files with thousands of lines and imposing useful organization is difficult (too many levels and things get buried; not enough and inevitably your headings aren't descriptive enough and you get confused. Furthermore, I end up living in clone-indirect-buffer-other-window'd and org-narrow-to-subtree'd buffers, which is operationally the same as having multiple files it just takes longer to set up.

The problem with the other approach, having lots of different files, is that I have a hard time remembering what is in each file, or in logically splitting big projects into multiple files. The agenda does help with this, but the truth is that the kinds of org-headings for organization and tasks are not always the same kinds of headings that make sense for the project itself. I often need more tasks than organizational divides in a project. I tried this approach a couple of times, and ended up with useless mush in my files.

Typically, I can never make the "lots of file approach" really work, and the big files problem lead me to general avoidance of everything. Not good. The key to success here is good aggregation tools.

Hodgepodge

In response, I've made a couple of tweaks to how I'm doing... pretty much everything. That is:

I've moved most of my open projects into a locally ruining and compiling ikiwiki instance. Both laptops have this setup, and there's a central remote to keep both (all?) machines in sync.
I'm using ikiwiki-tasklist to basically replicate the functions of org-agenda. Basically this crawls the entire wiki looking for lines that begin with certain keywords and generates a "todo" page based on these notes. Really simple, incredibly useful and it solves much of my aggregation needs.
I still have some stuff in org-mode: notes for the nearly-finished novel, lots of random old (legacy) data, 12 various open tasks, and org-capture. I'm thinking of pointing various org-capture templates at files in the wiki but haven't gotten there yet.
I've basically taken the "lots of little files," approach to my writing and work. I've not over-leaded the system yet. Each major project gets a page in the root level of the wiki for overview and planing, and then sub-pages for all related project files (if/as needed)
It turns out that the markdown-mode for emacs has gotten a few improvements since the last time I downloaded the file, including better support for wiki-links that are mostly compatible with ikiwiki. Also from the same developer deft which implements a pretty nifty incremental search for text files in a given directory. So between these tools, ikiwiki, and the ikiwiki-tasklist there's support for the most important things.
In terms of publishing, beyond ikiwiki for tychoish.com and the personal organization instance, I have a couple of other smaller wikis (also ikiwiki powered,) and I've been playing with Sphinx as publishing for more structured documents and resources (i.e. documentation, novels, and collections,) particularly those that need multiple formats and presentations.

I'm sure there will be more shifts in the future, I'm sure. I think this is a good start. ?Thoughts, suggestions or discussion?

This has pretty much always been the case. I think of it as a personal quirk. ↩

Writing Software Beyond Emacs

Tue, 27 Sep 2011 00:00:00 -0400

The ideal writing application is emacs, at least for me. In the absence of emacs (as on a tablet,) I've been thinking about what features I actually need in a writing application. While I've grown to admire the power of a full Lisp machine in my text editor, I accept that it's not, strictly speaking required. Here's a first stab at the list of requirements. Feel free to edit this page in the wiki or or discuss:

Simple, primarily full screen editing.
The ability edit very large files, 100kbs should present no issue.
Some sort of syntax highlight during the editing process, preferably support for LaTeX, Markdown, and org-mode.
Word count generation for the entire files and for current selections.
Auto-save as crash protection.
Undo/Redo last typing action.

Nice to have (but not crucial) features:

The ability to edit one file and reference another (or potentially edit) at the same time. Bonus points for being able to switch between to parts of a single file at once.
The ability to hide or collapse some sections of a file.
Optional spell checking.
Parenthetical and double-quote matching.
Soft and hard line/word wrapping.

Other than that I don't think there's anything that I really need to have to get writing done 90% of the time. How about you?

Org Mode and Mobile Writing

Thu, 15 Sep 2011 00:00:00 -0400

This post is adapted from a post I made to the org-mode email list a few weeks ago. I proposed an application to compliment MobileOrg for writing. Where MobileOrg collects the core bits of org-mode's task planning functionality in a form that makes sense for smart phone users, the parts of org-mode functionality that people use to for writing and organizing the content of larger form projects isn't particularly accessible.

I spend (or should spend) 70% or more of my time in front of a computer writing or editing something in org-mode. Most of my org files have tens of thousands of words of blog posts, notes, drafts of articles, and so forth. While I can store that data on an android device with only minor problems using a little script that I put together, and I can [capture content into my org-files using email and some nifty filters, and there are text editors that can let me edit these files: it could be better.

The proposal is simple. Can we build something like Epistle for org-mode? It might just render org-mode text to HTML, and frankly that would be enough for me. If the editing interface had an org-indent-mode equivalent, org-syntax highlighting, and even collapsing trees or org-narrow-to-subtree, that'd be kind of like heaven.

I'm not a mobile developer, so I can't promise to start making an app this instant if there's interest but if anyone's bored and thinks this might be a good idea (or knows of something that might work better for this.) I'd love to hear about it. If someone wants to start work on this, I'll do whatever I can to help make this a reality.

Onward and Upward!

Update Rhythm

Tue, 30 Aug 2011 00:00:00 -0400

I wonder if, at some point, this constant state of overload and flux in my world will begin to seem normal and I'll just adjust to that normal. In the mean time, exciting things are happening and I'm not quite sure of the best way to write about them. Perhaps soon. For now, I'm trying to get better about updating more regularly and I have a bunch of links of stuff that have happened on the wiki in the past couple of weeks that I'd like to share. Here we go:

Discussion of Rhizomes

jfm and I had a good exchange about an old post that I wrote on "Ideology and Systems Administration." Basically the posts says, "systems administrators have a unique approach to solving technological problems," and discussed the implications of systems administrators background on technology development. I think our clarifications were useful.

There are a couple of comments on my recent series on a productivity. First, I wrote a post about task planning and creating task items, and madalu posted a comment. Second, a number of us had an ongoing conversation on mobile productivity in response to the "Mobile Productivity Challenges" post (link,) that touched on emacs (of course!) input, and context switching.

Site Tweaks

This is a pretty minor point, but I've been subtly tweaking the design a little in the site. There are now links to the tags page and the site-map in the upper right hand corner. I've also made links to as-of-yet-uncreated wiki pages red (according to wiki-convention.) I think (and hope) that red links are easier to spot when they're red. Feedback on the design would be most welcome. My goal is to make the site welcoming, easy to use, and to minimize the amount of "fussiness." It might be time for a full refresh, but ?feedback on the subject might be good.

Critical Futures and Wiki Fiction

As a build on top of my"Wiki Fiction" post, I've moved the pages that had been located on the critical-futures page to previous/critical-futures. Eventually the story will move to the Critical Futures domain, but that's a bit down the road. Right now I'd rather focus my time/energy on writing some stories, for now (on this wiki.) Infrastructure can come next.

I hope to work on a series of posts that explore collaborative fiction organizing over the next few weeks. If people are interested, that is.

External Links

I came across a blog from the comments on the make emacs better post that I wanted to offer as a link The Babbage Files is a great cyborg/emacs/free software blog.

This is probably not news to anyone, but from John Wiegley I learned about the following two emacs gems that merit mention:

paredit which makes handling all of the parentheses in Lisp coding much easier.
redshank, which basically adds a number of tempting systems and associated tools for

And in another direction, I've been playing with pylookup. This emacs add on makes it possible to access python documentation from within emacs, from a local copy. The interface is a little bit fiddly but it's pretty much heaven. More things should work like this.

Onward and Upward!

Hyperlinks

Fri, 08 Jul 2011 00:00:00 -0400

Though short, this week has been pretty good. I've been doing cool things at work, I've been writing and posting blog entries, and fiction(!), I'm on top of email, and the sweater is growing. I hope this isn't just a fluke and that I can keep this up and also expand slightly into doing a bit more reading. Small steps.

I've done a little bit of work on the wiki and site. Notably, selected entries are mirrored on Planet Emacsen. Also consider the following links to updates on the wiki and other sites:

Discussion of "Make Emacs Better", which has been incredibly productive and an interesting discussion of emacs adoption and use by non-programmer niches. I think this discussion and the original post connect pretty well with a post that made the rounds a few weeks ago: Lets Just Use Emacs
Cyborg History - a link from my father on the history of computing. I replied to him with Code Quarterly Interview with Hal Abelson.
I've also collected a few LaTeX System links, of related projects, ideas and collaborators. I've also had a few conversations that I need to transcribe into the wiki. Watch this space.
Then there's emacs-instapaper, which isn't exactly a FaiF web service, but the functionality is great for the subway, and I like being able to keep Firefox closed more of the time.

That's all for now!

Make Emacs Better

Wed, 22 Jun 2011 00:00:00 -0400

I love emacs. I'm also aware that emacs is a really complex piece of software with staggering list of features and functionality. I'd love to see more people use emacs, but the start up and switch cost is nearly prohibitive. I do understand that getting through the "emacs learning curve" is part of what makes the emacs experience so good.

That said, there really ought to be a way to make it easier for people to start using emacs. Think of how much more productive some developers and writers would be if the initial experience of emacs was less overwhelming. And if emacs were easier to use, developers could use emacs as a core (embeded, even) component of text-editing applications, for instance, some sort of specific IDE built with emacs tools, or a documentation creation and editing toolkit built with emacs. I'd go for it, at least.

To my mind there are three major challenges for greater emacs usability. Some of these may be pretty easy to change non-intrusively, others less so. Feedback is, of course, welcome:

The biggest problem is that there's no default configuration. While I appreciate that this provides a neutral substrate for people to customize emacs for themselves, you have to write lisp in order to do pretty much anything in emacs other than write lisp. And customize-mode is well unmentioned, but not particularly usable.

Perhaps one solution to this problem would be to create a facility within emacs to build "distributions," that come configured for specific kinds of work. That way, emacs can continue to be the way it is, and specialized emacs can be provided and distributed with ease.
Improve the customize interface. I like the idea of customize, but I find it incredibly difficult to use and navigate, and end up setting all configuration values manually because that's easier to keep track of and manage. I'd prefer an option where you configure your emacs instance the way you want (through some sort of conventional menu system), and then have the option of "dumping state" to an arbitrary file that makes a little more sense than the lisp structure that customize produces. Then, as needed, you could load these "state file(s)," But then I've never used the menu-bar at all, so perhaps I'm not the best person to design such a system.

This strikes me as a more medium term project, and would make it easier for people who want to modify various basic behaviors and settings. I don't think that it would need to totally supplant customize, but it might make more sense.
Improve and add the ability to extend emacs beyond emacs-lisp. I initially thought emacs-lisp was a liability for emacs adoption and I don't think this is uncommon, but I've since come to respect and understand the utility of emacs lisp. Having said that, I think offering some sort of interopperability between emacs and other languages and interperators, might be a good thing. Ideas like ParrotEmacs and using the Guile VM to run existing emacs-lisp in addition to other new code would be great.

This is a longer term project, of course, but definitely opens emacs up to more people with a much more moderate learning curve.

I've been working (slowly) on getting my base configuration into a presentable state that I can push it to a git repository for everyone to see and use, which (at least for me) might start to address problems one and two, but three is outside of the scope of my time and expertise. The truth is that emacs is so great and so close to being really usable for everyone, that a little bit of work on these, and potentially other, enhancements could go a long way toward making emacs better for everyone.

Who's with me? Let's discuss!