Now don’t get me wrong: I have nothing personal against those strange people who end their sentences with a single space, I just want them locked in some place so they don’t interfere with us normals. But reality is reality, and after I found that I'm not the only one being angry with the one-spacers sending me their crippled files, I decided to do something about it. This is really a ten minute hack and a proof of concept rather than a full solution, but what about this?
(defvar sentence-end-double-space-threshold 2 "How many occurrences of \". \" per kilobyte should be enough to declare this file as using two spaces after sentences.") (defun set-sentence-end-double-space () "Set `sentence-end-double-space' according to how often the literal string \". \" occurs in the current buffer." (make-local-variable 'sentence-end-double-space) (if (>= (* (count-matches "\\. ") 1024) (* (buffer-size) sentence-end-double-space-threshold)) (setq sentence-end-double-space t) (setq sentence-end-double-space nil))) (add-hook 'find-file-hook 'set-sentence-end-double-space)
Now when you open a file, Emacs decides (using the very conservative value of
sentence-end-double-space-threshold, which you can
setq to whatever you feel right) which style it is. (Obviously, this does not help in case of pasting from the browser or whatever. It could be done, advising
yank and – if needed – replacing spaces in the yanked text as necessary, but hey, I only had 15 minutes for that!)
A few days ago I announced this on the Org-mode mailing list, and let me repeat it here. I started a small project, called org-one-to-many, whose aim is to provide a way to split an Org file into subfiles. Currently, all sections at a given level are output to their own files, and the main file is transformed into a file with all those sections replaced by links to them. All the internal links in the source file are converted (as needed) to external links pointing to the newly created files.
Feedback is appreciated, be it bug reports, feature requests or anything.
It is very often the case that one works on a certain document (it might be a scientific paper, it might be a book, it might be a newspaper article, it might be a master’s thesis – whatever) and from time to time one wants to revert some changes („this wasn’t that brilliant idea I thought it was”), or highlight the changes made since the last reading by the advisor, or be able to check which parts of the file were last edited on what date, or any similar thing. In general, knowing what part of the file changed from what and when is occasionally quite useful.
Of course, you can save subsequent versions of your paper under filenames like
paper-v23.tex and so on (actually, a better idea is to use
paper-v01.tex – the padding zeros make lexicographic sorting yield better results). Or better,
paper-2014-10-18.tex, using the ISO 8601 standard. But this method is error-prone and cumbersome. And usually, if there is something which is error-prone because it needs a lot of bookkeeping but no creative thinking, it is better to leave that task to a machine.
What is needed in such situations is called a version control system, or VCS. There are plenty of such systems out there. Personally, I used to use Mercurial, but after a few years it became clear that Git is a better choice, and so I made a switch. (Mercurial is easier to use for beginners. Git is more powerful. Don’t care about other ones unless you really have to. For instance, I heard rumors of Subversion (SVN) being a nasty beast, though, so you might want to avoid that one – in general, a so-called distributed VCS seems a more versatile tool anyway.)
What are the advantages of using such systems?
What are the disadvantages? Well, I can think of one: there is some overhead connected with „committing” each change (that is, telling the VCS „hey, this is the next version, please remember it!”). Of course, you can commit only after some major rewrites, but it is usually better to do it more often.
To sum it up: if you work alone, on small projects (say, less than 2 pages of text each), and do backups regularly, you might not need a VCS (but it might come handy anyway). In all other cases, you probably do need it.
(Więcej means More in Polish; click it to see older entries.)