From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Vincent_Bela=EFche?= Subject: =?UTF-8?B?UkU6IGluZm8gVVJMIMKrIG9wZW4gYXQgcG9pbnQgwrsgcGF0Y2g=?= Date: Wed, 27 Jun 2018 17:39:33 +0000 Message-ID: References: , <83h8lstfwh.fsf@gnu.org> , <8336xct8v0.fsf@gnu.org> , <83y3f4rpjt.fsf@gnu.org> , <83vaa7simv.fsf@gnu.org>, , <83muvhr4zp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <83muvhr4zp.fsf@gnu.org> Content-Language: fr-FR List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sender: "Emacs-devel" To: Eli Zaretskii Cc: "emacs-orgmode@gnu.org" , "brandelune@gmail.com" , "emacs-devel@gnu.org" List-Id: emacs-orgmode.gnu.org Hello Eli, Concerning the patch, I understood that you agree with it provided that it is upgraded to mention the change in the etc/NEWS file. So I did that & pushed the change. Concerning your point =AB=A0Modularity doesn't mean each module must be standalone and self-contained=A0=BB, I agree, and I did not say that there would be anything wrong for e.g. browse-url.el to use a utility function defined elsewhere. Modules are supposed to interact with each other, and that implies that they cannot be fully standalone. However, modulary means that one should observe some functional split: any package, to be called a package, should have in its documentation some terms of reference saying its purpose and listing what functions it accomplishes. While the purpose of the info package is not primarily url manipulation, I had suspected that this sort function was encompassed by the package providing the browse-url function, and that is why I stated that it would be a better modularity if info was relying on a function provided elsewhere --- which indeed is the opposite statement as saying that info has to be standalone and self-contain, and as such re-invent the wheel of url manipulation by itself. Maybe my mistake was however to assume that 'elsewhere' would be best in the same package as that providing 'browse-url', but anyhow, I stand on my point that keeping some URL format specific "\\(?:f\\(?:ile\\|tp\\)\\|https?\\)://" regexp within the the Info-follow-nearest-node is not very good from a modularity point of view. BTW, the 'browse-url-url-at-point' is not documented by a docstring, so can we assume that it is usable outside browse-url ? Anyway, looking at the code I realized that the real work of grabbing the URL is delegated to the thingatpt package, so my suggestion would be that info should also use thingatpt. Probably it would be even better with something like the following construct to remove info URI from those allowed, as they would better be handled from the info browser itself: (let* ((uri-schemes (copy-sequence thing-at-point-uri-schemes)) =A0=A0=A0=A0=A0=A0 (info-uri (car-safe (member "info:" uri-schemes))) =A0=A0=A0=A0=A0=A0 (thing-at-point-uri-schemes (delq info-uri uri-schemes))= ) =A0=A0=A0=A0=A0=A0 (thing-at-point 'url t)) OK, the info browser does not directly knows about info URL, so some additional work is needed to catch them too. To me this is a real corner case scenario to refer to a document inside a Texinfo docuemnt via an info URL: that would mean the document is available only in info format, ie has not be published in Texinfo. I am not even sure that such document exists. Aren't info URL meant only to refer to info document from document written with something else than Texinfo ? =A0 V. De : Eli Zaretskii Envoy=E9 : mardi 26 juin 2018 16:34 =C0 : Vincent Bela=EFche Cc : emacs-orgmode@gnu.org; brandelune@gmail.com; emacs-devel@gnu.org Objet : Re: info URL =AB open at point =BB patch=20 =A0 > From: Vincent Bela=EFche > CC: "emacs-devel@gnu.org" > Date: Tue, 26 Jun 2018 05:47:04 +0000 >=20 > My point is that for a modular design, the same package that provides > the browse-url function, should also provide some match-url-at-point-p > predicate, e.g. There is such a function: browse-url-url-at-point. But in general, I don't agree with your assertion: there's nothing wrong for, e.g., browse-url.el to use a utility function declared somewhere else.=A0 Modularity doesn't mean each module must be standalone and self-contained.