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: Wed, 28 Oct 2020 09:38:29 +0000 Message-ID: <874kmeofl6.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> <87tuujr6sd.fsf@gmail.com> <803c87c2-7d60-5997-2247-85d3e62e3d2c@gmx.at> <87a6w7puuz.fsf@gmail.com> <64831acc-996e-51d7-ce6f-b667a6334e3c@gmx.at> <87imavo322.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="10063"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: larsi@gnus.org, 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 Wed Oct 28 10:39:11 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 1kXhvD-0002V9-C8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Oct 2020 10:39:11 +0100 Original-Received: from localhost ([::1]:45344 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXhvC-0001x5-A8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Oct 2020 05:39:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53980) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXhv4-0001wo-Md for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 05:39:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35656) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kXhv4-0006G4-DT for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 05:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kXhv4-0001YS-Am for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 05:39:02 -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: Wed, 28 Oct 2020 09:39:02 +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.16038779205949 (code B ref 43609); Wed, 28 Oct 2020 09:39:02 +0000 Original-Received: (at 43609) by debbugs.gnu.org; 28 Oct 2020 09:38:40 +0000 Original-Received: from localhost ([127.0.0.1]:47202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXhui-0001Xt-6V for submit@debbugs.gnu.org; Wed, 28 Oct 2020 05:38:40 -0400 Original-Received: from mail-wm1-f41.google.com ([209.85.128.41]:36423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXhug-0001Xe-7C for 43609@debbugs.gnu.org; Wed, 28 Oct 2020 05:38:39 -0400 Original-Received: by mail-wm1-f41.google.com with SMTP id e2so4090755wme.1 for <43609@debbugs.gnu.org>; Wed, 28 Oct 2020 02:38:38 -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=4MFCDijM9LBiSIssnhsikSUkv0kbHlgFOXerdJEhnSQ=; b=gKxLpkHUha1Jo02x06xhdd+U+axkzF92idpyOx6gQ/XQ1JHj80V6h9Nw1JCkPH9Fgc dCkxFPtu1QtMlPyOTaDMaARQcDk40yJdNqD0yu2uRicMNZqkAlaU1+bwWqn/yAhn7H/t yVYGgoF5Zd83LZOuYQlT7PgFFB3zgzVqDNAhgFTRqx71spPEaYUxENOsoxau7ktiHPO+ vV8bohwb8RZ6sCdDpwauo/D/CLZcYA5mDqiXmsCdDPk87AK6kXCs+IEAjIgeI/TXaO26 9+MqHIN4KzJ9pQIn4HVeMEARI5Udf/pt7DQ6bvCs9ACQWaBtkTGFehwEkr2BNLc8L2It +iMw== 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=4MFCDijM9LBiSIssnhsikSUkv0kbHlgFOXerdJEhnSQ=; b=BYlglRPBvP1zDGmqLyg6hpmf+3CvS0GVKy0RwafDsLPWVP4qe8M35Xmb2VIkDd/vrJ d//tc109QZdI8wKJ8bi3Ab+LP5KwmmVf8nhdgH7qI7MDYqy9vwOmXdCzjFgx0D6nC5ZP aUc8rAQ+n2PMPZj5SrkvZpliuis1MxdWBI9nx1VU+xZZyOldsu0HjMFMoW3n3oUcoQhn RiJUTIX3HFjh3e2ISsqzoZP0sxvOhCMwiWi0+DpkC7Sk2DqHx+1ZMIdLyNR1mWmViWsH 1AEDHQhOMZvHHDxCZhd0ovW9tMG0UwRP0m6jaqL/8tSoDjJTfewxYkjo3SnHNv2LzN7h 0adQ== X-Gm-Message-State: AOAM531QgI5brURn6Tyya4xVM9BnmS9ymtSoWvcFRPfzM6CSLU5mpNH2 BrN05GRvGCxmzLgQQeNniPg= X-Google-Smtp-Source: ABdhPJz9sRNip9364gGVAmrRn9AgaxterhsH7/RJEKY5YgO5zR7I9DaQsOmzY57VxGSLXyKofHgs3Q== X-Received: by 2002:a7b:c113:: with SMTP id w19mr7539143wmi.25.1603877912340; Wed, 28 Oct 2020 02:38:32 -0700 (PDT) Original-Received: from krug (89-180-148-164.net.novis.pt. [89.180.148.164]) by smtp.gmail.com with ESMTPSA id q6sm5777184wma.0.2020.10.28.02.38.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2020 02:38:31 -0700 (PDT) In-Reply-To: (martin rudalics's message of "Wed, 28 Oct 2020 09:39:43 +0100") 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:191832 Archived-At: martin rudalics writes: > But how can I get that default mentioned in "By default, > =E2=80=98eldoc-documentation-function=E2=80=99 returns the first document= ation string > produced by the =E2=80=98eldoc-documentation-functions=E2=80=99 hook."? It's still the default. But I see your confusion. Instead of: "returns the first documentation string produced ..." It should say: "computes the first documentation string produced" Or even: "arranges for the first documentation string produced ... to be displayed to the user" These things are, of course, equivalent from the POV of the user as long as you're not calling eldoc-documentation-function, the variable. This is also shows what async does: If doc string are to be produced asynchronously, then by definition eldoc-documentation-function cannot return it as a Lisp return value. >> But there's still something I don't understand: in your original >> martin-tooltip.el library you didn't call this e-e-d-f function, did >> you? AFAIU, you did: >> >> (funcall eldoc-documentation-function) >> >> or am I mistaken? > > You're not mistaken. My expectation was and would be that in elisp mode > 'eldoc-documentation-function' returned the value produced by > 'elisp-eldoc-documentation-function' and IIUC that can't be done any > more because it would break you compatibility code for that variable. Yes but now _you're_ mistaken. You _can_ still set `e-d-f` to `e-e-d-f` and that still works. But the default in Elisp mode is to make use of `e-d-f`'s (also known as eldoc-documentation-strategy) superior capabilities that allow it to report more than one type of doc per symbol, for example. >> So you'd have to change your code anyway to now call >> elisp-eldoc-documentation-function, right? So, if you're going to >> change it, why not change it to the new, better alternatives I have >> presented? > > Because at the time I'm there I have other concerns than remember how I > did that. I didn't follow this at all, but it seems highly personal and related to how your mental memory works, so I'm not going to insist. I just think a code change is a code change and I've given you the code. > With your changes, I cannot simply customize a variable to get the old > behavior back. I have to do some extra coding somewhere. I'd say customize a variable and do some extra (trivial) coding are comparable in effort, especially when someone else is handing you that code. >> of Emacs in those drives/servers/hosts where an incompatible >> martin-tooltip.el lives? I just don't understand why updating an Emacs >> executable is somehow feasible in that setup but updating an Elisp >> library that it depends on isn't. > Because I expect Emacs to be backward-compatible (.elc included). We've gone through that, and I've noted that your library was calling a variable (not a functino) meant to be called by a library. That's relying on an implementation detail, and Emacs's implementation changes over time. >> I'm again confused: If you contribute your code to Emacs, then whenever >> you update Emacs (which seems to be what you're concerned about) the >> facilities you need will just be there. > > But my .emacs won't know. But your .emacs has to know about "custom-set-variables" too right? Why are you OK with that? >> As promised, a patch for you to review (and maybe Lars as well?) > > Thank you. If it also provided an option so the only thing I'd have to > do is to customize that, things would become for me as simple as the > present situation permits, I think. You can: (add-hook 'emacs-lisp-mode-hook (lambda () (setq-local eldoc-documentation-function 'elisp-eldoc-documentation-function))) Somewhere in your .emacs. Or in your martin-tooltip.el library. Frankly, I think a customization variable for this type of obsoleted behaviour is too much. I get that deleting elisp-eldoc-documentation-function was getting rid of a non '--' function that, even though: - it's quite questionable that third parties should be relying on it, - noone in the core Emacs relied upon it, - and noone in GNU Elpa relied upon it, - and not even your private martin-tooltip.el code relied upon it, So we bring that e-e-d-f back, OK seems it _could_ help you make the adaptation of martin-tooltip.el, even though I've given you already multiple better adaptations of that same file that you reject for some reason that I can't comprehend. But changing the _value_ of eldoc-documentation-function (the variable) was _not_ a backward incompatible change (I've explained at length why, I think). So a confusing user option here to save you those three lines of trivial code seems too much. Jo=C3=A3o