Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by h1439878.stratoserver.net (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id u358kZFL021633 for ; Tue, 5 Apr 2016 10:46:36 +0200 Received: from relay.uni-heidelberg.de ([129.206.100.212]) by mx-ha.gmx.net (mxgmx003) with ESMTPS (Nemesis) id 0M7VB9-1bit8P0w7z-00xKfq for ; Tue, 05 Apr 2016 10:46:27 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id u358iLvL026011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2016 10:44:22 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id u358hplr016404; Tue, 5 Apr 2016 10:44:21 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 13525985 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 5 Apr 2016 10:42:19 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id u358gIlF010282 for ; Tue, 5 Apr 2016 10:42:18 +0200 Received: from bongo.birch.relay.mailchannels.net (bongo.birch.relay.mailchannels.net [23.83.209.21]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id u358g9No021162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Apr 2016 10:42:13 +0200 X-Sender-Id: netnames|x-authuser|joseph.wright@morningstar2.co.uk Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5AA6D408F for ; Tue, 5 Apr 2016 08:42:08 +0000 (UTC) Received: from smtp2.easily.co.uk (ip-10-42-131-234.us-west-2.compute.internal [10.42.131.234]) by relay.mailchannels.net (Postfix) with ESMTPA id 0495242CE for ; Tue, 5 Apr 2016 08:42:06 +0000 (UTC) X-Sender-Id: netnames|x-authuser|joseph.wright@morningstar2.co.uk Received: from smtp2.easily.co.uk (smtp2.easily.co.uk [10.36.128.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.6.11); Tue, 05 Apr 2016 08:42:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: netnames|x-authuser|joseph.wright@morningstar2.co.uk X-MailChannels-Auth-Id: netnames X-MC-Loop-Signature: 1459845727558:1496302401 X-MC-Ingress-Time: 1459845727557 Received: from [139.222.114.108] (port=51304 helo=[139.222.114.108]) by smtp2.easily.co.uk with esmtpa (Exim 4.43) id 1anMYn-0005dX-4W for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 05 Apr 2016 09:42:05 +0100 References: <57029370.4090909@free.fr> <57029C43.8090605@latex-project.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AuthUser: joseph.wright@morningstar2.co.uk Message-ID: <57037A5C.5040000@morningstar2.co.uk> Date: Tue, 5 Apr 2016 09:42:04 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Re: Bug in \NewDocumentEnvironment To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <57029C43.8090605@latex-project.org> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:fkmQc0V3f1Y=:xdXAKZIz5GgqUKtC1uM4O5TKMC hIbtwLgKqauCnqSm8IuLTHl33GeFeWiIdP6k4p40UCjAvOLRZyRvMy0Fpu8S2YcpvgPT1XEJd z86o3Q6wAlq4bSs03vu9p3BLi1sKNK99QjacBY/rD4VA1yuBrM664SuA+GMvYJtgJiYcunLyS 58CPIhtkgLRZZYxWxP9IdLUdyFpiHV2/rV4SdRMuA14rrJGB2OEeErABnD2Dkqom3Ht/3B5Iv UMqbL9EDZoqPpzNpxOjESMWbHj2joatYExQxp3303m85uNd7gJGLnP0opn9gO46bwh168JPV3 /UsFR3haI25Uq5IyUBT0IjueftkzXFUPwSRRlDWuobtL2PtO1K9eH1zViWbWdABg5dnBl+Gqc YYjocTPqztDaAYor75uNjI6SQ2kfSDj+CPudRbXB/AskaHy7XBfwgn8FEcaFF/nwz7xmC+l+V OT/+SNl0iLS6pyet2ltqcUBAcnwUNEHbX/rix9qZDjtoi2M6964zG1+k43Winm6fcpiVcooKE Y5nGLO3N8bGk6X3K4RcdgRh9u1x2Zx9reElu/x5EOZ4r4vJJsqskNj58AVJ9SOOPsyr48EiB6 swzGlwpmW2U3LtUgAUcokGwrmfiLH5BfF8tySROSsv6P5BnVdzZjUhLS74Qwyj2boo/aq9Ees F5Z+EFDV0aZ9jo5eoaubytWue/BdhyCGQefcF1CZiNtM4wwSg4SJuCKgkcCbFjU/q+QvsYJmd z8OY6vM2iy+2h3BAlEjTbRxzbBNFm+XHq6I76UDg93z9MSPKjiegAWYTK08BH47SrX9yo1vVm vjXpe45nWc02+OV6cKQtaxFmXZdqEW2RJ6yU+8FPq7mNL6OBoksQjpppWJCnkeR/mMFuLReNb nGxa3/Z2iOttEaS2w6SNj3LMcND6vaPL4GCa2Xvik3q4R5Gz4/VRPG6edfo9SHFrpljePuP/t GbPNFeKFwjW6GRo1G4isKLtiVpeLw2d3faSF26brLsxOi9xxDJsHAz2OnhXOxhB8oACHLydFx QME9CQWIYzSrZeFbmnJDQfdTBrinllhwT7+loTjyesFlEvSv5q9ScniRiBNNmh2mS1en5yOSE 4MVLgMI24F+8hTfy1LFrNJyb65qcg8oGDS8Q9FIel4EqGs21Wj1cjs8PRujeyKj5AHplS4zEc X7nB+cCOf32biaKL+N/pDxLGp86J76OkadhBgyuS2ELsewLutrhrATA9Kcg4DQnqOXf74lroi JsgC8fVvJoshPnOlOtSI9InCPIGOJFF48eH5aRoFUJrSY8NmHqPtIKntDEa7LRwZA3lo4Gtq7 dcmn+8iYVa8A1tmcy/Hpaari41reLjJ0i/EgW+ZnJyadcJa9F5EqStScnsM6RGcjpsr6rSFkh +9fgKBxBKTAxmw/eGNiwI+nkp+ySqgVQDXeEt2+ViaULwBznNDYMV+XYJUQo2oN7lQ5oK2aw6 iuMkPhhIAB7wYaajb9dx57EmKaBmJZ3wH2Oi0IceDiih0/LHl5k9d2Ekcdtlo9YXTLr/ECJHV MJeazf1dN/u6011M+kgpkrBzDvwopGwXGhbEvHhD+prA+ue15DbEhT17pcarezR/rms1fZtBX OkejHNhFmBLj/ZbNXd2xO4tbL3Oyr3M+RUXAWjnFKhKsGGbQFalbTb63kpqHcVFTPZd+KhA4D 54= X-UI-Loop:V01:CnU7eC4PW1g=:N4TMUggzfG3dhRg/61gkQm4ZxdRPq0PHx3VFjF+Gg2Q= X-UI-Out-Filterresults: notjunk:1;V01:K0:FDqT8palgh8=:Viv2hUMtsFQuhR9QkvULHx 12kktvMpxxswPQeI3ln+FPgGRoCN8y5knBxWc5+kQ/NxRKTuIUzmPvKK8d4cmcp/3R9DqD0en Xo05e/RUx9z0TBJQa9ejvl3TkhVF0oU6l5eHzyB4cy0MCDHgE1v8VOMHp3BVTta+6ojVGeB45 jtP77YxMlmPLZaDmhf0yQqSRShOc1F5Vvr34Ue8Cbm9F5EEh9d7p+5Pp1mFP5Cgxc7sIUUNo0 Lg7t85DL38tly78TitgUWdPe5LzCYHtJ3eUJeIaUytErG0ryuR0DAtocwfDVneDXnedgG+UyP oS2nXRhIzllGWnjLh2diJ10kV59ePzDUrjBSh6eaRNJY71OLhinIsaVY+N+i8p6Ep8OVBFIxl HKljAPTDrau+N1OKKPnz4nxphHFdtFwXnf1Tfl4urfM/AHx2jy95XTzgsu4r01VIt9rj3UJ73 vedsB3KyfyUh0l6GyCJzSb5bVqYV7Cifp68GV23YAE4HZeFKtq88AvkFvwaThr4s4RgtG/Qey FscoTCkLXKp/4KM/7zDlgBylzWJ3s9+yP2Jq8ZdEy0+ X-Scanned-By: MIMEDefang 2.71 on 85.214.41.38 Status: R X-Status: X-Keywords: X-UID: 7925 On 04/04/2016 17:54, Frank Mittelbach wrote: > guess this is a case of \protected being harmful > > Am 04.04.2016 um 18:16 schrieb Julien RIVAUD (_FrnchFrgg_): > >> \NewDocumentEnvironment{foo}{m}{% >> \begin{tabular}{#1}% >> }{% >> \end{tabular}% >> } >> >> \begin{document} >> >> \fbox{ >> \begin{foo}{ccc} >> \hline >> Test & a & b \\ >> \hline >> \end{foo} >> } >> >> \fbox{ >> \begin{tabular}{ccc} >> \hline >> Test & a & b \\ >> \hline >> \end{tabular} >> } >> >> \end{document} >> >> The first and second \fbox-es should produce the same output, but don't: >> the foo environment starts a second line at closing time, before the >> control is passed to the author-supplied closing code. > > actually that's not equiv, equiv would be something like defining "baz" > > \newenvironment{baz}[1]{% > \begin{tabular}{#1}% > }{% > \end{tabular}% > } > > but yes, same difference > > reason is the following difference in processing: > > \show\endfoo > \show\endbaz > >> \endfoo=\protected macro: > ->\environment foo end aux . > l.10 \show\endfoo > > ? >> \endbaz=\long macro: > ->\end {tabular}. > l.17 \show\endbaz > > the \protected hides the \crcr inside \endtabular. > > Now it may be that the protected is needed for other reasons (hope not) > but perhaps it is just overprotection .. let Joseph say :-) This is a tricky area and in part at least reflects the fact that xparse (and expl3) is about both 'useful things now' and 'exploring ideas for building a new format'. I hope that broadly xparse is useful 'now' so we are probably doing something right. As observed, the issue here is that as set up in LaTeX2e, the tabular environment relies on the \halign primitive and the rather tricky expansion behaviour that relies on. At least from e-TeX 2.0 the \protected mechanism prevents expansion at the start of a cell so we manage to 'hide' the \crcr. (I'll come back to this below.) For xparse as a package 'on top' of LaTeX2e probably the easiest solution is simply to drop the \protected status for end-of-environment code. As Frank has (basically) observed, I'm a fan of having a clear separate between protected and expandable code but here at least for the present some pragmatism may be best. We could of course add some new xparse function instead, but environments are not really expandable so \DeclareExpandableDocumentEnvironment would be wrong and in any case the internal are not readily accessible so it's likely not required/sensible. Looked at in the context of 'for the future format' I'm not sure at present what might be best. As \halign is rather tricky it's not at all clear that a new tabular implementation should use it at all. However, the bigger issue there would be not the internals of environments but \end itself. As I've noted, environments aren't expandable: they form groups and need to do assignments. Overall I think having these macros \protected is a 'good thing' so would be unkeen on ending up with a 'not really expandable' \end (or equivalent: nothing is actually decided in terms of the interfaces in a new format). It would be possible to arrange that for example \\ or \hline (or equivalent) do f-type expansion of following material by ending them with \romannumeral`-0. We already have a similar trick in l3galley to allow detection of 'ignored' paragraphs. However, that would also expand other \protected macros which might not be desirable (see for example siunitx S column escape). There are possible solutions to this involving much the same stuff as in l3galley (inserting a marker \relax of the correct name where expansion is to stop, and skipping it where a \crcr/\omit/\noalign is to be found). (I also suspect I would take a different tack with parts of the siunitx table interface if/when writing for a new format, so that may not be an issue, particular if the tabular implementation is richer in the first place.) I wonder about the fact that e-TeX v1 -> v2 included adding \halign cells to places where \protected is 'active': presumably there was a good reason for this though it may (since Peter B.'s death) be hard to pin this down. Thoughts? Joseph