(Note to English-speaking readers: the links entitled Komentarze na tej stronie lead to comment pages.)
It is a well-known fact that a hacker’s life without
grep(1) would be rather terrible. It is extremely useful. It is a bit less known that a hacker’s life without Emacs is rather terrible. However, given two great tools, one wonders whether they could not be made to work together?
Oh yes, they could. Starting
grep from within Emacs is not only possible, but also advisible, for reasons I will explain in a minute.
C-h a grep RET shows (among others) the commands
rgrep. (There are more, but we will deal with these basic ones only.)
The most basic of them is just
grep. It shows a prompt saying
grep -nH -e, which means that the only thing you have to do is to type the search pattern (a regex) and a list of filenames (possibly with wildcard(s)). What is more Emacs-y than just running
M-! grep ... is that the results are shown in a buffer put in
grep-mode, which inherits from
compilation-mode. This means that you can do all sorts of cool stuff there – just press
C-h m to see for yourself. Two highlights are:
M-p for the next and previous match (respectively),
C-c C-c (or just
RET) to jump to the file and position shown at point, and (probably the coolest trick)
C-c C-f to enable
next-error-follow-minor-mode, which shows the match in another window dynamically, i.e., just moving point in the
*grep* buffer causes Emacs to show the match in context.
Now the disadvantage to this is that you have to remember to give the pattern first and the filename(s) next (which is kind of obvious, but anyway), and – which is more cumbersome – to quote things like backslashes properly. Both these problems are addressed by
lgrep, which asks for the pattern to search (conveniently deriving the default from the word at point), then the filename(s) (conveniently deriving the default from the current file’s extension) and finally the directory (conveniently deriving the default from the current dir). Prefixed with
C-u it even allows to modify the actual command line before execution. All that is really useful.
What is a real pain in the neck, however, is grepping recursively. Yes, there is
grep -r, but for more complicated searches a combination of
grep is needed, and anyone knows that the only thing worse than the syntax of
find(1) is the syntax of
tar(1). Yes, Emacs has
grep-find, which gives a template for a
find/grep combo, but one yearns for something more. And something more there is indeed:
rgrep. Just like
lgrep is a wrapper around
rgrep is a wrapper around a
find/grep engine, with similar features.
As I said, there is more than that, but this covers at leasts the basics of searching files from within Emacs. Happy grepping!
Robert'); DROP TABLE Students;-- (well, not exactly that in this case, but if you pass a user-defined string to
(lambda (string) (format "var crazyString='%s';" string)), you are asking for trouble. What needed to be done was (if I get all this stuff correctly) escaping
&, but also the quotes:
" (just in case I decided to change
var crazyString = '...'; to
var crazyString = "...";) and – importantly – the backslash. While writing the function to do this (which I based on
org-html-encode-plain-text, which incidentally is a very nice example of functional programming), I wrote this funny-looking expression, which at a first glance does nothing:
(replace-regexp-in-string "\\\\" "\\\\" text t t)
This is more or less a copy of a message on the Org-mode mailing list I posted there some time ago.
I started working on a custom exporter from Org to HTML for educational materials. My vision is that there will be (some kind) of syntax in Org (most probably, I’m going to (ab)use the existing syntax) for specifying various kinds of exercises.
The project page is on GitHub. It is currently (still) in a very early stage, when it should be considered more of a proof-of-concept rather than anything useful (though I am going to actually use it in a few days for a real project). What currently (sort of) works are: single and multiple choice tests and cloze tests.
The design goals are:
C-uin the browser will reveal all the correct answers. I consider this a feature, not a bug, since the aim of the tests is not to grade, but teach. AFAIU the web (though I may well be mistaken), there is no way to overcome this problem with HTML and JS alone anyway.
As of now, the project just has everything in one directory, together with the example Org file (jQuery v2.1.1 minified also needs to be present there, or the variable
org-edu-html-jquery-address should be set accordingly). If anyone is interested in such a project, any feedback (like bug reports/feature suggestions) is welcome. I would especially like to hear about what syntax might be a good idea on the Org side. (My limited experience from this and one other project, where I use Org to prepare e-learning materials shows that Org-mode might, alas, be not the best choice for that, though it definitely has its advantages, too.) Currently, for the choice tests I abused lists with checkboxes (which mark the correct answers). Also, any comments on the quality of the code (both on the Elisp and jQuery sides) are more than welcome – while I feel quite confident writing (at least simple) Elisp functions (though have yet much to learn from more experienced hackers), my jQuery experience is next to none. And last but not least, I’m curious whether there is any demand for such a thing (I assume it’s possible, since many Org users come from academia).
(Więcej means More in Polish; click it to see older entries.)