On 2013-11-15 14:51, Jean-Philippe Bernardy wrote:
> On Fri, Nov 15, 2013 at 1:01 PM, Bardur Arantsson <s...@scientician.net>wrote:
>
>> On 2013-11-15 11:34, Jean-Philippe Bernardy wrote:
>>> On Fri, Nov 15, 2013 at 10:21 AM, Dmitry Ivanov <etherc...@gmail.com>
>> wrote:
>>>
>> [--snip--]
>>
>> (I'm using C++ as an example here, but you could probably insert "any
>> horribly complicated-to-parse language".
>> Not that there are that many of them other than C++ that are popular
>> enough to matter for this discussion.)
>>
>>> It all depends on the level of detail we want to offer. To get basic
>>> highlighting we can merely use lexical syntax (which is not that hard to
>>> produce).
>>
>> Even this is pretty horrendous for the specific case of C++.
>
>
> Isn't this what Emacs and Vim do?
>
Last time I used Emacs on C++, it doesn't appear to actually work all
that well. More precisely the highlighting seems to be OK, mostly, but
the identation suffers from the a lack flexibility arising from a
limited "understanding" of actual C++ code. I seem to recall some of the
new "non-keyword keywords" ("override" and such) giving it trouble
because of the lack of context-sensitivity.
[--snip-]
>>
>>> 2. We'll have to deal with asynchronicity. That's opening a new can of
>>> worms.
>>>
>>
>> Indeed, but don't we want highlighting to be asynchronous anyway? Will
>
> the performance of the incremental highlighting really be good enough to
>> handle huge files and/or extremely complex languages at a speed that's
>> in the "interactive" time range?
>
>
> Current experiments give a millisecond response time on 10000-line long C
> program.
Pretty awesome :)
>
>
>> There's also the special case of the
>> first time a file is opened to consider.
>>
>
> Some options have been put forward earlier; e.g. parsing only the 1st 10000
> lines when opening the file.
Oh, right I missed that. Should definitely be sufficient, yes.
>
>
>>
>>> 3. For Yi to gain any traction it needs "killer" features. Syntax
>>> highlighting could be one of them. In particular I envision an editor
>> which
>>> has full-knowledge of the syntax tree, updated on the fly (and not some
>>> seconds later after some external program has run). Doing the same as any
>>> other editor? "meh". :)
>>
>> Clang is actually usable as an (embeddable) library, so there's really
>> no need to call into an external process. I believe you can also get the
>> full AST if you really want it.
>>
>> Is being available as a dynamic library (or embeddable as a static
>> library) sufficient to make it possible to write a Yi highlighting
>> "adapter" in the new scheme of things? This would of course require FFI,
>> and so would require the IO monad.
>>
>
> There is a non-trivial amount of work to lift the API to Haskell, I would
> imagine... And even more so if full access to the AST is desired.
The way I imagine things is that you'd have a Yi<->C++/Clang adapter
which has a bit of Yi code (which understands what's hecessary for
providing highlighting on the Yi side) talks directly, via some internal
protocol to a bit of C code (which talks directly the Clang API to
derive *just* enough information from the ASTs, etc. to be able to
supply highlighting information.
Would such a thing be *prohibited* under the new scheme?
Another issue which hasn't been mentioned yet is code completion and
other IDE-like features which can also benefit tremendously for libclang
integration. (Not that it is necessarily relevant for this particular
thread, but if someone *were* to invest effort into clang integration
for these purposes -- under the reasonable assumption that it's much
easier to use clang than doing it yourself -- it would be nice to know
that such integration could also "replace" any highlighting built-in to
Yi to be more consistent with clang.)
>
>>> That basically condemns Yi to using external highlighters, as there will
>> be
>>> little to no advantage to internal ones.
>>
>> OTOH, it would be prohibitively expensive (time-wise) to implement a C++
>> highlighter from scratch rather than just using libclang's
>> implementation which is already debugged and working.
>>
>
> This matters only if somebody is willing to invest time in implementing
> either of those options.
>
Oh, certainly. I think I'm just saying that it might be a bad idea to
remove the option. (I still haven't fully understood if it actually
*does* remove the option, but hopefully you can clarify that.)
Anyway, as in all cases in FOSS: The one who writes the code wins ;).
At the very least I'm glad to hear that it'll simplify things greatly :).
Regards,
--
--
Yi development mailing list
yi-devel@googlegroups.com
http://groups.google.com/group/yi-devel
---
You received this message because you are subscribed to the Google Groups
"yi.devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to yi-devel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
