help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

rfc: convention for marking source texts vs secondary texts


From: PILCH Hartmut
Subject: rfc: convention for marking source texts vs secondary texts
Date: Fri, 24 May 2002 11:56:05 +0200 (CEST)

Just as applications need to be able to find the 'coding' and 'mode' of a text
file, they may also need to know whether a file is its own source or whether
and where an editable source text is available.

My text files now have a file variable called 'srcfile', used in the following
ways


        % -*- coding: utf-8; srcfile: /home/phm/swpat/bgh-dispo76.el -*-

This headline would say that the LaTeX file I just opened is coded in utf-8
and the result of compilation from a Lisp source file 
/home/phm/swpat/bgh-dispo76.el.
I use this convention for my multilingual hypertext generation system.

        ; -*- coding: utf-8; srcfile:// -*-

This would be written at the top of /home/phm/swpat/bgh-dispo76.el.
It says that this file is its own source file.

The notation '//' is easy to parse and can never be a name of a real file.

Is this a good convention that can somehow be useful to others and mentioned
in Emacs manuals?  

Is there already an established convention for the same purpose?

The purpose is indeed important for me.  For example, my daily backup program
will search all directories for new text files which are marked as being their
own sources.  Thus secondary files do not waste space in my backup archives by
default, and any file which I edit will carry the 'srcfile://' mark.

Btw the below mentioned website swpat.ffii.org is compiled using the MLHT
system, which is written in E-Lisp and poorly documented (years ago, to be
updated) at http://mlht.ffii.org.

-- 
Hartmut Pilch, FFII & Eurolinux Alliance              tel. +49-89-12789608   
Protecting Innovation against Patent Inflation       http://swpat.ffii.org/
115,000 signatures against software patents      http://www.noepatents.org/









reply via email to

[Prev in Thread] Current Thread [Next in Thread]