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#43609: 28.0.50; eldoc-documentation-function [vs new eldoc-display-functions] Date: Sat, 24 Oct 2020 16:18:58 +0100 Message-ID: <87tuujr6sd.fsf@gmail.com> References: <2e610c3f-6e5f-c7dd-af2e-aeb5e20d8664@gmx.at> <87r1qjjppu.fsf@gmail.com> <3fa6b315-7fc0-06ee-81e9-b68d164aec1b@gmx.at> <87a6x7jf9a.fsf@gmail.com> <874knbi0jc.fsf_-_@gmail.com> <87362tggvl.fsf@gmail.com> <87d01vem7z.fsf@gmail.com> <17da3e99-d4fc-a603-baa3-4180d612af41@gmx.at> <878scie5ti.fsf@gmail.com> 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="29109"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Yuan Fu , 43609@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 24 17:20:10 2020 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 1kWLL0-0007SJ-Bk for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Oct 2020 17:20:10 +0200 Original-Received: from localhost ([::1]:53648 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWLKz-00024k-3j for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Oct 2020 11:20:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWLKs-00024Z-H8 for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2020 11:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50990) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kWLKs-0001RA-6d for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2020 11:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kWLKr-0001yo-Vz for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2020 11:20:01 -0400 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, 24 Oct 2020 15:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43609 X-GNU-PR-Package: emacs Original-Received: via spool by 43609-submit@debbugs.gnu.org id=B43609.16035527527548 (code B ref 43609); Sat, 24 Oct 2020 15:20:01 +0000 Original-Received: (at 43609) by debbugs.gnu.org; 24 Oct 2020 15:19:12 +0000 Original-Received: from localhost ([127.0.0.1]:34303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWLK3-0001xg-Vh for submit@debbugs.gnu.org; Sat, 24 Oct 2020 11:19:12 -0400 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:33548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWLK0-0001xR-Pd for 43609@debbugs.gnu.org; Sat, 24 Oct 2020 11:19:11 -0400 Original-Received: by mail-wr1-f47.google.com with SMTP id b8so6266604wrn.0 for <43609@debbugs.gnu.org>; Sat, 24 Oct 2020 08:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=XKp/YYVBI5N/EcuUyKQc4mE5ykx1462yekjg6eOqI9Y=; b=dlemW8Iem4wk9E6QMiWNSHY+YTaeAsAN4ejWpFoFX4teFMPFg3DITjkMgvjrr/Dd4H uzfqoqx9FzSplsW+S+7XSMferVr0pdPywb4FEZy6w3+xRgKEO2UfVRTDFne/SnMhXr9p RDg6XZgskctBBM1Nmv/KA7kvNk0j9TfD8RKU37MwRaC9JfHnq3s9L+ocCA2fxtLQ1fPP WLCd46/bXgOEW2h9SvWeVf41sl+XvWloOdzUa8IwdzUBurcI0qSJAAcG1EbfLh/VBGfw m/w7IqA3MV7/UoozgIJRKmzxEhODiOqOX9AQbIJJHdO1CIRud7ZJjWenxnXD82np/Q0Y JKBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=XKp/YYVBI5N/EcuUyKQc4mE5ykx1462yekjg6eOqI9Y=; b=V5GA7IQ422MvLMxz5oaCvH3eCg4w0dTUXszG7s1XhskCxhBRW9ywMhaNlCPQ0+3/TK luMYckwG8LPcATWhYfO7rOLzCpnmnDNJOq1sA2fIPJ3WWBMJDqaVijWt2h3Os4Dc9Ilq WIoibFjdYGzknpUIMU2S97t/Id+zjRDczb6cHfdkDDdQR+Y2K0dzVS2Li+t1uv3ccPvs PeMCtl0Gb564OUUD5bOo4DfPSZHGp+f7hkBTTXKXS/kmst2xr/Rgjyvn+IM1WZHyKj6v 54ArkANeFb5PuAR4/FlJLXhzeXiOHQ5em60B4gSLtQKPjQjFiPdKmRw9eV3gp5YKuRf9 9LIg== X-Gm-Message-State: AOAM5315jw+r8nK/jKV3sritYKXcIOvRRxuNOT1IImi4w6VeG/4sNOFM +SymWw9FxKToOU4IkT2ILP0= X-Google-Smtp-Source: ABdhPJzzgoSjZN1VrpfFM8FOY002SB/rrlx7cyHxc1Roftoi8anA/hObpwdEAYLDnqoVPa5oqGGV2w== X-Received: by 2002:adf:f246:: with SMTP id b6mr8103200wrp.111.1603552742758; Sat, 24 Oct 2020 08:19:02 -0700 (PDT) Original-Received: from krug ([89.180.147.56]) by smtp.gmail.com with ESMTPSA id u133sm11439211wmb.6.2020.10.24.08.19.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Oct 2020 08:19:01 -0700 (PDT) In-Reply-To: (martin rudalics's message of "Fri, 9 Oct 2020 10:03:31 +0200") 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:191430 Archived-At: Hi martin, Sorry for taking so long to reply. I've been busy. martin rudalics writes: > Meanwhile, please provide the compatibility layer you earlier promised > with > > But if you really insist , it's a very easy function to bring back I > would say (in fact the function I gave you earlier is probably more > useful generalization of it). > > so we can close this bug. > > Ideally, this would render your earlier changes backward-compatible and > make the obsoletion declaration for 'eldoc-documentation-function' clean > and follow our usual practice. As I explained, this is impossible. Let's recap: * eldoc-documentation-function is a variable exposed by eldoc.el meant to be set, not called, by libraries. Many libraries set it in a way that, when called without the proper context from within eldoc.el's internals, it doesn't make any sense. Such libaries are long-standing such as SLIME, Elpy, etc, and have existed for a long time. So, because your use case wasn't ever a valid use of that variable to begin with, I don't see the case for any backward-iccompatibility claim. * As I said, it's possible to write a eldoc-get-me-the-string function (not a variable) with the semantics that you want. This is what I meant by "if you insist". By that I meant there would have to be good reason for it. But is there? The use case you gave me was cleanly solved by relying on eldoc-display-functions, a feature which I'll push very shortly to master. So, while this _can_ be done, I don't think it's a priority, because there's no clear use case for it. > The downside of this approach is obviously that we would have to keep > the old definitions of 'elisp-eldoc-documentation-function' and its > colleagues around for a while. So if you think that removing these old > definitions immediately is crucial for future development, please > provide some substitute function and mention it in the doc-string of > 'eldoc-documentation-function(s)'. Let's say eldoc-get-me-the-string function is written: then there is no need to bring back these definitions. Your library calls eldoc-get-me-the-string if it finds it (which it presumably will in Emacs 28), and (brokenly) calls eldoc-documentation-function in other Emacs versions. In Emacs 28 your library will work OK will all documentation producers and in Emacs <=3D 27 it will not, but it will work with Elisp and C++ which appear to be your priorities. But, again, is the previous exercise really needed? I very much doubt it. You asked, and I provided, a modificaiton of your library so that it works in Emacs 28 _without_ this hypothetical eldoc-get-me-the-string. I showed you that all that is needed is a new element in eldoc-display-functions. If you want to make that library (again, brokenly) compatible to Emacs <=3D 27, you must merely check the version and use the previous technique. Surely you can make that happen yourself, it's a simple "if" statement. But a much better alternative, in my opinion, is to use the code I gave you and create a robust package that works correctly in Emacs >=3D 26.3. How? You make use of the fact the latest ElDoc in master is now _also_ available in GNU ELPA and you install that.. This means that even in Emacs 26.3 you can use your tooltip thing for Elisp and C++ and so would other people, for those modes and many others. As to the implementation of this solution, it's a simple case of adding this line: ;; Package-Requires: ((emacs "26.3") (eldoc "1.xx.0")) to the martin-tooltip.el file I gave you earlier, and then using the package.el system to package it. Alternatively, if you don't want to make a package, just 'M-x package-install eldoc' in Emacs >=3D 26.3 should bring in the latest eldoc. xx is the version of eldoc that will contain the new eldoc-display-functions development. Best regards, Jo=C3=A3o