Irreal

In a nice followup to yesterday’s post on Casual BibTeX, Charles Choi has another post on easily capturing a Web link to your BibTeX file. The idea is that you’re looking at some paper or other information in your Web browser and want to capture the reference to your BibTeX file.

The method works by abusing the Org protocol mechanism to deliver capture template information to a BibTeX file rather than an Org file. It’s really simple to set up. You merely add the capture template that Choi provides to your list of capture templates and you’re good to go.

It’s not completely automatic. You still have to specify the Author and Organization when prompted in the minibuffer but it’s much easier than entering all the information by hand and you have the advantage the the BibTeX schema will be respected.

If, like a lot of people, you locate your references on the Web, Choi’s trick will save you some time and effort. To be sure, it’s not as powerful as John Kitchin’s Org-Ref but as a simple method of capturing a BibTeX entry from the current Web site, it’s perfect. If you need more, take a look at the Org-Ref video linked above to get an idea of how far you can push the Web site to BibTeX idea.

Charles Choi is at it again. He has a new addition to his Casual suite. This time it’s for handling BibTeX files. As you probably know, BibTeX files are essentially plain text databases of bibliographic data. They’re deeply integrated with LaTeX but are also supported by Emacs and Org mode.

The problem is that, being a database, the BibTeX file has a schema that must be adhered to in order to ensure proper operation with LaTeX and Org mode. Emacs, of course, has a mode to handle all that but Choi finds it less than adequate. The commands are hard to discover and remember and Choi believes they are insufficiently opinionated in enforcing the BibTeX schema.

His newest Casual app, Casual BibTeX, aims to fix this in the same way that the other Casual apps have addressed their domains. The app provides a Transient menu that makes remembering the Emacs commands easy and also enforces the BibTeX schema with a forms based interface.

If you find yourself routinely adding and editing BibTeX entries you should take a look at Choi’s latest Casual app. Even more to the point, if you only occasionally deal with BibTeX files, you have even more reason to embrace Casual BibTeX because you probably won’t remember the BibTeX mode commands or the format of the BibTeX schema.

Randy Ridenour has risen to the challenge from the latest Emacs Carnival on obscure Emacs packages. His candidate is the Yankpad package. I vaguely remember hearing about Yankpad (edit: I mentioned it here) but didn’t remember anything about it so I’m glad Ridenour mentioned it.

The TL;DR is that Yankpad is a sort of reimagined YASnippet by Erik Sjöstrand. It’s like YASnippet but different. One difference that I really like is that all the snippets are kept in a single Org file. That makes it easy to add, delete, and edit snippets.

Another difference is that instead of being organized by major mode as YASnippet is, Yankpad is organized by “categories”, which are groupings that you define. Those categories can be things like projects, classes, email, or whatever makes sense to you. You can also have global categories for snippets that you want available everywhere.

Another nice thing about Yankpad is that if you have YASnippet installed, Yankpad will pass its expanded text through it. That means things like YASnippet’s tab stops and escape into Elisp will work with Yankpad too. It seems like the best of two worlds.

There are several ways of specifying expansions and ways to trigger them. It seems like the typical “scratch an itch” project. Every time Sjöstrand needed a new feature or another way of adding snippets, he simply added it. The result is a nice package that can meet most or all of your snippet needs. Take a look at Ridenour’s post or the Yankpad GitHub repository for the details.

It’s a matter of faith here at Irreal, and in many other places, that any function that can be brought into Emacs should be brought into Emacs. Oddly, to us true believers, there are those who disagree.

One such person is Michał M. Sapka who argues that editors are for editing text not flying spaceships. Sapka is not the usual know-nothing who’s never gotten within six feet of Emacs. He has, in fact, been using Emacs for a number of years. Recently, he’s returned to Vim specifically because he thinks that editors should edit text and not do things like read email or handle version control. He says that if he wants X/—where /X is not an editing function—he’ll use a dedicated X application. He wants small, dedicated, programs that do one thing well. That is, of course, the Unix Philosophy that almost everyone claims allegiance to.

Despite claiming otherwise, it seems to me that Sapka doesn’t really understand Emacs’ point of view. As I’ve said many times, I think that point of view is best expressed as saying that Emacs is today’s version of a Lisp Machine. Viewed that way, Emacs is not an editor. It does have an editor function but as with the original Lisp Machines, that’s just one of many functions. As much as I hate trotting out the tired old meme, Emacs really is more like an operating system that thinks of the underlying operating system as a device driver.

Emacs has modes and packages that act like Sapka’s dedicated apps and as Àlvaro Ramírez has shown you can even glue them together so that the output of one is the input of another. In short, you don’t have to give up the Unix Philosophy to use Emacs. You can have it while at the same time enjoying the many advantages of using Emacs.

