unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: phillip.lord@russet.org.uk (Phillip Lord)
To: "Clément Pit--Claudel" <clement.pit@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Beyond release
Date: Mon, 27 Jun 2016 21:35:28 +0100	[thread overview]
Message-ID: <8760sus73j.fsf@russet.org.uk> (raw)
In-Reply-To: <57716AEB.9050409@gmail.com> ("Clément Pit--Claudel"'s message of "Mon, 27 Jun 2016 14:05:31 -0400")

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> On 2016-06-27 12:40, Phillip Lord wrote:
>> I'm guessing that Isabelle/Emacs integration used "parsing output"
>> interaction. FWIW, I think that the days of this form of archictecture
>> are numbered. Both scala and clojure interaction now use something with
>> a structured protocol, with a specialized server on the scala or clojure
>> side. A similar thing is happening with R, also, and maybe with JDEE.
>
> And with Coq, another proof assistant that still uses Emacs as its main IDE.
> We're currently working on porting Proof General to use Coq's structured
> protocol.

Ah, didn't know that.


>> I don't know if anything could be done, but adding general support for
>> repl interaction to core or ELPA would probably be a good thing. I don't
>> know if it is possible -- most of the tools that I have mentioned so far
>> use different protocols, so perhaps it is not.
>
> Do you really mean REPL interaction? If so, comint-mode does exactly this, I
> think :)

Yeah, didn't put that very carefully. I meant "the sort of things that
in the past, we used to do my passing stuff to a REPL and parsing the
results". I.e. not REPL interaction.


> But if you meant structured protocols, then it's tricky; there's indeed a
> large variety of protocols. The main pain point when developing those (based
> on limited experience developing Emacs modes for Dafny, F* and Coq — which all
> use different protocols) is asynchronicity; you end up registering timers to
> delay certain actions or implement queues, and it's pretty tricky to keep the
> code organized properly.

CIDER uses call-backs, which seems to work okay, and is reasonably easy
to implement with closures.

How much of this could be made generic, I don't know. There are
definately some overlapping issues, though. Asynchronous callbacks are a
little hard to implement and debug, so providing way of making
call-backs that log might be nice.

I'll have a think on it.

PHil



  reply	other threads:[~2016-06-27 20:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-27  9:58 Beyond release Andreas Röhler
2016-06-27 14:18 ` Clément Pit--Claudel
2016-06-27 15:33   ` Andreas Röhler
2016-06-27 15:52     ` Clément Pit--Claudel
2016-06-27 16:10       ` Dmitry Gutov
2016-06-27 16:25         ` Andreas Röhler
2016-06-27 16:55           ` Dmitry Gutov
2016-06-27 18:10             ` Andreas Röhler
2016-06-27 19:55               ` Dmitry Gutov
2016-06-28  6:14                 ` Andreas Röhler
2016-06-28 11:13                   ` Dmitry Gutov
2016-06-27 20:29               ` Alan Mackenzie
2016-06-28  8:39                 ` Andreas Röhler
2016-06-27 16:21       ` Andreas Röhler
2016-06-27 16:40       ` Phillip Lord
2016-06-27 18:00         ` Clément Pit--Claudel
2016-06-27 18:05         ` Clément Pit--Claudel
2016-06-27 20:35           ` Phillip Lord [this message]
2016-06-27 15:53     ` Clément Pit--Claudel

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=8760sus73j.fsf@russet.org.uk \
    --to=phillip.lord@russet.org.uk \
    --cc=clement.pit@gmail.com \
    --cc=emacs-devel@gnu.org \
    /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).