TODO

[ChrisPenner]

• [x] ALL THE DOCS (Ongoing)
• [x] Switch Input Events to use adapter system
• [x] Switch Output Display to use adapter system
• [x] Add capacity for user plugins
• [x] Allow Plugins to maintain their own independent state
• [x] Add tests for TextLens
• [x] Switch to using Prisms for search-related TextLens' to signify whether a result was found.
• [x] Use monad transformers to allow modules to push side effects up to top level (like 'write file' or 'exit')
• [x] Modularize directive system so that editor core is "just another plugin"
• [x] Add 'Save'
• [x] Support Dependencies between plugins
• [x] Generalize cursor interface as an Extension
• [x] Expose API for setting text Attributes
• [x] Hide 'editor' and 'buffer' structures within Store and only expose direct-access lenses.
• [x] Allow extensions to maintain buffer-local state?
• [x] Somehow initialize extensions so they're not empty
• [x] Extension for multiple cursors
• [x] Improve interface for one-off scripts
• [x] Investigate Yi.Rope as possible text data-structure for performance.
• [x] Add logging modes
• [x] Extensible Event/Hook system
• [x] Asynchronous Action Execution
• [x] Windowing concepts (maybe using recursion-schemes)
• [x] Add buffer reference system
• [x] Allow embedding Actions in BufActions, but not the other way around.
• [x] Add Scrolling/Window support
• [x] Allow event listeners to be 'callbacks'
• [x] Per Buffer event/hook system
• [x] Expose API for expressing rendering preferences (I.E. Buffer size, location, or visibility)
• [x] 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]

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

[noughtmare]

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.

[ChrisPenner]

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]

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]

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: https://github.com/ChrisPenner/rasa/issues/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]

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]

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]

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 :)

[clojj]

ok, easier than I thought https://github.com/clojj/rasa/blob/master/rasa-example-config/app/Main.hs#L84

newtypes galore !

[ChrisPenner]

Let's continue the discussion here: https://github.com/ChrisPenner/rasa/issues/24; Looks like you've done a lot of work on this! I'll definitely read it over this weekend!

[jmatsushita]

@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]

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