One of the strengths of Emacs is that for most operations there are options. Line wrapping is a case in point. There are several line wrapping methods and which one you use depends on context.

When coding, you may not want any line wrapping. For text, it’s my experience that wrapping at fill-column is usually a good solution unless you need to export the text. In that case, assuming a fixed line length probably won’t work that well: a good line length on a computer screen is going to be a mess on a cell phone. I’ve long since solved that problem by using visual-line-mode for my exported text. It looks good on my screen as I’m writing it and will automatically adjust to whatever screen that it’s displayed on—at least for the devices that commonly export to. A lot of people use it for all their text modes.

Still, there’s a reason we have all those wrapping methods and depending on what you’re doing, you may want to use one or the other. It would be nice to have a way of cycling through the various methods. Sacha Chua to the rescue. She has a nice bit of code that cycles through

• Having everything on one line
• Breaking the line at the fill-column
• Having at most one sentence per line but respecting fill-column
• Having one sentence per line irrespective of fill-column.

That makes it easy to pick the option that’s best for any particular situation or even to experiment with the options. All the code is in the post and is easy to follow. If you find yourself needing to switch between various line wrapping methods, take a look at her post for some ideas.

If you’ve been around Irreal for even a little while, you know I hate using the mouse. I don’t like to use it anywhere but I particularly hate using it in Emacs. So I don’t—mostly. I use WebKit to display my HTML emails and it’s convenient to use the track pad (or the arrow keys) to scroll the email but mostly I never use the mouse while I’m in Emacs. Unfortunately, it’s really east to get inadvertent mouse actions with a track pad because your hands naturally lie on it when you’re typing.

If you, too, hate having to deal with the mouse, James Cherti—whom I’ve written about before [1, 2, 3]—has a solution. His inhibit-mouse package effectively turns off the mouse when you’re in Emacs and the mode is enabled. It seems like a nice package and may be just what you need.

As much as I hate the mouse—including the inadvertent clicks that take me to a different window in the middle of my work—I’m not sure I’d want to turn it off. The times when I do want to use it, it’s is to save work and having to stop and re-enable the mouse largely negates that.

Still, you may differ and, if so, this package could be just what you need to bring your runaway mouse under control. Cherti has a good write up about it in his README at the above link so take a look if you think you might be interested.

As I’ve said before, I’m not a fan of the Emacs Tab bar. Plenty of serious people disagree so it boils down to a matter of taste rather than virtue. Grant Rosson is a case in point.

Rosson is a Philosophy professor and a serious Emacs user—and so one more data point in the argument that Emacs is not just for technical users—who likes to organize his lecture notes as a bespoke set of tabs for each lecture.

The problem is that there’s no way of saving that tab bar configuration. Since he sometimes gives the same lecture more than once a week, he needed a way of saving and restoring his configurations. But, of course, this is Emacs so if you need some functionality, you can almost always add it. Note, again, that Rosson is a Philosophy professor not a developer but like many Emacs users he has nevertheless learned enough Elisp to customize Emacs to his liking.

The result was tab-sets.el, a utility that saves and restores tab sets. It was just what he needed. When he had to give a lecture again, he simply restored the tab set and had all the necessary files right there at his disposal. If you like tab bars and sometimes want to recreate them, take a look at Rosson’s post and code.

I love this type of story. Someone far removed from the engineering milieu is not only a dedicated Emacs user but has mastered it enough to make his own non-trivial customizations. The down side is that it makes me even less tolerant of people who are in engineering and whine that Emacs is too hard and that they don’t have time to learn it. Rosson stands as a damning repudiation of that.

Kiran Gopinathan has a very interesting video on how she uses Emacs, Org-Roam, and Zotero to do her literature reviews. If you aren’t familiar with the concept, Literature Reviews are the process of reading papers related to your current research topic. Typically there are a lot of papers and you have to take notes as you go along so that you can draw it all together for your own research and papers.

Her video serves as a real life example of a Zettelkasten in action. A she reads a paper, she takes notes and, critically, links them to the other papers she’s read on the current topic. Her workflow involves storing the papers in Zotero and automatically updating her BibTeX file as new papers are introduced.

You can see Gopinathan’s method in action in her video. Things move along fairly rapidly and can difficult to follow so you have to beardown when watching it but it’s worth the effort. Even if you’re not an academic, it’s easy to see how the process could be useful for organizing your own data.

Although she doesn’t mention it in the video, her Org-Roam configuration is available online in this Gist. Take a look at it if you’re interested in her method. The video is 16 minutes, 6 seconds long so it should be fairly easy to fit into your day. On the other hand, you may want to watch it more than once to wring out all the information it contains.