From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 14 10:58:12 2015 Received: (at submit) by debbugs.gnu.org; 14 Jul 2015 14:58:12 +0000 Received: from localhost ([127.0.0.1]:49141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZF1et-0001aw-PI for submit@debbugs.gnu.org; Tue, 14 Jul 2015 10:58:12 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43681) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZF1er-0001aa-5c for submit@debbugs.gnu.org; Tue, 14 Jul 2015 10:58:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZF1ek-0003D9-6K for submit@debbugs.gnu.org; Tue, 14 Jul 2015 10:58:03 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:59002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF1ek-0003D5-4J for submit@debbugs.gnu.org; Tue, 14 Jul 2015 10:58:02 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF1ei-0007hS-Pa for bug-gnu-emacs@gnu.org; Tue, 14 Jul 2015 10:58:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZF1ec-00032h-6s for bug-gnu-emacs@gnu.org; Tue, 14 Jul 2015 10:58:00 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:48840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF1eb-00031E-Q7; Tue, 14 Jul 2015 10:57:54 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NRH00K00G7IS700@a-mtaout21.012.net.il>; Tue, 14 Jul 2015 17:57:52 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NRH00K6CG8FMJ80@a-mtaout21.012.net.il>; Tue, 14 Jul 2015 17:57:52 +0300 (IDT) Date: Tue, 14 Jul 2015 17:57:56 +0300 From: Eli Zaretskii Subject: Info reader fails to follow xrefs to anchors In-reply-to: <87twt7x18d.fsf@gnu.org> To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=), Juri Linkov Message-id: <83y4ii7pmz.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <87615o2l0e.fsf@gnu.org> <83h9p884w2.fsf@gnu.org> <87twt7x18d.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) Redirecting the Emacs part to bug-gnu-emacs; see http://lists.gnu.org/archive/html/bug-texinfo/2015-07/msg00051.html for the related Texinfo discussion. CC to Juri, who made the offending change. > From: ludo@gnu.org (Ludovic Court=C3=A8s) > Cc: bug-texinfo@gnu.org > Date: Mon, 13 Jul 2015 22:16:02 +0200 >=20 > The standalone Info reader in Texinfo 6.0 fails to follow > cross-references to anchors: Following such a link leads to an unre= lated > place in the document. This is a regression compared to Texinfo 5.= 2 > (guix.texi is one example that illustrates the bug.) >=20 > Unfortunately the Emacs Info reader has had the same problem for a = long > time, but I suppose this one should go to bug-emacs? >=20 > That=E2=80=99s with 24.5.1, and I remember experience that with ear= lier > versions too. There are two issues here. One is that Emacs 24.4 introduced a change, as part of fixing bug #14125 (see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D14125), which caused t= he Emacs Info reader to go to the wrong place when it follows cross-references to anchors (as opposed to references to nodes). The other problem is the generous use of UTF-8 encoded characters in guix.info, including in the preamble, which makes Emacs's job even harder, because references in Info files are given in bytes, not characters. The second problem needs an infrastructure, part of which was introduced only recently: how to convert a file byte offset to an Emacs buffer position (which counts characters), accounting correctly for the file's encoding and EOL format. It sounds like we would need the reverse conversion for fixing this present problem, see below. As for the first part: I've read the discussions in bug #14125, and tried playing with the test file provided there, and I must say that = I understand neither the problem nor its solution. The analysis of the problem (see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D14125#11) was this: > Makeinfo 4.13 produced the character positions of indirect subfiles > relative to the beginning of the first node, but Makeinfo 5.0 produ= ces the > positions relative to the beginning of the subfile. The Emacs Info= reader > fails when the distance between the beginning of the subfile and > the beginning of its first node is longer than a thousand character= s. > [...] > The expression (+ (- nodepos lastfilepos) (point)) in `Info-read-su= bfile' > assumes that `lastfilepos' in `Info-read-subfile' is the beginning = of the > first node, so for Info files produced by Makeinfo 4.13 it returns = the > length of the summary segment, but for Makeinfo 5.0 it returns > two lengths of the summary segment. Perhaps I don't understand what this says, but the conclusion sounds incorrect to me. The actual difference between makeinfo 4.13 and makeinfo 5.0 and late= r is that with makeinfo 5 the starting position of the 2nd, 3rd, etc. subfile includes the length of the preamble text that precedes the first node in the subfile. In makeinfo 4, only the beginning of the first subfile included the preamble, and all the rest excluded it= . But that doesn't matter, IMO, because with both versions of makeinfo, if a subfile's beginning is recorded in the tag table as byte positio= n N, the first node in that subfile is also recorded to start at byte position N. Therefore, to find the byte offset of a node/anchor from the beginning of a subfile, one needs to do this: (+ (- nodepos lastfilepos) preamble-length) in both the old and the new versions. To find the length of the preamble, one needs to search from the beginning of the subfile for the start of the first node, and then compute the file's byte number of that position. Therefore, the original code in Info-read-subfile, viz.: (+ (- nodepos lastfilepos) (point)) was an approximation that did TRT for ASCII Info files. It is easy t= o extend this to UTF-8 encoded files: (+ (- nodepos lastfilepos) (position-bytes (point))) Other encodings, as well as DOS end-of-line format, will need a dedicated function similar to filepos-to-bufferpos, but in the reverse direction. (We also need to subtract 1 from the above expression, since we need a zero-based offset.) Juri, do you see any flaws in the above description? I couldn't reproduce the problem reported in bug #14125, so I'm not sure why the fix you installed was even needed, or where my reasoning is wrong. I tried both Emacs 24.3 (for which the bug was filed) and later versions, and they all work correctly with the Info file produced fro= m the Texinfo source attached to that bug report, no matter if I produc= e the Info file with makeinfo 4.13 or makeinfo 5.1 or 6.0. So I'm unsure what problems you saw with the original code in Info-read-subfile. Could you describe those problems in more detail than you did in the bug discussions? Why are these problems invisible when following references to nodes, you ask? Because in that case we search for the node's header line after going to the recorded position. So going to a position that undershoots (which is what that change caused) doesn't do any visible harm. But for references to anchors, we don't have any text to search, so the position where we place the reader should be reasonabl= y exact. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 14 19:19:59 2015 Received: (at submit) by debbugs.gnu.org; 14 Jul 2015 23:19:59 +0000 Received: from localhost ([127.0.0.1]:49362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZF9UU-0003Jf-ST for submit@debbugs.gnu.org; Tue, 14 Jul 2015 19:19:59 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43924) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZF9US-0003JQ-Ix for submit@debbugs.gnu.org; Tue, 14 Jul 2015 19:19:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZF9UM-0000CR-7v for submit@debbugs.gnu.org; Tue, 14 Jul 2015 19:19:50 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:59649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF9UM-0000CN-50 for submit@debbugs.gnu.org; Tue, 14 Jul 2015 19:19:50 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF9UL-0006Ei-CG for bug-gnu-emacs@gnu.org; Tue, 14 Jul 2015 19:19:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZF9UH-00009I-AE for bug-gnu-emacs@gnu.org; Tue, 14 Jul 2015 19:19:49 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:40755 helo=homiemail-a21.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF9UG-000080-Oc; Tue, 14 Jul 2015 19:19:45 -0400 Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 1EC03300080; Tue, 14 Jul 2015 16:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jurta.org; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version: content-type; s=jurta.org; bh=bP3a8ZNDsdhqlaC75wsgDrtM0CQ=; b=k2 VvgamEbHweuLvhApP66UURpn28zkFAf5SuolSpaWm2IAXBzUAPSFgI0uBIZt1h++ mHxymIkIyGwJG8qTob+bbT3obM2xCriXzy1N3PSNLnmzDxZYdD2c6P3udIQbKV5f VQS0YNOU9gJc7wmSuHTaHpJUhDE74oPG0QlceJLJM= Received: from localhost.linkov.net (m213-101-192-95.cust.tele2.ee [213.101.192.95]) (Authenticated sender: jurta@jurta.org) by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id E791C300079; Tue, 14 Jul 2015 16:19:39 -0700 (PDT) From: Juri Linkov To: Eli Zaretskii Subject: Re: Info reader fails to follow xrefs to anchors Organization: LINKOV.NET References: <87615o2l0e.fsf@gnu.org> <83h9p884w2.fsf@gnu.org> <87twt7x18d.fsf@gnu.org> <83y4ii7pmz.fsf@gnu.org> Date: Wed, 15 Jul 2015 02:16:32 +0300 In-Reply-To: <83y4ii7pmz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 14 Jul 2015 17:57:56 +0300") Message-ID: <874ml6s52n.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: Ludovic =?iso-8859-1?Q?Court=E8s?= , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) --=-=-= Content-Type: text/plain > Juri, do you see any flaws in the above description? I couldn't > reproduce the problem reported in bug #14125, so I'm not sure why the > fix you installed was even needed, or where my reasoning is wrong. I > tried both Emacs 24.3 (for which the bug was filed) and later > versions, and they all work correctly with the Info file produced from > the Texinfo source attached to that bug report, no matter if I produce > the Info file with makeinfo 4.13 or makeinfo 5.1 or 6.0. So I'm > unsure what problems you saw with the original code in > Info-read-subfile. Could you describe those problems in more detail > than you did in the bug discussions? I'm attaching here all the files that I used to fix bug#14125, so you could compare the output of different makeinfo versions and see the problem. The command line used to translate Texinfo files was: makeinfo --split-size=2000 test.texi --=-=-= Content-Type: application/zip Content-Disposition: attachment; filename=bug_14125.zip Content-Transfer-Encoding: base64 UEsDBAoAAAAAANwQ70YAAAAAAAAAAAAAAAAOABwAbWFrZWluZm9fNC4xMy9VVAkAAxCWpVX2l6VV dXgLAAEE6AMAAAToAwAAUEsDBBQAAAAIAENnnUIA+0f2iwMAAEMRAAAXABwAbWFrZWluZm9fNC4x My90ZXN0LnRleGlVVAkAAy5EflEclqVVdXgLAAEE6AMAAAToAwAA7VXLjhw3DLzrK3jJZbEexD76 kgkC+AfiYy4cibNDRC1p9VhM/t5FqXd21wH8BXNpdLP5KBZL1D+ayujU5arpnIno6OnTw6f9G28O ht8eHlrn2imf6SIcpLpjk37WKIk3QXTrB/Of5q49Cn2HbY+VFN5FuqOeU+6o4GKuspGWNrZHeh7K FDJs1LQ/EhLj6XNq4rv0UWEKWrR5pReJ5tIkuBmWcqI0tufBG4mORlsOClhbyZVJk9cwEgLQaeQT qpL0VUvcxk9ogjjqDMdDKnd6yXGUzshxsDBJCp9Am+KFASApL9DNpdx6Hah8leoVMZoT+hoxIp/P FSC0URtAXnRHoLlZfNKmSO9mdQ1IQcKI2WYDs3kAQvN/zFLEA4CsfRIU1AH8VUqVCziWapzADQ1b llsHiy6S1sT+A1TSi0aQFDEkZXHvCj3O7BrjPpOdpm0WPI8n5Vkkv6ZvIB6NusJVF9A/QZ7UTJKb 0czeD/Q65gdm0zOht0xBn9B90w1uYXiFx6NNk06RU9CuaLdUliapK2q/toPXIBAePIj78xCjuOKX TlzNLcCzHFpqtzZhuXopwKhQmMkhnzyLx7zIj6JBJ1nQkis1v2gQ8wFAteEIBpi6UetHLLy4yeez epMtUFb7jVqgWtkxZAJANtK2j9wUsqtuUckHM1zYPm36ILnK/MceNZuzUHjItYiBA2XoI3no60Cm 2agnI3rpHLP1iG2gqduJOIE/O4OY/RPUAbCgKE8n62ZJQLeZek0U2saUNMwvSJ2vuokrkb3Y0IFK cHJKtqFhWJQ3DPBNB9xwjlGJrezr39muaVQiZhZGO+xw9TRe5Yze8RF48gPTTqtFywlsTj+3qEni oeN5yCxBY2QmseMo63zLu6PbwGcZQaEnljlzJ/1N9nNtVDF5msOBkNaokTmRVe+iHoCT7R9ilCsK VYgzBfpuJIwFuQoQG803QhbAjXWKEQccFL07Z7OnIvUMTmfYZGqx0mBfYYs47gd3tC1625zuOLds 4SfZX/eFuywv7V8t9HvpVCISfsamjnGleIt7t4iPKQdkyAXJclmp/lcRsx3ugb5phSz/unDpUr9+ xZVB3y9C52n2y3yA39+CbsMHR/Nry3xznFVm6h3Fh/y4QdbLT+a5kj7fb477zXG/Oe43x/3m+NXN se/Vj/v4bbH+ZJ9H9st9s943632z3jfrfbP+erOe/hP3A1BLAwQUAAAACABbZ51CHkM2hVMDAAC+ CwAAGQAcAG1ha2VpbmZvXzQuMTMvdGVzdC5pbmZvLTFVVAkAA11EflEolqVVdXgLAAEE6AMAAATo AwAA7VXLjis1EN37J6glXI0ijWCVDUJIdwdCYviAil2ZlPBr/BiFv+eUuxMyLO4XTCuK3OV6nDp1 3H65aCf8hvRx0HwuT1RbCdNLoNM/lPhvMSu9S+taMv10eP6Rzq2kLWLIVQ/OxdIkkdY+0xO9TWUK BTbqOp6Ik+Dfl9zFDxmzwRS0aveKtNFcugS3wjJK5JneJicSnZ1SCYpSqZbGpNlrmBkBc1DkE6qS jK2WAOtr5uQ46grHnzQe9F7irIOR42BhkjWhPiXFggEgK2+gO6r30WZycpXmFTHoGH3NGJHPlwYQ 8OoTyKvuCLR0i8/a1dKv6hpIrk4YMWk1sJoHIDT/81aKJwBZ+yQTzE3gb1KbXCQHacYJ3NCwZbl3 sNFF0rvYPkBlvWgESRHDUJbHQk8ru8aImRi5O01pFTzPV+VVpNzSo31rlCo33YD+MmzshaR00OzY +4lep70AcR+F0FuhoK/ovmuCG4Sj8NjQnyLnoEPRbm0sXfJQsHtrBzCCRPA/lHi8TUPfGrZ04eo7 4FUOLfV7mx0D8lKBUaEwk0M5eRaPeZGfVYMuskxL0PK7BjEfAFQbjmCAeRi1fsbKG9RyPqs32QJl s23UAtWwMGQCQDbSvo8cwG+qQzugkg9muLDt2PRBchN7ObNHzb5C4SHXKgYOlKGP7KGvA5lmo56M 6E3nmK1HbAdNw07E6ZYg6ivUAbCgqCwn62ZJwGlaqbeJQtuYkob1BqnzVZNQjezFhg5UAr3VYkOz YZWEAbq7DrjjHKMSW9l9dz/Q0KhEzCzMftjh6mnucjaV4SXw4gemnVaLlhPYXH47NVk8dLwOmSXo jMxO7DjKdr7l4eh2KzyDQk8Quc3ctv+TvY26icnTHA4OaY0aWRPZ6l3UA3C27w8xylWFKmQp0A8j YY4dHRAbzXdCNoCJdYkRBxwUPZyzFVWlncGphW1MWYzjDvsWthHHAx/L79xXjXJ8/OTS7yXA8lKq reU6jvRVG2b+64XrEJxl+qse6fug7QfnXhDovuBx7gv9JnkebfEh4HgkPC8XofMy+818gN+fAvDh g6P59c18d/wGzP9D2wB/zAvzH03ebz0Zeqyce/4Yvdp4ePar5PnzKvm8Sj6vks+r5PMq+eZV8i9Q SwMEFAAAAAgAW2edQhJe5RgTAwAADgsAABkAHABtYWtlaW5mb180LjEzL3Rlc3QuaW5mby0yVVQJ AANdRH5RKJalVXV4CwABBOgDAAAE6AMAAO1UyW5UMRC8+yfoM4pGInDKBSEkjgiJ8AE9dk+mhbd4 iYa/p9rvZREHvmCiKMqze6muKvf9WTvhd0gfB82nckO1lTC9BDr+ocS/xU7pSVrXkunT4cNHOrWS towhFz04F0uTRFr7TDf0OJUpFJxR13FDnAR/fcld/JAxG46CVu1eUTZaSJfgVlpGizzT4+REorNT KkHRKtXSmDR7DTMjYQ6KfERXkrH1EmB9yJwcR13p+CONBz2VOOtg1DhYmmRN6E9J8Q8DQFbeQHd0 76PN5OQizStyMDHmmjGini8NIBDVJ5BX3RFo6ZaftauVX901kFycMHLSGmAND0AY/vPWiicA2fgk E8xN4G9Sm5wlB2nGCcIwsFV5mWCji6R3sXuAynrWCJIixFCWt41uVnWNEZoYuTtNaTU8zQfl1aQ8 l8f4NihVbroB/TJM9kJSOmh27P3ErNM+gLiPQpitUNAHTN81IQzGUURs6I+Rc9ChGLc2li55KNh9 HgcwgkTwP5R4PE5D3xqudOHqO+DVDiP1lzE7BPJSgVHhMLNDOXoWD73Iz6pBF1nmJXj5SYNYDACq iSMQMA+j1s9YeYNaTif1ZlugbHaNXqAaJwybAJBJ2nfJAfzZdRgHVPLBDs5sN6Y+SG5iHyf26NlX KiLkUsXAgTLMkT38dSDzbNSjEb35HNp65HbQNOxFHJ8LRH2AOwAWFJUVZNMsCzhNq/SmKLwNlTSs L1idL5qEamQvJjpQCfxWi4lmYpUEAd2LD7jjHaMTW9v9dn/Q8KhEaBZmP+xw9Th3O5vL8BF48YOj nVbLliPYXHE7NVk8fLwemRXojMpO7DnK9r7lzdPt1ngGhZ9gctPcrl9tb1I3MXtawMGhrFEjS5Gt 31k9AGfbP8RoVxWukOVAP4yEOXZ0QGw0vxCyAUysy4x44KDozTtbWVXaCZxa2saU5TjuON/SNuJ4 YFm+c980yt3blUvfS8DJT0HdQF/PXIfgAdOPJk939E0b5H89/VXv6L5U527/yXDv//nZN/PtdTNf N/N1M18383Uz/3czu79QSwMEFAAAAAgAW2edQl7N1OUiAwAADQYAABcAHABtYWtlaW5mb180LjEz L3Rlc3QuaW5mb1VUCQADXUR+USiWpVV1eAsAAQToAwAABOgDAABNVMtuG0cQvO9PpI8JoBCSZRsw L0EQJEAuvlg/0DvTJBuel+YhMCf/uqtnl4wAgdDM9KO6qnpfLtoIf11aP2g65QcqNfvhxNP6H0X+ LnZLb1Kb5kQfD0/PdKo5bhldrnpYlpCrRNLSRnyg16FMPuOOmvYH4ij4dTk1cV36qLjyWrQ5Rdlg IU38MtMSWqQRXwdHEh2NYvaKVrHkyqTJqR8JCaNT4BVdSfrWS4D1nDguHHSm40cqd3rLYZTOqHGw NEka0Z+i4h8GgKS8gW7o3nodcZGrVKfIwcSYa4SAei5XgEBUG0BedEeguVl+0qZWfnZXT3JdhJET 5wBzeADC8H9srXgAkI1PMsDcAP4qpcpFkpdqnCAMA1uV+wQbXSStib0DVNKLBpAUIIayvG/0MKtr CNDEyN1pirPhaZyVZ5N8K4/xbVAqXHUD+mc32TNJbqB5YecGZh12AOLWM2G2TF7PmL5pRBiMo4jY 0K+Bk9euGLdUliapK9i9jQMYXgL470rcX4ehrxVPOnG1HfBsh5HafcwGgZwUYFQ4zOyQV8fioBe5 UdTrJMu8BC+/qReLAUA1cQQCpm7UuhEKb1Dz6aTObAuU1Z7RC1TjhmETADJJ2y45gN9ch3FAJR/s 4sL2YuqD5Cp2OLFDzzZTESHXIgYOlGGO5OCvA5lng65G9OZzaOuQ20BTt41YbwWCnuEOgAVFeQbZ NNMCi8ZZelMU3oZK6ucJVuerRqES2ImJDlQCv5VsoplYOULA5e4DbthjdGJru7/uCw2PSoBmfrTD DlfXsdvZXIaD58kPrnZaLVtWsDnjdmqSOPh4LpkVaIzKi9g6yrbf8m51mzUeXuEnmNw0t+f/bW9S VzF7WsBhQVmjRqYiW7+LOgBO9v0hRruicIVMB7puJIy+owNio/lOyAYwsk4zYsFB0bs9m1lF6gmc WtrGlOUs3HC/pW3EccfH8pflX8QBbj8u98/u709Henr+8undzYcjPT8+fkb8C5/phdcgx+XXW+5v y9fs5UgvufyYidvxH62wyl8XLl3qj6dPnz/sD98EmP39Za/8N67u1ZefUEsDBAoAAAAAAOQQ70YA AAAAAAAAAAAAAAANABwAbWFrZWluZm9fNS4wL1VUCQADHJalVfaXpVV1eAsAAQToAwAABOgDAABQ SwMEFAAAAAgAQ2edQgD7R/aLAwAAQxEAABYAHABtYWtlaW5mb181LjAvdGVzdC50ZXhpVVQJAAMu RH5RKJalVXV4CwABBOgDAAAE6AMAAO1Vy44cNwy86yt4yWWxHsQ++pIJAvgH4mMuHImzQ0QtafVY TP7eRal3dtcB/AVzaXSz+SgWS9Q/msro1OWq6ZyJ6Ojp08On/RtvDobfHh5a59opn+kiHKS6Y5N+ 1iiJN0F06wfzn+auPQp9h22PlRTeRbqjnlPuqOBirrKRlja2R3oeyhQybNS0PxIS4+lzauK79FFh Clq0eaUXiebSJLgZlnKiNLbnwRuJjkZbDgpYW8mVSZPXMBIC0GnkE6qS9FVL3MZPaII46gzHQyp3 eslxlM7IcbAwSQqfQJvihQEgKS/QzaXceh2ofJXqFTGaE/oaMSKfzxUgtFEbQF50R6C5WXzSpkjv ZnUNSEHCiNlmA7N5AELzf8xSxAOArH0SFNQB/FVKlQs4lmqcwA0NW5ZbB4suktbE/gNU0otGkBQx JGVx7wo9zuwa4z6TnaZtFjyPJ+VZJL+mbyAejbrCVRfQP0Ge1EySm9HM3g/0OuYHZtMzobdMQZ/Q fdMNbmF4hcejTZNOkVPQrmi3VJYmqStqv7aD1yAQHjyI+/MQo7jil05czS3Asxxaarc2Ybl6KcCo UJjJIZ88i8e8yI+iQSdZ0JIrNb9oEPMBQLXhCAaYulHrRyy8uMnns3qTLVBW+41aoFrZMWQCQDbS to/cFLKrblHJBzNc2D5t+iC5yvzHHjWbs1B4yLWIgQNl6CN56OtAptmoJyN66Ryz9YhtoKnbiTiB PzuDmP0T1AGwoChPJ+tmSUC3mXpNFNrGlDTML0idr7qJK5G92NCBSnBySrahYViUNwzwTQfccI5R ia3s69/ZrmlUImYWRjvscPU0XuWM3vERePID006rRcsJbE4/t6hJ4qHjecgsQWNkJrHjKOt8y7uj 28BnGUGhJ5Y5cyf9TfZzbVQxeZrDgZDWqJE5kVXvoh6Ak+0fYpQrClWIMwX6biSMBbkKEBvNN0IW wI11ihEHHBS9O2ezpyL1DE5n2GRqsdJgX2GLOO4Hd7Qtetuc7ji3bOEn2V/3hbssL+1fLfR76VQi En7Gpo5xpXiLe7eIjykHZMgFyXJZqf5XEbMd7oG+aYUs/7pw6VK/fsWVQd8vQudp9st8gN/fgm7D B0fza8t8c5xVZuodxYf8uEHWy0/muZI+32+O+81xvznuN8f95vjVzbHv1Y/7+G2x/mSfR/bLfbPe N+t9s943632z/nqznv4T9wNQSwMEFAAAAAgAU2edQpaSG/VYAwAAyQsAABgAHABtYWtlaW5mb181 LjAvdGVzdC5pbmZvLTFVVAkAA05EflEolqVVdXgLAAEE6AMAAAToAwAA7VXLjiNFELzXT5DHZTWy dg9cfEEIaW8gJIYPSFelxym6HlOPkfl7IqvaxsMB8QHTsqzu6nxEREZ1PV+0EX5dWj9oOucnKjWH 4SXQ6S+K/KfYKr1JbZoT/XD4Quea40roctWDc1uuEklLG/GJXocyhYw1atqfiKPg3+fUxHfpo2Ip aNHmFVU3C2loZmkuoUMa8XVwJNHRKOagaBVLrkyavIaRkDA6bXxCV5K+egmgviSOjjed6fiTyp3e 8jZKZ9Q4kOVJ0ggAFBU3DARJeaFulHLrdUQnV6lekQTGIDa2DQV9rkCBqDYAvegOQXOz/KRNrfxs r4HkSsLO5zgZTPZABPY/0urFA5BMAJIB7QYYVClVLpKCVFMFYaBsZe4clmAkrYm9B6qkF90g04Zx KMtjp6dZXbdtn4pbQsXZ8DxelGeTfJMI/I0pFa66I/2p2+AzSW5Q2rH3A2yHPQBy65nALlPQF/Bv GhEG6ygiFvzTxiloV/AtlaVJ6gp9b3yAI8iGCXQl7q/D4NeKVzqBtX20sx04tTvPhhF5KQCpMJk5 Ip88i8fEyI+iQadaZie4+U2DWAwAqo1HMMIEAsn5sRVeUPP5rN6cC5TVXqMXtMYKwygAZENt+9AB /GY80IGWDHNh5cL2ygwAmavYw5k9mraZiwi5FjF00AxEkofFkGrG3fRkUi+zY7weyQ1CITbl063C pi8wCOBCpDyDjM90gdM4a6+hwt+Yk4b5BLvzVaNQ2diLzR2wBJYr2cZm48oRI3R3K3DDZkYntrb7 231Xw6ayYWphNEBfePU0dks7sMdD4CkRlnZlLV1OEHTG7eIk8fDy3GlWoDFKO7E9KWuXy8MGbtZ5 BIWlYHQbu73+x/o27SrmUAs4OJQ1bWTOZPW7qAfgZF8hYrQrCmPINKHvpsLoOzogNp3viiyAkXX6 EbscGj3stZlVpJ4hqqUtqSzHccP6SlvKcccn8zv3TTc5Pn536dccsPKci93LtR/pm1YM/ecLly7Y z/RHOdKnoPV7556R6D7jcu4z/SJpHO3mXcLxSLieL0LnuezX8gFxvwvAh3eBFtfW8j3wP2D+G9oC /L4uln+r8nbjZOhx59zX99mTxsO1HyhfPw6UjwPl40D5OFA+DpT/caD8DVBLAwQUAAAACABTZ51C QTgC1v4CAADlBQAAGAAcAG1ha2VpbmZvXzUuMC90ZXN0LmluZm8tMlVUCQADTkR+USiWpVV1eAsA AQToAwAABOgDAABdVMtqYzkQ3esnutZDME1gNtk0Q0Mvm4bJfEBZKsdF6xU9gufv55R0kzEJwfjq 1uO85OerdsL/kD5Omi/lgWorYXoJdP6XEv8WO6U3aV1Lpj9PX+nSStoNQ256cu6L+6FRnu6H0M8S cPK3+JIDfb9yHdJw/KvJ2xP90NbH3ek/9YmeS3Xu8VOH++PTn3OxNEmPWvtMD/Q6lSkUnFHX8UCc BJ+Y0MUPGRPDOWjV7hUUopV0MLM2l0Enz/Q6OZHo7JRKUHBItTQmzV7DzGiYgyKfsZVk7F0CXV4y J8dRVzs+pPGgtxJnHYwZJ7I+yZoAgJLiCwNBVt6oO+XSR5vJyU2aVzRBXkk0Y8RAXxpQoKpPQK96 QNDSrT9rVxu/1msguZGw8yUtBos9EIH9N9q7eAKSCUAyE+kEgya1yVVykGaqoAyUbcwHhy0YSe9i 74Eq61UjZIrwWVnuNz2s6Rrj4YrbQqW18DJflNeS8i4R+BtTqtz0QPrXsJQVktKhtGPvJ9hOewDk PgqBXaGgL+DfNaEMOVVUbPjnyDnoUPCtjaVLHgp93/kAR5AIB4YSj9dp8FvDK13A+mHtWgdO/YNn h0VeKkAqQmaJKGfP4uEY+Vk16FLL4oSr86ZBrAYA1ewRWJhBIDs/Y+UNtVwu6i25QNnsNXZBa5ww ggJAZmo/TAfw9+CBDrRkhAsnV7ZXFgDI3MQeLuyxtK9eVMitiqGDZiCSPSKGVgtu1LNJvcMOez2a O4RCbS7n9wlRXxAQwIVIZRUZn5UCp2nN3qYi3/BJw3pC3PmmSahG9mK+A5YgcrWYbWZXSbDQfUSB Oy4zNrGtPd4etxoxlQjXwuyAvvHqeR6RdmCPh8BLIhwdylq7nCHoqjvEyeKR5XXTbEBnjHZid1L2 LZe7C9xt8wyKSCHoZru9/j/65nYTS6gVnBzGmjayPNn7ruoBONuvEDHWVUUwZIXQD1NhjgMdEJvO H4psgIl15RG3HBrd3bXVVaVdIKq1bamsx3HH+W7byvHA7/N/UEsDBBQAAAAIAFNnnUIOfIHpmgAA AN0AAAAWABwAbWFrZWluZm9fNS4wL3Rlc3QuaW5mb1VUCQADTkR+USiWpVV1eAsAAQToAwAABOgD AABNjMsKwjAQRffzE85SQUvqo2q2ouDGjfmBtJnaoM2UJIqu+utWrEW4m/s6qrIBO0UKMbGu5Ck2 ns29IIP5C2t9pU+KD/LBssNVIrD0XH8PkZ42ARjB0RnrqYgSBtAslZht//xc4kJssm6t9AWVzm8k Yfx7TuDEhiQqbtp0KURvD9aHiLtKN5F8m66ydV+cqWBnhqYn77tooMMbUEsBAh4DCgAAAAAA3BDv RgAAAAAAAAAAAAAAAA4AGAAAAAAAAAAQAO1BAAAAAG1ha2VpbmZvXzQuMTMvVVQFAAMQlqVVdXgL AAEE6AMAAAToAwAAUEsBAh4DFAAAAAgAQ2edQgD7R/aLAwAAQxEAABcAGAAAAAAAAQAAAKSBSAAA AG1ha2VpbmZvXzQuMTMvdGVzdC50ZXhpVVQFAAMuRH5RdXgLAAEE6AMAAAToAwAAUEsBAh4DFAAA AAgAW2edQh5DNoVTAwAAvgsAABkAGAAAAAAAAAAAAKSBJAQAAG1ha2VpbmZvXzQuMTMvdGVzdC5p bmZvLTFVVAUAA11EflF1eAsAAQToAwAABOgDAABQSwECHgMUAAAACABbZ51CEl7lGBMDAAAOCwAA GQAYAAAAAAAAAAAApIHKBwAAbWFrZWluZm9fNC4xMy90ZXN0LmluZm8tMlVUBQADXUR+UXV4CwAB BOgDAAAE6AMAAFBLAQIeAxQAAAAIAFtnnUJezdTlIgMAAA0GAAAXABgAAAAAAAAAAACkgTALAABt YWtlaW5mb180LjEzL3Rlc3QuaW5mb1VUBQADXUR+UXV4CwABBOgDAAAE6AMAAFBLAQIeAwoAAAAA AOQQ70YAAAAAAAAAAAAAAAANABgAAAAAAAAAEADtQaMOAABtYWtlaW5mb181LjAvVVQFAAMclqVV dXgLAAEE6AMAAAToAwAAUEsBAh4DFAAAAAgAQ2edQgD7R/aLAwAAQxEAABYAGAAAAAAAAQAAAKSB 6g4AAG1ha2VpbmZvXzUuMC90ZXN0LnRleGlVVAUAAy5EflF1eAsAAQToAwAABOgDAABQSwECHgMU AAAACABTZ51ClpIb9VgDAADJCwAAGAAYAAAAAAAAAAAApIHFEgAAbWFrZWluZm9fNS4wL3Rlc3Qu aW5mby0xVVQFAANORH5RdXgLAAEE6AMAAAToAwAAUEsBAh4DFAAAAAgAU2edQkE4Atb+AgAA5QUA ABgAGAAAAAAAAAAAAKSBbxYAAG1ha2VpbmZvXzUuMC90ZXN0LmluZm8tMlVUBQADTkR+UXV4CwAB BOgDAAAE6AMAAFBLAQIeAxQAAAAIAFNnnUIOfIHpmgAAAN0AAAAWABgAAAAAAAAAAACkgb8ZAABt YWtlaW5mb181LjAvdGVzdC5pbmZvVVQFAANORH5RdXgLAAEE6AMAAAToAwAAUEsFBgAAAAAKAAoA kwMAAKkaAAAAAA== --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 15 11:11:11 2015 Received: (at submit) by debbugs.gnu.org; 15 Jul 2015 15:11:12 +0000 Received: from localhost ([127.0.0.1]:50172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZFOL0-0005Lc-Lu for submit@debbugs.gnu.org; Wed, 15 Jul 2015 11:11:11 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33863) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZFOKx-0005LE-Hl for submit@debbugs.gnu.org; Wed, 15 Jul 2015 11:11:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFOKl-0002aT-PE for submit@debbugs.gnu.org; Wed, 15 Jul 2015 11:11:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:60889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFOKl-0002aL-Lu for submit@debbugs.gnu.org; Wed, 15 Jul 2015 11:10:55 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47324) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFOKj-000071-W0 for bug-gnu-emacs@gnu.org; Wed, 15 Jul 2015 11:10:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFOKc-0002Wr-L8 for bug-gnu-emacs@gnu.org; Wed, 15 Jul 2015 11:10:53 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:59575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFOKb-0002WK-OP; Wed, 15 Jul 2015 11:10:46 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NRJ00200AZS0B00@mtaout28.012.net.il>; Wed, 15 Jul 2015 18:09:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NRJ001KMBGFU520@mtaout28.012.net.il>; Wed, 15 Jul 2015 18:09:51 +0300 (IDT) Date: Wed, 15 Jul 2015 18:09:56 +0300 From: Eli Zaretskii Subject: Re: Info reader fails to follow xrefs to anchors In-reply-to: <874ml6s52n.fsf@mail.linkov.net> To: Juri Linkov Message-id: <83k2u178zf.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <87615o2l0e.fsf@gnu.org> <83h9p884w2.fsf@gnu.org> <87twt7x18d.fsf@gnu.org> <83y4ii7pmz.fsf@gnu.org> <874ml6s52n.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: submit Cc: ludo@gnu.org, bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > From: Juri Linkov > Cc: ludo@gnu.org (Ludovic Court=C3=A8s), > bug-gnu-emacs@gnu.org > Date: Wed, 15 Jul 2015 02:16:32 +0300 >=20 > I'm attaching here all the files that I used to fix bug#14125, > so you could compare the output of different makeinfo versions > and see the problem. The command line used to translate > Texinfo files was: makeinfo --split-size=3D2000 test.texi Thanks. I see the problem now. It only happened in makeinfo 5.0 and 5.1, and is fixed since 5.2. Furthermore, it only rears its ugly head if the Texinfo source has an @ifnottex block before the Top node; any other blurbs usually put there, like @copying, @direntry, etc. -- don't trigger the problem even in those 2 versions of makeinfo. Moreover, when this problem happens, it only affects the 1st subfile; the rest have their offsets set correctly. So it's a pretty rare combination of conditions. Therefore, I think we should fix the anchor use case by making the value returned from Info-read-subfile as accurate as possible, and then cater to the problematic output of makeinfo 5.0 and 5.1 by attempting another search for a node with a larger slop value. So any objections to the patch below? It introduces a new infrastructure, and then uses it to get the file byte offset corresponding to the first node on a subfile. --- lisp/international/mule-util.el~0=092015-06-21 06:45:33.000000000= +0300 +++ lisp/international/mule-util.el=092015-07-15 18:00:57.053036400 += 0300 @@ -412,6 +412,79 @@ (decode-coding-region (point-min) (min (point-max) (+ pm = byte)) coding-system t))))))))= )))) +;;;###autoload +(defun bufferpos-to-filepos (position &optional quality coding-syste= m) + "Try to return the file byte corresponding to a particular buffer = POSITION. +Value is the file position given as a (0-based) byte count. +The function presumes the file is encoded with CODING-SYSTEM, which = defaults +to `buffer-file-coding-system'. +QUALITY can be: + `approximate', in which case we may cut some corners to avoid + excessive work. + `exact', in which case we may end up re-(en/de)coding a large + part of the file/buffer. + nil, in which case we may return nil rather than an approximation.= " + (unless coding-system (setq coding-system buffer-file-coding-syste= m)) + (let* ((eol (coding-system-eol-type coding-system)) + (lineno (if (=3D eol 1) (1- (line-number-at-pos position)) = 0)) + (type (coding-system-type coding-system)) + (base (coding-system-base coding-system)) + byte) + (and (eq type 'utf-8) + ;; Any post-read/pre-write conversions mean it's not really= UTF-8. + (not (null (coding-system-get coding-system :post-read-conv= ersion))) + (setq type 'not-utf-8)) + (and (memq type '(charset raw-text undecided)) + ;; The following are all of type 'charset', but they are + ;; actually variable-width encodings. + (not (memq base '(chinese-gbk chinese-gb18030 euc-tw euc-ji= s-2004 + korean-iso-8bit chinese-iso-8= bit + japanese-iso-8bit chinese-big= 5-hkscs + japanese-cp932 korean-cp949))= ) + (setq type 'single-byte)) + (pcase type + (`utf-8 + (setq byte (position-bytes position)) + (when (null byte) + (if (<=3D position 0) + (setq byte 1) + (setq byte (position-bytes (point-max))))) + (setq byte (1- byte)) + (+ byte + ;; Account for BOM, if any. + (if (coding-system-get coding-system :bom) 3 0) + ;; Account for CR in CRLF pairs. + lineno)) + (`single-byte + (+ position -1 lineno)) + ((and `utf-16 + ;; FIXME: For utf-16, we could use the same approach as = used for + ;; dos EOLs (counting the number of non-BMP chars instea= d of the + ;; number of lines). + (guard (not (eq quality 'exact)))) + ;; In approximate mode, assume all characters are within the + ;; BMP, i.e. each one takes up 2 bytes. + (+ (* (1- position) 2) + ;; Account for BOM, if any. + (if (coding-system-get coding-system :bom) 2 0) + ;; Account for CR in CRLF pairs. + lineno)) + (_ + (pcase quality + (`approximate (+ (position-bytes position) -1 lineno)) + (`exact + ;; Rather than assume that the file exists and still holds= the right + ;; data, we reconstruct its relevant portion. + (let ((buf (current-buffer))) + (with-temp-buffer + (set-buffer-multibyte nil) + (let ((tmp-buf (current-buffer))) + (with-current-buffer buf + (save-restriction + (widen) + (encode-coding-region (point-min) (min (point-ma= x) position) + coding-system tmp-buf))) + (1- (point-max))))))))))) =0C (provide 'mule-util) =20 --- lisp/info.el~0=092015-06-16 10:34:22.000000000 +0300 +++ lisp/info.el=092015-07-15 18:08:58.585385400 +0300 @@ -1217,6 +1217,18 @@ =09=09 (goto-char pos) =09=09 (throw 'foo t))) =20 + ;; If the Texinfo source had an @ifnottex block of tex= t + ;; before the Top node, makeinfo 5.0 and 5.1 mistakenl= y + ;; omitted that block's size from the starting positio= n + ;; of the 1st subfile, which makes GUESSPOS overshoot + ;; the correct position by the length of that text. S= o + ;; we try again with a larger slop. + (goto-char (max (point-min) (- guesspos 10000))) +=09 (let ((pos (Info-find-node-in-buffer regexp strict-case))) +=09=09(when pos +=09=09 (goto-char pos) +=09=09 (throw 'foo t))) + (when (string-match "\\([^.]+\\)\\." nodename) (let (Info-point-loc) (Info-find-node-2 @@ -1553,10 +1565,13 @@ (if (looking-at "\^_") =09(forward-char 1) (search-forward "\n\^_")) - ;; Don't add the length of the skipped summary segment to - ;; the value returned to `Info-find-node-2'. (Bug#14125) (if (numberp nodepos) -=09(- nodepos lastfilepos)))) + ;; Our caller ('Info-find-node-2') wants the (zero-based) by= te + ;; offset corresponding to NODEPOS, from the beginning of th= e + ;; subfile. This is especially important if NODEPOS is for = an + ;; anchor reference, because for those the position is all w= e + ;; have. +=09(+ (- nodepos lastfilepos) (bufferpos-to-filepos (point) 'exact))= ))) =20 (defun Info-unescape-quotes (value) "Unescape double quotes and backslashes in VALUE." From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 16 18:51:09 2015 Received: (at 21055) by debbugs.gnu.org; 16 Jul 2015 22:51:09 +0000 Received: from localhost ([127.0.0.1]:51458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZFrzg-0000cj-G4 for submit@debbugs.gnu.org; Thu, 16 Jul 2015 18:51:08 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:34512 helo=homiemail-a17.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZFrzd-0000ca-GL for 21055@debbugs.gnu.org; Thu, 16 Jul 2015 18:51:06 -0400 Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 11D802B206D; Thu, 16 Jul 2015 15:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jurta.org; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version: content-type; s=jurta.org; bh=Zh7SYl5n1CkRfZlVzckOUpLNmlA=; b=kI jfz5PLsQfO4PMCKmz44Ia88UDeSdVq0+R/SJTwRrCKXxhwjmv24F/GEnEQMfUXh0 nhJEHCYZs9IwxOQbWe/GW66+ItDFMpe0c7gMW4Cp2tTFir73N2XN5lLPbvCxWMs2 IRQ/rTned3MIyFEB0i20evw4a77Pb2dt1rqfPDEiI= Received: from localhost.linkov.net (m212-119-140-128.cust.tele2.ee [212.119.140.128]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id A8E882B206A; Thu, 16 Jul 2015 15:51:02 -0700 (PDT) From: Juri Linkov To: Eli Zaretskii Subject: Re: Info reader fails to follow xrefs to anchors Organization: LINKOV.NET References: <87615o2l0e.fsf@gnu.org> <83h9p884w2.fsf@gnu.org> <87twt7x18d.fsf@gnu.org> <83y4ii7pmz.fsf@gnu.org> <874ml6s52n.fsf@mail.linkov.net> <83k2u178zf.fsf@gnu.org> Date: Fri, 17 Jul 2015 01:49:19 +0300 In-Reply-To: <83k2u178zf.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 15 Jul 2015 18:09:56 +0300") Message-ID: <87d1zryaz4.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21055 Cc: ludo@gnu.org, 21055@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > So any objections to the patch below? It introduces a new > infrastructure, and then uses it to get the file byte offset > corresponding to the first node on a subfile. I tested your patch on the output of makeinfo versions 4.13, 5.0 and the newest version 6.0, and it works flawlessly. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 18 06:24:41 2015 Received: (at 21055-done) by debbugs.gnu.org; 18 Jul 2015 10:24:41 +0000 Received: from localhost ([127.0.0.1]:52558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZGPIO-0004el-Tl for submit@debbugs.gnu.org; Sat, 18 Jul 2015 06:24:41 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:46710) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZGPIL-0004eW-QW for 21055-done@debbugs.gnu.org; Sat, 18 Jul 2015 06:24:38 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NRO00M00HNJ1F00@mtaout24.012.net.il> for 21055-done@debbugs.gnu.org; Sat, 18 Jul 2015 13:16:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NRO00L03HUQZH10@mtaout24.012.net.il>; Sat, 18 Jul 2015 13:16:02 +0300 (IDT) Date: Sat, 18 Jul 2015 13:24:44 +0300 From: Eli Zaretskii Subject: Re: Info reader fails to follow xrefs to anchors In-reply-to: <87d1zryaz4.fsf@mail.linkov.net> X-012-Sender: halo1@inter.net.il To: Juri Linkov Message-id: <83fv4l69w3.fsf@gnu.org> References: <87615o2l0e.fsf@gnu.org> <83h9p884w2.fsf@gnu.org> <87twt7x18d.fsf@gnu.org> <83y4ii7pmz.fsf@gnu.org> <874ml6s52n.fsf@mail.linkov.net> <83k2u178zf.fsf@gnu.org> <87d1zryaz4.fsf@mail.linkov.net> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21055-done Cc: ludo@gnu.org, 21055-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Juri Linkov > Cc: ludo@gnu.org, 21055@debbugs.gnu.org > Date: Fri, 17 Jul 2015 01:49:19 +0300 > > > So any objections to the patch below? It introduces a new > > infrastructure, and then uses it to get the file byte offset > > corresponding to the first node on a subfile. > > I tested your patch on the output of makeinfo versions 4.13, 5.0 > and the newest version 6.0, and it works flawlessly. Thanks, pushed to master. From unknown Sun Jun 22 07:53:05 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 15 Aug 2015 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator