Posts tagged with "Orgmode"

The latest development version of GNU Emacs contains features coming in the next major release so I build Emacs from source. This development release is generally stable and very reliable.

The source code for GNU Emacs is available on Savannah and there is also a GitHub mirror available. I tend to use the GitHub mirror as it seems more reliable and faster.

Clone the latest, bleeding edge Emacs code.

$ git clone https://github.com/emacs-mirror/emacs.git    # GitHub mirror

Configure and build Emacs

$ cd emacs
$ ./autogen.sh
$ ./configure --with-mailutils   # silence warning
$ make -j 4                      # 4 parallel threads
$ sudo make install

Occasionally, after upgrading to the latest version, Emacs produces a warning caused by a version mismatch for the Orgmode package. This helpful error message gives four possible causes.

Warning (emacs): Org version mismatch.
This warning usually appears when a built-in Org version is loaded
prior to the more recent Org version.

Version mismatch is commonly encountered in the following situations:

1. Emacs is loaded using literate Org config and more recent Org
   version is loaded inside the file loaded by ‘org-babel-load-file’.
   ‘org-babel-load-file’ triggers the built-in Org version clashing
   the newer Org version attempt to be loaded later.

   It is recommended to move the Org loading code before the
   ‘org-babel-load-file’ call.

2. New Org version is loaded manually by setting ‘load-path’, but some
   other package depending on Org is loaded before the ‘load-path’ is
   configured.
   This "other package" is triggering built-in Org version, again
   causing the version mismatch.

   It is recommended to set ‘load-path’ as early in the config as
   possible.

