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-publish-project-alist
|
||||
. (("oni-files"
|
||||
:base-directory "~/var/src/orgweb/site/"
|
||||
:publishing-directory "~/var/src/orgweb/_publish/"
|
||||
:base-directory "~/projects/orgweb/site/"
|
||||
:publishing-directory "~/projects/orgweb/_publish/"
|
||||
:recursive t
|
||||
:base-extension "css\\|png"
|
||||
:publishing-function org-publish-attachment)
|
||||
("oni-org"
|
||||
:base-directory "~/var/src/orgweb/site/"
|
||||
:publishing-directory "~/var/src/orgweb/_publish/"
|
||||
:base-directory "~/projects/orgweb/site/"
|
||||
:publishing-directory "~/projects/orgweb/_publish/"
|
||||
:recursive t
|
||||
:base-extension "org"
|
||||
: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