TODO

[ChrisPenner]

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

@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: #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: #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 👍