From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Y. E. via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#53205: 28.0.90; [PATCH] GNU ELPA: Provide more control over linked documentation Date: Fri, 14 Jan 2022 13:11:07 +0200 Message-ID: References: Reply-To: "Y. E." Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3710"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yet@ego.team, 53205@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 14 12:20:42 2022 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 1n8KdM-0000kg-8S for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jan 2022 12:20:40 +0100 Original-Received: from localhost ([::1]:50786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n8KdL-0000YL-AW for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jan 2022 06:20:39 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39538) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8KV3-0007vQ-IO for bug-gnu-emacs@gnu.org; Fri, 14 Jan 2022 06:12:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42836) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n8KV0-0004XT-3N for bug-gnu-emacs@gnu.org; Fri, 14 Jan 2022 06:12:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n8KUz-0008KN-Mt for bug-gnu-emacs@gnu.org; Fri, 14 Jan 2022 06:12:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Y. E. Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jan 2022 11:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53205 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 53205-submit@debbugs.gnu.org id=B53205.164215867331939 (code B ref 53205); Fri, 14 Jan 2022 11:12:01 +0000 Original-Received: (at 53205) by debbugs.gnu.org; 14 Jan 2022 11:11:13 +0000 Original-Received: from localhost ([127.0.0.1]:35739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8KUC-0008J5-Ma for submit@debbugs.gnu.org; Fri, 14 Jan 2022 06:11:12 -0500 Original-Received: from out1.migadu.com ([91.121.223.63]:10769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8KUA-0008Iw-54 for 53205@debbugs.gnu.org; Fri, 14 Jan 2022 06:11:11 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ego.team; s=key1; t=1642158668; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to; bh=yi4ZKa7yyaJlsOnGC5mjW8GUPP94Ej/vuEB/LVantRs=; b=hZVOvzgTkUB2p7svjKi/IKPL1bK0x0r/7E4YAwmoRssbxswD9nmwiE21RTQ2soKeSYiq7N 5AKbEwBIPCd7iyJ2hvWdU3r1gIQTBnHLmVsi2JnHyJ736CJFSich3PtmyQ7pvVo+IymxR7 dDrVbCpSb5ns3OSLfaQLANj2+rjDv2M= In-Reply-To: (message from Stefan Monnier on Thu, 13 Jan 2022 10:08:13 -0500) X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: ego.team 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" X-ACL-Warn: , Y. E. Xref: news.gmane.io gmane.emacs.bugs:224195 Archived-At: > Stefan Monnier writes: > Ah... yes, this is indeed a serious problem with the current code. > But we should fix it rather than disable the generation of the > HTML manual. > [ Note that the problem also applies to Org manuals, and to the > `:readme`s. ] I'm aware of the issues reported at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53069 (though the second example images are loaded fine with my setup). I looked at it because of the images load issue coincidence. It seemed to me that changes of a different type than discussed here would be required for that bug. > >> My initial idea for fixing this issue was to add a property >> ':doc-asset', which could be configured to '(FROM . TO)' directories >> names, then used for moving images to the 'archive-devel/doc/company/' >> folder, as shown below: > > That sounds like a good plan. After getting back to this plan, appears there's one more issue for which I don't see a good strategy to handle. In the final part of the 'elpaa--html-build-doc' function, it creates a symlink to the actual HTML file; this symlink is displayed at the package page. Naturally, putting images the suggested way ('doc-assets' diff) works fine for the actual HTML file, but not for the symlinked. Creating a symlinked directory, with the name(s) only one particular package needs, in the shared '/doc/' directory doesn't look like a good idea to me. Neither does requiring packages to comply with some naming for the ELPA needs only. Any advice on which approach could be suitable to handle this? > I'd still much prefer to get the "local HTML doc" working better. This sounds good to me. Thinking about improving images output for Company local HTML doc, may it become possible to allow adding small quantity per-package page styles directly to the ELPA repository? Having an HTML "package-name wrapper" could allow doing something like: #pkg-company img { max-width: 300px; }