WIP: Tapioca LSP #2001
WIP: Tapioca LSP #2001
Conversation
Prototype retrieving stdin from Rails addon, sending messages to it which triggers DSL generation
lib/ruby_lsp/tapioca/addon.rb
Outdated
| sig { params(changes: T::Array[{ uri: String, type: Integer }]).void } | ||
| def workspace_did_change_watched_files(changes) | ||
| # TODO: avoid direct access | ||
| files_to_entries = @index.instance_variable_get("@files_to_entries") |
There was a problem hiding this comment.
@vinistock how do you feel about the Tapioca DSL directly accessing this?
(cc @KaanOzkan)
There was a problem hiding this comment.
I'd like for all of this logic to live inside the index object, it can give us the entries from a given file. Dealing with files_to_entries here is too internal and we'd need an attr_reader.
There was a problem hiding this comment.
Paired with Vini on this a bit earlier. We now have a method on @index that can be called.
@index.entries_for(path, RubyIndexer::Entry::Namespace)
lib/ruby_lsp/tapioca/addon.rb
Outdated
| entries.map(&:name) | ||
| end.flatten.compact | ||
|
|
||
| # TODO: confirm with kaan if we expect a response here? (i.e. should it be a notificatio or a request) |
There was a problem hiding this comment.
@KaanOzkan do you think see situation where the Tapioca LSP will need to provide a response? Or will it be 'fire-and-forget'?
There was a problem hiding this comment.
I don't know how responses are used by the client. End result of what we need is logs in the output tab and potentially an error notification popup (Not sure).
There was a problem hiding this comment.
Let's keep it flexible and allow for the possibility of some error that we want to display. I will change it to be a request.
See also: