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: Tue, 27 Oct 2020 19:56:53 +0000 Message-ID: <87imavo322.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> 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="40431"; 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 Tue Oct 27 20:58: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 1kXV6g-000AQE-Gd for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Oct 2020 20:58:10 +0100 Original-Received: from localhost ([::1]:58684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXV6f-0002Xj-If for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Oct 2020 15:58:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54758) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXV6Y-0002XU-Bl for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2020 15:58:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34414) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kXV6Y-0000Ng-2k for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2020 15:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kXV6Y-00068W-1B for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2020 15:58: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: Tue, 27 Oct 2020 19:58: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.160382862523520 (code B ref 43609); Tue, 27 Oct 2020 19:58:01 +0000 Original-Received: (at 43609) by debbugs.gnu.org; 27 Oct 2020 19:57:05 +0000 Original-Received: from localhost ([127.0.0.1]:45960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXV5d-00067G-9l for submit@debbugs.gnu.org; Tue, 27 Oct 2020 15:57:05 -0400 Original-Received: from mail-wr1-f53.google.com ([209.85.221.53]:42643) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXV5a-00066l-PH for 43609@debbugs.gnu.org; Tue, 27 Oct 2020 15:57:03 -0400 Original-Received: by mail-wr1-f53.google.com with SMTP id j7so3249125wrt.9 for <43609@debbugs.gnu.org>; Tue, 27 Oct 2020 12:57:02 -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=XqTh5GEu+YN/PQb7DumWvJSKBtag0itAh5sFfrz4Aqw=; b=eszm7TVb/1OPTwdMm6cml0Z/HTZXEftS1NiLsB3owSsugX3ThCcf1tnEZPToPSKp3D 44Rs6HipxdXhcJueTN0gki2gHP/0yFPGw9YYedZ5I4+uxazbhqZL9Ok8oWnf1mcLHvf/ nZI6ci7Qst4BwpfGBaRNAEPiDjrLPeTcO0Lj/XJJ2nadBgsq9DWJFH38cpSWljDAOpl+ 3rixQ0O5/Op6p6sALMc0VkqGCKyogUyYN0ui7fPULOxX8nITYRczwa2XbNtepcrgyLhH y6I8AiB9RWKyteQLLQJPx7bBa2S9ay1uRcv5BqB6UfZrB6CrB2bAen0J+ejtho36ZRq0 b1cw== 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=XqTh5GEu+YN/PQb7DumWvJSKBtag0itAh5sFfrz4Aqw=; b=UBYleR3tDyfd1PeQsAiwWLtW1p2vstZZkHOjgXkPWY5Uei1xvryqhBvbmXiJ8WcBRz oFwAisG+hQnut7jyHUhjLqCC9u8DC2f1NSZXfBaRjQEFrK1Mgd5Tzj1gKNMANLk8WNMH BB4oUFVS+Wxfm0Jl2EXdknIySCgBCvlJw8RQOu5edMbI4TNMllB2p6RimvVt03aZ1qCs 4Csm4v5qNQWvpFYvfGN+7foDGo1SsFhYTskkdMVd5Krg1uy3D8NjadwdsaVZEALq5jV9 3e9wvm5FCh+JvuURZGLpEPH7UKhR8IG5y1sV1mInSzkVKs4gWAKmJaYHNZIlrBuK5kX3 46Wg== X-Gm-Message-State: AOAM533ywnwgiMJruGOdHbEybk7iTeXMcNPpMuQ2RqLqViwJjAx9mvc3 rstfgk663DAhQCI+60vzcQA= X-Google-Smtp-Source: ABdhPJyhKL9zYrEV/OgwSajmdAA6Oio0RaUbK7otXnxjYPL1VBYAHVpvG6ZXFXq36ea1xgItX15gUA== X-Received: by 2002:adf:8bdd:: with SMTP id w29mr5139534wra.276.1603828616678; Tue, 27 Oct 2020 12:56:56 -0700 (PDT) Original-Received: from krug ([89.180.148.164]) by smtp.gmail.com with ESMTPSA id x6sm3414796wmb.17.2020.10.27.12.56.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2020 12:56:55 -0700 (PDT) In-Reply-To: <64831acc-996e-51d7-ce6f-b667a6334e3c@gmx.at> (martin rudalics's message of "Tue, 27 Oct 2020 19:05:37 +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:191778 Archived-At: [Lars, I'm CC'ing you specifcally since there's a patch to review at the end.] martin rudalics writes: >> I'd like to help you, but I don't understand: are you updating Emacs to >> master in all 50 of those drives? Do you do this 50 times? By hand? >> Why can't you update your eldoc-tooltip.el in the process? > > Every year I experience around two or three crashes among my machines > which run various operating systems ranging from Windows XP to Windows > 10 and old stable to unstable Debian. When a HD drive crashes, I try > to recreate the prior state by plugging in an older disk or copy the > contents of that older disk into a new one. Thereafter, I usually > update my Emacs repositories reusing my older libraries. If I also have > to update my libraries, I'm ending up in Augean stables. I'm not sure I follow 100%, I'm just thinking that whatever process you use to update Emacs in those machines you can also use to update eldoc-tooltip.el. > Then I fail to understand why my old code stopped working after your > changes. On the version of master I'm currently using here it's even > documented in the Elisp manual as > > =E2=80=98eldoc-documentation-function=E2=80=99 > This variable holds the function which is used to retrieve > documentation for the item at point from the functions in the hook > =E2=80=98eldoc-documentation-functions=E2=80=99. By default, > =E2=80=98eldoc-documentation-function=E2=80=99 returns the first doc= umentation > string produced by the =E2=80=98eldoc-documentation-functions=E2=80= =99 hook. And these things are true, still today, as far as I know. What I meant is that the link between eldoc-documentation-function and eldoc-documentation-functions was already established. You were arguing for some conceptual separation between these two variables and I noted that they were already interconnected. >> If "function definitions" were at stake, I would certainly agree with >> you. But they're not. > > Here 'elisp-eldoc-documentation-function' is a function defined in > elisp-mode.el. IIUC this function has gone now. Ah right, then I misunderstood: you're talking about _that_ function. That is indeed a function. I thought you were talking about eldoc-documentation-function, the variable, since that seems~ to have been the original problem. But what you're requesting seems to be the functionally the martin() function I gave you earlier, right? (defun martin () "CAUTION: Only works in default Emacs Lisp mode or modes with all-sync docstring generating functions. If some functions calls the callback afterwards, that result is discarded." ...) So you'd like it to be called elisp-eldoc-documentation-function, and put in elisp-mode.el, right? That _could_ be done, I guess, and I've attached a patch at the end of this message. 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? 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? Regardless, here's my take on '--': The presence of '--' clearly specifies something to be an internal implementation detail. But that's not the same as taking the absence of '--' as a sign that something is an "external" function. The '--' convention is relatively recent, and programmers had been using internal details before the convention existed. This was one of them. >> If you are going to update Emacs to master in N servers, you might as >> well update your library in those N servers. If you're updating it by >> hand, then this doesn't seem like a tremendous extra effort to expend. >> If you're using a script, just put the library update in that script. I >> personally use Git to good effect for this: push once, pull many times. > > This is not something I do once to be done for ever. It's something > that I usually have to do in a troublesome situation where I have to > recover from a previous crash and I'm trying to make some system run > again. I can't afford to plug in all sorts of hard disk drives in order > to make them future-proof. But isn't the problem that you've somehow built or placed a new version 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. >> Alternatively, and perhaps even better, you're invited to contribute >> your library to Emacs (or GNU ELPA). Then you'll just have to update >> Emacs, using your preferred method. > > I'd still have to update each of my .emacs and install the respective > calls for each version of Emacs I might use there. 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. Jo=C3=A3o As promised, a patch for you to review (and maybe Lars as well?) diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index eed73f5791..f133635ec1 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -1411,6 +1411,30 @@ elisp--eldoc-last-data or argument string for functions. 2 - `function' if function args, `variable' if variable documentation.") =20 +(defun elisp--documentation-one-liner () + (let* (str + (callback (lambda (doc &rest plist) + (setq str + (format "%s: %s" + (propertize (prin1-to-string + (plist-get plist :thing)) + 'face (plist-get plist :fac= e)) + doc))))) + (or (progn (elisp-eldoc-var-docstring callback) str) + (progn (elisp-eldoc-funcall callback) str)))) + +(defalias 'elisp-eldoc-documentation-function 'elisp--documentation-one-li= ner + "Return Elisp documentation for the thing at point as one-line string. +This is meant as a backward compatibility aid to the \"old\" +Elisp eldoc behaviour. Consider variable docstrings and function +signatures only, in this order. If none applies, returns nil. +Changes to `eldoc-documentation-functions' and +`eldoc-documentation-strategy' are _not_ reflected here. As such +it is preferrable to use ElDoc's interfaces directly.") + +(make-obsolete 'elisp-eldoc-documentation-function + "use ElDoc's interfaces instead." "28.1") + (defun elisp-eldoc-funcall (callback &rest _ignored) "Document function call at point. Intended for `eldoc-documentation-functions' (which see)."