From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#47109: eldoc.el: Allow custom separator between documentations in the echo area Date: Sat, 13 Mar 2021 14:35:38 +0000 Message-ID: References: <87o8foaxdc.fsf@tcd.ie> <871rcj6tjw.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6434"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mathieu Marques , 47109@debbugs.gnu.org To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 13 15:36:36 2021 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 1lL5Nb-0001aL-Se for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Mar 2021 15:36:35 +0100 Original-Received: from localhost ([::1]:37964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lL5Na-0000JT-Rb for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Mar 2021 09:36:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lL5N5-0000JD-L1 for bug-gnu-emacs@gnu.org; Sat, 13 Mar 2021 09:36:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47821) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lL5N3-0005CR-TA for bug-gnu-emacs@gnu.org; Sat, 13 Mar 2021 09:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lL5N3-0007Aj-PW for bug-gnu-emacs@gnu.org; Sat, 13 Mar 2021 09:36:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Mar 2021 14:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47109 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 47109-submit@debbugs.gnu.org id=B47109.161564615827560 (code B ref 47109); Sat, 13 Mar 2021 14:36:01 +0000 Original-Received: (at 47109) by debbugs.gnu.org; 13 Mar 2021 14:35:58 +0000 Original-Received: from localhost ([127.0.0.1]:59367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lL5N0-0007AS-Ck for submit@debbugs.gnu.org; Sat, 13 Mar 2021 09:35:58 -0500 Original-Received: from mail-il1-f172.google.com ([209.85.166.172]:38127) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lL5Mx-0007AD-TE for 47109@debbugs.gnu.org; Sat, 13 Mar 2021 09:35:57 -0500 Original-Received: by mail-il1-f172.google.com with SMTP id f10so5304554ilq.5 for <47109@debbugs.gnu.org>; Sat, 13 Mar 2021 06:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uGU9H0mbawhRgLPxTBI2C0++43tzTSMVlIdVKD9CNQ4=; b=Ay/vuWsGAlhvksciDXRBf6J4gTw6Q34VC7mKSJqIiDEw0nOBMPkez3VaSKRX9HFZWO HlB+UDzP6wU7l0erv0Z/boPEDErykwX9gxT0uOnzLKkfU8C6dh5Am6mFnSkbm1o09oQQ lQsWSZBKXq3RNoHhSVvgrnqLT6CyM+dRFcaoxH7c+4DV1BU2uv4nJM0ozMczMbmLQ5m7 6m0kAD6lo7zIMHoDj5eCKJA1v4crVWV/lOpN5n3LXuZB0kd8u5Ryerfo2nYyIwerI3Y1 Hnm/Ib0xo4wYKGdD7YqutQqcm2myVso31QxaPwS0eAZmejft+4ARMEohEPlDSuG7qTek QPow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uGU9H0mbawhRgLPxTBI2C0++43tzTSMVlIdVKD9CNQ4=; b=eewfLDP48qUg6vVOX0SK7X9P164jOgzrxLRDrnFCrw1j6KyPhtATRkohhuXhUXWA1e sqELmbV1dUoIIYxBWdghGmD0yXZSoVE8AXNDj0ddqlH9kUk5nYyuJr+IZdvUwpBbCIev UdfP6XBvXsdkoGiV1Xv11jUTmFGbBICuyrxIVe0bvFlWBD3uSoLs1csqsVA3KZASroK6 w8CwT19fM01UrEdmlXwogsx0GE9A61+KX/IX6yDJdZUaOfYosJ4oZ2a8mN0qpiIaCEhh vgVjPbDT8gtHnPkiNWs2CiEzpv34X22fML4VNadfD4P22WFZAZsPoewLDowQwoDZA4EW BzPg== X-Gm-Message-State: AOAM533ry5cDcsORpvgdtbTMte3xn4+e+/xOvrUsx5OjOJ+OdFPaHd+O m1zb95MM9b1WXJc3q3xmZ+pmZD3ZuDyLawT1aHs= X-Google-Smtp-Source: ABdhPJx6sNYAILSpVb6nMYQelrvM2U1Gf1Nc/dam5XxHcgCD0jUfKb82Rhu9Kwf9T4IQXmsprCIvLCWbYPWwncS9ggs= X-Received: by 2002:a92:da48:: with SMTP id p8mr6137318ilq.137.1615646150261; Sat, 13 Mar 2021 06:35:50 -0800 (PST) In-Reply-To: <871rcj6tjw.fsf@tcd.ie> 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" Xref: news.gmane.io gmane.emacs.bugs:202264 Archived-At: Thank you both, Personally, I'm fine with the first whitespace patch, as long as it's only whitespace. I've had a look at the simple second patch and while such a thing is indeed mostly innocuous (and potentially very useful), I wonder if we shouldn't be a bit more ambitious. There are bound to be many more sophisticated strategies for composing items of documentation and it doesn't make sense, to me, for Eldoc to add two new user-visible endpoints to what is already a long, ad-hoc-tailored list of legacy endpoints just for the relatively limited technique of "composition by concatenation". For example, in elisp-mode, one plan could be have the composition of the multiple documentation items collected by the elisp eldoc backends resultin a documentation buffer that looks very much like what you get from describe-symbol or C-h o in form, function and content. That potentially needs a much more sophisticated composition strategy that is specific to the elisp-mode major mode. So I'd argue for a a new eldoc-render-documentation function. That should give the user enough freedom to do these basic separators but doesn't bloat the API with limited micro-switches (at least not yet, we can add such things in the main eldoc.el eventually). eldoc-render-documentation could be a generic function given: - the items of documentation to render - the target "canvas", which may be a buffer (the eldoc buffer), the echo area, or some other object (a tooltip? some user-defined documentation container?) It should output things in a buffer, or maybe a string. There seems be bit of an overlap here with `eldoc-display-functions', but it is rather a healthy relation, in my view. Those functions should be more concerned with managing access and visibility of the target canvas than actually rendering the text, which may be specific to a major-mode and a potentially orthogonal task. So each element in `eldoc-display-functions` should call `eldoc-render-documentation` passing it suitable arguments to produce the final text. Jo=C3=A3o