Complete and Look should share semantics/implementation #491
Replies: 3 comments
-
Sounds like a good idea to me. At risk of over-complicating things: I'd like both complete and look to be configurable. If you're engaged in a non-trivial refactoring effort, can you consider letting the logic be provided via some kind of external helper? Then we could provide connect it to lsp? |
Beta Was this translation helpful? Give feedback.
-
I was poking at how to hook up such helpers. Currently the only pattern for external "help" in acme/edwood is the events file. |
Beta Was this translation helpful? Give feedback.
-
If Chrome is any indication... it's possibly an invitation for race conditions. Our filesystem implementation should be as scalable as the kernel. 🙂
I'm not sure what you mean exactly. I think that we should avoid having some kind of event handling chaining. In particular: I'd like the "which helper handles this" should be O(1) and unambiguous. And we should have a well-tested approach for handling "the helper doesn't answer soon enough" -- I worry a little bit about inserting a two-way IPC on the typing critical path. So maybe: "completion handler" is a per-window attribute? |
Beta Was this translation helpful? Give feedback.
-
I've been making Look behave more correctly on Windows where path names are much uglier than in unix-land.
Right now, the windows path uses a regexp to match filenames (in expandfile). That differs from how the posix paths work and how Complete works.
Probably Complete should handle expandfile as well.
One benefit of how this is done is that expandfile could walk the file tree properly instead of using a stack of heuristics to figure out if something is a filename. Perhaps heuristics to find the start of a filename, then path following with Complete until a filename is fully identified.
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions