From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id o5EKknSX000947 for ; Mon, 14 Jun 2010 16:46:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 7FB8D15636A for ; Mon, 14 Jun 2010 22:46:43 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cXXrWb5pW3CW for ; Mon, 14 Jun 2010 22:46:42 +0200 (CEST) X-KTH-Auth: kristaps [85.8.60.51] X-KTH-mail-from: kristaps@bsd.lv X-KTH-rcpt-to: tech@mdocml.bsd.lv Received: from lappy.bsd.lv (h85-8-60-51.dynamic.se.alltele.net [85.8.60.51]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 0AC73156357 for ; Mon, 14 Jun 2010 22:46:40 +0200 (CEST) Message-ID: <4C16952F.1060906@bsd.lv> Date: Mon, 14 Jun 2010 22:46:39 +0200 From: Kristaps Dzonsons User-Agent: Thunderbird 2.0.0.16 (X11/20080812) X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 To: tech@mdocml.bsd.lv Subject: Re: [PATCH] deal with bad block nesting References: <20100614024711.GI14228@iris.usta.de> In-Reply-To: <20100614024711.GI14228@iris.usta.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Ingo, First I'm going to tag 1.10.2, which features improved -Tps and some performance/simplicity improvements (the cached data points), then we can take a more in-depth look at this with a stable roll-back point. My first impression is that this makes our nice and regular AST into shit soup. Don't get me wrong--it's a wonderful piece of work, but I think we can do it better in a completely different way. I propose (dum dum duuuum): If the offending macros are all Ao/Ac Eo/Ec blk_part_exp(), which it seems from the code, why don't we just make these into in_line_argv(1) macros and completely avoid this complexity? My motivation is that none of the Ao/Ac/etc. macros are semantically or syntatically valuable. They're just eye-candy. They don't affect their contents, just the point at which the Ao or Ac is invoked. The only thing this doesn't apply to is Oo/Oc, which has semantic meaning in the SYNOPSIS. Even this failure can be reduced if we special-case Oo/Oc within the SYNOPSIS (we already do this with Vt) to be a "real" block and the rest to be some shitty in_line_eoln(). Ingo, what are your thoughts on such an approach? Of course, my arguments hinge on the primary offenders for this behaviour... Kristaps -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv