From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.2 Received: (qmail 32366 invoked from network); 27 Apr 2020 10:02:07 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with UTF8ESMTPZ; 27 Apr 2020 10:02:07 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 59045b7c for ; Mon, 27 Apr 2020 05:02:04 -0500 (EST) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 3dac50ec for ; Mon, 27 Apr 2020 05:02:04 -0500 (EST) Received: by mail-io1-f43.google.com with SMTP id e9so18129031iok.9 for ; Mon, 27 Apr 2020 03:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anjbe-name.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:comments:mime-version :content-id:date:message-id; bh=cOrieWTh1occc9KI1fozW0273pT/0HW6b915AcX3DvM=; b=1MhmhyV1774+IUO6lp6wH+3LuFrX5U/SNfB8Al84yA61BLxAy/QiWgzD7K6+SlBRGf OHWaZsLoeoYD+EeXEtdP8tpVER+ll2iVse3J9VMnfY/rEiLeexFea0+XFtGvUp3dq7Ii WXeSMl+1vCx4dLOkBf5p5dYFKZzm9Nk6NNS03ZYSlKUhNb1ffFVTPxLOj4U7CESJj9vP +SEVhlUrEa0r0Y/6MSFr6sVtWY/9bX/2KWP5c5hsAqszIrxBjj5RBl3MoJ6LnUMHbhR/ nblDJ3G678mZUZJICUbLQtssWFs1jVnfJFv95UaPtXeraAau2X33EMm3bA9L4P/mljqY wo7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :comments:mime-version:content-id:date:message-id; bh=cOrieWTh1occc9KI1fozW0273pT/0HW6b915AcX3DvM=; b=j4cptlELprO2RDunAaDLYPBguVAYFJJYRgQDDWwp9E1+yu5/etUcvKARJOZA0mD0Fk WxNweDN77lFYnV/dsTo937ABwCZIshUGCUUdHTrFFFn/6hkFoA9zWAAMondHA5+YLp73 TLT3xdq6wZrwIPd5yFyO3DD5s2pkXoiY6vV2KbgRVLdXue5evB5C01l0WyyWM9vfkzx9 JsmCoBIzfytgjAUvqngnmGhX6JOszPE9OoDrLxfv0mlkaJ2/v3bkTUcBBu9gV4pXzfiT Ej93uGL+YpCdPmE+jKopGxBsxnTy7stO9IYugnxP3m2iSk1QSw5vn1HiHkLAfS5QoH7Z PzVQ== X-Gm-Message-State: AGi0PuZlDEwsqh7ccDps884vfVI8PNz+0/b/Uc0sdvzenxxmOT1WW0mv 4HftfA0Pg3256y+HgAZojozP0g== X-Google-Smtp-Source: APiQypIKmUs5GDiTlsPP8f5qtBRdeYS48DI5QUrX+Yy7r9Ti0cHvVF2KTVgcUBExGf191rJvd+Cs5A== X-Received: by 2002:a02:b055:: with SMTP id q21mr20221793jah.7.1587981722062; Mon, 27 Apr 2020 03:02:02 -0700 (PDT) Received: from desktop.ajb.soy (c-174-56-122-129.hsd1.nm.comcast.net. [174.56.122.129]) by smtp.gmail.com with ESMTPSA id u16sm5303421ilg.55.2020.04.27.03.02.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 03:02:01 -0700 (PDT) Received: from desktop.ajb.soy (localhost [127.0.0.1]) by desktop.ajb.soy (OpenSMTPD) with ESMTP id db2e2dd9; Mon, 27 Apr 2020 04:02:00 -0600 (MDT) From: "Anthony J. Bentley" To: Ingo Schwarze cc: discuss@mandoc.bsd.lv Subject: Re: Fl Fl for long options In-reply-to: <20200427001640.GB55740@athene.usta.de> References: <8a57c2f3270c2455@mandoc.bsd.lv> <14105-1587941943.721637@wO-a.W87w.5Fm4> <20200427001640.GB55740@athene.usta.de> Comments: In-reply-to Ingo Schwarze message dated "Mon, 27 Apr 2020 02:16:40 +0200." X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61058.1587981719.1@desktop.ajb.soy> Date: Mon, 27 Apr 2020 04:02:00 -0600 Message-ID: <67103-1587981720.056894@Anan.Avbo.XjVs> Hi Ingo, Ingo Schwarze writes: > > And again, I still find it incredibly unintuitive that in OpenBSD's > > grep(1) manual jumping to the --label tag unintuitively requires > > searching for "-label" rather than "label". > > That had already been fixed for some time before this commit: > > $ man -O tag=label grep > --label=name > Print name instead of the filename before lines. > [...] Hm, so it has. That's what I get for not updating this machine lately. > It is not so much something that requires an active interpretation, > it already follows from the structure of the language itself. Macros > in mdoc(7) and man(7) form a tree structure. In many cases, whether > adjacent macros will become siblings or parent and child requires > knowledge about the language that isn't apparent from the syntax, > and in a few cases, there are equivalent possibilities for the > relative positioning of the nodes in the tree that would ultimately > result in the same formatting, but that each macro generates a node > can hardly be questioned. Thanks, this helps me understand your reasoning. > I'm not aware of any, and that is why i decided to implement this > syntactical conversion to have "empty flag immediately before > non-empty flag" transformed to "flag with double hyphen-minus". > ... > Going forward, some of this discussion has now become moot. Fair enough. So, Ingo, it seems that you provided the solution before I even asked my question! Would that all problems in my life could be resolved in such a way. -- Anthony J. Bentley -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv