by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Justin Tirrell
@jjttjj
My personal opinion is that it's not worth continuing with BOT and it would be best to just design a new editor from scratch
Pratik Karki
@prertik
Yes, that's true @jjttjj, although BOT has a certain advantage to react to events and create custom behaviour to each event, similar to earlier gaming standard: ECS(entity component system), but, modern editors are different and complex than that. Even game developers seem to loathe ECS.
Although, LT's tying up with BOT wouldn't be any issue for updating it, it's much more coupling with external js libraries which pushed towards a rewrite.
J Atkin
@JJ-Atkinson

(sorry for the very long radio silence - got caught up in life and a new startup :).

I arrived at the same conclusion a few months ago. I read everything I could find on BOT and read the code as much as I could. Eventually determined that a re-write was called for. I have spent alot of time with Fulcro recently, and I think that's a good stepping off point for all of this. My current thoughts are that a combination of Fulcro and a version of Integrent for cljs would be a great combination. I'm just now getting to a leveling off with my startup, and I'm interested in dedicating some serious time to the rewrite. Current progress is documented here: https://github.com/JJ-Atkinson/Fisher. I'm more than willing to pitch in on another program if it seems to be better positioned.

Pratik Karki
@prertik
@JJ-Atkinson interesting. Hey, if you're available to want to do some rewrite for LT, maybe we can collaborate and divide tasks? Like, I'm more focused on developing the base of editors going on. We can collaborate on plugin system/adding code bubbles and such.
Pratik Karki
@prertik
Although, I must say that, though using some frameworks and extra libraries will give me an edge on development time, it would then, take away that time for its maintenance.
LT' s codebase contains beautiful clojurescript codebase but, being coupled on the external ecosystem took away the maintenance possibilities.
I don't want to repeat that, so, using frameworks/extra libraries is okay and might be better IFF it's a plugin. The bare essentials of the editor will be CLJC all the way, only requiring essential libraries (from Clj/Cljs ecosystem).
Pratik Karki
@prertik
and to employ most of the required features, we have to and am looking into nREPL and cider(orchard) ecosystem.
J Atkin
@JJ-Atkinson

Absolutely. I'm currently thinking in terms of sustainability. 1 (or even 2-4) people cannot realistically support an advanced editor independently in their spare time. The quality of some of these libraries is high and they undergo continuous maintenance, which is a huge amount of effort saved.

If you could clarify here, it would be useful.

Although, I must say that, though using some frameworks and extra libraries will give me an edge on development time, it would then, take away that time for its maintenance.

Not sure I understand the point.

