Skip to content
This repository was archived by the owner on Oct 7, 2020. It is now read-only.

Loose comments from editor (emacs) perspective #5

Closed
gracjan opened this issue Oct 22, 2015 · 2 comments
Closed

Loose comments from editor (emacs) perspective #5

gracjan opened this issue Oct 22, 2015 · 2 comments
Milestone

Comments

@gracjan
Copy link
Contributor

gracjan commented Oct 22, 2015

Loose comments from editor (emacs) perspective:

  1. Buffers (open files) can be not yet saved and therefore differ from what is on disk currently. Generally we want to operate with the visible contents.
  2. Files-while-editing have the tendency to by not-valid Haskell. Or at least no type correct. There were multiple issues raised so that haskell-mode works with somewhat valid Haskell instead of totally not working.
  3. Editors have cursor position that can serve as indicator what to act on.
  4. Editors have marked region that can serve as indicator what to act on.
  5. Smooth interaction requires latency hiding because 200ms is when people start to notice non-smoothness. Editor needs to be ready to handle longer-running queries, actually any query can run 'too long'. This means communication needs to be asynchronous.
@alanz
Copy link
Collaborator

alanz commented Oct 24, 2015

Great to get this input. Some comments

  1. ghc-mod has a map-file mechanism whereby the unsaved buffer is transferred to the backend for error checking or other processing.
  2. invalid files are a problem, but I think being able to bring the full power of the GHC parser and/or the approach taken in Yi (originally) or http://blog.haskell-exists.com/yuras/posts/incremental-lexer.html will help.
  3. The editor context should definitely be available to plugins. How precisely to communicate available commands/features from a plugin to an editor is something we still need to get to grips with.
  4. Same as 3
  5. The session needs to run locally, and be fast. Hopefully this can be achieved by splitting out the comms into multiple logical channels (possibly all multiplexed onto a single one for emacs) and ensuring that the backend is always "live" in the sense of responding on channels not explicitly marked as possibly blocking.

@gracjan
Copy link
Contributor Author

gracjan commented Nov 6, 2015

I think I got my point across so we can close this issue.

@gracjan gracjan closed this as completed Nov 6, 2015
@alanz alanz added this to the prehistory milestone Feb 2, 2019
fendor referenced this issue in fendor/haskell-ide-engine Sep 5, 2019
Completion changes from master
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants