ChrisPenner/rasa

TODO

ChrisPenner opened this issue · 12 comments

ChrisPenner commented
  • ALL THE DOCS (Ongoing)
  • Switch Input Events to use adapter system
  • Switch Output Display to use adapter system
  • Add capacity for user plugins
  • Allow Plugins to maintain their own independent state
  • Add tests for TextLens
  • Switch to using Prisms for search-related TextLens' to signify whether a result was found.
  • Use monad transformers to allow modules to push side effects up to top level (like 'write file' or 'exit')
  • Modularize directive system so that editor core is "just another plugin"
  • Add 'Save'
  • Support Dependencies between plugins
  • Generalize cursor interface as an Extension
  • Expose API for setting text Attributes
  • Hide 'editor' and 'buffer' structures within Store and only expose direct-access lenses.
  • Allow extensions to maintain buffer-local state?
  • Somehow initialize extensions so they're not empty
  • Extension for multiple cursors
  • Improve interface for one-off scripts
  • Investigate Yi.Rope as possible text data-structure for performance.
  • Add logging modes
  • Extensible Event/Hook system
  • Asynchronous Action Execution
  • Windowing concepts (maybe using recursion-schemes)
  • Add buffer reference system
  • Allow embedding Actions in BufActions, but not the other way around.
  • Add Scrolling/Window support
  • Allow event listeners to be 'callbacks'
  • Per Buffer event/hook system
  • Expose API for expressing rendering preferences (I.E. Buffer size, location, or visibility)
  • Add ability for Buffer 'Views'
  • In-editor help interface
  • Extension for cmdline (like vim/emacs)
  • Extension to 'Shell out'
  • Extension to generalize notion of 'motions' and 'operators' over lenses.
  • Add 'Open'
  • Extension for syntax highlighting support (read Vim/emacs syntax files?)
  • Quick-fix style list
  • Add timer API for timer related tasks
  • Allow plugins to 'cancel' events
ChrisPenner commented

@Dtatoo Let me know when you have questions, I'm sure there'll be a few!

noughtmare commented

Switch to DYRE??

I recommend against doing this (at least in the current state of dyre). Yi does this, but it has been a source of many problems that newcomers have. I wrote a post about it here.

My main points are:

  • Dyre doesn't handle exceptions smoothly.
  • Dyre doesn't rebuild with cabal or stack (i.e. you just have a single haskell source file as configuration file). This causes a lot of issues related to missing dependencies (like this one).
  • It is often unclear whether dyre has actually recompiled or not.

I think dyre is an awesome concept, but it still needs more development until its ready to use.

  • ❤️2
ChrisPenner commented

Those are some great points; thanks @noughtmare!

You're not the first to voice concerns about Dyre; and it definitely wasn't at the top of the priority list anyways. Looks like it's not a great idea, I'll remove it from the list!

I appreciate your feedback on this!

clojj commented

Hi,

Maybe for "Per Buffer event/hook system" or a separate TODO entry...

It would be nice to have some kind of BufferChanged event, indicating some deletion/insertion/.. in text-buffers.
That could be beneficial to any kind of analysis/parsing/lexing extension.

I'd love to help out, if you can point me to the relevant places...

ChrisPenner commented

Hey there @clojj! That sounds like a good idea!

My plan is to limit the API for editing buffers to the operations available using this [range lens]. If you're willing to work on it that would be a great place to start!

Continue the discussion here: #20 I've added some bullet points that should help you get started! Post there if you have any questions, or drop into our Gitter chat

clojj commented

Great.
btw. I am pondering what phase is best for colorizing/styling the buffer, after the lexer has tokenized.. ?

I would think that is beforeRender, or ?

ChrisPenner commented

beforeRender is correct yup 😁; it's after text-changes have occurred, but before they're rendered to the screen. You can see how the cursors extension renders the cursor here .

This uses elements from rasa-ext-style to signal to renderers how to display other ranges.

We'll likely have to make a few small changes to the way styles are rendered to allow optimizing performance for things like syntax highlighting; having a bufferChanged event is going to be useful for that 😁

clojj commented

So here is the basic setup of what I am trying to do...
https://github.com/clojj/rasa/blob/master/rasa-example-config/app/Main.hs#L54

I'd like to setup the (Chan String, Chan [Located Token]) in onInit of course,
but storing this in ext (btw, is Rasa.Internal.Editor.ext the editor-global state ? opposed to bufExt) is not easy.

As far as it goes, it is working.. I get all tokens inside the beforeRender handler (lexHaskell)
Lots of todo's for sure :)

ChrisPenner commented

Let's continue the discussion here: #24; Looks like you've done a lot of work on this! I'll definitely read it over this weekend!

jmatsushita commented

@ChrisPenner Here are some possible new action items to sort through after our gitter pow-wow.

In order to introduce widgets for autocomplete, file browsing and so on, there seems to be a need to extend the widget functionality to render them elsewhere than at the top/bottom/left/right of a View.

  • Allow Widgets rendering to be:
    • floating (overlaid maybe above/below/right/left of a specific position in text?)
    • block (inserted/embedded inside a text block)

Seems that making the Widgets depend on a text position would allow to not leak the rendering abstractions. Does that work?

Also, work in progress on rasa-ext-syntax some questions come up about managing file types, language syntax, key maps per language and user configuration.

  • Allow Buffers to have types by introducing data BufTypeChanged bufType = BufTypeChanged
    • BufTypeChanged ReadOnlyBuffer for read-only buffers in rasa-ext-files (rasa -R example.txt)
    • BufTypeChanged (EditorBuffer languageType) for specifying syntax choice in rasa-ext-syntax. Allowing to make syntax modular by having for instance a markdown syntax extension listen to BufferTypeChanged (EditorBuffer MarkdownLanguage).
    • BufTypeChanged FileBrowser for a file browser in a new
  • Dispatch FileOpened FilePath SomeOtherUsefulStuff in rasa-ext-files
  • Introduce an extension (and probably some UserConfig a event to read user configuration in dhall for:
    • file type to language syntax mappings
    • file type to key bindings
    • key bindings

Should the BufTypeChanged type be introduced in Rasa.Internal.Events or in an extension? Should BufAdded be extended also to include the BufType in addition to the BufRef?

ChrisPenner commented

Great! I made issues for each of those and put them in a milestone 👍