I don't know enough to translate a darcs repo to git. I could probably manage this, but tcr buried the NAMED-READTABLES repo somehow inside an EDITOR-HINTS repo, and linked the two in some way I don't understand.

I have a script to do that somewhere on common-lisp.net. I actually already did a conversion from darcs to git some time ago, for the sake of xcvb. If your main darcs repo is: http://common-lisp.net/project/editor-hints/darcs/named-readtables Then it hasn't changed since I did a conversion a few years ago: git://common-lisp.net/projects/xcvb/named-readtables.git Moreover, my repo already includes two XCVB patches in branch xcvb, that you may want to merge into master if you're the new upstream after you import to e.g. github. I see that there is another one from github, with another patch: https://github.com/kmizumar/named-readtables Of course, the two conversions are incompatible, so you'll need to pick either one as the new master, and extract patches from the other.

There are pending patches I need to push into NAMED-READTABLES, but I would need some assistance to fix this.

I hope the above helps.

I note that NAMED-READTABLES are necessary to support your proposed changes, but *are not sufficient*, since support for named readtables would have to be added to the development environments.

named-readtables is not strictly necessary, but something like it is. In my proposal, only systems that actively modify the readtable need use it. Currently, if any system does modify readtables, all other systems, even that don't use readtables, need to use it to be safe. I'll open a bug on launchpad explaining the situation.

I would like to forestall facile answers to the above claim, too. I don't just mean "SLIME would have to handle IN-READTABLE." SLIME would have to be fixed, yes, but also ELI, Allegro Composer, Hemlock (or whatever the CCL IDE is), LispWorks whatchamacallit, etc., etc.

True. However, lack of support there is not a regression. Things that used to work still will work. New things that may work will require additional support, but we can leave that up to those who will use those things. I suspect Attila and the dwim.hu guys have extensions like that already.

ASDF should not demand a programming style that doesn't have full support for in-editor dynamic code writing and maintenance.

ASDF doesn't demand anything; it just enables new extensions by providing hygiene. These extensions may in turn demand editor support, but then it's the job of the extensions' authors and/or users to add this support to the tools they use. The job of ASDF is just to help with division of labor, according to the principle that he who knows specifies, he who doesn't know doesn't have to specify anything.

Yes, this means that there can be bad libraries out there, but there are lots of crappy libraries even aside from misusing readtables or pretty-print dispatch, and ASDF cannot fix them all.

I think ASDF can prevent them from unwittingly harming other libraries. If I didn't care about backward compatibility, I would use with-standard-io-syntax and tell those who want to modify the default *readtable* without explicitly selecting a new one first that they are in error, enforced by good implementations. Because of backward compatibility, I believe it's safer to grant every system one new readtable by default. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The pleasure of citizens discussing politics is a powertrip by proxy. By identifying themselves to the masters, they wallow in slavery.