From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2791 invoked from network); 31 May 1999 09:43:07 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 May 1999 09:43:07 -0000 Received: (qmail 13908 invoked by alias); 31 May 1999 09:42:49 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6380 Received: (qmail 13895 invoked from network); 31 May 1999 09:42:43 -0000 Message-Id: <9905310903.AA15294@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: issues Date: Mon, 31 May 1999 11:03:22 +0200 From: Peter Stephenson These are mainly some open replies to Bart and Sven on things while I've been away, and memos to myself. Sorry to lump them together, but the most likely alternative was not to do it at all. 64-bit stuff in 3.0.6: Well, I described the final result as experimental, and that's certainly true when you're using zsh memory management because of the new alignment constraints (on the architectures in question, sizeof(long long) == sizeof(double) so the system's malloc is quite used to using 8 byte alignment). But as it has to be explicitly turned on there would be no harm done to ingenu installers. It's probably going to take some work and there's a conference coming up, so it'll be some way down the list, and if 3.0.6 is ready to go it's not worth waiting for possibly suboptimal 64-bit integer support. (I still have to check the compilation log with --enable-lfs that Andrej sent me in more detail, there are one or two things that look like they need tweaking, but nothing disastrous.) $_ in preexec: this gets set later than you might think, after preexec is executed, so that you get the previous command line, and doesn't track all the syntax to find the last word. I always found it of rather limited use anyway; I imagine Paul stuck it in because it was in the ksh manual and didn't worry too much how it worked --- it's probably one of those things like $LINENO that works better in ksh. Conceivably one could do more sophisticated things as a module with special parameters. quoting in completion: if you do % echo "` you get dquote bquote> from the cmdpush() stuff added by Sven to lex.c. Could that be of any use in completion? Could we make a stack of contexts available and choose quote behaviour based on that? It would mean removing the delete-quote code, so it doesn't sound too simple. As for the test I modified for detecting quotes (long ago, and I didn't make it very sophisticated), it was simply because you didn't have any choice about how the shell behaved, so it seemed important to have a good guess. The cp -f thing in configure.in was just me being dozy. However, I deliberately didn't use mv because I want config.status to exist with the right permissions, otherwise the edited version needs chmod +x; this was just a short cut so that ... >config.status worked. Using mv and chmod is another possibility. ${..."$(...)"...}: I haven't looked yet, but I don't see why the change shouldn't work in 3.0.6; the test will simply have to be in a different place as the nested expansion (I was going to say subduced representation, I'm that confused at the moment) mechanism is less sophisticated. It's simply a case of ignoring null tokens and relying on quoted dollars and I'm pretty sure the basic algorithms for these go way back. By the way, it's possible there are other places where ignoring null tokens in this way would be useful, but around a nested expansion is the most obvious. the minor parameter fixes: I didn't check if parameters with PM_UNSET were allowed in the parameter table in 3.0, if they aren't then the problem goes away. I'll try and remember to fix the other thing to make it consistent. NO_RCS/NO_GLOBAL_RCS: I didn't get replies apart from Bart's, i.e. no protests from people who use it to turn off .zlogout, so I suppose it's OK to change the behaviour so you can unset either at any time (the first alternative) and mention it in the appropriate section of the FAQ. the su thing: looks like I'd better alter this again. I don't see any harm in working around su problems if shell users are going to be stuck with them --- and to claim it's a an su bug when zsh emulates sh just because it saw the s of su seems to me to be a bit over the top. Shame it's too difficult to test for explicitly, but we could restrict it to, say, SunOS 4 (that's the only one I know about). maybe I'll just go back to the first patch that came. history changes: I think there were two major patches of Wayne's; the only things I did were turn on share_history for ksh emulation, which removes a notable incompatibility, and shorten the name of incappendhistory. It's definitely a functional change, it doesn't really need to be in 3.0.6, I would have said. it would be nice to have real argument passing to zle functions, but I would guess it's a lot more complicated than what Wayne added for numeric arguments (though that's extremely useful), since it will depend on the command being called how the argument is treated, and passing around strings of characters as arguments means working out how the interface with the standard character input mechanism should work. Probably the stuff on pipelines and terminals is mostly or all applicable; I don't remember this changing much in 3.1. typeahead problem (pasing multiple lines when zle is already active, again): just occurred to me that you can't even tell whether the typeahead is for the shell anyway. consider 'catecho^D' or 'echoecho' --- only when the first command has finished do you know what input is for zsh. sorry. I've probably forgotten lots of things already, but maybe you'll remind me. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy