From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-01-web.scc.kit.edu (scc-mailout-kit-01-web.scc.kit.edu [129.13.231.93]); by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 9b5779bd; for ; Mon, 9 Mar 2015 06:46:50 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (envelope-from ) id 1YUw92-0002ky-Ko for discuss@mdocml.bsd.lv; Mon, 09 Mar 2015 12:46:49 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1YUw92-0000f6-Fy for discuss@mdocml.bsd.lv; Mon, 09 Mar 2015 12:46:48 +0100 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.80) (envelope-from ) id 1YUw92-0004SX-A5 for discuss@mdocml.bsd.lv; Mon, 09 Mar 2015 12:46:48 +0100 Received: from localhost (1031@localhost [local]); by localhost (OpenSMTPD) with ESMTPA id 3d05d81b; for ; Mon, 9 Mar 2015 12:46:48 +0100 (CET) Date: Mon, 9 Mar 2015 12:46:48 +0100 From: Ingo Schwarze To: discuss@mdocml.bsd.lv Subject: Re: Linking in mdoc(7) Message-ID: <20150309114648.GA18431@athene.usta.de> References: <54FC74F4.9090200@bsd.lv> <20150309110908.gN5E-QPE%sdaoden@yandex.com> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150309110908.gN5E-QPE%sdaoden@yandex.com> User-Agent: Mutt/1.5.23 (2014-03-12) Hi Kristaps and Steffen, Steffen Nurpmeso wrote on Mon, Mar 09, 2015 at 12:09:08PM +0100: > Kristaps Dzonsons wrote: >> Summary: mdoc(7) has linking, but it's very restrictive. You can link >> to `Sh' and `Ss' macros by using the `Sx' macro. I propose adding >> another macro, `Ix', that creates an invisible anchor that `Sx' can >> jump to. Thus, `Sh' and `Ss' work as they always did and `Sx' works >> as it always did, but we can also jump to arbitrary locations from >> `Sx' as defined with `Ix', which is otherwise silent. Obviously, this >> is only useful in -Thtml. On the console, nothing happens at all. I >> also propose an `Lkx', which is like `Lk' but for inter-page links. >> This is when the argument to `Sx' should be different from the index name. My initial reaction is: It is about time to do something like that. However, introducing new macros is not be taken lightly, and the design must not be rushed. Before committing to something specific, we should make sure that it is as powerful as possible, as extensible as possible, and as simple as possible. I'm not yet convinced the proposed design is the most general and simple one. In particular, it isn't obvious to me yet how implicit linking - i.e. internal linking that doesn't require any new markup - integrates into Kristaps concept, and lack of an idea how terminal output can profit is a very serious downside too, give that terminal output is by far the most important output mode. Then again, we have a tradition of having good designs override bad ones soon afterwards (no insult intended :). > I have proposed something similar back in September 2014 on groff@ Exactly what i wanted to say. :-) The thread is here: http://lists.gnu.org/archive/html/groff/2014-09/msg00145.html > and implemented a complete package that can do this and much more > with an interface that follows Ingo's suggestions since then. > The macro is .Mx, the documentation, troff(1) awk(1) preprocessor, > mdoc(1) macro extensions etc., and a patch for less(1) v471 that > allows internal (including .Sh and .Ss, but many more) and > external anchors (for .Xr) to be followed are available. Use it > or leave it. I didn't look at either implementation yet, i focussed on different topics (man(1), eqn(7), UTF-8, messages, afl mopup, pod2mdoc(1)). Even though Steffen rightfully says that i influenced the design he finally chose, and even though that design seemed better to me than what was initially proposed, and even though Steffen was positively enthusiastic about it, i wasn't quite satisfied yet. So my hope is that what we finally arrive at will at least be as powerful as the union of your two implementations and at most as complex as the intersection of both of them, or maybe even better... Kristaps, if you want to commit to minimize risk of loss of work, maybe create a branch for it for now? I'm planning to prepare the 1.13.3 release soon, and this is clearly post-release material. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv