2015-12-07
What I like web templating languages for
In reaction to my entry on the problems with creating new (web) template languages, some of the people on Hacker News felt that the time of web templating languages was over due to various improvements in full programming languages. As it happens, I disagree. While there are situations where I would rather create HTML in code instead of through a template system, there are also plenty of situations where I would much rather use a template system.
In my opinion, templates work well in two interrelated situations. The first is when there is (much) more HTML than there is templating syntax to generate your dynamic content. One case this happens is if you're wrapping a form or some displayed (variable) information in a bunch of explanatory text. If you did this in the application's code, what you'd wind up with is mostly some large strings with periodic interruptions for the actual code; in my opinion, this is neither attractive nor very easy to follow (especially if the actual text of the page is broken up into multiple sections).
(I'd expect this to be even worse in a language that forced you to assemble the HTML through structured elements; you'd have a lot of code that existed just to make a whole stream of elements with the static content and string them together, interspersed with a few bits that generated the dynamic stuff.)
The second situation is where presenting the whole text and code of a page in one place makes it clearer what is going on and how the page is formed. Here, a single template is serving as the equivalent of a single giant function, except of course you probably wouldn't write a single giant function. Good template languages help this by creating compact but clear ways of describing their dynamic portions; generally these are much smaller than you could write in actual code without a lot of complex helper functions. While single templates can get tangled and complicated, this is in a sense a good thing because it's an honest expression of how complicated you're making generating the page be. Just as big, tangled functions are a code smell that suggests something needs to be refactored, big tangled template pages are probably a suggestion that they should be split into several template variants or otherwise restructured to be clearer.
Ultimately, templating languages versus programming languages are another incarnation of the gulf between shells and scripting languages. Programming languages are optimized for writing code that happens to have some embedded text, while templating languages are optimized for writing text that happens to have some embedded code. The more you have of one relative to the other, the more you will generally tilt one way.
(It's possible to make a templating system without embedded code, where your templates simply define places that code will later manipulate to add your custom content. I used to quite like this idea in the abstract, but I've come around to feeling that it's not what I want in practice.)
The old-fashioned and modern ways to remap keys in X (some notes)
As I mentioned recently, I've been remapping my
keyboard in X for a very long time. In all
of this time, I've been using the traditional and now old fashioned
way of doing this, namely xmodmap
. Xmodmap is now a deprecated
mechanism, although it still works; these days you usually want to
be remapping keys with setxkbmap
.
You might wonder why X has two different programs for this. As you could guess, it's the usual reason; X added a new system for handling keyboard remapping without removing the old one (because X never removes anything). Xmodmap uses the old system, which I believe has been in X since at least the start of X11, while setxkbmap uses the new system, the X KeyBoard extension.
(Well, 'new' is relative here. XKB apparently dates from 1996, almost two decades ago. I was a little bit surprised to find that out, since I hadn't heard of it myself until recently. This is probably the hazard of having become set in my X ways a very long time ago.)
I'm not the right person to write up a big evaluation of the two
mechanisms against each other, because up until recently I hadn't
looked into XKB and setxkbmap
at all (and even now I only know a
bit). So from my limited perspective, the big difference between
the two is that xmodmap
offers relatively simple and direct
low-level control for weird operations while setxkbmap
gives you
simple ways to do most of what you often want, provided that you
can work out the right arguments.
To show what I mean by this, here is more or less the xmodmap
magic needed to swap Backspace and Delete keys and to make CapsLock
act as a Control key:
keysym BackSpace = Delete keysym Delete = BackSpace remove Lock = Caps_Lock keycode 0x42 = Control_L add Control = Control_L
You put this in a file and then run 'xmodmap FILE
' and magic
happens.
By contrast, here is the setxkbmap
command needed to make CapsLock
act as a Control key and make the right Windows key act as Compose:
setxkbmap -option ctrl:nocaps -option compose:rwin
You will notice that I have not shown you how to swap Backspace and
Delete with setxkbmap
. That's because that particular change is
not among the predefined changes that XKB supports and once you
venture outside of those predefined changes, things become rather
complicated.
(The predefined changes themselves are documented in the
xkeyboard-config
manpage. The files that define what these options
and so on mean are all found under /usr/share/X11/xkb
; see for
example /usr/share/X11/xkb/symbols/ctrl
. If you look at these
files, you'll see that XKB configuration is, well, intricate.)
Because setxkbmap
fits my needs right now (now that I'm not
swapping Delete and Backspace) and because it's
apparently the more approved-of way these days, I've switched from
xmodmap
to setxkbmap
. I probably would not have changed over if
I was doing anything that setxkbmap
couldn't handle through its
existing options for -options
; while more sophisticated things
are possible, they appear to be a lot of work.
The ArchLinux wiki has some nice references on Keyboard configuration
in Xorg,
xmodmap, and the
X KeyBoard extension.
While I accumulated a bunch of additional links while I was looking
into setxkbmap
, I'm not going to put any of them here because I
don't know enough to assess their quality and whether they're up to
date.