- Interesting additions (that you may have already seen in development)
- Choose latex compiler keyword
- PlantUML convenience
An Emacs’ configuration is an Emacs Lisp (Elisp) program. Whether you write it by hand or using the Easy Customization GUI it is still a program. Some of us write it once and never touch it for years. I’ve done that and it works well. Some of us make changes daily, even hourly. I’ve done that too and it works well. When non Emacsers hear stories about this never ending program they shudder in horror and I don’t blame them. Configuring a text editor for multiple years does sound horrible! What is really happening here though, are all Emacsers sadists?
No, not really. Instead they are creators, makers, writers, and weavers of that which can be easily represented as plain text. They are programmers, too. Of course, that is the easy one! Unfortunately, that is the one that instantly kills any conversation (in some contexts). What people miss out on though is that its not just programmers who use Emacs. So do composers. So do publishers. So do finite element analysts. So do pen testers. So do screenwriters. So do hardware designers. Every Emacs configuration is an opportunity to learn something about something totally new to you! What comes to mind here is where Emacs configurations might play a role in interviews.
One of the stories going around is that during job interviews you should be able to cite an open source project so your interviewers can review it. Great idea. Does it ever really happen? (I’m looking for your feedback here). My Emacs’ configuration is a labor of love. It contains perfection, neglect, and horror. It is all a trade-off. Every single line means something to me and I’d love to share with anyone interested why I did what I did there. It is fun to share because you always learn something new. Every single time you learn something new when you mutually share.
This is my story why Emacs’s is an infinite program that would reveal more during a job interview than any personality profiling test out there.
Via here, in this example it handles the situation when you want to run Magit but haven’t got a project file open:
(let ((current-prefix-arg '(4))) (call-interactively #'magit-status))
My configuration results in an environment where you can only evaluate code within the document and never during export or tangling. That way it is easier to understand what happens when.
Code is only ever evaluated when you execute the document. The results of execution are stored within the document. That is my workflow.
Knitr in comparison does the opposite only evaluating code during export.
Here is the easiest way to make sense of what happens when resulting in what:
- If you want hooks to run call
- If you don’t want hooks to run call
I just found a neat trick today i.e hiding uninteresting(temporary files like backup or autosave files, all files of a particular extension or a particular set of files which match a regexp) files in
dired-x. Here’s how I did it in my
Been looking for an excuse to play with AppleScript?!
Now you have one very good one!
For creating audio-books I use a text-to-speech engine. One problem is that the application dies on Unicode text. The documents that I encode are too long to correct manually so I want it automated. The correction isn’t as simple as removing all Unicode text though because if possible I don’t want to lose the meaning of the character when it is easily converted to ASCII.
;; Transliterate ASCII a-z and A-Z to their Unicode mathematical ;; Fraktur equivalent. Eszett and umlaut aren't used because the Unicode ;; specification defines these characters only as a mathematical symbol via ;; `http://www.unicode.org/faq/ligature_digraph.html'.