Org-agenda module for turning task management into a game.
— via here
Haven’t read the overview yet but skimming it, it appears to be rich and thoughtful. Perfect timing for those of us curious about gamification.
Org-agenda module for turning task management into a game.
— via here
Haven’t read the overview yet but skimming it, it appears to be rich and thoughtful. Perfect timing for those of us curious about gamification.
SMIE demonstrates use of operator-precedence grammars
I am just parroting what the author kindly explains as I don’t know about the topic and it is nice to learn about it in “real code”.
Lately I’ve been curious whether or not my actual Emacs keymapping usage actually reflects how I think I use it. What I mean is that I have a goal of mapping frequently used operations to easily-accessible keybindings on the keyboard. What I plan to do is to record my usage so that I can study it to find mapping decisions that I got right, and wrong, and also identify things that I use that I should be mapping closer to home.
The simplest approach would be to use a keylogger, or advice inside of Emacs.
What I am curious about is your approach if you had done, or would do, something like this, and your thoughts an ideas.
In my case I lay out my mappings for how far away from home they are, and that has worked well so far, but I would like some numbers to back up that claim though it is not too serious depending upon how you look at it.
Cross posted from help-gnu-emacs
org-mode’s literate programming (Babel) functionality is amazing. The limitation in my case is me, not the tool. The power and abstraction just aren’t something that you think about it for a document. While I suppose that is the whole point of LP, it does just take time for it to sink in, and experience. That said, this example is nice.
Clearly generating a headline is something you may do once, and probably not very often, so would perhaps be more likely just use a macro definition. When I see how simple this is though, the idea of using macros really goes out the window because this is far easier and simpler and much more powerful. Here is a simple example:
This:
* Code
#+name: hname
#+header: :exports none
#+begin_src emacs-lisp
"Hello, world."
#+end_src
* call_hname()[:results raw]
Produces this:
1 Code
══════
2 Hello, world.
═══════════════
In case you were wondering, here is an answer:
Some features could be merged, but there is an important difference in that org-ref uses bibtex as the backend database, and reftex for searching, and org-bibtex uses org-mode headings as the backend database, and tag/property searches (I think). It is like the difference between org-contacts and bbdb. They both serve similar needs, but with different data sources, and different ways to think about it.
Both approaches are quite nice. Sometimes it seems easier to be able to share the original, not exported, database with folks even though technically it makes no difference what is the system or origin for that data!
Thanks to Jon’s org-ref package post, now there is a video demonstrating org’s built in BiBTeX management solution.
My goodness, that 8 minute video sums up what was not obvious to many even after wantingly browsing the documentation on it. Very cool Eric!