unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: "João Távora" <joaotavora@gmail.com>
Cc: Yuan Fu <casouri@gmail.com>, 43609@debbugs.gnu.org
Subject: bug#43609: 28.0.50; eldoc-documentation-function [vs new eldoc-display-functions]
Date: Tue, 27 Oct 2020 10:58:55 +0100	[thread overview]
Message-ID: <803c87c2-7d60-5997-2247-85d3e62e3d2c@gmx.at> (raw)
In-Reply-To: <87tuujr6sd.fsf@gmail.com>

 > * 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.

Let's disagree on the backward incompatibility issue.  As a rule, Emacs
changes have always tried to not alter the signatures of functions in a
way that makes previously written calls invalid but I'm not very eager
to argue about that.

For me the sad fact remains that I will now have to change all these
calls on my 50-some Winchester and USB partitions where I have Emacs
installed, whenever I plug in or reactivate any of them and the
respective error message pops up rendering the actual session invalid.

Something you could have avoided by keeping a clean separation of the
old behavior of 'eldoc-documentation-function' on the one side and the
new behavior of 'eldoc-documentation-functions' on the other.  Please
everybody keep in mind for future changes to avoid introducing such
incompatible behavior.  If there is a function definition and that
function is not clearly marked as internal (via the usual two slashes),
please keep the signature and the semantics intact so users can rely on
it behaving as intended until that function has been declared obsolete
for a sufficient long time.

 > 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 <= 27 it will not, but it will work
 > with Elisp and C++ which appear to be your priorities.

I still have to make the change in all copies of my library I intend to
run.  While this may look like a minor issue to you, it would make Emacs
in the long term unusable for me, if such changes were introduced on a
regular basis.

 > 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 <= 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 >= 26.3.
 > How?  You make use of the fact the latest ElDoc in master is now _also_
 > available in GNU ELPA

Since I don't use any package archives and do not require them, this is
not a practical option for me.

 > 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 >= 26.3 should
 > bring in the latest eldoc.
 >
 > xx is the version of eldoc that will contain the new
 > eldoc-display-functions development.

Thanks, martin





  parent reply	other threads:[~2020-10-27  9:58 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25  8:46 bug#43609: 28.0.50; eldoc-documentation-function martin rudalics
2020-09-26 18:34 ` Dmitry Gutov
2020-09-27  8:30   ` martin rudalics
2020-09-29 11:20     ` Dmitry Gutov
2020-09-29 15:09       ` martin rudalics
2020-09-29 15:23         ` Dmitry Gutov
2020-09-30  8:14           ` martin rudalics
2020-09-30  8:50             ` Dmitry Gutov
2020-09-30 14:37 ` João Távora
2020-09-30 17:33   ` martin rudalics
2020-09-30 18:22     ` João Távora
2020-10-01  8:40       ` martin rudalics
2020-10-01  9:23         ` João Távora
2020-10-03 19:15         ` bug#43609: 28.0.50; eldoc-documentation-function [vs new eldoc-display-functions] João Távora
2020-10-05  8:35           ` martin rudalics
2020-10-05  9:29             ` João Távora
2020-10-06  8:23               ` martin rudalics
2020-10-06  9:29                 ` João Távora
2020-10-07  8:36                   ` martin rudalics
2020-10-07  8:40                     ` João Távora
2020-10-07  9:36                     ` João Távora
2020-10-08  8:22                       ` martin rudalics
2020-10-08  8:27                         ` João Távora
2020-10-09  8:03                           ` martin rudalics
2020-10-24 15:18                             ` João Távora
2020-10-26 14:12                               ` João Távora
2020-10-27  9:59                                 ` martin rudalics
2020-10-27  9:58                               ` martin rudalics [this message]
2020-10-27 15:11                                 ` João Távora
2020-10-27 18:05                                   ` martin rudalics
2020-10-27 19:56                                     ` João Távora
2020-10-28  8:39                                       ` martin rudalics
2020-10-28  9:38                                         ` João Távora
2020-10-31  8:01                                           ` martin rudalics
2020-10-28  9:17                                       ` Lars Ingebrigtsen
2020-10-28  9:54                                         ` João Távora
2020-10-30 22:51                                           ` João Távora
2020-10-31  8:02                                             ` martin rudalics
2020-10-23  2:37           ` Yuan Fu
2020-10-24 17:09             ` João Távora
2020-10-31 13:07               ` Basil L. Contovounesios

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=803c87c2-7d60-5997-2247-85d3e62e3d2c@gmx.at \
    --to=rudalics@gmx.at \
    --cc=43609@debbugs.gnu.org \
    --cc=casouri@gmail.com \
    --cc=joaotavora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).