Emacs Chat with Steve Purcell

In this Emacs Chat, Steve Purcell shares how he got started with Emacs by using a Vim emulation mode, what it’s like to give hundreds of package authors feedback on Emacs Lisp style, and how he’s eventually replacing himself with Emacs Lisp (flycheck-package). He also highlights useful packages for managing buffers of version-controlled files (ibuffer-vc), working with lines if the region isn’t active (whole-line-or-region), or maximizing certain buffers (full-frame).

http://youtu.be/Gq0hG_om9xY

Quick video table of contents (times are approximate):

0:04 From Vim to Emacs with Viper
0:11 Packages
0:18 Feedback
0:20 Lisp style
0:21 Flycheck
0:28 Versioning
0:32 Config
0:40 ibuffer-vc
0:41 whole-line-or-region
0:44 full-frame
0:47 Not using Emacs for everything
0:48 Auto-complete, hippie-expand
0:51 Graceful degradation with maybe-require-package
0:57 Making sense

Transcript will follow. In the meantime, you can check out Steve’s config at https://github.com/purcell/emacs.d, follow him on Twitter at @sanityinc, or go to his website at http://sanityinc.com/. You can find other Emacs Chats at http://sachachua.com/emacs-chat .

Got a nifty Emacs workflow or story that you think other people might find useful? I’d love to set up an Emacs Chat episode with you. Please feel free to comment below or e-mail me at [email protected]!

Move your goalposts to get around an inability to finish projects

I hardly ever finish projects. I start them with a burst of enthusiasm, and then I trail off when something else catches my attention. I’ve learned to work with this instead of beating myself up about it. On some days, I might even consider it a good thing. Here’s one of the things I’ve learned:

You can trick your brain by moving the goalposts.

Let’s say that you’re working on a project. Toward the end of the project, you catch yourself losing steam. You’ve gotten 80% of the way there, and the remaining 20% of the work will take four times as much time. The itch to start a different project is pulling you away.

Don’t think of yourself as nearly done. Think of yourself as getting started on another new project that just happens to overlap with the previous one.

 

In fact, mentally set the beginning of that project to include some of the work you’ve just completed, to take advantage of the Endowed Progress effect (research PDF).

moving-the-goalposts

Tada! Goalposts moved. You might find that the newly-reframed project is now novel enough to be included in the list of new projects you enjoy working on, and it might even tempt you away from other distractions.

Moving the goalposts is usually a bad thing. It’s why many people never feel rich, because whenever they reach what used to be unimaginable wealth, they find that the amount of money needed for them to feel happy has gone up. (Solution: don’t anchor happiness to amounts of money.) Moving the goalposts has led to many a logical fallacy in heated arguments. But if you don’t like playing a close-quarters game, moving the goalposts further away can help.

I often use this technique for life-long learning, especially for things that you can’t really declare finished. Can one ever finish learning how to write or draw or program? No, but you can keep moving your targets a little forward as you learn.

You might think, “I won’t be able to celebrate achieving my original goal!” You can still celebrate milestones. Better yet, celebrate even the tiny, tiny steps that you take towards your (constantly-moving) goal. Look behind you once in a while and celebrate the progress you’ve made.

It can be hard to see progress if you don’t have anything tangible. Invest time in looking for useful chunks that you can extract even from work in progress. It’s surprising how few projects are truly all or nothing. If you can share drafts, prototypes, alpha or beta versions, or even blog posts about the journey, you don’t have to worry about the whole thing being a complete waste of time if you get distracted from the project before you finish it. If you always wait until you’ve finished something, you might end up leaving a mess of incomplete projects around.

Worried that your mind will see through this technique and lose interest even earlier in the process? Try being playful about it instead of being too serious. Yes, it’s a mental trick (and not even a particularly complex one), but if your mind likes novelty and beginnings, it can hardly fault you for giving it what it likes.

This technique doesn’t solve everything – I haven’t been able to write a 200-page Emacs book yet, and our couch still doesn’t have a slipcover. But it helps me from time to time, and maybe it will help you too!

