bug#43609: 28.0.50; eldoc-documentation-function [vs new eldoc-display-functions]

[martin rudalics <rudalics@gmx.at>]

 > I'm not sure I follow 100%, I'm just thinking that whatever process you
 > use to update Emacs in those machines

It's git pull nowadays and used to be some cvs or bzr command in the old
days.

 > you can also use to update
 > eldoc-tooltip.el.

You're right that I probably should write some sort of script but the
process is highly individual depending on the state of the machine that
crashed, the state of the disk I'm recovering from and the state of the
machine I'm moving too.  Restoring a crashed XP partition, for example,
is a pain these days since I cannot connect to XP from newer Debians via
the network.

 >> ‘eldoc-documentation-function’
 >>       This variable holds the function which is used to retrieve
 >>       documentation for the item at point from the functions in the hook
 >>       ‘eldoc-documentation-functions’.  By default,
 >>       ‘eldoc-documentation-function’ returns the first documentation
 >>       string produced by the ‘eldoc-documentation-functions’ 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.

But how can I get that default mentioned in "By default,
‘eldoc-documentation-function’ returns the first documentation string
produced by the ‘eldoc-documentation-functions’ hook."?

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

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

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

The absence of "--" is a sign that neither semantics nor signature of
that function, primitive, variable or macro should ever change unless
explicitly marked as obsoleted (for some time) or as an incompatible
change (which inherently means that there was some force majeure that
caused us to do that).

For example, in the fix of Bug#44080 Clemens preserved the old behavior
of 'fit-frame-to-buffer' and provided the now desired behavior by
introducing a new function 'fit-frame-to-buffer-1' that now becomes the
default value called by 'resize-mini-frames'.  While this is clumsy and
changes the default behavior of Emacs by calling another function when
the size of the minibuffer changes, it both (1) guarantees that
'fit-frame-to-buffer' behaves right as before and (2) allows to get the
previous, now undesired, behavior triggered by minibuffer size changes
by customizing 'resize-mini-frames' to 'fit-frame-to-buffer'.

With your changes, I cannot simply customize a variable to get the old
behavior back.  I have to do some extra coding somewhere.

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

Because I expect Emacs to be backward-compatible (.elc included).

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

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

martin