I'm a bit out of it and haven't followed this conversation closely... I think the situation is roughly
- people need non-ASCII characters in files - the ASDF definition file handles charset info for source files - the new "charset-detection" patch attempts to do the same for ASD files - non-ASCII is mostly used in ASD files for names and documentation - this is a portability issue
I'm doubtful that automatic charset detection is practical. I've never seen a web browser that did it right in the cases I cared about (mostly Asian language sites). A "compatible" charset may parse without error but render completely bogus characters, clearly wrong even to one do doesn't know the language.
It seems safer to make the charset explicit in an ASD file rather than require the end user to somehow know and specify the charset, or to require ASDF to guess the charset.
One proposal was to use a special sequence at the start of the file, like Emacs or other tools use for specifying configuration settings. However, this needs to then be compatible with those tools. This implies that ASDF needs to know a wide variety of such formats or has to introduce a sufficiently unique format to coexist with others.
What if ASDF allowed one ASD file to set up a dynamic scope when including another ASD file? I think this might also clean up some places where people are currently invoking CLOS.
Something like
system.asd: (defsystem system (asdf-let ((charset :some-charset)) (load-sytem system-impl)))
system-impl.asd: ;; non-ASCII characters here (defsystem ...)
Then all primary ASD files could be ASCII-only.
Later, Daniel