Developing Emacs micro-habits: Abbreviations and templates

When it comes to improving how you use Emacs, picking one small change and paying close attention seems to work well. Little things make a lot of difference, especially when frequently repeated over a long period of time. It reminded me of this quote I came across on Irreal:

I’ve gotten the hang of basic multiple-cursors-mode and I’m making gradual progress towards internalizing smart-parens by the simple approach of focusing on one tiny habit at a time. For example, I spent a week reminding myself to use mc/mark-all-like-this-dwim or mc/mark-lines instead of using keyboard macros.

Inspired by the Emacs Advent Calendar, I wanted to start a 52-week series on micro-habits for more effective Emacs use. I brain-dumped an outline of four sets (basic Emacs, Org, programming, meta-habits) of thirteen small tips each. Looking at my list, I realized there were many ideas there that I hadn’t quite gotten the hang of myself. I figured that this might be more of a project for 2016; in the meantime, I could learn by doing.

The first micro-habit I wanted to dig into was that of automating text: abbreviations, templates, and other ways to expand or transform text. I’d used Yasnippet before. I sometimes accidentally expanded keywords instead of indenting lines if my cursor happened to be at the wrong spot. But I hadn’t yet drilled the instinct of automation or the familiarity with templates into my fingers.

This blog post isn’t the easy-to-understand guide to automating text. I’ll write that later, when I’ve figured more things out. In the meantime, I’ll share what I’ve been learning and thinking so far, and maybe you can help me make sense of it.

Emacs has a separate manual for autotyping, which I had never read before. The short manual covers abbrev, skeleton, auto-insert, copyright messages, timestamps, and tempo. Did you know that define-skeleton lets you create a template that accepts multiple interregions if you call your skeleton function with a negative argument? (Interregions? What are those?) It took me an embarrassing amount of time to figure out how to mark interregions and use them. It turns out they have to be contiguous. It might be easier to think of marking the beginning of the region, marking some points in the middle, and then calling the command when your point is at the end – which is probably how most people would interpret the diagrams, but I was trying to mark discontinuous regions because that would be super-cool, and that totally didn’t work. And then I forgot that using helm-M-x means you need to specify numeric arguments after typing M-x instead of before. (I wrote about that very point in one of my blog posts, but it slipped my mind.) Once I got past that, I was delighted to find that it worked as advertised. I still haven’t imagined a situation where I would use it, but it seems like a good sort of thing to know.

What are the practical situations where text automation can help people work more effectively? I looked around to see how other people were using it. Coding, of course – especially if you use Emacs Lisp to transform the text. Debugging, too. Marking up text. Remembering parameters. Wrapping regions. Writing e-mails. Adding blog post metadata. Citing references. Lifehacker has a long list, too.

I came up with several categories I’m going to focus on so that I can more easily recognize opportunities to work better:

2015-01-05 Seeing opportunities for abbreviations and text automation -- index card

2015.01.05 Seeing opportunities for abbreviations and text automation – index card

  • Abbreviations are about typing long words with fewer keystrokes. For example, you might shorten “description” to desc.
  • Phrases are like word abbrevations, but longer. You might want to be able to expand btw to “by the way.”
  • Code benefits from expansion in multiple ways:
    • Automatically inserting characters that are harder to reach on a keyboard, like { and }
    • Being consistent about coding style, like the way many people like adding a comment after the closing brace of an if
    • Transforming text that shows up in multiple places, such as variable names that need getters and setters
    • Filling in the blanks: parameters, comments, etc.
    • Reducing the cognitive load of switching between languages by establishingq a common vocabulary. For example, I sometimes need to look up the syntax of for or the proper way to display a debugging statement when I switch to a language I haven’t used in a while
  • Templates are also useful for consistency in writing, planning, and other areas
  • Text transformation can save time and minimize error.

2015-01-04 Automating text - index card

2015.01.04 Automating text – index card