J Atkin
@JJ-Atkinson
What are your current ideas on a rewrite and it's architecture?
Justin Tirrell
@jjttjj
I think one key point (and I think the lighttable developers did understand this) is that a text editor is really just a UI platform upon which arbitrary applications/extensions can be built, one of these extensions being the core text editing functionality. Codemirror is decent at text editing (another thing LT figured out). The hard part is how do you expose the CodeMirror functionality to other extensions/applications? So really you need to first figure out how to build an extensible cljs platform, or a sort of "operating system" that will manage the display and interaction of multiple extensions/components, which also sort of need to be infinitely flexibile.
Justin Tirrell
@jjttjj
I don't know that integrant is a great fit because your components will be ephemeral, you will have editors and file pickers and repls come and go all the time, each of which is its own mini system that also must interface with the outside system
I suppose a good exercise might be to imagine these three components: a code editor, a repl and a file picker. What will the interfaces between these look like? What will control the displaying of these?
Justin Tirrell
@jjttjj
I just spent some months hoping to get my own custom editor to a point where I could dogfood it but ultimately failed, I couldn't figure out a way to do this cleanly, and at some point realized it was a much harder problem than it seemed when I started
Pratik Karki
@prertik
Hmmm, what I meant by that statement, @JJ-Atkinson is that, understanding from LT's past point, we can see, it extensively using CodeMirror(which gave it it's edge) and numerous other dependencies that helped it make it so. Yes, that made it easier and faster to get going as, using codemirror we didn't have to implement our own text/syntax support mechanism in LT, we could simply use that.
But, like LT, CodeMirror is a large project of it's own, it also has toolings it depends on, it also might have it's breaking changes, it also might have it's days when it goes unmaintained. When, these things go away, we end up maintaining the instance of codemirror and it's dependencies as LT is coupled onto that.
If we get again using CM, we end up writing alot of Cljs and to top all that we will be again going to the path of electron.
Now, I'm in no way saying CodeMirror or Electron or even JS/NPM ecosystem is bad and cannot be trusted. They are useful and must be used wisely to yield effective software.
Pratik Karki
@prertik
During my talk in IN/Clojure, I did mention of 2 ideas to get going new LT, i.e. Client/Server architecture and JSON-RPC based text editing. Though, recently after working on JSON-RPC based editing facilities, I noticed it to be quite slow in most cases when talking to REPL and having other advanced Clojure functionalities.
and, after reading the posts of the author of Xi-editor, I decided to halt on JSON-RPC based extensive code editing functionality
But, the big part of client/server architecture still remains which is, implement the editing/REPL functionalites into a Server i.e. raw Cljc codes requiring only essential Clojure libraries and have clients like Electron use it but, do not attach the core with it.
Like NeoVim, where GUIs are available but, neovim provides extensibility to connect to it rather than have a built in GUI.
IF, we do this and make this architecture work on this, we can finally, be able to effectively release and survive LT.
Pratik Karki
@prertik
A thing to note: At this moment, we do not/might not want to compete with other editors, we won't be supporting syntax and ecosystem of other languages. We will only focus on Clojure/Script and maybe JS, HTML, CSS, Md and such. If a person wants to work on Python, it would be better for them to use Emacs to do that, which is a superior editor
LT's future role will be like of Android Studio, whatever people may use Emacs, Vim, Atom, etc. if people want to create an Android App, they will have to open Android Studio even if it's large and slow. Or opening IntelliJ IDEA for working on big Java projects. We will only focus on providing excellent features/toolings to Clojure ecosystem.
and for some tools which tie up to that, namely, HTML, CSS, Js, Md and such.
J Atkin
@JJ-Atkinson

I like what I'm hearing. I'm actually on a very similar page with you @prertik and you @jjttjj. Here are my notes from reading what both of you said

jjttjj
I think one key point (and I think the lighttable developers did understand this) is that a text editor is really just a UI platform [...]

Fully agree. That's why I'm interested in a plugin system where plugins expose some extension mechanism as well. As far as I can tell, IntelliJ has 1 level extensions - i.e. you can extend IntelliJ, but you cannot really extend an IJ plugin. LT was/is capable of the plugin system being recursive. The plan for finding extension points for an editor is relatively simple IMO. I'm hoping to make both an AST and text editor. Code completion, paredit, saving, opening, etc, should be relatively high level. A completion plugin (first option is a wrapper for Complement) should not even have to bother knowing which editor it's serving. The editor shouldn't have to know that ctrl+space triggers completion windows. Not sure on which side the glue for this should reside, but that could be hammered out in development I bet.

This is also why I'm interested in Integrent.

