A tool to add the coding file option to lisp source files is now available. This can also be used to transcode all the files to UTF-8, or to attempt transcoding to ISO-8859-1 or US-ASCII with loss in comments. There is an example for the current Quicklisp releases with a few required exceptions. This is experimental, particularly the transcoding to ISO-8859-1 or US-ASCII. Please backup your code before giving this a try! See: http://www.scieneer.com/files/transcode.lisp
With the coding file option in place, the developmental version of ASDF is able to pass the correct external-format to 'load and 'compile-file.
Note the lambda-reader is handled by substituting references to the lambda character back to "(lambda".
Since the :encoding file option should become unnecessary with the coding file option, and also because it would be invalid upon any transcoding, it is removed from .asd files. I don't think it would be practical to try and update the :encoding declarations.
With the coding file option on all the files, all that asdf-encodings needs to do is read this file option. The UTF-8 and other detection could be removed and moved into a tools such as this.
If some of the CL implementations would add the reading of the file option as an external-format then the coding file option could be used by 'load and 'compile-file outside of ASDF - then for these CL implementations asdf-encodings would not be necessary and ASDF could pass on the encoding-file-option reading external-format which may well be the :default. I will look at implementing this for the Scieneer CL, and perhaps take a look at CMUCL, but it would be best optimized for each CL implementation.
Regards Douglas Crosher
On Tue, Apr 24, 2012 at 23:39, Douglas Crosher dtc-asdf@scieneer.com wrote:
A tool to add the coding file option to lisp source files is now available. […] http://www.scieneer.com/files/transcode.lisp
Very cool! Thanks a lot Douglas.
With this tool, package authors, distributors and/or users can easily migrate their code to whichever setup they prefer with respect to encoding — and they don't even have to agree with each other!
Since the :encoding file option should become unnecessary with the coding file option, and also because it would be invalid upon any transcoding, it is removed from .asd files. I don't think it would be practical to try and update the :encoding declarations.
Removing a :encoding specification is good when you have an explicit coding file option. There are exceptions, such as lambda-reader-8bit.asd, but it's only meant as a debugging trick.
With the coding file option on all the files, all that asdf-encodings needs to do is read this file option. The UTF-8 and other detection could be removed and moved into a tools such as this.
Until everyone uses such explicit option, it's not too bothersome having this detection.
If some of the CL implementations would add the reading of the file option as an external-format then the coding file option could be used by 'load and 'compile-file outside of ASDF - then for these CL implementations asdf-encodings would not be necessary and ASDF could pass on the encoding-file-option reading external-format which may well be the :default. I will look at implementing this for the Scieneer CL, and perhaps take a look at CMUCL, but it would be best optimized for each CL implementation.
Excellent!
However, if the code is going to spread, please make sure it is at least as compatible with Emacs as users will ever want it to be. Fixing N copies of the code ain't fun, and having to handle subtle discrepancies in behavior is worse.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If debugging is the process of removing bugs, then programming must be the process of putting them in. — Dijkstra
-
Douglas Crosher -
Faré