From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id q4VCGPYD007456 for ; Thu, 31 May 2012 08:16:25 -0400 (EDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 563FA14E26A; Thu, 31 May 2012 14:16:19 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id ZJdkJU-om5FN; Thu, 31 May 2012 14:16:11 +0200 (CEST) X-KTH-Auth: kristaps [193.10.49.5] X-KTH-mail-from: kristaps@bsd.lv Received: from ctime.hhs.se (ctime.hhs.se [193.10.49.5]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 9204114D7E0; Thu, 31 May 2012 14:16:10 +0200 (CEST) Message-ID: <4FC7610A.6050803@bsd.lv> Date: Thu, 31 May 2012 14:16:10 +0200 From: Kristaps Dzonsons User-Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:5.0) Gecko/20110805 Thunderbird/5.0 X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 To: tech@mdocml.bsd.lv CC: Ingo Schwarze Subject: Re: fix blank line handling in .if References: <20120531014222.GB11297@iris.usta.de> <4FC73EC4.2090803@bsd.lv> <20120531102857.GA16923@iris.usta.de> In-Reply-To: <20120531102857.GA16923@iris.usta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/31/12 12:28, Ingo Schwarze wrote: > Hi Kristaps, > > Kristaps Dzonsons wrote on Thu, May 31, 2012 at 11:49:56AM +0200: > >> Good one! As usual, do just commit and I'll look over the patches >> in hindsight and see if anything makes me sad. > > Thanks, will do so tonight. > >> I'm particularly fond of this fix---the trailing space/newline has >> always been annoying. >> >> I anticipate finally (finally!) having some free time by this >> weekend and next week (projects rolling over), so I'll polish the >> SQLite fixes (this will initially come with a hit to apropos >> functionality--only OR searches, for example, but is worthwhile >> given the massive reduction of code complexity). > > OK, so i will try to get that in and tested, too! > (Or at least to nag... ;-) > > One thing i have to do is send a revert patch for the WARNING macro. > A variable number of arguments for a macro is not portable. > >> Given Jesse's mention of many roff macros he'd like to >> implement---few of them possible without layer violations---I'd like >> to throw together a concept, as we've discussed before (with fear >> and awe in our voices), of all macros thrown together and parsed in >> a common way. > > I'm not sure it would be fair with respect to Jesse to do that right > now; well, he can't get clean earth to till, but at least he should > have a stable platform. I don't think you will get that project to > a stable state until his time is up, so it won't help him. > From your perspective, it's probably less work, too, to start that > after he has moved on to diff(1) - less conflicts, in case he manages > to produce any patches good enough for commit... Ingo, Oh, don't get me wrong---I fully agree. As mentioned in the last mail, a greater priority for me is to clean out the dratted tab-handling code in -mdoc column lists. With this cleaned up, and argument parsing unified, there'd be a much clearer basis from which to consider a Grand Unification of Macros. I also want to generalise the [x]html frontend to use macro names as classes, which would remove a lot of superfluous code. But that's an entirely different story. Of course, after such a long caesura, it may take a few hours simply to remember what's where in the code-base! My local tree is a mess of sqlite benchmarks and tests. Best, Kristaps -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv