From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#68970: 30.0.50; Info.el: Info-url-alist should support format-sequence that encodes "Top" node as "index" Date: Fri, 09 Feb 2024 09:02:49 +0200 Message-ID: <8634u2w25i.fsf@gnu.org> References: <87fry44bz6.fsf@posteo.de> <867cjgz5rm.fsf@gnu.org> <87bk8s3usi.fsf@posteo.de> <86le7wxc3e.fsf@gnu.org> <8734u352rm.fsf@posteo.de> <86bk8rxyia.fsf@gnu.org> <87ttmi3ar3.fsf@posteo.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22087"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68970@debbugs.gnu.org To: Mekeor Melire Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 09 08:04:10 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rYKvf-0005US-Tn for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 09 Feb 2024 08:04:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rYKvQ-0003lt-AT; Fri, 09 Feb 2024 02:03:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rYKvL-0003ku-P4 for bug-gnu-emacs@gnu.org; Fri, 09 Feb 2024 02:03:47 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rYKvL-0007Fx-Fw for bug-gnu-emacs@gnu.org; Fri, 09 Feb 2024 02:03:47 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rYKva-0006gc-0w for bug-gnu-emacs@gnu.org; Fri, 09 Feb 2024 02:04:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Feb 2024 07:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68970 X-GNU-PR-Package: emacs Original-Received: via spool by 68970-submit@debbugs.gnu.org id=B68970.170746219525580 (code B ref 68970); Fri, 09 Feb 2024 07:04:01 +0000 Original-Received: (at 68970) by debbugs.gnu.org; 9 Feb 2024 07:03:15 +0000 Original-Received: from localhost ([127.0.0.1]:40399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rYKup-0006eU-8S for submit@debbugs.gnu.org; Fri, 09 Feb 2024 02:03:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rYKun-0006e4-Bz for 68970@debbugs.gnu.org; Fri, 09 Feb 2024 02:03:14 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rYKuS-00078j-Mp; Fri, 09 Feb 2024 02:02:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Jn+HPqm2IY6dAXr2Rb22v1VuWbNIS/pZ2VmkwiGRgZ8=; b=Gj9e5poli/66 jFEDrKOhtfDQO9zuwifnbGtjqn8iZG32hHe/gK5BUjLzmVmVKz+UBsXu5gJ5IkmuYcO5GXk1fS3hm QqPn0uuk4i5M75mRWTVcBmheVTzD4ptDzNKBpTFLiFprucnZtjVx3p+e1nR06K4NwvxRsZ8FFTB0e OpDUMM7RuxL5KSyL4K1b9xT3Z6UZ5LeiZNDLaxAKm1umy0hg/8ez1Z/EoFVAYjM31zFvV0Gk+wQhg bCmPFwDQBEXiSuB35R10iXP1aoucih1tgFofg3C/xobRjTeZS+zE1cezoEsvxB8DQDtJfzlcz2quS ozNyP/keLx3uVsv90+V1MQ==; In-Reply-To: <87ttmi3ar3.fsf@posteo.de> (message from Mekeor Melire on Thu, 08 Feb 2024 20:20:18 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279680 Archived-At: > From: Mekeor Melire > Cc: 68970@debbugs.gnu.org > Date: Thu, 08 Feb 2024 20:20:18 +0000 > > But let me try to explain what I really meant. Let's look at a node > named "Summary". Texinfo will generate a "Summary.html" file for it. For > this file, some webservers do not allow to omit the .html suffix when > requesting it via HTTP. For example: > > https://sourceware.org/gdb/current/onlinedocs/gdb/Summary > -> error 404, not found > > https://sourceware.org/gdb/current/onlinedocs/gdb/Summary.html > -> works fine > > Thus, for the GDB manual, the user would consider to use > > https://sourceware.org/gdb/current/onlinedocs/gdb/%e.html > > because %e does not contain the .html-suffix and because the webserver > requires to keep the .html-suffix for non-index-HTMLs. But that > URL-specification would not work in case of the "Top"-node because %e > will be substituted with the empty string "" in that case, thus > yielding: > > https://sourceware.org/gdb/current/onlinedocs/gdb/.html > -> error 404, not found > > The user would now understand that, with the restrictions of the current > implementation of the feature, they must define a custom function and > use it as URL-specification for the GDB-manual. > > > > Another idea would be to let users specify two URL-SPECs: One for the > > > Top-node; another for non-Top nodes. > > > > I'd prefer this latter alternative. > > Having thought about this idea again, it seems unnecessary because we > know that the "Top" node is always translated as "index.html". Here's a > quote from (info "(texinfo) HTML Xref Node Name Expansion"): > > A special exception: the Top node (*note The Top Node) is always > mapped to the file 'index.html', to match web server software. > > As a result, I'd like to propose yet another approach. Currently, the > implementation on the master branch offers %m (manual-name), %n (raw > node-name) and %e (URL-encoded node-name without .html-suffix). Let's > add the format-sequence %E that does include the .html-suffix. In case > of the Top-node, it'll be the empty-string "", i.e. it'll behave just > like %e in that case. Why should %e omit the .html extension in the first place? What problems will we cause if we make %e include the .html extension when that is required, and omit it when it isn't (like when converting the "Top" node)? AFAICS, the use of %e in Emacs 29 doesn't add the .html extension to the produced URLs, but would producing the .html extension from %e cause any problems with the GNU manuals we had in Info-url-alist in Emacs 29? Do we know of any package which augments Info-url-alist with specs that use %e.html? > | node | %e | %E | > |-------+-------+------------| > | "Top" | "" | "" | > | "Foo" | "Foo" | "Foo.html" | > > The gnu.org webserver is configured to allow omission of the > .html-suffix. We can thus use the %e format-sequence: > > | URL-specification | https://gnu.org/s/emacs/manual/html_node/emacs/%e | > |----------------------+------------------------------------------------------| > | URL for "Top" node | https://gnu.org/s/emacs/manual/html_node/emacs/ | > | URL for "Intro" node | https://gnu.org/s/emacs/manual/html_node/emacs/Intro | > > The sourceware.org does not allow to omit the .html-suffix. But it > allows to omit "index.html". We can thus use %E: > > | URL-specification | https://sourceware.org/gdb/current/onlinedocs/gdb/%E | > |------------------------+----------------------------------------------------------------| > | URL for "Top" node | https://sourceware.org/gdb/current/onlinedocs/gdb/ | > | URL for "Summary" node | https://sourceware.org/gdb/current/onlinedocs/gdb/Summary.html | > > I think with these format-sequences we'd cover a lot of cases. I'm asking why cannot we make %e behave like your proposed %E?