Zed: The Next Phase(zedapp.org)
zedapp.org
Zed: The Next Phase
http://zedapp.org/2014/04/zed-the-next-phase
40 comments
Thanks for posting, and great work so far! Unfortunately, I encountered a few deal-breaker issues with Zed. So here are a few criticisms, if this helps you improve the project (but by no means let this detract from the current success of a great project!):
1. IMO you're using the wrong text matching algorithm for file search. This is pretty critical, considering it's the main interface for opening files.
Zed seems to search for simple text substrings only, whereas both Sublime Text 2 and Xcode look for the longest common subsequence. This is huge, for me at least; in Xcode or ST2 I can type the first few letters of one of my files, followed by a few more letters from different words in it, followed by ".cpp" and it finds the file.
Zed (as is) is completely unusable to me, because my project folder contains many similarly named files (.h, .cpp) as well as a ton of other source files from external libraries/modules with similar sub-words with what I'm searching for which for some reason always show up first and saturate the search results. With Zed there's no way to narrow down to what I'm looking for besides typing in the full name of the file. With ST2 or Xcode this is not a problem due to LCS.
2. This is not your fault necessarily, but it's a big deal to me: Text rendering is slow in Zed (and in every other web-technology-based code editor I've tried, e.g. Light Table).
For example, scrolling is even choppier than Xcode. The primary (if not sole) reason I moved away from Xcode to ST2 was because Xcode's horribly laggy UI was driving me crazy.
This is a bit of a personal rant, but we're living in an age with multi-gigaflop CPUs and multi-terraflop GPUs, yet we have somehow regressed to a point where scrolling (of all things) is laggy? IMO this is absurd, as an industry trend in general. For this reason, I generally dislike the trend to write everything (including local apps) in HTML/CSS/JS. These technologies really weren't designed to support this sort of complex dynamic UI. While it's quite impressive what's possible despite this, the stress of forcibly warping HTML/CSS/JS to accomplish some of these UI feats shows through as horrible inefficiency.
1. IMO you're using the wrong text matching algorithm for file search. This is pretty critical, considering it's the main interface for opening files.
Zed seems to search for simple text substrings only, whereas both Sublime Text 2 and Xcode look for the longest common subsequence. This is huge, for me at least; in Xcode or ST2 I can type the first few letters of one of my files, followed by a few more letters from different words in it, followed by ".cpp" and it finds the file.
Zed (as is) is completely unusable to me, because my project folder contains many similarly named files (.h, .cpp) as well as a ton of other source files from external libraries/modules with similar sub-words with what I'm searching for which for some reason always show up first and saturate the search results. With Zed there's no way to narrow down to what I'm looking for besides typing in the full name of the file. With ST2 or Xcode this is not a problem due to LCS.
2. This is not your fault necessarily, but it's a big deal to me: Text rendering is slow in Zed (and in every other web-technology-based code editor I've tried, e.g. Light Table).
For example, scrolling is even choppier than Xcode. The primary (if not sole) reason I moved away from Xcode to ST2 was because Xcode's horribly laggy UI was driving me crazy.
This is a bit of a personal rant, but we're living in an age with multi-gigaflop CPUs and multi-terraflop GPUs, yet we have somehow regressed to a point where scrolling (of all things) is laggy? IMO this is absurd, as an industry trend in general. For this reason, I generally dislike the trend to write everything (including local apps) in HTML/CSS/JS. These technologies really weren't designed to support this sort of complex dynamic UI. While it's quite impressive what's possible despite this, the stress of forcibly warping HTML/CSS/JS to accomplish some of these UI feats shows through as horrible inefficiency.
I understand your frustration. This is the 3rd editor I've got excited about by looking at screenshots (see also Atom and Brackets). Then was disappointed when I realised they render using a browser.
=Slow. Not slow enough to be unuseable. But slow enough to drive you crazy after working with it for a day. And perhaps 30% reduction in laptop battery life, because of increased power requirements.
I moved to Sublime Text. Millions of us did. It provided both fantastic usability and rocket-fast speed. That's the baseline. Any new editor needs to at least have BOTH those features!
=Slow. Not slow enough to be unuseable. But slow enough to drive you crazy after working with it for a day. And perhaps 30% reduction in laptop battery life, because of increased power requirements.
I moved to Sublime Text. Millions of us did. It provided both fantastic usability and rocket-fast speed. That's the baseline. Any new editor needs to at least have BOTH those features!
>This is a bit of a personal rant, but we're living in an age with multi-gigaflop CPUs and multi-terraflop GPUs, and we have somehow regressed to a point where scrolling is laggy again? IMO this is absurd, as an industry trend in general. For this reason, I generally dislike the trend to write everything (including local apps) in HTML/CSS/JS. These technologies really weren't designed to support this sort of complex dynamic UI. While it's quite impressive what's possible despite this, the stress of forcibly warping HTML/CSS/JS to accomplish some of these UI feats shows through as horrible inefficiency.
I doubt the issue is simply the use of web technologies...the fact is the more powerful our computers become the more demand is placed on them. Your web browser is just one more thing running on your computer, there are a bunch of other things influencing overall performance. You could replace the entire web stack of technologies and you would probably end up in the same place performance-wise.
I envision a future where we have even faster computers but then maybe your OS would have integrated a bunch of AI that'll bring performance to a crawl :)
I doubt the issue is simply the use of web technologies...the fact is the more powerful our computers become the more demand is placed on them. Your web browser is just one more thing running on your computer, there are a bunch of other things influencing overall performance. You could replace the entire web stack of technologies and you would probably end up in the same place performance-wise.
I envision a future where we have even faster computers but then maybe your OS would have integrated a bunch of AI that'll bring performance to a crawl :)
I can barely push my pc above 10% usage and yet I enjoy from time to time laggy interfaces and locks. Worst offender right now - Eclipse after being out of focus for more than 10-12 hours.
I've noticed that too on OSX - it's not just Eclipse, any memory heavy app such as xcode causes the same. I don't get this happening in Eclipse on either my Windows or Linux installs. I think it's just very aggressive paging to disk or something similar.
It is on SSD ... and I have 32 Gigs of ram. And some of the intelij products I use have no problems - and they are java based. Windows 8.1.
But anyway on current PCs any kinds of unresponsive UI-s are inexcusable.
But anyway on current PCs any kinds of unresponsive UI-s are inexcusable.
Ah.. weird I have no idea then. I've got an Eclipse running on Win7 SSD that has been open for over a month using 3GB of ram out of 16GB. It's very very snappy. I do have an Eclipse running on a macbook pro SSD 16GB and that one has about a 2-3 sec freeze when swapping back to Eclipse after backgrounding it for awhile, so I thought that was your issue. Maybe Win 8.1 works more similarly to OSX than Win 7?
Something in OSX paging is broken. See http://workstuff.tumblr.com/post/20464780085/something-is-de... for details. Apple refuses to fix this for years. This rendered my old Core2Duo/2GB RAM/spinning disk MBP useless even for web browsing. This sort of system rot is one of the reasons I'm running Arch on my Haswell MBP/16GB.
No doubt, as computational supply increases, so does the demand. Normally, this is a sign of health/progress; it only becomes a problem when demand shoots so far past the supply that we actually regress important user experience metrics (e.g. interaction latency or battery life experienced by the user). So why does this happen?
"HTML5" has rightfully exploded in popularity. In fact, these days it's hard to justify NOT building your front on this stack. But much like any explosion of a popular technology, the developer community will tend to push the limits of what it can reasonably do. This exploration is a good thing, but it can be frustrating until people settle into best practices of what applications do and do not suit a given tech stack.
"HTML5" has rightfully exploded in popularity. In fact, these days it's hard to justify NOT building your front on this stack. But much like any explosion of a popular technology, the developer community will tend to push the limits of what it can reasonably do. This exploration is a good thing, but it can be frustrating until people settle into best practices of what applications do and do not suit a given tech stack.
I doubt the issue is simply the use of web technologies...the fact is the more powerful our computers become the more demand is placed on them.
It's probably not simply the use of web technologies, but I'm quite sure it makes a difference. There's a lot of buzz about how slow Github's Atom is compared to Sublime Text, for instance. And BBEdit -- an old Mac text editor which often gets ignored these days as an unfashionable relic -- just loaded up a 24M, 181,000-line MySQL dump and is having no perceptible speed issues either scrolling the file or letting me insert new text on its first screen, even with syntax coloring enabled. The same was also true of Vim and Emacs (despite Emacs kvetching about the file's size when it loaded it).
It's my suspicion that the age of these warhorses may help them here rather than hurt them: serious editors twenty years ago required serious optimization work. While I do most of my programming in Sublime Text, there are certain times BBEdit is just the fastest tool for the job. If I was starting a new text editor, which I wouldn't, I'd be much more concerned about editing speed than it appears the developers of the current batch are.
It's probably not simply the use of web technologies, but I'm quite sure it makes a difference. There's a lot of buzz about how slow Github's Atom is compared to Sublime Text, for instance. And BBEdit -- an old Mac text editor which often gets ignored these days as an unfashionable relic -- just loaded up a 24M, 181,000-line MySQL dump and is having no perceptible speed issues either scrolling the file or letting me insert new text on its first screen, even with syntax coloring enabled. The same was also true of Vim and Emacs (despite Emacs kvetching about the file's size when it loaded it).
It's my suspicion that the age of these warhorses may help them here rather than hurt them: serious editors twenty years ago required serious optimization work. While I do most of my programming in Sublime Text, there are certain times BBEdit is just the fastest tool for the job. If I was starting a new text editor, which I wouldn't, I'd be much more concerned about editing speed than it appears the developers of the current batch are.
Modern applications have a host of demands placed upon them today that older ones did not. Whether it's complex theming capability, accessibility support, or special font/unicode support, things aren't so simple.
I say this as a long-time vim/emacs user... (yes, I've learned and use both although I primarily use vim).
So while I'll readily agree that I doubt they work as much at optimisation, they're also being asked to do significantly more.
I say this as a long-time vim/emacs user... (yes, I've learned and use both although I primarily use vim).
So while I'll readily agree that I doubt they work as much at optimisation, they're also being asked to do significantly more.
I think you're right, but Vim and Emacs and BBEdit all seem to have managed this without unduly choking. I'm not sure where the "fault" actually is in these specific cases -- if I had to place a bet it might be on the syntax scoping algorithms, as nearly every post-TextMate editor seems to re-implement TextMate's language files. (I don't know if Zed does.)
Let's not pretend emacs/vim are perfect; there are certainly situations where they slow down. I certainly have files where the syntax highlighting isn't so speedy or where it's temporarily broken.
I'm just trying to point out that attempting to compare applications from a certain period in computer history to modern applications is doomed to fail.
While I certainly believe optimisation work would help some modern editors, it would be silly to attempt to blame that all on optimisation work instead of recognising that the world is different now.
I'm just trying to point out that attempting to compare applications from a certain period in computer history to modern applications is doomed to fail.
While I certainly believe optimisation work would help some modern editors, it would be silly to attempt to blame that all on optimisation work instead of recognising that the world is different now.
> It's my suspicion that the age of these warhorses may help them here rather than hurt them:
Of course it does. Back in the day one couldn't take a megabyte file and say, "I'll just load it all into memory." When I worked in Visual Studio, it annoyed me to no end that VS had trouble loading large text files when ancient FoxPro (another MSFT dev product whose origins are from the 80s) would load them just fine. FoxPro didn't try to cram the whole thing in memory, just the parts it needed. I'm guessing vim and Emacs work in a similar manner. Don't use VS anymore, so I don't know if they ever fixed that or not. Particularly annoying is that it ever needed to be fixed, rather than being designed correctly (for which there was plenty of prior art) from the start.
Of course it does. Back in the day one couldn't take a megabyte file and say, "I'll just load it all into memory." When I worked in Visual Studio, it annoyed me to no end that VS had trouble loading large text files when ancient FoxPro (another MSFT dev product whose origins are from the 80s) would load them just fine. FoxPro didn't try to cram the whole thing in memory, just the parts it needed. I'm guessing vim and Emacs work in a similar manner. Don't use VS anymore, so I don't know if they ever fixed that or not. Particularly annoying is that it ever needed to be fixed, rather than being designed correctly (for which there was plenty of prior art) from the start.
>didn't try to cram the whole thing in memory, just the parts it needed. I'm guessing vim and Emacs work in a similar manner.
Yes, but with the caveat that it's line based (1 dimensional) not 2 dimensional so a VERY long line can still choke vim and Emacs.
--- long time primary Emacs, secondary vim user
Yes, but with the caveat that it's line based (1 dimensional) not 2 dimensional so a VERY long line can still choke vim and Emacs.
--- long time primary Emacs, secondary vim user
> it's line based (1 dimensional) not 2 dimensional so a VERY long line can still choke vim and Emacs.
Have an upvote because (to quote Johnny Carson) I did not know that.
Have an upvote because (to quote Johnny Carson) I did not know that.
Certainly true. (I'm old enough to remember TRS-80 word processors, only one or two of which were able to handle files larger than memory. SuperScripsit's ability to handle files as large as your floppy disk -- all, what was it, 180K of it? -- seemed amazing!)
Re: FoxPro vs. VS, it's probably quite unfair to suggest that it's in part because FoxPro didn't start its life at Microsoft, but I admit it was the first thing that came to mind...
Re: FoxPro vs. VS, it's probably quite unfair to suggest that it's in part because FoxPro didn't start its life at Microsoft, but I admit it was the first thing that came to mind...
> I doubt the issue is simply the use of web technologies...the fact is the more powerful our computers become the more demand is placed on them. Your web browser is just one more thing running on your computer, there are a bunch of other things influencing overall performance. You could replace the entire web stack of technologies and you would probably end up in the same place performance-wise.
Running a profiler would seem to suggest otherwise.
Running a profiler would seem to suggest otherwise.
>These technologies really weren't designed to support this sort of complex dynamic UI
I used to think of this when I saw UI developed in C++ (instead of pure assembler. Jesus, they would just multiply with a scan width instead of shifting!). I thought it when I switched to Windows (they're running everything through a giant abstraction layer here! That will never perform!). And yes, I find myself thinking this again now that the final bits of software seem to be moving into the browser. But this time, I'm going to assume that I'm probably wrong :-)
I used to think of this when I saw UI developed in C++ (instead of pure assembler. Jesus, they would just multiply with a scan width instead of shifting!). I thought it when I switched to Windows (they're running everything through a giant abstraction layer here! That will never perform!). And yes, I find myself thinking this again now that the final bits of software seem to be moving into the browser. But this time, I'm going to assume that I'm probably wrong :-)
Bottom line: What is the end user experience?
I don't care how many abstraction layers, VMs, and scripting languages you do or don't use. I care that my UI doesn't lag or have choppy scroll animations, and that the battery doesn't drain 2x faster than expected.
Yeah, eventually these problems will likely disappear with more powerful hardware. But we're not the yet, and a good engineer realizes hardware limitations and designs software appropriately to achieve a great user experience.
I don't care how many abstraction layers, VMs, and scripting languages you do or don't use. I care that my UI doesn't lag or have choppy scroll animations, and that the battery doesn't drain 2x faster than expected.
Yeah, eventually these problems will likely disappear with more powerful hardware. But we're not the yet, and a good engineer realizes hardware limitations and designs software appropriately to achieve a great user experience.
"software is getting slower more rapidly than hardware becomes faster"[1]
I was showing a junior some plpgsql yesterday and he asked me what languages use BEGIN, END etc. So I pointed him to Pascal and ended up myself on wikipedia where I (re)found the above quote.
One of the points people normally make for HTML/JS/CSS is that the browser is sandboxed and there is already a well defined standard on how to serve dynamic content to a browser, across ALL platforms.
This might change with all platforms moving to a package manager or walled garden, and we then might start to see some "native" code again. But even the new platforms op-in for web tech like Metro etc.
But meh I'm rambling again so I will leave who ever will read this comment with a link to vsftpd[2] security section because I liked the idea of sandboxing a application with chroot and with that you can start to build a "Secure" native app.
[1]: https://en.wikipedia.org/wiki/Wirth%27s_law [2]: https://security.appspot.com/vsftpd.html#security
I was showing a junior some plpgsql yesterday and he asked me what languages use BEGIN, END etc. So I pointed him to Pascal and ended up myself on wikipedia where I (re)found the above quote.
One of the points people normally make for HTML/JS/CSS is that the browser is sandboxed and there is already a well defined standard on how to serve dynamic content to a browser, across ALL platforms.
This might change with all platforms moving to a package manager or walled garden, and we then might start to see some "native" code again. But even the new platforms op-in for web tech like Metro etc.
But meh I'm rambling again so I will leave who ever will read this comment with a link to vsftpd[2] security section because I liked the idea of sandboxing a application with chroot and with that you can start to build a "Secure" native app.
[1]: https://en.wikipedia.org/wiki/Wirth%27s_law [2]: https://security.appspot.com/vsftpd.html#security
JavaScript is a slightly different situation. The degree of "sufficiently smart compiler" required to get C to run at assembly speed/power is nearly trivial (strength reducing multiply to shift? really not hard). On the other hand, the degree of "sufficiently smart compiler" required to map JS's type system and execution model to the machine is much higher and in some cases is impossible, which is why we have to use lots of JIT tricks (which takes power and time) just to get a mature, native-optimized JS program to run at half native speed at who-knows-what power.
Thank you for your constructive comments. I can work with this :)
fwiw the search is called fuzzy matching
also, gl on the project
also, gl on the project
Another interesting algorithm for fuzzy searching is this one: http://www.catalysoft.com/articles/StrikeAMatch.html
It essentially compares the number of matching two letter pairs in strings.
I used it in a C# app that did a fuzzy instant search as the user typed more letters in. On a dataset of about six thousand names it performed really well, but it was a pretty simple app. I also used a javascript version on the same list to see how it performed on an X120e netbook, and again, it was instantaneous.
No idea how the performance would compare to the methods for common substring. I like the pairs matching because I can screw up letter positioning and accidentally type a letter or two that doesn't exist in the string, but still get back strongly matching results and usually find what I want. I used it because we had a huge issue at work with people brutalizing names they entered into our employee database.
Here's an implementation I wrote in javascript: https://gist.github.com/doorhammer/3016ecaac5313a87804b
I never used it in production, and it's not optimized really at all, but it shows how straight forward a typical version can be.
It essentially compares the number of matching two letter pairs in strings.
I used it in a C# app that did a fuzzy instant search as the user typed more letters in. On a dataset of about six thousand names it performed really well, but it was a pretty simple app. I also used a javascript version on the same list to see how it performed on an X120e netbook, and again, it was instantaneous.
No idea how the performance would compare to the methods for common substring. I like the pairs matching because I can screw up letter positioning and accidentally type a letter or two that doesn't exist in the string, but still get back strongly matching results and usually find what I want. I used it because we had a huge issue at work with people brutalizing names they entered into our employee database.
Here's an implementation I wrote in javascript: https://gist.github.com/doorhammer/3016ecaac5313a87804b
I never used it in production, and it's not optimized really at all, but it shows how straight forward a typical version can be.
I took a quick look. What he described is essentially a specific case of n-grams (n=2, bigrams).
http://en.wikipedia.org/wiki/N-gram
http://en.wikipedia.org/wiki/N-gram
Thanks for the information. So it looks like it's a specific application of an algorithm to vectors of bigrams? The most relevant part of the wikipedia page (I think): http://en.wikipedia.org/wiki/N-gram#n-grams_for_approximate_...
It also appears that the algorithm I linked is actually the Sørensen–Dice index. They have the exact same formula on the wiki page: http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coef...
Appreciate the heads up. Gave me much better terms to search for. Going to add them to the notes of my gist. I'm on vacation now, so I'll have to do more reading on it over the next few days
Also made a public gist for whoever is interested:
https://gist.github.com/doorhammer/9957864
It also appears that the algorithm I linked is actually the Sørensen–Dice index. They have the exact same formula on the wiki page: http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coef...
Appreciate the heads up. Gave me much better terms to search for. Going to add them to the notes of my gist. I'm on vacation now, so I'll have to do more reading on it over the next few days
Also made a public gist for whoever is interested:
https://gist.github.com/doorhammer/9957864
And here's an explanation with some code examples: http://www.quora.com/Algorithms/How-is-the-fuzzy-search-algo...
On a related note, Komodo Edit/IDE has a great feature in their fuzzy matcher.
In ST3 for example, a space is basically treated like the regex /.*/
This means that if you type something you can only the filter results on the RHS of your input do far.
Consider: Models/player.js Controllers/player.js Views/player.js
If I type "play" then I need to hit home to filter further.
In Komodo, space is treated as a logical AND, which you can use to more effectively search the above.
I've not tried Zed yet, but if it can handle this case then that's a plus point from me.
In ST3 for example, a space is basically treated like the regex /.*/
This means that if you type something you can only the filter results on the RHS of your input do far.
Consider: Models/player.js Controllers/player.js Views/player.js
If I type "play" then I need to hit home to filter further.
In Komodo, space is treated as a logical AND, which you can use to more effectively search the above.
I've not tried Zed yet, but if it can handle this case then that's a plus point from me.
Visual Assist does the Komodo thing in its file name and symbol selectors. It's excellent. I've never used any other search mechanism that's quite so good for very quickly narrowing down large lists to a handful of items.
(emacs users may be familiar with iswitchb, which can be operated in a similar manner. Entering space-separated strings in Visual Assist is equivalent to entering those same strings in iswitchb and then pressing C-SPC after each one to perform each search on the result of the previous one. This is marginally more fiddly, but the key part is being able to narrow the list down with one substring, and then add more substrings to further refine things.)
I've added a similar Visual Assist-/Komodo-style UI for finding things to a couple of programs I've worked on, basically copying exactly what Visual Assist does. The response is always positive.
(emacs users may be familiar with iswitchb, which can be operated in a similar manner. Entering space-separated strings in Visual Assist is equivalent to entering those same strings in iswitchb and then pressing C-SPC after each one to perform each search on the result of the previous one. This is marginally more fiddly, but the key part is being able to narrow the list down with one substring, and then add more substrings to further refine things.)
I've added a similar Visual Assist-/Komodo-style UI for finding things to a couple of programs I've worked on, basically copying exactly what Visual Assist does. The response is always positive.
it makes me somewhere between depressed and angry whenever i type into an entry widget that cannot keep up with my keystrokes. i really don't know why this is not a drop-everything-and-fix-this bug, but the computing world seems to have accepted it as one of those things that happens.
I think this is because developers tend to have fairly fast computers, and simply don't realize that their program is slow on old hardware.
But does this happen with Zed? For me it works well even on old pentium4 desktop.
But does this happen with Zed? For me it works well even on old pentium4 desktop.
wasn't talking about zed specifically, just about text entry software in general. the worst offenders seem to be IDEs and web-based forms that want to do per-character callbacks.
>Can’t some random person fork the project and attempt same thing? Yep. Worse, they can fork the project, and create a proprietary version and start selling it.
If you released it under the GPL, then they would not legally be allowed to make a proprietary version and start selling it. Also, the GPL does not prevent you from selling your software: https://www.gnu.org/philosophy/selling.html
If you released it under the GPL, then they would not legally be allowed to make a proprietary version and start selling it. Also, the GPL does not prevent you from selling your software: https://www.gnu.org/philosophy/selling.html
Seeing as how this beverages web technologies (although it installs locally right now), AGPL might be a better choice. As long as he retains copyright, he'll be free to also sell commercial licenses if that becomes interesting/viable.
That said, having the legal right to something, and being able to enforce it, isn't the same thing (just ask Adobe).
That said, having the legal right to something, and being able to enforce it, isn't the same thing (just ask Adobe).
That's only because Adobe isn't in the movies business.
Yeah, that's right. Movies aren't subject to illegal downloads. /s
(On a more serious note, while I'm not a supporter of the draconian DRM schemes that have been enacted into law -- and while the studios make completely ridiculous claims for damages -- implying that films aren't being copied in a way that conflicts with their licensing terms is clearly wrong)
(On a more serious note, while I'm not a supporter of the draconian DRM schemes that have been enacted into law -- and while the studios make completely ridiculous claims for damages -- implying that films aren't being copied in a way that conflicts with their licensing terms is clearly wrong)
I REALLY hope he already knows this, as he's putting his career and saving on the line here.
Although I don't think he should go GPL, he should at least know about the license differences.
Although I don't think he should go GPL, he should at least know about the license differences.
I'm aware of the GPL, of course. I'm not a big fan of the political views behind the license.
Mh. Could you expand on that point? I know we are not supposed to discuss politics too much here, but I really see only benefits to the GPL, particularly in your case, and I wonder what are the opinions which make you say that.
Sorry for negativity, but is it really a code editor or yet another notepad clone with syntax highlighting? There are too many of the latter and almost none of the former.
I believe code editor to be called one must be designed to work with the code and provide standard facilities to manipulate upon it. The rest is for particular language support module that'd recognize semantics and do the transformations.
For example, the very core must have option to bind language module-provided semantics data to text fragments, so, say, highlighter (a proper one, not a TextMate-like mess of regexps) would base its work upon knowing not only "syntax regexp says this is a variable" but "semantic analyzer says this is a variable `foo`, and it's also used here and there, too (but not there, it's another scope), if that matters", while remaining generic.
(Edited: minor re-formatting)
I believe code editor to be called one must be designed to work with the code and provide standard facilities to manipulate upon it. The rest is for particular language support module that'd recognize semantics and do the transformations.
For example, the very core must have option to bind language module-provided semantics data to text fragments, so, say, highlighter (a proper one, not a TextMate-like mess of regexps) would base its work upon knowing not only "syntax regexp says this is a variable" but "semantic analyzer says this is a variable `foo`, and it's also used here and there, too (but not there, it's another scope), if that matters", while remaining generic.
(Edited: minor re-formatting)
This rant is a bit unfair, by your definition the only true code editors are big IDEs like Eclipse, Visual Studio or slim for emacs, and then only for a tiny subset of languages.
Most of us right now are probably writing code in "notepad clones" by your standards. I'm sure there is room for one more.
That being said, while reading the "Why Zed?" page[1] I kept thinking "emacs can already do that" all the way.
Well at least kudos for going open source, I wouldn't even consider investing time learning to use a closed source text editor, it's too important a tool to depend on the whims of the devs.
[1] http://zedapp.org/vision
Most of us right now are probably writing code in "notepad clones" by your standards. I'm sure there is room for one more.
That being said, while reading the "Why Zed?" page[1] I kept thinking "emacs can already do that" all the way.
Well at least kudos for going open source, I wouldn't even consider investing time learning to use a closed source text editor, it's too important a tool to depend on the whims of the devs.
[1] http://zedapp.org/vision
I'm inclined to agree with the OP. There is huge power in having a semantic IDE. Many old timers will say that Smalltalk is the most productive language they ever developed in, precisely because of the power of its semantic IDE.
Just a few things you get cheaply when your IDE is semantic aware: - Complex refactorings with a single keystroke - Context aware code completion - Instant feedback on potential compilation errors/type errors
You can sort of hack these things into something not semantic aware, but it's not quite the same thing.
Just a few things you get cheaply when your IDE is semantic aware: - Complex refactorings with a single keystroke - Context aware code completion - Instant feedback on potential compilation errors/type errors
You can sort of hack these things into something not semantic aware, but it's not quite the same thing.
That being said, while reading the "Why Zed?" page[1] I kept thinking "emacs can already do that" all the way.
"Oh here ... I have made a plane that flies"
"emacs can already do that"
classic.
That's because emacs can already do anything, if you're willing to learn how. Still though, it's not a very useful thing to say.
That wasn't my point really. Of course emacs lisp is turing complete so yeah, you could probably pilot an airplaine using an emacs AI, it's still pretty far fetched though.
On the other hand the features described in the page I linked are mostly already built into emacs, at most you need to flip a couple customization switches to get the same idea.
Basically: remove the toolbars, enable ido-mode, use tramp for remote editing. The splitting thing is built in although you'll need to redefine a couple functions to get the exact behaviour shown in the gif (nothing very fancy though).
On the other hand the features described in the page I linked are mostly already built into emacs, at most you need to flip a couple customization switches to get the same idea.
Basically: remove the toolbars, enable ido-mode, use tramp for remote editing. The splitting thing is built in although you'll need to redefine a couple functions to get the exact behaviour shown in the gif (nothing very fancy though).
There is plenty of room for competition. Everyone has their own needs and wants for a code editor and I would disagree with your definition. In general I want my code editor to be simple rather than try to be smart; be fast, do basic syntax highlighting, provide nice search.
+1 on the search part. I think Sublime shines there. I cannot imagine spending $70 for an editor, but I would really like it if Emacs' code browsing was as smooth as sublime's @
[deleted]
Curious, how do you browse code in Sublime that you can't in emacs? I've seen coworkers using Sublime navigate code much the same as I do in emacs which is mostly just by using incremental search.
I use Emacs at home and ST2 at work, and there are two things that ST2 does much, much better, both related to browsing large projects. One is scrolling - Emacs always wants to jump too many lines at a time, so it's very difficult to get lines of code exactly where you want them. The other is tree navigation - speedbar is more powerful, but you can't see multiple directories at once, which makes it hard to get a feel for the structure of the project as a whole.
Many times, I find myself just 'C-s' or 'C-r' (searching) in Emacs to the piece of code I want, even if it's already visible, then doing 'C-l' to get it centered. And when org-mode is loaded, 'C-l' will cycle through making the current line vertically centered, top of buffer, and bottom of buffer. Not sure it's what you're looking for, but that's what I do, and I'm sure there's a way to customize how far emacs will scroll ('M-x customize-variable RET scroll TAB TAB' might be a good starting point for looking into this).
I also mostly navigate using C-s and C-r. Also, when you do that you can recursively use C-u C-SPACE which brings you back to where you were previously, this feature is really awesome, since most of the time you move in the code temporarily to adjust something somewhere else or even just to lookup something somewhere else.
WRT scrolling, this is what I use in my .emacs:
(setq scroll-margin 0
scroll-conservatively 100000
scroll-preserve-screen-position 1)
(setq mouse-wheel-scroll-amount '(3 ((shift) . 1))) ;; one line at a time
(setq mouse-wheel-progressive-speed nil) ;; don't accelerate scrolling
(setq mouse-wheel-follow-mouse 't)
;; scroll window under mouse
(setq scroll-step 1)
I was specifically talking about
C-r file@function_name
All the parts are fuzzy. So if I wanted to go to function install_local_package in helper_functions.py, I can type
C-r h_fu@ins_l_p (pretty much like we use ido)
While I use Emacs for all my editing, this would have been cool to have.
While I use Emacs for all my editing, this would have been cool to have.
While I understand that it is useful to have semantic information (nothing stops Zed from having it from what I can see in its mode files which use ace-editor's modes currently), I don't really think a code-editor needs to come with semantic information for all languages it supports. I don't know if that is even possible in a generic way. I mean, the behaviour of scope itself isn't generic. There are dynamic-scoped languages (like elisp) vs block-scoped languages (Java) vs function-scoped languages (JavaScript) which are all syntax-highlighted by most popular editors. I would relegate such work to heavier IDEs.
Well, my point is not that multi-language code editor must provide semantic information for every language it can edit (that's just infeasible), but that editor's core must be designed with semantics in mind.
I.e., not "well, it's text and core has no idea what it is but plugins are free to do anything with that", but "well, core has no idea what that 'typeclass' thingy code analyzer says it is, but it's happy to keep track of it and provide standard interfaces to use this info so maybe highlighter or code folding parts would figure out how to use that information"
Then you could start with regexp mess-based parser that provides very basic understanding of the code and replace it with something that gives better code insight at later time, without rewriting the rest. And have generic refactoring module that can operate on many languages just by knowing about names and their possible scopes (whatever scoping type language is, in common cases I believe that still could be reduced to "in this text region").
I.e., not "well, it's text and core has no idea what it is but plugins are free to do anything with that", but "well, core has no idea what that 'typeclass' thingy code analyzer says it is, but it's happy to keep track of it and provide standard interfaces to use this info so maybe highlighter or code folding parts would figure out how to use that information"
Then you could start with regexp mess-based parser that provides very basic understanding of the code and replace it with something that gives better code insight at later time, without rewriting the rest. And have generic refactoring module that can operate on many languages just by knowing about names and their possible scopes (whatever scoping type language is, in common cases I believe that still could be reduced to "in this text region").
You nailed it. Do you know of any editors which work this way, except emacs?
Unfortunately, not many.
I've heard LightTable is doing something like this, but never had a time to properly evaluate it and see for myself.
Also, JetBrains' IDEs (IntelliJ IDEA, PyCharm, etc.) are notorious to have good understanding of code semantics, both out of the box and through plugin system.
I've heard LightTable is doing something like this, but never had a time to properly evaluate it and see for myself.
Also, JetBrains' IDEs (IntelliJ IDEA, PyCharm, etc.) are notorious to have good understanding of code semantics, both out of the box and through plugin system.
It seems to have at least autocompletion and ctags support. Not really something for me, but best of luck to the author.
Congrats on launching, this looks like an interesting project.
Sorry if I missed this from the post, but is there any particular reason why Zed is tied to Chrome? Are there any technical benefits?
P.S. I am asking because I am currently involved in a project of similar type - a web based GUI for databases (MySQL, Postgres, MSSQL, Oracle) - Datazenit[0], but we decided against shipping it as a packaged Chrome app, because it would narrow potential user base.
[0] - http://datazenit.com/
P.P.S. Just to let you know - link to your twitter account is broken (https://twitter.com/zed_editor).
Sorry if I missed this from the post, but is there any particular reason why Zed is tied to Chrome? Are there any technical benefits?
P.S. I am asking because I am currently involved in a project of similar type - a web based GUI for databases (MySQL, Postgres, MSSQL, Oracle) - Datazenit[0], but we decided against shipping it as a packaged Chrome app, because it would narrow potential user base.
[0] - http://datazenit.com/
P.P.S. Just to let you know - link to your twitter account is broken (https://twitter.com/zed_editor).
The author mentions the benefits of sticking with chrome -
* Cross platform: Zed runs on any platforms that desktop Chrome runs on (including Chromebooks)
* Installation is easy with just a few clicks
* Upgrades are automatic
* Settings are automatically synchronized between all computers logged into with the same Google account.
* Special “Notes” space is stored in Google Drive and synchronized between computers automatically as well.
Link - http://zedapp.org/
* Cross platform: Zed runs on any platforms that desktop Chrome runs on (including Chromebooks)
* Installation is easy with just a few clicks
* Upgrades are automatic
* Settings are automatically synchronized between all computers logged into with the same Google account.
* Special “Notes” space is stored in Google Drive and synchronized between computers automatically as well.
Link - http://zedapp.org/
Take the underscore out of the Twitter link.
I'm using it for a few months after 10 years of Vim.
It's very similar to Vim, with proper defaults and JavaScript as approachable language compared to vimscript.
I believe the most innovative thing Zed introduces is hackability. Configuration is basically just another project inside the editor.
Other cool features/defaults are presented on http://zedapp.org/features/
It's very similar to Vim, with proper defaults and JavaScript as approachable language compared to vimscript.
I believe the most innovative thing Zed introduces is hackability. Configuration is basically just another project inside the editor.
Other cool features/defaults are presented on http://zedapp.org/features/
I read that you're not sure how you will earn an income but basically, you will depend on the generosity of your users. If I might try one tip:
Who are you? What drives you? Tell us a bit about yourself on your website. I think it will help with income.
Who are you? What drives you? Tell us a bit about yourself on your website. I think it will help with income.
Apologies if this is OT, but does anyone have link(s) to a "Making Money From Open Source for Dummies" guide? The only options I'm aware of:
1. Donations.
2. "Open core" or "freemium" model.
3. Paid books/lectures about it.
4. Get hired as a consultant to teach, trouble-shoot, and/or customize.
5. Get hired as an employee to work more on it or something else.
However other than 1, none truly consist of getting paid for the open source per se. Which maybe works out OK, anyway.
To clarify, this is not a rhetorical question where I'm trying to slag on open source. I'm already doing a number of open source projects, and enjoy it. I'm genuinely interested, if I wanted to support myself doing open source, realistically what are the options? And I genuinely don't fully understand how.
1. Donations.
2. "Open core" or "freemium" model.
3. Paid books/lectures about it.
4. Get hired as a consultant to teach, trouble-shoot, and/or customize.
5. Get hired as an employee to work more on it or something else.
However other than 1, none truly consist of getting paid for the open source per se. Which maybe works out OK, anyway.
To clarify, this is not a rhetorical question where I'm trying to slag on open source. I'm already doing a number of open source projects, and enjoy it. I'm genuinely interested, if I wanted to support myself doing open source, realistically what are the options? And I genuinely don't fully understand how.
[deleted]
Charge for the installer. If I want to use a tool I do not want to try to compile it
One option is building an open source framework to be the base for your commercial projects. Rails and Django started this way.
What XChat does is charge for the official Windows binary[1] while being open source. I think something like this would be a good option for Zed.
[1] http://xchat.org/windows/
What XChat does is charge for the official Windows binary[1] while being open source. I think something like this would be a good option for Zed.
[1] http://xchat.org/windows/
There's lots of approaches (as you note), but if I had to boil them down to a rule of thumb it would be this: give away functionality, charge for convenience.
You love our app, but want an MSI installer so you can deploy it on your network more easily? You can roll your own by checking out our source code here... or you can pay us $X for this already-made-and-thoroughly-tested installer.
You love our app, but want to learn more about how it works? You can browse this repository of 15,000 Doxygen-generated API pages... or you can pay us $Y for this beautiful book that explains everything in plain English.
You love our app, but want someone who can support it if something goes wrong? You can spend ten years turning someone on your staff into an expert on it... or you can pay us $Z for this support contract, and get access to our experts.
This approach can feel counter-intuitive to geeks, because we value functionality more than convenience, so it feels "wrong" to charge for the things we see as needless frills. But in general, people put a lot of value on convenience, and they are more than willing to pay for it if you're willing to provide it.
Sometimes people try the opposite approach -- charging for functionality. (i.e. "Try the open source edition of our app, or pay $X for the Premium Edition and get custom fields!") This rarely works.
You love our app, but want an MSI installer so you can deploy it on your network more easily? You can roll your own by checking out our source code here... or you can pay us $X for this already-made-and-thoroughly-tested installer.
You love our app, but want to learn more about how it works? You can browse this repository of 15,000 Doxygen-generated API pages... or you can pay us $Y for this beautiful book that explains everything in plain English.
You love our app, but want someone who can support it if something goes wrong? You can spend ten years turning someone on your staff into an expert on it... or you can pay us $Z for this support contract, and get access to our experts.
This approach can feel counter-intuitive to geeks, because we value functionality more than convenience, so it feels "wrong" to charge for the things we see as needless frills. But in general, people put a lot of value on convenience, and they are more than willing to pay for it if you're willing to provide it.
Sometimes people try the opposite approach -- charging for functionality. (i.e. "Try the open source edition of our app, or pay $X for the Premium Edition and get custom fields!") This rarely works.
Thanks, that's really helpful advice. I'm going to call this The Dead Kennedys principle of monetizing open source.
If you are planning on having plugins, some of them could be paid.
6. Let people pay you to develop their favourite/urgently needed features on a priority basis
On ChromeOS, I got stuck on the very first screen:
I can either enter a Project or a URL to edit. Typing text in either place does nothing interesting. "Enter" does nothing.
Clicking around, I can't find any way to make a new window. All I want to do is see your editor and start playing with it. I don't even really want to edit a file yet. No obvious way to make any of that happen.
The first window is too small. The note about how to edit remotely requires scrolling, but it isn't obvious that the page needs to be scrolled.
I can either enter a Project or a URL to edit. Typing text in either place does nothing interesting. "Enter" does nothing.
Clicking around, I can't find any way to make a new window. All I want to do is see your editor and start playing with it. I don't even really want to edit a file yet. No obvious way to make any of that happen.
The first window is too small. The note about how to edit remotely requires scrolling, but it isn't obvious that the page needs to be scrolled.
You can edit a local project (click "Open Local Folder"), a Dropbox folder ("Open Dropbox Folder") or the built-in Notes, Configuration and Manual projects. None of those work? Works fine my my Chromebook.
Even after making the window big enough so I don't have to scroll, this is all I see:
http://imgur.com/9WWEFmz
http://imgur.com/9WWEFmz
I really want to suggest rewriting it in native code. A web based editor is a fine side project but if you want it to be a business people pay for, it needs to have native performance.
It's popular to claim that the web is near native performance, but honestly, it's a load of horseshit. Web performance is better than it's ever been but it still has a long way to go before it's anywhere near native.
It's popular to claim that the web is near native performance, but honestly, it's a load of horseshit. Web performance is better than it's ever been but it still has a long way to go before it's anywhere near native.
But then he will spend a huge amount of time replicating functionality that browsers provide, functionality which is hard to implement and hard to maintain. Also will loose advantage of being easy to extend.
But on what kind of computer did you test this? On my windows desktop it is as fast as sublime. On mac scrolling isn't smooth, but from chrome timeline i see that it is choppy because it doesn't handle scroll events correctly, not because of performance.
But on what kind of computer did you test this? On my windows desktop it is as fast as sublime. On mac scrolling isn't smooth, but from chrome timeline i see that it is choppy because it doesn't handle scroll events correctly, not because of performance.
I hope it works out for you.
I'll be hesitant about the productivity pitch though...a lot of developers don't truly care about productivity in the way that one would expect. Often what opinionated developers want is something that conforms to their opinions, productivity just becomes a convenient excuse for the choice of a particular tool.
At least as someone who's spent a lot of time pitching productivity to developers I have become skeptical that developers value it as much as one would ordinarily expect. I am the developer of HiveMind (crudzilla.com), a web app platform that literally allows you to get a whole bunch of things done with writing little to no code. I find this pitch simply doesn't fly with a lot of developers :)
The open source pitch for instance is something I am sure will get you some followers, though how big a following is not certain.
Welcome aboard the entrepreneurial train!
I'll be hesitant about the productivity pitch though...a lot of developers don't truly care about productivity in the way that one would expect. Often what opinionated developers want is something that conforms to their opinions, productivity just becomes a convenient excuse for the choice of a particular tool.
At least as someone who's spent a lot of time pitching productivity to developers I have become skeptical that developers value it as much as one would ordinarily expect. I am the developer of HiveMind (crudzilla.com), a web app platform that literally allows you to get a whole bunch of things done with writing little to no code. I find this pitch simply doesn't fly with a lot of developers :)
The open source pitch for instance is something I am sure will get you some followers, though how big a following is not certain.
Welcome aboard the entrepreneurial train!
> a lot of developers don't truly care about productivity in the way that one would expect
A lot of developers are also mature enough not to think that the choice of the developing environment matters (above a reasonable base level, of course).
All serious environments are configurable and programmable. It's a plain matter of taste what you use.
A lot of developers are also mature enough not to think that the choice of the developing environment matters (above a reasonable base level, of course).
All serious environments are configurable and programmable. It's a plain matter of taste what you use.
I agree that productivity is more than dev environments.
However productivity to me means something very simple, how quickly can you go from "I want x" to having a functional x.
The more a tool is helpful in this regard the more productive it makes me.
Maybe someone should start a service that actually measures various dev products in terms of how quickly they allow you to complete various dev tasks.
For instance most web apps are just CRUD apps, it should be possible to benchmark various frameworks/tool to see how quickly they facilitate development....it should make for an exciting exercise :)
However productivity to me means something very simple, how quickly can you go from "I want x" to having a functional x.
The more a tool is helpful in this regard the more productive it makes me.
Maybe someone should start a service that actually measures various dev products in terms of how quickly they allow you to complete various dev tasks.
For instance most web apps are just CRUD apps, it should be possible to benchmark various frameworks/tool to see how quickly they facilitate development....it should make for an exciting exercise :)
Biggest issues with Zed:
1) Chrome extension (I understand the stand-alone application is coming)
2) Vim-style modality missing (exact keybinding replication is not necessary, just the principle of remaining on the home row)
3) Excess editor chrome - the top of the editor takes up 2 lines when it could be compacted to 1
1) Chrome extension (I understand the stand-alone application is coming)
2) Vim-style modality missing (exact keybinding replication is not necessary, just the principle of remaining on the home row)
3) Excess editor chrome - the top of the editor takes up 2 lines when it could be compacted to 1
Yes, I'm a Firefox user, and when I install extensions I don't expect being asked to provide a login and password. I'm definitely NOT comfortable with Google knowing what extensions I use, when I use them, etc. A nice reminder of one of the reasons I can't seriously consider Chrome as my main browser.
Zed highlights the always forgotten necessity of documentation. The app looks great. Has a few quirks but seems otherwise stable and I LOVE being able to edit remote files with a local editor.
But I don't care how good your app is; if you didn't write documentation then you're just not done. And don't go giving me that adage "its open source! contribute the docs yourself." The fact is, its YOUR project that YOU wrote and it is simply incomplete with little/poor documentation.
So, to the Zed author: before adding anymore features please take some time and write good quality docs. The community will thank you.
But I don't care how good your app is; if you didn't write documentation then you're just not done. And don't go giving me that adage "its open source! contribute the docs yourself." The fact is, its YOUR project that YOU wrote and it is simply incomplete with little/poor documentation.
So, to the Zed author: before adding anymore features please take some time and write good quality docs. The community will thank you.
There are too many editors named Zed, please get a different name to reduce the confusion (and it can't be Xed)
Yes ! I get excited because the author lists "Reduce cognitive load" at the editor's first goal. It's not an absolute and easy to measure metric but is worth having having as a first class citizen. Plus he already proves that he's moving in that direction by removing the concept of open/closed files.
For funding: how hard would it be to create a "shared hire" subscription model where participants get a vote into what the author is doing ?
For funding: how hard would it be to create a "shared hire" subscription model where participants get a vote into what the author is doing ?
Hi, first off, love that you've decided to keep it open source (lack of open-source code is what pushed me away from sublime into the arms of my current mistress, emacs), keep up the good work!
Can I digress into a feature suggestion? This is no small one and I don't really know where it lies on a feasibility scale. One thing I'd really like would be the ability to turn whatever text-box I'm writing in into a frame of my current editor (I currently use edit-with-emacs). I looked into writing a chrome-extension (which is the only way I can think of to accomplish it) with ACE editor to do this but I didn't have enough time.
My thoughts are, since you use a web based editor, you can use javascript to replace the input box with a resized frame of your editor, the next requirement is importing your personal user settings from your chrome packaged app into the frame to have it working there (I currently don't know how you'd accomplish this, maybe some integration with google drive which you already have for your notes?).
The main reason I think this would be a useful feature is vim keybindings, I use them for everything and feel less productive editing text without them. Being able to integrate the IDE that I use and am used to into every text box ubiquitously on the web seems like a huge win to me.
Sorry about the digression, it's just I liked the sound of your application and wanted to share the one thing I've been missing online (which is a web-based editor where it's extensible, and can be used on any site, I do realise that there is a big gap between your project and my feature suggestion, just wanted to make it.)
Can I digress into a feature suggestion? This is no small one and I don't really know where it lies on a feasibility scale. One thing I'd really like would be the ability to turn whatever text-box I'm writing in into a frame of my current editor (I currently use edit-with-emacs). I looked into writing a chrome-extension (which is the only way I can think of to accomplish it) with ACE editor to do this but I didn't have enough time.
My thoughts are, since you use a web based editor, you can use javascript to replace the input box with a resized frame of your editor, the next requirement is importing your personal user settings from your chrome packaged app into the frame to have it working there (I currently don't know how you'd accomplish this, maybe some integration with google drive which you already have for your notes?).
The main reason I think this would be a useful feature is vim keybindings, I use them for everything and feel less productive editing text without them. Being able to integrate the IDE that I use and am used to into every text box ubiquitously on the web seems like a huge win to me.
Sorry about the digression, it's just I liked the sound of your application and wanted to share the one thing I've been missing online (which is a web-based editor where it's extensible, and can be used on any site, I do realise that there is a big gap between your project and my feature suggestion, just wanted to make it.)
We actually talked about that feature a good bit when working on Bespin (in 2009). I haven't used it in years, but you may find this bookmarklet helpful:
http://ajaxorg.github.io/ace/build/textarea/editor.html
http://ajaxorg.github.io/ace/build/textarea/editor.html
Interesting, but needs a few tweaks:
- I simply cannot resize the windows on a Mac using the Accessibility API (I'm using Moom to tile my windows via keyboard bindings, and Zed is invisible to it) - Needs a few more docs on how to set up a theme (I tried three times before I managed to set Solarized on) - As much as it may seem counter its philosophy, I need vim bindings :)
And yes, it's a tad slow. So is LightTable, which is why I am still using vim inside a terminal...
- I simply cannot resize the windows on a Mac using the Accessibility API (I'm using Moom to tile my windows via keyboard bindings, and Zed is invisible to it) - Needs a few more docs on how to set up a theme (I tried three times before I managed to set Solarized on) - As much as it may seem counter its philosophy, I need vim bindings :)
And yes, it's a tad slow. So is LightTable, which is why I am still using vim inside a terminal...
> I’m making Zed my day-time job
I'm super excited for you! Passion & Dedication! Bravo
I'm super excited for you! Passion & Dedication! Bravo
Much success and wisdom to you in your efforts - love the courage, and your eagerness to take feedback.
As to the app, my recommendation is to avoid putting .zedstate files inside the project directories themselves. Instead, keep them in a ~/.zed/ directory. Keeps folks from having to make special .gitignore commits for all of their projects.
As to the app, my recommendation is to avoid putting .zedstate files inside the project directories themselves. Instead, keep them in a ~/.zed/ directory. Keeps folks from having to make special .gitignore commits for all of their projects.
FYI, BitDefender shows site as infected: http://trafficlight.bitdefender.com/info?url=http%3A//zedapp...
Might want to check it out, I got a bit red alert before I could visit the page.
Might want to check it out, I got a bit red alert before I could visit the page.
Thanks for making this a Chrome App! This will fill a big gap for me on my Chromebook, especially the ability to edit Dropbox files. You should add Google Drive support as well if possible, since you're already in the Chrome ecosystem.
I like Zed author's choices. I don't think there's anything new in them per se, but a different combination of small existing principles may breed an interesting culture. Good luck.
At first glance, it appeared to be a Zed Shaw thing to me.
I'm glad to not be the only one who thought "he's writing an editor now?"
I'll give this a try. I've been knocking around looking for a new OSX editor, and haven't been completely happy with any of them. Current editor-of-choice is Light Table, but I'm not in love with it.
It's really interesting to try all these new, modern editors and see the subtle tradeoffs the creators made.
It's really interesting to try all these new, modern editors and see the subtle tradeoffs the creators made.
Do you have plan on making the Zed server described in http://zedapp.org/features/edit-remote-files/ to allow concurrent edit of the same file by different clients to enable collaborative work?
I would love to use a chromebook as my main development machine, but the main thing is that I would like to be able to use Git offline. Has anybody moved to a chromebook as their main machine and been able to use version control while not connected to the internet?
One option is to put the Chromebook in dev mode and use Crouton[^1] to install Ubuntu as a chroot. It's easy to do and works well. You can use ChromeOS as usual side by side.
[1]: https://github.com/dnschneid/crouton
[1]: https://github.com/dnschneid/crouton
The Spark project ( https://github.com/dart-lang/spark ) is porting git to work on ChromeOS. I'm not sure how far along they are.
I have, assuming installing Ubuntu on it isn't cheating.
Reading some of the ideas made me update my .vimrc a bit. The point that buffers versus files is mostly useless now is on point. The rest of the points about minimal UI I already use. Create files same way you find them, sure!
I can't avoid thinking it is a sweet attack vector for being a browser extension... I would probably use it if i have to edit on a chromebook, but then again, i prefer to avoid touching chromebooks even with a 10ft pole.
He should also take donations, not just letting people buy the software.
[deleted]
You say: "Worse, they can fork the project, and create a proprietary version and start selling it"
So why not release the source code under GPL or even MPL or EPL?
So why not release the source code under GPL or even MPL or EPL?
It's nice, simple, usable. But whenever I maximize the app window, it just goes fullscreen. Is it supposed to be like that? Or is it a bug?
I would like the ability to highlight all instances of a highlighted word, like in Notepad++
Yeah this is the most important feature in editor.
But did you try zed? it already has this feature.
I believe his math forgets that we pay 40+% taxes out here in SV :)
Nice job all around. Will check it out
Nice job all around. Will check it out
Can someone give me their opinion of Zed vs Sublime? I'm curious.
node-webkit is amazing, but is it really suited for an IDE? I don't see how you could launch a node-webkit application as fast as Sublime Text for example.
Amazing, that really close to what I thought Atom was going to be, "just" a webapp.
Mac OS X seems to be incredibly widely used by programmers now. Because every time I see a screen shot to illustrate some GUI, it was taken on a Mac. :)
> Zed currently is only available as a Chrome packaged app
Sorry: this is not the kind of OSS that I want to support. Best of luck, though.
Sorry: this is not the kind of OSS that I want to support. Best of luck, though.
Next paragraph:
> The stand-alone version will be built on top of node-webkit and be available for Mac, Windows and Linux. Once the initial work there is done, both version should continue working from the same code base, so I should be able to support two versions (Chrome App and standalone) without much effort.
> The stand-alone version will be built on top of node-webkit and be available for Mac, Windows and Linux. Once the initial work there is done, both version should continue working from the same code base, so I should be able to support two versions (Chrome App and standalone) without much effort.
[deleted]
standalone (node-webkit) is in development.
I wonder if this guy's success so far is based on Zed Shaw's tech fame. There should be a trademark on tech personalities.
"Like that" being that we don't care if a file is open or closed. If I'm swapping between 2 files a lot, I will just swap buffers, but usually I just navigate straight to whatever file I need and open it. If it's already open, the buffer will come up; otherwise a buffer will be created. ido-mode makes it trivial to query files/buffers: https://www.youtube.com/watch?v=lsgPNVIMkIE
(edit: inversely, ido-mode actually saves a history of opened files so if you try to switch to a buffer of a file that isn't open, but you've opened before, it will transparently open it for you and it feels like it was never closed)
Also, same thing with file creation. I'll just navigate to the file I want to create and hit enter.