{
 :plugin.complement
 {:insert-suggestion-fn
  ; vector indicates middleware maybe... 
  [#ig/ref :core/get-active-component
   #ig/ref :editor-abstraction/insert-completion] ;; maybe plugins are a map of keywords -> #{meta or fns}, and
  ;; the editor-abstraction knows which keys of the map should invoke the insert-completion action.
  ;; maybe both the ast and standard editor would provide some standard key, e.g. :editor/insert

  :system {:open-file-action 

           #ig/ref :editor-abstraction/ask-which?
           ;#ig/ref :editor-abstraction/open-ast
           ;#ig/ref :editor-abstraction/open-text
 }}}

This is very fast and loose, but maybe it gives you an idea of what I'm thinking. Would need to try it out a bit to see what does and doesn't work

prertik
But, like LT, CodeMirror is a large project of it's own, it also has toolings it depends on, it also might have it's breaking changes, it also might have it's days when it goes unmaintained. When, these things go away, we end up maintaining the instance of codemirror and it's dependencies as LT is coupled onto that.

Yup. I don't want to be stuck maintaining some specific editor for a long time. I think a slightly re-imagined version of LT would need to be almost exclusively an OS setup. Most of the work we put in would be around specific plugins that are supported by the core team. e.g. we support a specific code editor, (code mirror, calcit, parensoup, in house something, ...), but leave the ecosystem as open as possible for additional plugins to come around and fill that role. This would absolutely require some method of isolating the plugins from the implementation of other plugins. i.e. code mirror should not know that complement exists, (both from the point of view that code mirror should support alternatives easily, and that code mirror should be easily exchanged while keeping complement).

J Atkin
@JJ-Atkinson
This is also why I love the way integrent works - it allows very deep configuration of the system with relatively little effort.

prertik
But, the big part of client/server architecture still remains which is, implement the editing/REPL functionalites into a Server i.e. raw Cljc codes requiring only essential Clojure libraries and have clients like Electron use it but, do not attach the core with it.

I'm a bit more torn here... The majority of the code written for a useable editor experiance will be inherently UI driven. We can depend on very good tooling server side that is already supported for other clj editors (complement, emacs ecosystem, clj-kondo), relegating the server to either relatively simple but platform limited functionality, or the fact that it is terribly hard to get multi-threaded js to work.

J Atkin
@JJ-Atkinson

prertik
A thing to note: At this moment, we do not/might not want to compete with other editors, we won't be supporting syntax and ecosystem of other languages. We will only focus on Clojure/Script and maybe JS, HTML, CSS, Md and such. If a person wants to work on Python, it would be better for them to use Emacs to do that, which is a superior editor

Yep, and it limits the scope of development quite nicely. Not sure we have to be large and slow though :)

I'll be on until 6:00 PM UTC if either of ya'll want to have a more direct conversation and not have to wait for a day or 2 for responses.
J Atkin
@JJ-Atkinson
@prertik I do have a specific question though - how does LT load in plugins? I assume they are independently :advanced compiled, but how does that work? That would mean that for every plugin installed there is an independent CLJS core library loaded.
Pratik Karki
@prertik
Yes, every plugin is an independent clojure/script project while outputs a compiled js to be loaded into Lighttable.
Like I said @JJ-Atkinson, Yes, I have these rational decision for now, but, I'm not married into it.
Embedding or designing around UI hurt me for so long while working on current LT, so, I'm not the person who would just readily want to do that again.
I want to see/venture other options of Client/Server before going to that.
But, yes, only editing and repl functionality can be made from that, the syntax highlighting and others are tied to UI.
think of it as LSP server architecture but, bit different, as LSP is complex and makes your editor chunky.
Pratik Karki
@prertik

Embedding or designing around UI hurt me for so long while working on current LT, so, I'm not the person who would just readily want to do that again.

There's a nepali proverb on this:
अगुल्टोले हानेको कुकुर बिजुली चम्कँदा तर्सिन्छ
Literally: The dog beaten by a stick gets startled when a lightning strikes
Meaning: Once bitten, twice shy / Once someone is made to lose trust (or is betrayed), then he/she frets on small things (or treads carefully)

But, yeah, let's try to have a more direct conversations. If you want to help me get new LT @JJ-Atkinson, you only need to say. We can try pair programming and collaborating more during weekends from mid August.
weekends/some weekdays
Pratik Karki
@prertik
But, oni-vim and it's use of Revery which is binding to React Native on Reason is quite interesting to see.
I've had been entertaining the ideas of creating a much better bindings to electron/react native on cljs so that we could use that.
or we could even use Revery.
Need to experiment these things before setting my mind onto UI platform.
J Atkin
@JJ-Atkinson
Yup. I actually purchased a copy of oni-vim, it's pretty slick.
I'm going to start doing some minimal prototypes of 2 or 3 ideas that I have. I'll also look into revery, looks pretty neat on first blush
Pratik Karki
@prertik
@JJ-Atkinson jump to direct messaging to create less noise around room?