[rust-dev] Modules and visibility
gaetan at xeberon.net
Fri Jan 24 01:16:00 PST 2014
I've started to work on better implementation of ctags.
2014/1/24 Lee Braiden <leebraid at gmail.com>
> On 23/01/14 22:23, Steve Klabnik wrote:
>> Ehhh, my phrasing on that one was poor. What I was trying to say is
>> that there are a significant number of users of Rust who do not have
>> IDEs, and adding anything that would _require_ you to use an IDE with
>> Rust is a significant drawback.
>> If an IDE floats your boat, no complaints from me. As long as I can
>> use my vim, I don't care what you use. :)
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
> Even many serious vim / emacs users have it tweaked to the point where it
> does a lot of IDE-like things, such as completion and project file
> switching / builds / tag search too. I think the need is to support IDE
> features in a flexible way, that any editor / IDE can interface with as
> suits them.
> I think the best solution to that would be some sort of daemon that takes
> a top-level project definition, or a set of files, compiles them, monitors
> for changes, and interactively answers questions about it via some simple
> // static info support, which becomes interactive, if
> update_edited_overlay() is used
> all_tags(include_metadata) // returns tags, plus optional metadata
> like doc strings and highlighting info
> // interactive editing extensions
> update_edited_overlay(f, start_line, start_col, end_line, end_col,
> highlight_info(f, start_line, end_line)
> completions_at(f, line, col)
> You could then run this in the background, for big IDEs, or just run it
> ahead of time, extract tags, and write an index / highlighting file, for
> simpler editors. What's more, it would be a framework that many other
> languages could adopt.
> Rust-dev mailing list
> Rust-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev