From: Dmitry Gutov <dgutov@yandex.ru>
To: "João Távora" <joaotavora@gmail.com>
Cc: 41531@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
andreyk.mad@gmail.com
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Sun, 5 Jul 2020 00:27:20 +0300 [thread overview]
Message-ID: <5d768a69-3574-10c5-e80a-8ab77ec60462@yandex.ru> (raw)
In-Reply-To: <87tuynsdp6.fsf@gmail.com>
On 04.07.2020 14:48, João Távora wrote:
>> Unsurprisingly, I object to this approach. We should have better async
>> support in multiple Emacs facilities, and that means standardizing on
>> some particular async primitives and functions that can manipulate
>> them. There is no need to release support for ad-hoc async values (you
>> didn't like mine, so it's only fair play that I object to yours) when
>> we can transition to full futures right away.
>
> I haven't seen a consistent plan "for transitioning to futures".
Do you want to see the patch based on your code? It's the only
"transition" I meant here.
If you have other questions, please ask.
> All
> I've seen is (complicated, IMO) ideas on how to avoid the
> callback-calling style by hiding the callback in an object.
Hiding is absolutely not the point.
> I've seen
> little argument or discussion of what futures are supposed to do or fix
> or improve.
I think I have described at length the very simple idea of what it is
supposed to improve: provide a standard primitive and a library of
composition/manipulation functions that would make these operations
simpler. Which can be used in Emacs core, and in clients of the various
facilities and expose future-based interfaces.
> And I've seen no feedback from the author of what seems to
> be the most promising futures library, aio.el which uses the
> generator.el library, to provide, presumably, more elegant
> "language-level" futures (i.e. futures that aren't only hiding the
> callback in some other object).
I'm very curious to know Christopher's opinion myself. Based on my
experience, this will result in a much longer, protracted discussion, if
it will result in one at all.
You seem to be in a hurry to get this in for some reason, but I'm fine
with waiting a little more, if we get a better result.
> Despite that, I've stated here repeatedly, tiringly: In principle, I
> don't object to futures at all. I just think it has to be a
> thought-through change. Propose your library to emacs-devel and let's
> iterate it there.
If you think emacs-devel will bring more feedback, no problem.
>> I'll get into a little more detail in the more full review, tonight or
>> tomorrow, but for now my impression is that, in the absence of such
>> standard library and async manipulation functions, you decided to
>> implement them specially in Eldoc.
>
> Of course, and that's what engineering is about. For the most trivial
> of changes X there is _always_ a refactoring R that will make
> implementing X and a possible Y and Z much simpler, more elegant, more
> "meta". Knowing where to stop is what this game is about. In this
> case, there is only a vision what Y and Z might be, and a foggier vision
> of how bad/good design decisions in R might affect them.
The thing about refactoring, is it doesn't change observable behavior.
Refactoring would keep the stable interface (and e.g. reuse future-based
utility functions under the covers).
Whereas the improvement I would like to see here, would change it. So
it's not something that could be simply moved to backlog.
And as I intent to explain later, I believe you will need
future-manipulating functions inside eldoc client code anyway, for best
user experience. So we might as well bite the bullet and introduce
futures at the API level.
> So I fixed the real, actual problem in Eldoc using the async paradigm
> that is widely used in Emacs and most widely understood by programmers
> of all (most?) trades: callbacks.
Please recall how you rejected my proposal along the same lines.
And it's fine. We can do better.
> And, again, for the nth time, there is nothing in my code that prevents
> your -- or someone else's -- "futures" library to be the nec plus ultra
> of async in Emacs. But, in the meantime, I won't let you make these
> Eldoc changes hostage to your predilection for futures.
"won't let you" is not exactly how things work here. We usually try hard
to reach a consensus.
In any case, I have considered this for some time, and my arguments for
"let's work on this some more" won't be limited to futures-vs-callbacks.
> It's quite a
> legitimate inclination, of course, it musn't be needlessly put it in the
> way of other's work.
I agree that there are improvements to be made in documentation-related
code (whether it's in Eldoc, or not), and I also think that you might
not be going far enough in some respects.
But the problem you seem to be urgent to fix (having eldoc-message
called from client code) is not so terrible that we can't wait until the
future-related discussion at least has had a chance to happen.
next prev parent reply other threads:[~2020-07-04 21:27 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 17:04 bug#41531: 27.0.91; Better handle asynchronous eldoc backends João Távora
2020-05-25 23:52 ` Dmitry Gutov
2020-05-26 1:21 ` João Távora
2020-05-26 13:57 ` Dmitry Gutov
2020-05-26 16:03 ` João Távora
2020-05-26 19:14 ` Dmitry Gutov
2020-05-26 20:00 ` João Távora
2020-05-27 21:14 ` Dmitry Gutov
2020-05-27 22:13 ` João Távora
2020-05-27 23:35 ` Dmitry Gutov
2020-05-27 23:57 ` João Távora
2020-05-26 2:38 ` Stefan Monnier
2020-05-26 11:22 ` João Távora
2020-05-26 14:53 ` Stefan Monnier
2020-05-26 15:19 ` João Távora
2020-05-26 15:56 ` Stefan Monnier
2020-05-26 16:26 ` João Távora
2020-05-26 17:39 ` Stefan Monnier
2020-05-26 18:49 ` João Távora
2020-06-03 2:45 ` Stefan Monnier
2020-06-03 18:07 ` João Távora
2020-06-03 20:22 ` Stefan Monnier
2020-06-03 20:36 ` João Távora
2020-06-03 21:21 ` Stefan Monnier
2020-06-05 11:26 ` João Távora
2020-06-03 21:28 ` Dmitry Gutov
2020-06-06 1:57 ` Dmitry Gutov
2020-05-26 13:32 ` Dmitry Gutov
2020-05-26 16:56 ` João Távora
2020-06-03 18:56 ` bug#41531: 28.0.50; proper Eldoc async support João Távora
2020-06-04 16:20 ` Andrii Kolomoiets
2020-06-04 18:22 ` Dmitry Gutov
2020-06-04 19:00 ` Andrii Kolomoiets
2020-06-05 22:53 ` João Távora
2020-06-05 11:00 ` João Távora
2020-06-05 17:50 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-06-05 23:25 ` João Távora
2020-06-05 23:28 ` João Távora
2020-06-11 11:11 ` Andrii Kolomoiets
2020-06-30 11:31 ` bug#41531: 27.0.91; Better handle asynchronous eldoc backends João Távora
2020-07-04 7:45 ` Eli Zaretskii
2020-07-04 9:21 ` João Távora
2020-07-04 9:31 ` Eli Zaretskii
2020-07-04 9:37 ` João Távora
2020-07-04 9:44 ` Eli Zaretskii
2020-07-04 11:00 ` João Távora
2020-07-04 21:06 ` Dmitry Gutov
2020-07-04 23:12 ` João Távora
2020-07-07 0:43 ` Dmitry Gutov
2020-07-07 10:58 ` João Távora
2020-07-07 14:18 ` Dmitry Gutov
2020-07-07 14:34 ` João Távora
2020-07-05 12:03 ` João Távora
2020-07-05 15:09 ` Eli Zaretskii
2020-07-05 15:13 ` Stefan Monnier
2020-07-04 10:04 ` Dmitry Gutov
2020-07-04 11:48 ` João Távora
2020-07-04 21:27 ` Dmitry Gutov [this message]
2020-07-04 21:30 ` Dmitry Gutov
2020-07-04 23:07 ` João Távora
2020-07-07 3:01 ` Dmitry Gutov
2020-07-07 10:56 ` João Távora
2020-07-07 12:23 ` João Távora
2020-07-07 13:38 ` Stefan Monnier
2020-07-07 14:24 ` Dmitry Gutov
2020-07-07 16:07 ` Stefan Monnier
2020-07-07 23:11 ` Dmitry Gutov
2020-07-08 3:58 ` Stefan Monnier
2020-07-08 11:20 ` Dmitry Gutov
2020-07-08 13:25 ` Stefan Monnier
2020-07-08 13:41 ` João Távora
2020-07-08 14:21 ` Dmitry Gutov
2020-07-08 15:12 ` João Távora
2020-07-08 18:32 ` Dmitry Gutov
2020-07-08 19:12 ` Eli Zaretskii
2020-07-07 14:45 ` João Távora
2020-07-07 14:40 ` Dmitry Gutov
2020-07-07 22:24 ` Dmitry Gutov
2020-07-07 22:49 ` João Távora
2020-07-07 23:00 ` Dmitry Gutov
2020-07-07 23:24 ` João Távora
2020-07-07 23:42 ` Dmitry Gutov
2020-07-07 23:46 ` João Távora
2020-07-08 0:10 ` Dmitry Gutov
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=5d768a69-3574-10c5-e80a-8ab77ec60462@yandex.ru \
--to=dgutov@yandex.ru \
--cc=41531@debbugs.gnu.org \
--cc=andreyk.mad@gmail.com \
--cc=joaotavora@gmail.com \
--cc=monnier@iro.umontreal.ca \
/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).