3. New Org version is loaded using straight.el package manager and
   other package depending on Org is loaded before straight triggers
   loading of the newer Org version.

   It is recommended to put

    (straight-use-package 'org)

   early in the config.  Ideally, right after the straight.el
   bootstrap.  Moving ‘use-package’ :straight declaration may not be
   sufficient if the corresponding ‘use-package’ statement is
   deferring the loading.

4. A new Org version is synchronized with Emacs git repository and
   stale .elc files are still left from the previous build.

   It is recommended to remove .elc files from lisp/org directory and
   re-compile.

In my case, none of these fixes resolved my issue but I discovered that there is a package cache stored in the ~/.emacs.d/elncache directory.

This 'elncache' directory stores natively compiled .eln files for Emacs packages with sub-directories for each Emacs version.

$ ls ~/.emacs.d/eln-cache/
30.2-6a8b22b2
31.0.50-be59b212
$ ls -1 ~/.emacs.d/eln-cache/31.0.50-be59b212/
autorevert-841d6890-e5e85ba9.eln
benchmark-0e5ff0c6-b45151e2.eln
blogmore-bd298bd5-140db3f8.eln
bookmark-8667481e-0391040a.eln
browse-url-87f72988-d18440ad.eln
<snip>
org-capture-31aeb3cb-5a0ab108.eln
org-compat-8f643782-38135399.eln
org-d208de9c-51cfc11b.eln
org-faces-fdfdb79f-6e1f5bdc.eln
org-footnote-a50a8027-86895802.eln
org-id-b4e96473-012fc1e0.eln
org-indent-91cb060a-1219f44c.eln
org-keys-d9945960-5b58cda5.eln
org-roam-56f7ff31-fcc8f708.eln
<snip>

You can either remove all files or remove individual packages.

$ rm -fr $HOME/.emacs.d/eln-cache

The eln cache is rebuilt on the next Emacs startup and this fix silences the irritating message on startup.

Your Main Content¶

This is where the magic happens. Write your awesome content here!

Here is the wonderful second paragraph.

Standard text markup¶

bold

italic

underline

Verbatim

code

StrikeThrough

Lists¶

Unordered list

• Apples
• Oranges
• Pears

Ordered list

1. First
2. Second
3. Third

Blocks¶

Sample quote

Everything should be made as simple as possible, but not any simpler --Albert Einstein

Example code block

#include <stdio.h>

int main(int argc, char *argv[])
{
 printf("Hello world"):;
}

Tables¶

Sample table

Hyperlinks¶

External

BBC

Images¶

Example image

Non League football

Misc rarely used niche markup¶

Subscripts and Superscripts example. Superscripts need some additional orgmode configuration but I don't care.

orgmode sub and superscripts

The radius of the sun is R_sun = 6.96 x 10^8 m. On the other hand, the radius of Alpha Centauri is R_{Alpha Centauri} = 1.28 x R_sun.

Footnotes

The Org website¹ now looks a lot better than it used to.

Sometimes, I spend a lot of time on technical tasks that are of seemingly questionable benefit or limited practical use.

For example, I remember converting the format of my 977 blog posts between markup languages and migrating the content to esoteric blogging platforms (more then once). I also wasted an unbelievable amount of time meticulously editing the meta data (YAML front-matter) and writing scripts simply to preserve Disqus comments after a change to the permalink structure.

All for a personal blog that no-one read but me.

Obviously, I choose to spend time on these tasks because I'm technically minded and like a challenge. There's also a stubborn desire to see something through to the bitter end rather than give up half way through. Also, they're fun little tasks that aren't work related.

However, I don't necessarily see this was wasted time. I often say to my son (who is starting out on a career in IT) that 'knowledge is never wasted'. This has been borne out for him as, when he was interviewing last summer, he was often set technical challenges (coding exercises) as part of the screening process.

Having subsequently secured a permanent role, he remarked last week: 'I solved a tricky problem at work today using Python code from that horse racing simulation'.

Anyway, I have made progress on organising my work. I was aware of the Projectile package for Emacs which is very popular. Originally, I didn't think it would be that useful for me as I don't produce code and work in Git all day.

However, after just two days, Projectile has already proved to be immensely useful for me and the way I work. You can easily create a project which can simply be a collection of notes, source code, PDF's, videos etc. Projectile then allows you to switch between projects and all file and buffer operations (open, latest, search, kill) are narrowed to the context of that project.

That sounds like a trivial, simple change but this has proved unbelievably useful for me as the list of files is automatically shrunk to what you are actually interested in. I was staggered how this simple change had such an impact.

My main problem was (and remains) muscle memory and trying to learn the new, modified key bindings for the Projectile variants of the basic Emacs and dired style commands I have used for years.

Each project I am currently working on is now a Projectile project and so is my orgmode directory which is also very useful.

I then did something I should have done years ago and moved all my orgmode notes from their respective project directories to my dedicated directory in '~/orgmode'. This is much more logical and allows me to use the 'deft' package to search content in all my orgmode files as well as the searching functionality provided by Projectile.

Then it was obvious that I needed to merge and consolidate this large, random and unwieldy collection of orgmode files. For now, I have decided to use the following:-

• projects.org (currently, active work projects)
• project_archive.org (completed projects, mainly read only)
• project_tasks.org

Again, this was hardly any work but offered a significant improvement and somehow just felt right - that I was using Emacs and orgmode more logically, closer to the way it was intended. Like everyone else.

I realised that previously, I was bending the tools to fit my mindset of 'Projects must have a dedicated directory and all information and data on a project must reside in that directory'.

Another useful orgmode package, org-projectile, forced me to rethink this and addressed another of my key requirements perfectly.

I often want to be able to record tasks against a project. Often, I would be working on project A and get an email or phone call requiring me to quickly record a ToDo item for project B.

Previously, I would labouriously navigate to the directory for project B, open up the 'notes.org' file and append the ToDo item at the end. This had several issues; ToDo's scattered in multiple files, scattered in multiple places. Lots of context switching, lots of wasted time. It was impossible to have a coherent, unified list of outstanding tasks. Even worse, the important tasks were duplicated or promoted to Thunderbird.

[ Reading this back, I'm almost embarrassed and ashamed to document how ineffectively I used to work but at least I now understand why promotion keeps passing me by. ]

The org-projectile package is blissfully simple and allows you to create a orgmode task for a given project. You simply create a task and org-projectile prompts you for the project (from Projectile's list of projects) and the orgmode ToDo is added to a file in my 'orgmode' directory which now contains all the tasks for all the projects.

orgmode already has support for creating agendas and unified ToDo's from multiple orgmode files so there isn't necessarily a need to separate personal reminders from work related tasks.

Two Emacs packages, just an hour to install and configure, longer to learn and master perhaps but already very satisfying and relatively, simple, quick changes which have improved my productivity significantly.

Frustratingly, I can't locate it now but I recently saw a post on Mastodon from someone who had great difficulty creating a new file in his Documents folder.

This struck me as very amusing but I think the point he was trying to express was that his 'Documents' directory is a disorganised, unstructured, cluttered mess of files so he is incredibly reluctant and can barely bring himself to compound the issue further by typing vi linux-notes.txt while in the 'Documents' directory.

I have a similar issue. I use Emacs and orgmode - primarily for note taking. Well it's sort of a bastard combination of notes and a journal - but not a proper orgmode journal. Maybe it should be. Come to think of it, every notes file contains a 'ToDo' section but not a proper orgmode list of ToDo items. Maybe it should. Sue me.

To clarify a little, when I'm working on a technical project, I am almost always required to produce some project documentation later on. Typically, this might be an installation guide or a handover document for a client. Obviously, this needs to be a polished, structured, coherent document that is technically accurate.

Clearly, it is very difficult to create such a document after the fact when the memory is hazy and the precise, important details are almost forgotten. As an input to that formal document, and for my own benefit, I tend to keep notes as I go along. If I encounter a problem, I write it down together with the error codes and the various avenues I explored and the final resolution. Often, my notes include links to articles or technical blogs describing the same or similar issues. Occasionally, you won't be surprised to know the notes may even contain an outburst or a mini-rant.

Bug first noted and ack'ed in September 2017. Still fecking present in May 2020. God help us.

Currently, I create a new directory for each project I work on. For the ACME project, I will work in the '$HOME/work/acme' directory. Often there will be additional sub-directories 'apex', 'scripts', 'documents' etc.

My notes file for each project used to be named 'notes.org' but this was sub-optimal as I would then have multiple 'notes.org' files in the Emacs buffer list and 'Recent Files' list so it was hard to distinguish them.

To address this, I then prefixed the filenames thus; 'customer-notes.org'. This worked a little better as typing 'acme' offered the correct completion almost immediately.

However, this isn't ideal either as sometimes I am hunting for the details of an APEX issue that I encountered last year for that customer but was it 'ACME' or was it 'Vodafone' or was it 'ABC Corp' ?

I suspect the orgmode experts would say the solution to this is a single, larger orgmode file ('work.org') containing all the projects I have worked on which is searchable and only the currently active customer is expanded and all the others are hidden.

Funnily enough, years ago, I did experiment with the 'single large text file' idea and I have also used TiddlyWiki when I needed to share notes between a laptop and a desktop machine and later DokuWiki when, for some reason,I thought my notes, jottings and ill-considered rants should be available on the Internet.

Using a single orgmode file for work is attractive but that file would obviously have to reside in the ~/orgmode directory whereas when I am taking notes and want to open source code, M-x find-file works neatly as I am already in the context of the project directory. If I move my notes to the orgmode directory, I sense more context switching, more typing and more work.

Maybe I could investigate the Emacs projectile package to see if that would help resolve this minor issue. That would represent an ideal opportunity for more procrastination.