Helmut Eller writes:
Luke Gorrie luke@bluetail.com writes:
But I suspect the main issue right now is to make sure that a custom-hacked readtable that one installs globally as *READTABLE* will be used by `M-.'. That's how I do my readtable'ery, at least.
Yeah, and it's probably what 99% of the users do. People who use multiple readtables deserve to loose :-)
I'm currently working on Objective-C integration with CLOS, and the code implementing the integration uses a normal readtable, while ObjC-using code needs a different readtable (so far the only change is to use :invert read-case to support camelCase ObjC method names). The specter of having to constantly switch readtables has made me think about adding the ability to associate a readtable with an Emacs buffer.
All this is to say that I think there are reasonable situations in which this might come up.
All this is currently only used for SBCL and I don't know if *readtable-alist* is very useful for users. I assumed it is more convenient to associate readtables with packages than to use Emacs-style file variables, ala -*- readtable: ... -*-. OTOH, file variables would be handy when find-definitions opens an arbitrary file; we could just look at the first line.
I think the file variables method is the way to go, maybe in combination with grovelling for a (setf *readtable* ...) form at the top of the file, so the common case gets handled automatically.