It's really an editor in Go and Javascript. I think it might be an interesting platform for exploring some ideas and wish him luck, but the title implies that it's only written in Go.
True. Now I just can't seem to edit the title.
Show HN: EDI – An editor in Go
31–40 of 50 posts
Re: Show HN: EDI – An editor in Go
#32I don’t see much about this idea that requires a new editor. This seems to be mainly a new terminal app, not a new editor. The only points of integration between the terminal and the editor are the E/W/L commands to manage open files and the right-click context rules. With so little connection between the editor and the terminal, I think this project would be better off changing focus to be only a new terminal app. T…
Many a time I see myself having two windows open. My editor and shell. I keep jumping from these windows either copying content or executing commands. The whole idea of the project is to bring them together. It is to act as a bridge between the commands that the OS provides and the editor.
Re: Show HN: EDI – An editor in Go
#33Old dudes like me might have a strong negative reaction to something called "EDI."
Thought of it as a succession to ed. And it nicely inverses to IDE.
Re: Show HN: EDI – An editor in Go
#34Great start. Although almost the same and more can be done using tmux - running editor in one split and executing commands in others. Are there any keyboard shortcuts for navigation between commands/collapsed commands/file or it needs to be done with the mouse?
Ctrl+l toggles focus from command pane to editor pane. There is no shortcut as of now to collapse the command pane.
Re: Show HN: EDI – An editor in Go
#35Excellent editor this. But I'm not quite sure why you would create this.
From your profile I understand you are good with Python and you are good with Javascript, in your blog post : http://satyajit.ranjeev.in/2014/05/15/WTF-Github.html, you argue that Github took a very wrong step towards creating Atom, and you quoted > Havoc Pennington wrote:
Don’t start by launching your own project. Lots of people want to write free software, so the first thing they do is scribble some code, slap on the GPL, and release version 0.0.1 alpha. While fun and possibly educational, this is totally unproductive.
And finally in the essay you quote that Javascript is a terrible language that happened to us and yet here we are a Text Editor written in Go and Javascript.
Re: Show HN: EDI – An editor in Go
#36Excellent editor this. But I'm not quite sure why you would create this. From your profile I understand you are good with Python and you are good with Javascript, in your blog post : http://satyajit.ranjeev.in/2014/05/15/WTF-Github.html , you argue that Github took a very wrong step towards creating Atom, and you quoted > Havoc Pennington wrote: Don’t start by launching your own project. Lots of people want to write…
True my own words haunt me. I complained about atom as it was an editor that was a plain rip off sublime text. Just that it is done in JavaScript. I complained how they could not create something similar to Acme which was a brilliant innovation. I did try to customize Acme to what suited me. But clearly Acme's philosophy is quite different. Rob Pike says a big no to line numbers and highlighting.
On why I chose JavaScript: that is the only language you can use on the web browser. I tried several cross platform GUI toolkits that Go supported. They were half complete or abandoned. The web is the only sane cross platform development environment.
Re: Show HN: EDI – An editor in Go
#37I don’t see much about this idea that requires a new editor. This seems to be mainly a new terminal app, not a new editor. The only points of integration between the terminal and the editor are the E/W/L commands to manage open files and the right-click context rules. With so little connection between the editor and the terminal, I think this project would be better off changing focus to be only a new terminal app. T…
Many a time I see myself having two windows open. My editor and shell. I keep jumping from these windows either copying content or executing commands. The whole idea of the project is to bring them together. It is to act as a bridge between the commands that the OS provides and the editor.
> The whole idea of the project is to bring them together.
What does this do that a normal shell and vim doesn't? If I use that together with something like tmux I can jump between the two seamlessly entirely with keyboard commands.
Re: Show HN: EDI – An editor in Go
#38I don’t see much about this idea that requires a new editor. This seems to be mainly a new terminal app, not a new editor. The only points of integration between the terminal and the editor are the E/W/L commands to manage open files and the right-click context rules. With so little connection between the editor and the terminal, I think this project would be better off changing focus to be only a new terminal app. T…
Many a time I see myself having two windows open. My editor and shell. I keep jumping from these windows either copying content or executing commands. The whole idea of the project is to bring them together. It is to act as a bridge between the commands that the OS provides and the editor.
This is an interesting project for sure (writing text editors are fun, and the mix of technologies chosen is interesting) - but I think it would be fairly straightforward to implement the features you've shown in your demonstration as an emacs package :)
Re: Show HN: EDI – An editor in Go
#39Earlier quoted context omitted.
I would recommend against using multiple languages for the plugin interface. It just becomes a mess, the Sublime Text way of using Python and Python only for all the plugin system makes it extremely clean and extremely powerful. In your case maybe making all the plugins Go would be the way to go, It helps a lot with performance (not having to create an environment for each programming language) and the power (all the…
The problem with having plugins be in Go is that dynamic linking of shared libraries (written in Go) is not very well supported right now with gc (standard Go tools, not gccgo). There are plans to address this post Go 1.4. There are, of course, hacky ways to do plugins without shared library support (gobs via rpc to other processes or whatever), but if it were me I wouldn't spend a lot of time right now working on a…
Google protocol buffers over stdin/stdout of subprocesses maybe.
Re: Show HN: EDI – An editor in Go
#40Earlier quoted context omitted.
Old dudes as well as young dudes in old-school industries like healthcare or logistics. I work at a logistics company and inter-company integration via EDI messaging is still considered cutting-edge technology in this field. Of course it doesn't just mean pre-internet standards like ANSI X12 and EDIFACT anymore, these days much of the messaging is CSV and XML data pushed over FTP or AS2. But it's almost like no one h…
> Old dudes as well as young dudes in old-school industries like healthcare or logistics. [...] > Of course it doesn't just mean pre-internet standards like ANSI X12 and EDIFACT anymore, these days much of the messaging is CSV and XML data pushed over FTP or AS2. But it's almost like no one has even heard of an HTTP REST API or JSON (or even SOAP) yet. Given that both an HTTP+Mime and a SOAP transport are mandatory f…
Interesting, thanks for sharing. Like I said, I work in logistics. I've never worked in healthcare before so I didn't know they are required to use SOAP, but I was aware that they use lots of X12 and I guess I thought SOAP content was always XML. SOAP is pretty rare in my industry. Almost all FTP & AS2.