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