Translating the examples I’d seen to my personal interests, I could probably find plenty of opportunities to automate text while coding, debugging, writing, planning, or publishing. To dig deeper, I looked at each of the categories in detail.

Abbreviations

2015-01-06 Abbreviations -- index card

2015.01.06 Abbreviations – index card

When I was curious about typing faster, I read forum posts from people who had increased their speed by developing their own form of digital shorthand. The trick works on paper, too. When I need to write quickly or in limited space, I use abbreviations like bc for “because” and w/o for “without.” Why not on the computer as well?

I often take advantage of dynamic abbreviations when I know I’ve recently typed the word I want. To trigger those, I just have to type the beginning of the word and then use dabbrev-expand. I haven’t set up my own static abbreviations, though. Main obstacles:

  • I want to write shorter words instead of longer ones
  • In the beginning, it’s faster to type the word instead of thinking of the abbreviation and expanding it
  • If I have to undo or backspace, that makes me slower
  • If I burn this into my muscle memory, I might be more frustrated on other computers or in other apps (then again, I already customize Emacs extensively, so I guess I’m okay with the tradeoff)

Anyway, here’s a short list I’m trying out with define-global-abbrev and hippie-expand:

hw however
bc because
wo without
prob probably
st sometimes

Hmm. Let’s say that it takes me two keystrokes to trigger the expansion, whether it’s the xx keychord I’ve just set up or the M-/ I’ve replaced with hippie-expand. (Hmm, maybe a double-space keychord is a good candidate for expansion too.) Is the retraining worth a ~50% possible reduction in keystrokes? Probably not.

How about text with punctuation, so I can minimize reaching for symbols?

blog http://sachachua.com/blog/
mail [email protected]

Maybe it’s better to look at the words I frequently misspell, or that I tend to slow down then typing. I’ll keep an eye out for those.

Phrases

2015-01-06 Phrases -- index card

2015.01.06 Phrases – index card

Phrases are an easier sell. Still, I’m trying not to settle into the rut of set phrases. I should cut those mercilessly or avoid writing them from the beginning.

co check out
iti I think I
otoh on the other hand,
mean in the meantime,
fe for example
fi for instance,
oc of course
ip in particular

Code insertion

This is, fortunately, well-trodden ground. The yasnippet package comes with a large collection of snippets for many programming languages. You can start by familiarizing yourself with the pre-defined snippets for the modes that you use. For example, in my installation, they’re under ~/.emacs.d/elpa/yasnippet-20141117.327/snippets. You can use the filename (or keywords defined with key, if specified) as the abbreviation, and you can expand them with yas-expand (which should be bound to TAB if you have yas-global-mode on).

I mostly work with HTML, CSS, Javascript, Ruby on Rails, and Emacs Lisp, so this is the cheat sheet I’ve made for myself:

2015-01-07 Code insertion -- index card

2015.01.07 Code insertion – index card

For HTML, I need to remember that the tags are generally expandable, and that there are a few Lorem Ipsum abbreviations triggered by lorem.1 through .5. CSS has a v abbreviation that sets up a bunch of rules with vendor prefixes. For Javascript, I’ll probably start with f to define a function and log to output something to console.log. Rails has a bunch of iterators like eai that look interesting. As for Emacs Lisp, the pre-defined templates generally add parentheses around common functions so you don’t have to type them, and there are a few shortcuts like bs for buffer-string and cc for condition-case. I think I’ll modify the default snippets to make better use of Yasnippet’s field support, though, so that I don’t have to delete and replace text.

Templates

In addition to using text expansion for code, you can use it for planning and writing other text. I saw Karl Voit use it to great effect in my Emacs Chat with him (around the 44:00 mark), and I’ve been gradually refining some templates of my own.

2015-01-07 Templates -- index card

2015.01.07 Templates – index card

For example, here’s the template I’ve been using for sketched books. Note: If you use Yasnippet for Org Mode properties, you may want to set yas-indent-line to fixed or the fields will get confused.

