Show HN: EDI – An editor in Go | Hacker News Reader

Show HN: EDI – An editor in Go

satyajit.ranjeev.in

93 pointssatyajitranjeev48 comments

Open articleView on HN

Old dudes like me might have a strong negative reaction to something called "EDI."

For the young dudes like me could you explain why?

This: http://en.wikipedia.org/wiki/Electronic_data_interchange

http://en.wikipedia.org/wiki/Electronic_data_interchange

For the record the term is still thrown around left and right in enterprise settings.

US Healthcare Insurance industry relies heavily on this for... everything.

Yep. And to a somewhat lesser extent, so does international commerce and logistics. Nearly all major importers of goods (think Wal-Mart for example) and their various suppliers and service providers rely on EDI to exchange commercial documents (purchase orders, commercial invoices, packing lists), file customs entries, track their incoming shipments and inventory, etc etc.

EDI is probably irrelevant and dead in Silicon Valley (unless maybe you work at Oracle). But in healthcare and commerce it's very much alive.

It exists heavily in my industry (retail channel management) but mostly as design specs. Most companies tend to use XML it seems but they still base their feeds off of the old-school spec.

Not just old dudes, in my job we have to output and ingest various EDI formats (though mostly 820) all the time dealing with financial information.

Please tell me it has a built in EDI parser/linter

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 has even heard of an HTTP REST API or JSON (or even SOAP) yet.

> 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 for all payers to support for transactions (which, yes, are still X12) covered under operating rules adopted as national requirements under HIPAA [1], I'm pretty sure that its not the case that no one in the healthcare industry has heard of SOAP.

[1] Under the CORE 270 Connectivity Rule, http://www.caqh.org/pdf/CLEAN5010/270-v5010.pdf

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.

Thought of it as a succession to ed. And it nicely inverses to IDE.

You just need some new and more pleasant associations! http://masseffect.wikia.com/wiki/EDI

Instead of complaining you can just try to fix the situation.

Things get better: Open Source, Git Hub and you can have your share, too!

My 0.02 Cents here: http://www.use-the-tree.com

I am still waiting for people to join in (write parsers) and customers to be convinced and use it :-)

I've added binaries for Linux-64 and Mac in the blog article. This will help you try it if you do not have Go installed. :)

I 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. There is no need to reinvent the wheel by bundling an editor with it. You haven’t listed any planned features for the editor that other editors don’t already do, so by cancelling the editor portion of the project, you wouldn’t lose any features.

Your terminal could still support customizable E/W/L commands and right-click context rules – but there is no need to tie those features to any one particular editor. Instead, provide a custom configuration of the terminal that sends commands to your favorite existing editor through built-in means. Or if that integration wouldn’t be powerful enough, provide a plugin for the editor that integrates it with your new terminal. That way, users of many different editors could use your terminal.

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.

Right now it does not do anything a vim and a normal shell can't do. But the idea of plumbing is something that would be quite difficult(not impossible) to achieve in vim and a terminal.

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

Emacs has a ton of baggage. I like the fresh approach and especially the idea of hacking on my editor in go. As a hardened vim user I like that influence and I think it shows in edi.

Excellent 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.

I mean if you really believe in contribution why did you create a new Editor in GO? Please note, I am no way against you creating this text editor, I'm just trying to understand what your intention is.

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.

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.

Rob didn't say 'no' to highlighting. His infamous quote saying it was juvenile was meant as a joke.

Looks really nice and simple in an elegant way; I'll be interested in trying this.

It looks like a terminal inside Firefox. I didn't see any file tree view, or even an actual editor.

The editor is on the right and you can get a tree view by running the `tree` command.

You say that ACME is excellent yet has its problems, and I believe EDI is an answer to that. What are these specific problems you try to solve ?

Also, the plumbing of ACME is truly excellent, I hope you can reproduce its power.

Interesting concept. Are you planning on adding a system where you can write plug-ins in Javascript or Python for example? I saw in the blog post you were looking to adding a way to extend the editor.

Yes in a future release I do plan to do so.

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 cool stuff you can do in Go).

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 Go plugin system for a Go app.

Google protocol buffers over stdin/stdout of subprocesses maybe.

There is a javascript engine written in Go called otto so you could use that for plugins. That way people can write plugins with many languages if they wish. i.e. clojurescript, typescript ,dart, etc etc

I'd rather have it use Lua: low profile, good language, trivial embedding[0], excellent performance.

[0]: https://gist.github.com/lloeki/792ef5e4c98831baa0ed

Looks like a nice start. I'll be watching with interest. The collapsible command context is a neat idea for a shell that's attached to an editor -- I could see just having a pane that's always running the app being developed.

I'm curious how you handle the right-clicking on filenames in the shell pane -- for example, does it only work if the clicked text contains the complete relative path from the current working directory? If not, how do you determine the full path to the clicked file?

Every command executed has a stored in current working directory. So when you right click the relative path to the cwd of the command is used.

The biggest plus that I see is that this allows to do do remote editing on a server which may otherwise be restricted from access due to security concerns. If the backend can be developed to have a lot more admin features which can be used to restrict the features which can be used, then the admin can simply leave one port open through which the front end can communciate

Great 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.

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.

Honest question, since you posted this yourself on HN, what is the purpose of adding a “post to HN” button at the end of the post? Do further submissions after the original count as upvotes?

> Do further submissions after the original count as upvotes?

Indeed they do. However the "post to HN" button is part of his CMS design so appears at the bottom of every article entry on that site - including articles he may not have posted to HN himself.

Thanks. I have never submitted an URL, so I don't know how it works. This explains why there are many blogs that have a submit to HN button.

Currently this runs on the browser, and in the future it seems he will ship the same architecture as Atom.

My question is: can a browser based editor ever handle big files as well as Sublime and Vim?

I wonder if adding that command deletion ability to iTerm2 is possible? Does anyone know how the text buffer works exactly?

Reply on news.ycombinator.com