[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: asynchronous parsing
From: |
joakim |
Subject: |
Re: asynchronous parsing |
Date: |
Wed, 12 Aug 2009 22:01:23 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
Ted Zlatanov <address@hidden> writes:
> On Wed, 12 Aug 2009 19:16:15 +0200 address@hidden wrote:
>
> j> Ted Zlatanov <address@hidden> writes:
>>> On Tue, 11 Aug 2009 12:04:20 -0400 Stefan Monnier <address@hidden> wrote:
>>>
>>>>> I. Asynchronous parsing
> SM> BTW, I'm interested in adding core-Emacs support for such parsing, so if
> SM> you have any ideas about it, please share them. The way I see it, there
> SM> should be a table-based parsing engine written in C running in
> SM> a spearate thread, so the question are "what should the tables look
> SM> like?", "what should the output look like?", "what should the engine
> SM> look like?", "how should the asynchronous code synchronize with the rest
> SM> of Emacs?". Any help along this effort would be welcome.
>>>
>>> Maybe it would make sense to make this engine the first implementation
>>> of an asynchronous process in Emacs. We know we need general-purpose
>>> asynchronous processes, it's been discussed many times. Doing it with a
>>> parser, a read-only process with internal state, would be a good start.
>>> The difference from your suggestion is that rather than implementing a
>>> one-off, the goal becomes the first cut of a general facility.
>>>
>>> I bring this up because the need for asynchronous processes keeps coming
>>> up in Gnus discussions...
>
> j> Sounds very interesting, how would that work?
>
> The same way Stefan's suggestion would work: a separate thread running
> this parser. The difference is that we don't just do one thread for the
> parser and code especially for that purpose, but instead think of a
> general thread facility the parser can use. Once we prototype the
> facility, we'll know better what works and what doesn't.
Its this I'm interested in.
> The specifics of the parser, if that's what you're curious about, are
> not important to me (I don't plan to write such parsers or configure
> them myself). I just need the general threading facility for Gnus work.
That would indeed be great.
> Ted
>
>
--
Joakim Verona
- Re: "Font-lock is limited to text matching" is a myth, (continued)
- Re: "Font-lock is limited to text matching" is a myth, Stefan Monnier, 2009/08/13
- Re: "Font-lock is limited to text matching" is a myth, Eric M. Ludlam, 2009/08/11
- Re: "Font-lock is limited to text matching" is a myth, Miles Bader, 2009/08/12
- Re: "Font-lock is limited to text matching" is a myth, Xah Lee, 2009/08/12
- asynchronous parsing (was: "Font-lock is limited to text matching" is a myth), Ted Zlatanov, 2009/08/12
- Re: asynchronous parsing, joakim, 2009/08/12
- Re: asynchronous parsing, Ted Zlatanov, 2009/08/12
- Re: asynchronous parsing,
joakim <=
- Re: asynchronous parsing, Stefan Monnier, 2009/08/12
- Re: asynchronous parsing, Ted Zlatanov, 2009/08/13
- Re: "Font-lock is limited to text matching" is a myth, Lennart Borgman, 2009/08/11
- Re: "Font-lock is limited to text matching" is a myth, Stefan Monnier, 2009/08/10
- Re: "Font-lock is limited to text matching" is a myth, Lennart Borgman, 2009/08/10
- Re: "Font-lock is limited to text matching" is a myth, Stefan Monnier, 2009/08/10
- Re: Why js2-mode in Emacs 23.2?, Stefan Monnier, 2009/08/10
- Re: Why js2-mode in Emacs 23.2?, Deniz Dogan, 2009/08/10
- Re: Why js2-mode in Emacs 23.2?, Stefan Monnier, 2009/08/10
- Re: Why js2-mode in Emacs 23.2?, Stephen Eilert, 2009/08/10