Gist: sbook

# key: sbook
# name: Sketched Book
# --

**** TOSKETCH ${1:short title}
      :PROPERTIES:
      :TITLE: ${2:long title}
      :SHORT_TITLE: $1
      :AUTHOR: ${3:authors}
      :YEAR: ${4:year}
      :BUY_LINK: ${5:Amazon link}
      :BASENAME: ${6:`(org-read-date nil nil ".")`} Sketched Book - ${2:$(sacha/convert-sketch-title-to-filename yas-text)} - ${3:$(sacha/convert-sketch-title-to-filename yas-text)}
      :ISBN: ${7:ISBN}
      :BLOG_POST: http://sachachua.com/blog
      :END:

$0

***** TODO Sketchnote $1
:PROPERTIES:
:Effort: 2:00
:QUANTIFIED: Drawing
:END:

[[elisp:sacha/prepare-sketchnote-file][Prepare the file]]

***** TODO Write personal reflection for $1
:PROPERTIES:
:Effort: 1:00
:QUANTIFIED: Writing
:END:

[[http://sachachua.com/blog/wp-admin/edit.php?page=cal][View in calendar]]

****** Sketched Book - $2 - $3

$3's /$2/ ($4) ...

I’ve sketched the key points of the book below to make it easier to remember and share. Click on the image for a larger version that you can print if you want.

Haven't read the book yet? You can [[$5][buy it from Amazon]] (affiliate link) or get it from your favourite book sources.

Like this sketch? Check out [[http://sketchedbooks.com][sketchedbooks.com]] for more. Feel free to share – it’s under the Creative Commons Attribution License, like the rest of my blog.

***** TODO Post $1 to blog
:PROPERTIES:
:Effort: 1:00
:QUANTIFIED: Packaging
:END:


***** TODO Update sketched books collection
:PROPERTIES:
:Effort: 1:00
:QUANTIFIED: Packaging
:END:

1. [[elisp:sacha/index-sketched-book][Index sketched book]]
   - [[file:~/Dropbox/Packaging/sketched-books/index.org][Edit index]]
   - [[file:~/Dropbox/Packaging/sketched-books/ebook.org][Edit ebook]]
2. [[elisp:sacha/package-sketched-book][Compile]]
3. Update [[https://gumroad.com/products/pBtS/edit]]

***** TODO Tweet sneak peek of $1 with attached picture

[[elisp:(progn (kill-new (format "Sneak peek: Sketched Book: %s - %s %s" (org-entry-get-with-inheritance "SHORT_TITLE") (org-entry-get-with-inheritance "AUTHOR") (org-entry-get-with-inheritance "BLOG_POST"))) (browse-url "http://twitter.com"))][Copy text and launch Twitter]]

It’s a lot of code and I keep tweaking it as I come across rough corners, but it’s handy to have that all captured in a template that I can easily expand. =)

Text transformation

One of the advantages of tweaking text expansion inside Emacs instead of using a general-purpose text expansion program is that you can mix in some Emacs Lisp to transform the text along the way. I’m still thinking about how to make the most of this, as you can see from this half-filled note-card:

2015-01-07 Text transformation as part of expansion -- index card

2015.01.07 Text transformation as part of expansion – index card

For example, this snippet makes it easier to share source code on my blog while also linking to a Gist copy of the code, in case I revise it or people want to comment on the code snippet itself. It doesn’t use any of the built-in text expansion capabilities, but I think of it as a text expander and transformer because it replaces work I used to do manually. You’ll need the gist package for this one.

Gist: Sacha (updated to clean up region code)

(defun sacha/copy-code-as-org-block-and-gist (beg end)
  (interactive "r")
  (let ((filename (file-name-base))
        (mode (symbol-name major-mode))
        (contents
         (if (use-region-p) (buffer-substring beg end) (buffer-string)))
        (gist (if (use-region-p) (gist-region beg end) (gist-buffer))))
    (kill-new
     (format "\n[[%s][Gist: %s]]\n#+begin_src %s\n%s\n#+end_src\n"
             (oref (oref gist :data) :html-url) filename
             (replace-regexp-in-string "-mode$" "" mode)
             contents))))

Both Yasnippet and Skeleton allow you to use Lisp expressions in your template. If you don’t have all the data yet, you might consider writing another Lisp function that you can call later when you do. For example, in the sketched books code above, I have an Emacs Lisp link that composes a tweet with a link, puts it in the clipboard, and then opens up a web browser. (I do this instead of posting directly because I also want to attach an image to that tweet, and I haven’t figured out how to modify any of the Emacs Twitter clients to do that.)

So that’s what I’ve learned so far about automating text in Emacs. It’ll take me more than a week to get the hang of the abbreviations I’ve just set up, and I’ll probably need to add even more before adding and using abbreviations become true habits. But hey, maybe this will help you pay closer attention to repetitive text and editing actions in Emacs so that you can automate them too, and we can swap notes on useful abbreviations. What kind of text do you expand?

For more information, see:

Breaking down the skill of outlining

What do I mean when I say that I want to get better at outlining? What can outlining help me with, anyway?

Outlines are good for:

  • Capturing thoughts quickly: You don’t have to write full sentences. You can add keywords or phrases in any order, and you can flesh them out later.
  • Writing non-linearly: You don’t have to write one paragraph after another. You can jot down your key point, come up with a few supporting points, and then think about your introduction or conclusion.
  • Organizing your thoughts: You don’t need to always go from topic to detail. You can capture random thoughts and then group them afterwards.
  • Deciding on depth and coverage: How much detail should you include? What subtopics do you want to cover, and what will you save for another post? What can you cut, and what’s missing? An outline can help you discover these things before you spend a lot of time writing.
  • Rearranging topics for a more logical flow: Does it make sense to discuss one idea before the other? Fixing the flow in your outline saves you from rewriting all the transitions.
  • Writing quickly: If you’ve mapped out what you want to talk about, you don’t have to worry as much about writer’s block – all you have to do is follow the trail.
  • Picking things up where you left off: If you’re writing something that you can’t finish in one sitting (or if you want to be able to revise it easily even after some time), an outline helps you remember what you want to say and see what you need to do next.

Let me break outlining into sub-skills and think about different ways I can practise each of them.

  1. Outlining a single blog post
  2. Reverse outlining
  3. Outlining link-heavy posts or summary posts
  4. Outlining larger resources and books
  5. Outlining lifelong learning

1. Outlining a single blog post

I tend to write short blog posts focusing on a single question I want to explore or a point I want to make. This results in posts that are usually somewhere between 400 and 2,000 words. Although I’m comfortable with this way of working, I think outlining can help me organize my posts more effectively. Writing in paragraphs sometimes gets in the way of seeing the post as a whole or tweaking its flow easily. If I make an outline and then transform it into text, I find it easier to keep the whole post in mind as I write.

Because I use Org Mode for Emacs to write, it’s easy for me to work with outlines. I can hide and show parts of my outline using keyboard shortcuts. I can also keep a copy of the outline in one part of my window while I rewrite another copy of the outline into the actual text.

In addition to practising by outlining posts like this one, I can double-check the flow of a post while it’s in outline form, and I can also try different permutations of the order.

2. Reverse outlining

To create a reverse outline, start with an existing text. Identify the key points of each paragraph, and create an outline based on that. Organize those points into a more complex structure as needed.

I sometimes use reverse outlines with my own posts or drafts if I get the sense that things are a little out of order, but I can’t pin down why. With Org Mode, I can add list items before each paragraph, summarizing their key points. Then I can manipulate those list items with keyboard shortcuts, hiding the paragraphs or moving them around. When I’m happy, I can remove the outline structure and go back to working with paragraphs.

Reverse outlines are also useful when studying other people’s writing for content or for structure. They help you see the text as a whole instead of getting lost in paragraphs. I don’t do as much of this as I could. If I spent more time reverse-outlining posts that appealed to me, I could probably learn more about techniques for writing.

In addition to practising by creating reverse outlines for my posts and other people’s writing, I might find it useful to tweak Emacs for reverse outlining. I could write a function that automatically structures paragraphs into list items, and another function that extracts the paragraphs from the outline. Hmm…

3. Outlining link-heavy posts or summary posts

This is one step up from posts that deal with a single thought.

It can be challenging to write a blog post that links to lots of other blog posts. I find myself wondering where I want to go into more detail, how to avoid restating so much, how to bridge the different topics, and how to reconcile various types of writing.

I find outlines helpful for thinking about the structure of the post.

  • Should I bring in background information and then focus on a single question, exploring that in the body of the post?
  • Are the links tangential to the post, pointers for further exploration?
  • Am I trying to explain something to someone, and can I use links to let them dive down to the level of detail they want?

Outlines help me keep track of possible ideas to add and how to connect the different topics.

I write many posts that use links for background information or tangents, and the process for these is similar to the one for outlining a single blog post.

I don’t write many summary posts, though, and that’s something that I could practice. To do this well, I could pick more things that people want to learn (such as Emacs and Org) and write high-level overviews that link to more details.

One of the things getting in my way when it comes to working on summary posts, I think, is that it’s easy to pick the immediate benefit of moving myself forward a little, over the long-term benefit of teaching others (whom I could eventually learn from too). I can remind myself that I have plenty of time to write those exploratory posts, and that writing summary posts helps me consolidate, test, and share what I know.

4. Outlining larger resources and books

This is quite a few steps up from writing summary posts. I am not at all good at this yet, and will probably take a few years (at least!) to get the hang of it.

I practised a little this year by:

I tend to focus on writing the parts that are most interesting for me, so outlines sometimes make me feel guilty about the gaps. It turns out that working with existing material or committing to small chunks helps me get around challenges with motivation. I also do much better developing things in the open, getting feedback from people and revising things on the fly.

I’m looking forward to practising with 12-week courses, which make sense as the next small step to take.

5. Outlines for lifelong learning

Outlines can help with more than books and blog posts. I think they can help me learn overall, too. I think they might give me a way to place what I’m learning in context, connect things with other things I’ve learned or that I’m working on learning, capture threads that I’m not planning to investigate at the moment, and let me follow up with those threads when I want to revisit them.

I periodically update my learning plans, but I could give this more attention. Most of my learning notes are in my other Org files: rough notes by date in my journal, blog posts by topic in my index, outlines for things to write about in my sharing outline, and a high-level overview of evil plans.

There’s probably a better way to do this – perhaps incorporating my learning outline into my weekly and monthly review? I haven’t quite figured out how to combine past, present, and future in outlines in a way that makes sense to me while still making it useful to other people, like the way my blog index is useful because it’s not cluttered with other irrelevant points. Hmm.

Next steps

I hadn’t realized it before writing this post, but writing summaries and tiny guides (post-length, not book-length) would be a good in-between step for learning more about outlining before trying to tackle larger projects like books. A 12-week course of short tips might be interesting to do, too.

If you’re curious, you can find the outline for this post at https://gist.github.com/a69de5549d66694b387d . =)

How about you? What are the specific sub-skills you’re working on, and how?

Improving my evil plans for Emacs

Mwahahaha. My evil plans are yielding results, or at least that’s the impression I get because I’m learning so much from people who tell me that they found my blog helpful years ago. Even more recent experiments bear fruit: punchagan checked out Memacs because of my Emacs Chat with Karl Voit, and ended up writing a blog post about using the Emacs profiler.

2015-01-17 My Evil Plans for Emacs are yielding results -- index card #emacs #sharing

2015-01-17 My Evil Plans for Emacs are yielding results – index card #emacs #sharing

This makes me curious: What am I doing right, and how can I do it even better?

Looking at my Emacs posts, it seems I mostly write about figuring things out (and occasionally about cool things I’ve come across). People like the enthusiasm, and they sometimes pick up cool ideas too. The Emacs Hangouts and Emacs Chats are my way of working around my limitations; I don’t particularly like travel and I’m not up to organizing in-person meetups, but virtual meetups let me reach out to more people (and we can record the conversations more easily, too).

What are my goals?

  • I want to get better at using Emacs, because it’s useful and it tickles my brain
  • I want to help more people become intermediate and advanced users of Emacs, because then I get to learn from them (and also Emacs thrives as a community). I can do this by:
    • Showing people the benefits and possibilities of customization
    • Working out loud, showing my thought processes and the tools/libraries I use
    • Helping people develop a good mindset and handy skills
    • Sharing little tips and neat functions

How can I get even better at helping the Emacs community?

2014-04-26 Helping the Emacs community #emacs

2014-04-26 Helping the Emacs community #emacs

I really like the way (or emacs has daily Emacs snippets and Rubikitch describes Emacs packages in Japanese. I think I’ll slowly ramp up from once-a-weekish Emacs posts to maybe twice or three times a week. I have more posts already scheduled, but I just spread them out so that my non-geek readers don’t get overwhelmed.

Guides

Because I’m interested in things that tend to be idiosyncratic (workflows, customizations, etc.), I have a hard time making clear recommendations or putting tips into logical order. That’s probably why I do a lot more “thinking out loud”-type posts instead. I can experiment with identifying who might find a tip useful, extract the tips from my thinking-out-loud explorations, and gradually build up sets of related tips that way.

2015-01-16 Hmm – not guides but explorations – index card #sharing #packaging

I did actually manage to put together one guide (How to Read Lisp and Tweak Emacs) and half of another A Baby Steps Guide to Managing Your Tasks With Org. The sketches for How to Learn Emacs and Tips for Learning Org Mode are high-level guides, too.

Microhabits

I’ve been going back to the basics, working on developing even better Emacs microhabits. I’ve focused on two so far: abbreviating text and switching windows.I think there’s plenty of space to improve even in terms of taking advantage of what’s already out there (with minimal configuration along the lines of setting variables and keyboard shortcuts). And then there are even bigger opportunities to improve through customization and Emacs Lisp.

Helping people directly

I’ve mentioned coaching a few times. Bastien Guerry and a few other folks offer coaching as a service. Me, I’m not particularly familiar with the kinds of issues people run into or are curious about (ex: Mac OS X, programming mode setup). I’m mostly curious about workflow, and I’m happy to talk to people about that. It could be a good source of ideas for blog posts.

2015-01-08 Imagining coaching or guiding others -- index card

2015-01-08 Imagining coaching or guiding others – index card

When I ran my Google Helpouts experiments, I turned many of those tips into blog posts. I think that would be even more effective if people wrote up those tips themselves (it’ll reinforce their learning and it will bring them into the community), so I’ve been playing with the idea of strongly encouraging or even requiring write-ups.

2015-01-15 What if I required people to pay it forward -- #workingoutloud #sharing #teaching

2015-01-15 What if I required people to pay it forward – #workingoutloud #sharing #teaching

Unrealistic, but one can dream. Or one can focus on helping people who are already sharing their questions and ideas in blog posts or discussion forums, so that’s another approach. There’s no shortage of questions, that’s for sure.

Hangouts

I like Emacs Hangouts more than one-on-one coaching. Hangouts are public and recorded automatically, so people can learn from them even if no one has posted notes. It’s shaping up to be a wonderful peer-coaching sort of thing, which is good because I don’t have to be so worried about not being able to help at all. I wonder what this would be like with a bit of a mastermind group structure; maybe we each pick a microhabit or idea to work on for the month (or for two weeks), we help each other out, and then we report back at the next one. That way, there’s casual conversation and discovery, but there’s also purpose and motivation.

2015-01-08 Imagining Emacs hangouts - index card

2015-01-08 Imagining Emacs hangouts – index card

2015-01-16 Emacs community -- index card #emacs

2015-01-16 Emacs community – index card #emacs

Connecting with more parts of the Emacs community

Evil-mode users are a growing part of the Emacs community. Maybe I should try it out to get a better sense of what the experience is like for people who are coming into Emacs via evil-mode. Besides, composability might be an interesting mental tool to add to my toolkit.

2015-01-18 Thinking about evil-mode and Emacs -- index card #emacs

2015-01-18 Thinking about evil-mode and Emacs – index card #emacs

Wrapping up

Maybe I can get better at helping the Emacs community by:

  • Focusing on those micro-habits and sharing what I learn (good for helping intermediate users develop a better appreciation of Emacs)
  • Playing with more workflow improvements and sharing them
  • Writing about how to tinker with popular packages like Org
  • Reaching out through blog comments and Emacs Hangouts to help people learn (in a publicly recorded way)
  • Bringing out what people know through Emacs Hangouts and Emacs Chats (especially if people know cool things but haven’t gotten around to writing about them)

Helping me get better at helping the Emacs community (my selfish reason: so that I learn more from people) can also support your evil plans (your selfish reason: so that you can learn more from me and from other people). Any suggestions? Tell me what I’m doing right and should do more of / better at, or tell me about somewhat adjacent things that are easy to do – low-hanging fruit! =)

Minimizing upward or downward skew in your sketchnotes

When drawing without rules or grid lines, you might find your writing skew a little upwards or downwards. I tend to skew upwards, like the way I do in the image below:

2014-11-12 What are the things I want to learn more quickly, and what would that look like?

2014-11-12 What are the things I want to learn more quickly, and what would that look like?

Minimizing skew gives you a more polished sketchnote, and you don’t end up with awkward space at the upper right or bottom right corner. It’s usually better to correct for this while drawing, since rotating images can result in fuzziness or the need to move things around to fit.

Here are some general tips for minimizing skew.

In general, it helps if you write narrower columns of text, since skew becomes more noticeable the longer your lines get. If you write in narrow columns or with short phrases, you can correct for skew by making part of the next line a little larger.

If you want, you can also mix angles so that the variety is an intentional part of your design.

If you draw on small sheets of paper or in notebooks, you can:

  • Rotate the paper so that it’s perpendicular to your usual writing angle. With experience, you’ll get a sense of how much you normally skew and how much you need to rotate what you’re drawing on in order to compensate for that.
  • Look at the edges of the paper as a guide. If you write your first line while looking at the top edge of your paper, you might find it easier to keep that perpendicular to the edge. Then you can use that as the guide for the next line, and so on.
  • Look at everything as a whole. Every so often, take a step back and look at your drawing in progress. This will help you spot skew, imbalance, and other things you can tweak while you’re drawing.
  • Draw with a guide sheet underneath your paper. If your paper is thin enough, you might be able to see lines or grids printed on a sheet slipped underneath what you’re drawing on. If so, you can use it as an invisible guide.
  • Consider using paper with very light grids or lines on it. You can leave the grid or lines as is, or you might be able to remove the grid or lines after scanning.

If you draw on large-scale rolls of paper, you can:

  • Stand up straight and use your body as a guide. With practice, you can get the hang of drawing perpendicularly to your body. Good posture helps. Of course, when you tape up your paper, make sure that it’s parallel to the floor.
  • Look at the top or bottom edge of the paper as a guide. Looking at a straight line while writing can help you write in a straight line too.
  • Step back and look at everything. This is a good time to check for balance, skew, and other things you can fix while drawing.

If you draw on a tablet or on a computer, writing in straight lines is much easier. If your drawing program supports layers, you can use one layer to show a light grid while you draw on another layer. This also helps you keep your sizes consistent even if you’re working zoomed in. Lock your grid layer so that you don’t accidentally draw on it. I use a dot grid when sketching. You can download the template I use, if you want.

Hope that helps you minimize skew in your sketches!