Delete blog, move project
This commit is contained in:
parent
fc57f09150
commit
b4928633d8
18 changed files with 4 additions and 541 deletions
|
|
@ -5,14 +5,14 @@
|
||||||
(org-confirm-babel-evaluate . nil)
|
(org-confirm-babel-evaluate . nil)
|
||||||
(org-publish-project-alist
|
(org-publish-project-alist
|
||||||
. (("oni-files"
|
. (("oni-files"
|
||||||
:base-directory "~/var/src/orgweb/site/"
|
:base-directory "~/projects/orgweb/site/"
|
||||||
:publishing-directory "~/var/src/orgweb/_publish/"
|
:publishing-directory "~/projects/orgweb/_publish/"
|
||||||
:recursive t
|
:recursive t
|
||||||
:base-extension "css\\|png"
|
:base-extension "css\\|png"
|
||||||
:publishing-function org-publish-attachment)
|
:publishing-function org-publish-attachment)
|
||||||
("oni-org"
|
("oni-org"
|
||||||
:base-directory "~/var/src/orgweb/site/"
|
:base-directory "~/projects/orgweb/site/"
|
||||||
:publishing-directory "~/var/src/orgweb/_publish/"
|
:publishing-directory "~/projects/orgweb/_publish/"
|
||||||
:recursive t
|
:recursive t
|
||||||
:base-extension "org"
|
:base-extension "org"
|
||||||
:publishing-function org-publish-org-to-html
|
:publishing-function org-publish-org-to-html
|
||||||
|
|
|
||||||
2
blog/.gitignore
vendored
2
blog/.gitignore
vendored
|
|
@ -1,2 +0,0 @@
|
||||||
unfinished
|
|
||||||
index.org
|
|
||||||
|
|
@ -1,21 +0,0 @@
|
||||||
#+TITLE: A new org-blog
|
|
||||||
#+DESCRIPTION: Going for another org blogging module
|
|
||||||
|
|
||||||
I've taken it upon myself to update the ~org-blog.el~ that was written
|
|
||||||
a long time ago. I want something other than an extra layer over some
|
|
||||||
other system, ~org-mode~ has everything a blog needs, but it doesn't
|
|
||||||
generate an RSS feed or a special index page.
|
|
||||||
|
|
||||||
There was the ~org-blog.el~, but that uses some old functions that
|
|
||||||
don't exist anymore, so I thought I'd try to update it.
|
|
||||||
|
|
||||||
I just barely got it working, as you can see from this post. It
|
|
||||||
generates an RSS feed, but the links don't work. It generates an index
|
|
||||||
page, but no links to the individual pages (not that it needs it,
|
|
||||||
really). It doesn't listen to some of the settings (toc, sections) the
|
|
||||||
rest of the publishing projects do.
|
|
||||||
|
|
||||||
I'd also like to have all posts in a single file and use things like a
|
|
||||||
post's category and tags and such.
|
|
||||||
|
|
||||||
It'll be interesting to see what else I can fix.
|
|
||||||
|
|
@ -1,14 +0,0 @@
|
||||||
#+TITLE: Quick org-blog update
|
|
||||||
#+DESCRIPTION: just a quick update
|
|
||||||
|
|
||||||
Apparently there are some things it does seem to do, and some it
|
|
||||||
doesn't, that I didn't realize.
|
|
||||||
|
|
||||||
* Generate index html
|
|
||||||
|
|
||||||
It only generates an ~index.org~ file, which it then doesn't convert
|
|
||||||
to HTML. That should be fixable.
|
|
||||||
|
|
||||||
* Generate links
|
|
||||||
|
|
||||||
It seems to generate links correctly after all.
|
|
||||||
|
|
@ -1,44 +0,0 @@
|
||||||
#+TITLE: Silly django confusion
|
|
||||||
#+DESCRIPTION: Think about this next time...
|
|
||||||
|
|
||||||
I'm setting up a testing environment for work, using fixtures to save
|
|
||||||
and load test data and I got a little stumped by something I ran into.
|
|
||||||
|
|
||||||
I had exported one of the database tables we use to a json file that I
|
|
||||||
was going to import into a fresh new database to test with. When I
|
|
||||||
imported it everything seemed fine, except when looking at the actual
|
|
||||||
page. So this is what I found:
|
|
||||||
|
|
||||||
#+BEGIN_SRC sql
|
|
||||||
SELECT * FROM app_table;
|
|
||||||
=> 3 rows of data
|
|
||||||
#+END_SRC
|
|
||||||
|
|
||||||
#+BEGIN_SRC python
|
|
||||||
from app.models import Table
|
|
||||||
|
|
||||||
Table.objects.count()
|
|
||||||
=> 3
|
|
||||||
|
|
||||||
Table.objects.all()
|
|
||||||
=> []
|
|
||||||
#+END_SRC
|
|
||||||
|
|
||||||
This is weird. So I looked at the ~django.db.connection.queries~
|
|
||||||
property and I realized that it was doing a join since the model
|
|
||||||
subclasses another:
|
|
||||||
|
|
||||||
#+BEGIN_SRC python
|
|
||||||
from django.db import models
|
|
||||||
|
|
||||||
from app.models import SuperTable
|
|
||||||
|
|
||||||
class Table(SuperTable):
|
|
||||||
field1 = models.CharField(max_lenth=200)
|
|
||||||
#+END_SRC
|
|
||||||
|
|
||||||
Which, of course, means that in order to get the complete ~Table~
|
|
||||||
instance, the related ~SuperTable~ instance is also required, but in
|
|
||||||
order to do a ~COUNT~ of ~app_table~ it isn't necessary. And that's
|
|
||||||
where the inconsistency came from, now that I've also copied the
|
|
||||||
contents of ~SuperTable~ everything is fine again.
|
|
||||||
|
|
@ -1,41 +0,0 @@
|
||||||
#+TITLE: Ask for selection in emacs
|
|
||||||
#+DESCRIPTION: Something I came across
|
|
||||||
|
|
||||||
I came across an email on one of the emacs mailing lists today, where
|
|
||||||
someone asked how to ask a user for input whilst providing
|
|
||||||
completions. The first answer he got was to try ~tmm-prompt~, so I
|
|
||||||
looked into it a little.
|
|
||||||
|
|
||||||
I use ~mu4e~ as my primary email program, but since it isn't designed
|
|
||||||
(seemingly) for use with multiple accounts I've got some wrapper
|
|
||||||
functions that set some variables according to my liking and then
|
|
||||||
start ~mu4e~. This works very well, but it's a pain to have to use
|
|
||||||
~M-x view-ryu-mail~ or ~M-x view-ninthfloor-mail~ and such, so I wrote
|
|
||||||
a function to read a string from the minibuffer, which I then bound to
|
|
||||||
the ~<XF86Mail>~ key, this turned it into, for example ~<XF86Mail>
|
|
||||||
ryu~ and ~<XF86Mail> ninthfloor~ and so on, but this doesn't have any
|
|
||||||
completion or notification of my options.
|
|
||||||
|
|
||||||
So after looking at ~tmm-prompt~ I came up with the following:
|
|
||||||
|
|
||||||
#+BEGIN_SRC emacs-lisp
|
|
||||||
(defvar oni:mailbox-map
|
|
||||||
'(("ryulash.org" . "ryu")
|
|
||||||
("ninthfloor" . "ninthfloor"))
|
|
||||||
"A mailbox map for use with `tmm-prompt'.")
|
|
||||||
|
|
||||||
(defun view-ryu-mail ()...)
|
|
||||||
(defun view-ninthfloor-mail ()...)
|
|
||||||
|
|
||||||
(defun view-mu ()
|
|
||||||
(interactive)
|
|
||||||
(let* ((tmm-completion-prompt "Choose a mailbox\n")
|
|
||||||
(inbox (tmm-prompt oni:mailbox-map)))
|
|
||||||
(funcall (intern (concat "view-" inbox "-mail")))))
|
|
||||||
#+END_SRC
|
|
||||||
|
|
||||||
I've left out the definitions and some mail accounts for brevity.
|
|
||||||
|
|
||||||
~tmm-prompt~ is usually used when using the text-mode menu with ~M-`~,
|
|
||||||
but it works very well here too. This changes mailbox selection to,
|
|
||||||
for example ~<XF86Mail> r~ or ~<XF86Mail> n~.
|
|
||||||
|
|
@ -1,21 +0,0 @@
|
||||||
#+TITLE: Show identica icon with new dents
|
|
||||||
#+DESCRIPTION: I kinda like it
|
|
||||||
|
|
||||||
I've written this a while ago after I found out how images can be
|
|
||||||
added to the emacs modeline. I like being notified of things that go
|
|
||||||
on, and new dents is a good example of this, though ~notify-send~ and
|
|
||||||
an urgency hint don't always work for that.
|
|
||||||
|
|
||||||
This works:
|
|
||||||
|
|
||||||
#+BEGIN_SRC emacs-lisp
|
|
||||||
(add-to-list
|
|
||||||
'global-mode-string
|
|
||||||
'(:eval
|
|
||||||
(unless (zerop identica-new-dents-count)
|
|
||||||
(propertize " " 'display identica-active-indicator-image))))
|
|
||||||
#+END_SRC
|
|
||||||
|
|
||||||
This will show an icon in your modeline whenever there are new dents,
|
|
||||||
at this time there dents will not have been loaded into the buffer, so
|
|
||||||
you'll have to refresh it, after which the icon disappears.
|
|
||||||
|
|
@ -1,19 +0,0 @@
|
||||||
#+TITLE: Ask for selection in emacs, addendum
|
|
||||||
#+DESCRIPTION: Oops, I forgot this
|
|
||||||
|
|
||||||
I erroneously assumed (and thought I tested) that using ~tmm-prompt~
|
|
||||||
could be done the way I described before. The ~oni:mailbox-map~
|
|
||||||
variable needs to be a little different from what I'd shown before,
|
|
||||||
namely:
|
|
||||||
|
|
||||||
#+BEGIN_SRC emacs-lisp
|
|
||||||
(defvar oni:mailbox-map
|
|
||||||
'("top" ("menu" ("ryulash.org" . "ryu")
|
|
||||||
("ninthfloor" . "ninthfloor")
|
|
||||||
("gmail" . "gmail")
|
|
||||||
("aethon" . "aethon")))
|
|
||||||
"A mailbox map for use with `tmm-prompt'.")
|
|
||||||
#+END_SRC
|
|
||||||
|
|
||||||
Without the /top/ and /menu/ items it will complain about wrong
|
|
||||||
arguments.
|
|
||||||
|
|
@ -1,25 +0,0 @@
|
||||||
#+TITLE: Another way to get a selection
|
|
||||||
#+DESCRIPTION: Another thing I came across
|
|
||||||
|
|
||||||
When I was first looking into improving my mailbox selection function
|
|
||||||
I was looking at how to just ask the user for input with
|
|
||||||
completions. Though now that I came across ~tmm-prompt~ I really
|
|
||||||
prefer this way of working, at least in this case.
|
|
||||||
|
|
||||||
However, today another function was mentioned, in response to someone
|
|
||||||
pointing out ~org-completing-read~: ~completing-read~. Wow that's a
|
|
||||||
far leap.
|
|
||||||
|
|
||||||
Anyway:
|
|
||||||
|
|
||||||
#+BEGIN_SRC emacs-lisp
|
|
||||||
(completing-read "Your favorite color: "
|
|
||||||
'("red" "green" "blue" "yellow"))
|
|
||||||
#+END_SRC
|
|
||||||
|
|
||||||
This will ask for user input and provide these options as completions,
|
|
||||||
but it won't show a list of options, of provide shortcuts, like
|
|
||||||
~tmm-prompt~ does.
|
|
||||||
|
|
||||||
It's good to know these things, and I really should read both the
|
|
||||||
emacs manual and the emacs lisp reference manual at some point.
|
|
||||||
|
|
@ -1,25 +0,0 @@
|
||||||
#+TITLE: Testing org-blog fix
|
|
||||||
#+DESCRIPTION: Let's see if it works
|
|
||||||
|
|
||||||
I've just adjusted just a little bit of code in org-blog, and now I
|
|
||||||
want to see if it works correctly.
|
|
||||||
|
|
||||||
I was getting the following error message when I would try and export
|
|
||||||
an ~org-blog~ project:
|
|
||||||
|
|
||||||
#+BEGIN_EXAMPLE
|
|
||||||
Selecting deleted buffer
|
|
||||||
#+END_EXAMPLE
|
|
||||||
|
|
||||||
It turns out that this is because of this little piece of code:
|
|
||||||
|
|
||||||
#+BEGIN_SRC emacs-lisp
|
|
||||||
;; if buffer is already open, kill it
|
|
||||||
(if index-buffer
|
|
||||||
(kill-buffer index-buffer))
|
|
||||||
#+END_SRC
|
|
||||||
|
|
||||||
I'm guessing it wasn't originally meant as a function for
|
|
||||||
~org-publish~, well it was meant as an index function, but that
|
|
||||||
feature seems to have changed over time. Let's see what can be made of
|
|
||||||
it.
|
|
||||||
|
|
@ -1,6 +0,0 @@
|
||||||
#+TITLE: Testing out an RSS fix
|
|
||||||
#+DESCRIPTION: Oopsie
|
|
||||||
|
|
||||||
I was working on [[http://ryuslash.org][my website]] yesterday and I noticed that the RSS feed
|
|
||||||
doesn't generate links correctly. So I've changed it, and now I'm
|
|
||||||
trying it out.
|
|
||||||
|
|
@ -1,15 +0,0 @@
|
||||||
#+TITLE: Website update
|
|
||||||
|
|
||||||
As you can [[http://ryuslash.org][see]] I finally updated my website again. It's the same basic
|
|
||||||
idea as before, except this time I try to make the posts look more
|
|
||||||
lisp-y, since I'm writing a lot more ~emacs-lisp~ as of late I've
|
|
||||||
grown fond of all the parentheses.
|
|
||||||
|
|
||||||
I've also moved my [[http://org.ryuslash.org][static website]] from ninthfloor to my own domain in
|
|
||||||
the hopes it will become more a part of my website than it was before,
|
|
||||||
although the beauty of static websites generated by things like
|
|
||||||
~org-mode~, ~jekyll~ and such is of course that they can pretty much
|
|
||||||
be placed on any public web space, and they're fast.
|
|
||||||
|
|
||||||
Anyway, perhaps I'll post more, but for now I'm happy to have changed
|
|
||||||
things a little again.
|
|
||||||
|
|
@ -1,25 +0,0 @@
|
||||||
#+TITLE: Literate emacs init
|
|
||||||
|
|
||||||
A little while back I saw [[http://sachachua.com/blog/2012/05/where-i-am-in-terms-of-emacs/][Sacha Chua]] mention using ~org-mode~ for
|
|
||||||
literate programming. I'd heard of literate programming, but its use
|
|
||||||
escaped me. Still, reading that and looking at what ~noweb~ is I
|
|
||||||
started thinking that it would indeed be a great way of documenting
|
|
||||||
code, especially something my emacs init file, since that is not a
|
|
||||||
serious software project ans some weird stuff goes on in there.
|
|
||||||
|
|
||||||
I still didn't really get the hang of it. It seemed like a lot of work
|
|
||||||
to get into it and how exactly it fit together with using ~org-mode~
|
|
||||||
didn't really hit me so I pushed it aside for the moment.
|
|
||||||
|
|
||||||
Today I see her [[http://sachachua.com/blog/2012/06/literate-programming-emacs-configuration-file/][presenting]] her new literately programming init file
|
|
||||||
with some links to other resources and I just had to try it too.
|
|
||||||
|
|
||||||
I haven't gotten very far yet, but what I have so far I have put
|
|
||||||
[[http://ryuslash.org/inittest.html][here]]. It's just the generated HTML file, no org source, and I'm still
|
|
||||||
messing around with the colors and stuff, but it's fun to see the
|
|
||||||
result already.
|
|
||||||
|
|
||||||
I don't know if I'm actually going to use it, since my init file's
|
|
||||||
sloc count is 1038 and its total line count is 1280 lines I fear that
|
|
||||||
adding even more documentation (= lines) would make my init file
|
|
||||||
*very* bulky. It is still fun to see and experiment with, though.
|
|
||||||
|
|
@ -1,39 +0,0 @@
|
||||||
#+TITLE: New config project
|
|
||||||
|
|
||||||
After [[http://sachachua.com/blog/2012/06/literate-programming-emacs-configuration-file/][reading]] that it was very easy to use [[http://en.wikipedia.org/wiki/Literate_programming][Literate Programming]] for
|
|
||||||
one's emacs init file and discovering that it's also a lot of fun to
|
|
||||||
do, I was thinking that I could easily use this for all my
|
|
||||||
configuration files.
|
|
||||||
|
|
||||||
Of course, not all programs have [[http://orgmode.org/worg/org-contrib/babel/][~org-babel~]], so they can't all have
|
|
||||||
something like this in their init file:
|
|
||||||
|
|
||||||
#+begin_src emacs-lisp
|
|
||||||
(require 'org)
|
|
||||||
(require 'ob-tangle)
|
|
||||||
|
|
||||||
(org-babel-load-file "~/.emacs.d/rinit.org")
|
|
||||||
#+end_src
|
|
||||||
|
|
||||||
Which, for emacs, tangles (extracts the code) and then loads the
|
|
||||||
generated file. So something else has to be done.
|
|
||||||
|
|
||||||
On the other side of things, I, fairly recently, had a run-in with
|
|
||||||
some Makefiles, which got me thinking that ~make~ is a very interesting
|
|
||||||
tool and that it could be used to help with a lot of other tasks as
|
|
||||||
well, much like I perceive Rake does. I just wasn't able to find where
|
|
||||||
exactly it would fit (other than, of course, as compilation
|
|
||||||
instructions for my projects).
|
|
||||||
|
|
||||||
Now, yesterday I got the idea of using ~org-mode~ to literate-program
|
|
||||||
all my configuration files and then use ~make~ to tangle and install
|
|
||||||
them. This would mean that I could easily keep documentation about
|
|
||||||
decisions in configuration files and such in an easy to read format,
|
|
||||||
easily export these files to somewhere on the web and practice my ~make~
|
|
||||||
skills to make everything easy.
|
|
||||||
|
|
||||||
[[http://code.ryuslash.org/?p=newdot.git;a=tree][Here]] is the result. I'm still working on it, as you can see my emacs
|
|
||||||
init file still has a long way to go, my focus is on getting it in
|
|
||||||
~org-mode~ first and actually get it well-documented later. I've
|
|
||||||
published it [[http://org.ryuslash.org/dotfiles/][here]], what I have at least, in case you would like to
|
|
||||||
read about my mostly uninteresting configuration files.
|
|
||||||
|
|
@ -1,103 +0,0 @@
|
||||||
#+TITLE: My new keyboard
|
|
||||||
|
|
||||||
I have been using [[http://www.gnu.org/software/emacs][GNU Emacs]] for a few years now, at first only in my
|
|
||||||
spare time, and for about 1.5 years also for work. Since I've started
|
|
||||||
using it for work my [[http://org.ryuslash.org/dotfiles/emacs/init.html][init file]] has exploded in size and my knowledge
|
|
||||||
of both emacs and emacs-lisp have as well.
|
|
||||||
|
|
||||||
As a result of using it full time, I have started paying more
|
|
||||||
attention to what I'm doing and how I can do it faster or more
|
|
||||||
efficiently. Sometimes this means writing a function, and possibly
|
|
||||||
hooking it up to some key combination, but sometimes it also means
|
|
||||||
changing the way you use your PC.
|
|
||||||
|
|
||||||
The first change was trying more and more to leave the mouse behind
|
|
||||||
and use the keyboard for everything. In emacs this is easy, there are
|
|
||||||
many window managers that offer this, mostly tiling, and for browsers
|
|
||||||
this is somewhat more difficult.
|
|
||||||
|
|
||||||
After switching to an almost completely keyboard-based system, I was
|
|
||||||
starting to feel pain in my left pinkie. It was getting tired of
|
|
||||||
always having to travel to the lower left bottom of my keyboard in
|
|
||||||
order to press that darn ~CTRL~ key that I use oh so very much. So I
|
|
||||||
switched my ~CTRL~ and ~Caps Lock~ keys, as is suggested by many an emacs
|
|
||||||
user.
|
|
||||||
|
|
||||||
Following that, much later, was the desire to type more efficiently.
|
|
||||||
I've read a long time ago already that QWERTY was designed to be slow
|
|
||||||
and that it is unbelievable that we all still use it. Now, as I don't
|
|
||||||
like mangling my keyboard by using a layout that it was never designed
|
|
||||||
for and which was never designed for it, like dvorak, I chose [[http://colemak.com][colemak]].
|
|
||||||
I've now gotten the hang of it, for the most part, and I'm happy with
|
|
||||||
it, it types pretty nicely and still fits well on a QWERTY keyboard.
|
|
||||||
|
|
||||||
At this point, I'm at the stage where a friend of mine commented to
|
|
||||||
me, once, that he would just love to see a burglar/thief make heads or
|
|
||||||
tails of the setup I'm using, since my keyboard doesn't show the keys
|
|
||||||
in the right place, when you log in you're greeted by an empty screen
|
|
||||||
with no hints on how to proceed, the ~CTRL~ key is not the ~CTRL~ key and
|
|
||||||
the mouse does absolutely *nothing*.
|
|
||||||
|
|
||||||
*But*, after a while of using colemak and paying attention to my typing
|
|
||||||
and paying attention to tips about how to type, like use the modifier
|
|
||||||
on the opposite side of the keyboard in relation to the character you
|
|
||||||
have to use with it, I got frustrated by my keyboard. Using the
|
|
||||||
modifier opposite of the key you're using with it doesn't work well if
|
|
||||||
they're hidden away from your hands, all the way down in the lower
|
|
||||||
right and left corners. So I started keeping an eye out for keyboards
|
|
||||||
that would better fit my needs.
|
|
||||||
|
|
||||||
After weeks, months, of seeing absolutely nothing that interested me I
|
|
||||||
finally came across [[http://xahlee.org/index.html][Xah Lee]]'s [[http://ergoemacs.org/emacs/ergonomic_keyboards.html][Ergonomic Keyboards Gallery]], I see my
|
|
||||||
vision has come to life. [[http://www.trulyergonomic.com/][The Truly Ergonomic Keyboard]] seems like
|
|
||||||
exactly what I'm looking for, *finally* a keyboard that has /big/ modifier
|
|
||||||
keys on /both/ sides.
|
|
||||||
|
|
||||||
From the moment I saw it I knew I wanted it, but impulse buys are
|
|
||||||
never a good idea, so I slept on it, talked to some people I respect
|
|
||||||
and I thought about it, it is €230 after-all. Then after a few days
|
|
||||||
there I am, ordering it, having just weeks before proclaimed that I
|
|
||||||
couldn't fathom ever paying more than some €20 for one.
|
|
||||||
|
|
||||||
Unfortunately it was still in production, or at least this batch was,
|
|
||||||
and I had to wait. I went to pick it up a few days ago, an extra
|
|
||||||
charge of €64.12 was added by customs. The people that brought me
|
|
||||||
there were intrigued and surprised by my purchase and didn't really
|
|
||||||
understand it, but they thought it looked cool nonetheless.
|
|
||||||
|
|
||||||
Now I have it and have been using it for a few days. *Man* is it
|
|
||||||
different. It's like learning colemak all over again, although
|
|
||||||
luckily this seems to be going faster.
|
|
||||||
|
|
||||||
The few moments I have where I don't screw up every single word and
|
|
||||||
have to type everything at least thrice I feel comfortable using it.
|
|
||||||
Having both the Control and Shift keys near the sides of my hands, big
|
|
||||||
and high up is convenient. Being able to press ~RET~ with either my
|
|
||||||
thumbs or my index fingers is much more comfortable than my right
|
|
||||||
pinkie. It also makes a nice sound when I'm typing and the keys are
|
|
||||||
not all that resistant, so I don't have to press hard, on either the
|
|
||||||
modifiers or the keys, which would be a pretty big downer.
|
|
||||||
|
|
||||||
Of course it's not all perfect. I still have to press ~M-x~ with just
|
|
||||||
my left hand, since the right ~ALT~ key is an ~AltGR~ key, which is
|
|
||||||
completely different and doesn't seem to be recognized as a modifier
|
|
||||||
by any program, instead being a direct switch on the keyboard itself.
|
|
||||||
But in this case I could look into reprogramming the keyboard's
|
|
||||||
firmware, which it supports and allows, to switch the two alt keys, or
|
|
||||||
I could use xmodmap. Having my ~Super~ key in the top-center portion of
|
|
||||||
my keyboard is an adjustment, I usually use it as /the/ modifier key for
|
|
||||||
everything window-manager related. And, of course, having often-used
|
|
||||||
keys such as (back)slashes and brackets/accolades in far-away places
|
|
||||||
is different. But I'm sure I will overcome these difficulties once I
|
|
||||||
get a little more used to it.
|
|
||||||
|
|
||||||
Well, writing this post should help, I feel my proficiency has grown
|
|
||||||
about 10%.
|
|
||||||
|
|
||||||
Anyway, if you're writing a lot on the computer, or you use a lot of
|
|
||||||
modifier keys with programs like emacs, I won't yet recommend buying
|
|
||||||
it, but I will recommend taking a serious look at it, it might be /just/
|
|
||||||
what you are looking for, even if you don't yet know you're looking
|
|
||||||
for it. In the end it cost me €293,12 and I haven't regretted it yet.
|
|
||||||
In fact, I already felt completely lost when using my netbook, to
|
|
||||||
which I did not connect my new keyboard.
|
|
||||||
|
|
@ -1,23 +0,0 @@
|
||||||
#+TITLE: gitto
|
|
||||||
|
|
||||||
I've been meaning to do two things for quite some time:
|
|
||||||
|
|
||||||
1. Write a utility for tracking the status of my various git
|
|
||||||
repositories.
|
|
||||||
2. Write a program in Guile scheme.
|
|
||||||
|
|
||||||
A few days ago I accomplished both and I named it ~gitto~.
|
|
||||||
|
|
||||||
It is a simple utility that allows you to register some repositories
|
|
||||||
on your computer and it will list how many changes there are to push
|
|
||||||
and pull, if the working directory is "dirty" and how old the last
|
|
||||||
known commit on the upstream branch it, which it shows as last
|
|
||||||
updated.
|
|
||||||
|
|
||||||
More details can be found [[http://org.ryuslash.org/projects/gitto.html][here]], including a link to the source. It
|
|
||||||
requires at least guile 2.0.x and some version of git.
|
|
||||||
|
|
||||||
I still have to at least add docstrings and perhaps even a texinfo
|
|
||||||
document, and I haven't released any version yet, but feel free to try
|
|
||||||
it and be sure to let me know any suggestions/complaints/rants/bugs
|
|
||||||
you might have or find.
|
|
||||||
|
|
@ -1,38 +0,0 @@
|
||||||
#+TITLE: eval-and-compile
|
|
||||||
|
|
||||||
I'm reading up a little on byte-compilation in [[emacs][GNU Emacs]] and I read
|
|
||||||
about just exactly a feature that I needed.
|
|
||||||
|
|
||||||
A while ago, I was working on my
|
|
||||||
init[fn:init:[[http://ryuslash.org/dotfiles/emacs/init.html]]] file,
|
|
||||||
adding some ~auto-complete~ code since I wanted to try it again. I
|
|
||||||
noticed that, because ~auto-complete~ is installed through ~package~, it
|
|
||||||
couldn't load the appropriate files at compile time.
|
|
||||||
|
|
||||||
I know that =package-initialize= should be called before calling or
|
|
||||||
using any ~package~-installed functions and I have it in my
|
|
||||||
init[fn:init] file, but this doesn't help at compile time. So, ugly
|
|
||||||
as I thought it was, I added
|
|
||||||
|
|
||||||
#+begin_src emacs-lisp
|
|
||||||
(eval-when-compile (package-initialize))
|
|
||||||
#+end_src
|
|
||||||
|
|
||||||
just above the call to the ~auto-complete~ functions. I hated having to
|
|
||||||
do that, I know it's just one line, but its not at all DRY[fn::Don't
|
|
||||||
Repeat Yourself].
|
|
||||||
|
|
||||||
Just now, though, I read about =eval-and-compile=, and according to the
|
|
||||||
documentation in the elisp reference manual, it should do exactly what
|
|
||||||
I want, eval both when running and when compiling.
|
|
||||||
|
|
||||||
#+begin_src emacs-lisp
|
|
||||||
(eval-and-compile (package-initialize))
|
|
||||||
#+end_src
|
|
||||||
|
|
||||||
I'm currently trying it out, I just tested it once and it seems to
|
|
||||||
work like a charm.
|
|
||||||
|
|
||||||
/Of course/, this might never have been an issue if I didn't use ~emacs
|
|
||||||
-Q~ to compile my init[fn:init] file, just to speed up loading during
|
|
||||||
compilation a little bit.
|
|
||||||
|
|
@ -1,76 +0,0 @@
|
||||||
#+TITLE: Cool new scratch buffers
|
|
||||||
|
|
||||||
I had a thought today: It would be nice if I could have more than one
|
|
||||||
scratch buffer, and even nicer if they could easily have different
|
|
||||||
major modes.
|
|
||||||
|
|
||||||
So, I had this function in my emacs init file, =raise-scratch=:
|
|
||||||
|
|
||||||
#+begin_src emacs-lisp
|
|
||||||
(defun raise-scratch ()
|
|
||||||
"Show the *scratch* buffer."
|
|
||||||
(interactive)
|
|
||||||
(switch-to-buffer "*scratch*"))
|
|
||||||
#+end_src
|
|
||||||
|
|
||||||
Its nice, it allowed me to do exactly what I wanted to do, easily open
|
|
||||||
my scratch buffer. I bound this to ~XF86HomePage~, which makes sense to
|
|
||||||
me, since emacs always starts in the ~*scratch*~ buffer.
|
|
||||||
|
|
||||||
Today, though, it didn't seem to be quite enough. As I said, it would
|
|
||||||
be nice to have the ability to have multiple scratch buffers with
|
|
||||||
different major modes. This is handy for messing around with some
|
|
||||||
~sawfish-mode~ code, or ~python-mode~, for example.
|
|
||||||
|
|
||||||
#+begin_src emacs-lisp
|
|
||||||
(defun raise-scratch (&optional mode)
|
|
||||||
"Show the *scratch* buffer. If called with a universal
|
|
||||||
argument, ask the user which mode to use. If MODE is not nil,
|
|
||||||
open a new buffer with the name *MODE-scratch* and load MODE as
|
|
||||||
its major mode."
|
|
||||||
(interactive (list (if current-prefix-arg
|
|
||||||
(read-string "Mode: ")
|
|
||||||
nil)))
|
|
||||||
(let* ((bname (if mode
|
|
||||||
(concat "*" mode "-scratch*")
|
|
||||||
"*scratch*"))
|
|
||||||
(buffer (get-buffer bname))
|
|
||||||
(mode-sym (intern (concat mode "-mode"))))
|
|
||||||
|
|
||||||
(unless buffer
|
|
||||||
(setq buffer (generate-new-buffer bname))
|
|
||||||
(with-current-buffer buffer
|
|
||||||
(when (fboundp mode-sym)
|
|
||||||
(funcall mode-sym)
|
|
||||||
(goto-char (point-max))
|
|
||||||
(newline))))
|
|
||||||
|
|
||||||
(switch-to-buffer buffer)))
|
|
||||||
#+end_src
|
|
||||||
|
|
||||||
This is quite a bit bigger. It now takes an optional =mode= argument,
|
|
||||||
when it is called interactively it will check if the universal prefix
|
|
||||||
argument (~C-u~) was used and if so, asks for the value of =mode=.
|
|
||||||
|
|
||||||
If mode has been specified it will create a new buffer with the name
|
|
||||||
~*MODE-scratch*~. It will then insert a file local property line
|
|
||||||
specifying the major mode to use and then switches to it.
|
|
||||||
|
|
||||||
It's the first time I'm using a list with the ~interactive~ command, it
|
|
||||||
always seemed very alien to me, but it seems quite clear how it works
|
|
||||||
now.
|
|
||||||
|
|
||||||
It was a challenge to figure out how I wanted to do this. My first
|
|
||||||
idea was to ask for a file extension and match that to
|
|
||||||
~auto-mode-alist~, but that has regexps for keys, so not easily matched.
|
|
||||||
Then there is the problem of figuring out how to load the right major
|
|
||||||
mode in another way, since adding such a file local property line
|
|
||||||
happens /after/ the buffer has been loaded, and thus has no effect on
|
|
||||||
which major mode is chosen.
|
|
||||||
|
|
||||||
Of course, this approach doesn't ensure the right major mode gets
|
|
||||||
chosen, but that's really up to whomever uses it.
|
|
||||||
|
|
||||||
It makes me very happy to use such an extensible editor.
|
|
||||||
|
|
||||||
*Update:* fixed my flawed code.
|
|
||||||
Loading…
Add table
Reference in a new issue