Looks beautiful and well-designed. Clearly a lot of effort has gone into it. I can't say I will try as I don't see enough selling points to peel me away from Sublime. I see some features that seem to address some pain points of Japanese users, so maybe that demographic will be more interested.
Looking at the screenshots, I have to wonder why the developer chose to place the settings for line endings, encoding, and file content type in prime real estate: the top left corner. Something's wrong upstream if you have to deal with these settings. They've rarely, if ever, caused me problems and I don't want to see them. They just work 99% of the time. Maybe not so much for Japanese users.
I think the developers need to put on a their business hats and figure out who the target audience is and tailor their pitch to them. I don't seem much here that would change people's text editor habits away from Vi, Sublime, Atom, etc. That said, this definitely must have been a very good learning experience for the developer.
I can confirm that text encoding is still a real pain in Japan. Despite the fact that we now have UTF-8, which should be used whenever possible, legacy encodings like SJIS, EUC, etc. still abound.
For instance, whenever I download CSV bank or credit card data here in Japan, I always have to convert the file from one of those encodings before using it. At work in Tokyo, I deal with email in these encoding (or worse -- parts of the email in SJIS, with other parts in EUC).
So yes, I think the barbaric text encodings of yesteryear are still a pain point for Japanese users. (Even so, I agree that it doesn't merit top billing in the window toolbar.)
Off-topic bonus tip for aspiring text editor authors: make an awesome autocompletion UI, but leave the indexing/autocompletion up to third party open source plugins. Look at Chocolat.app for what the completion UI should look like (a big, attractive complex popover view (not just a menu) with optional documentation display), but open up the actual dynamic completion itself to your users. There is no way a small team can do good completion in tons of languages, but providing a great UI is totally doable.
Off-topic response: w.r.t. code completion plugins in Chocolat, the hard part is already done. With v3, the plugin API is now process-separated, and communication is over mach ports. Now that there's a stable, non-blocking and low-latency foundation for plugins, all I need to do is figure out a good API for it.
My advice to aspiring text editor authors would be: do development on the slowest most outdated computer you can find. I use a 2007 iMac: 2GHz, 3GB of RAM and a 128MB ATI Radeon 2400. If the app works OK for me, it should work awesomely for everybody else!
That is great to hear! I bought Chocolat (a purchase mainly instigated by the hilarious "the demo expired so it still works, but only with Comic Sans font" gimmick). And I even sent friends screenshots[1] raving about its completion UI.
But... Chocolat didn't really stick for me, with the plethora of editors I already use. Even though it's good.
I would definitely revisit it, if it got extensible completion.
The auto complete in Chocolat is just mind-blowing.
Unfortunately I really miss all the keyboard friendly features in Sublime (CMD+P then write the name of a file; CMD+SHIFT+P and write a command). I think if you had those implemented many Sublime users may consider switching to Chocolat. (then there are also features that may be harder to implement, like Sublime's search and multi-cursor selection)
> I see some features that seem to address some pain points of Japanese users, so maybe that demographic will be more interested
Definitively. The three selling points are explicited as "OSX only", "Japanese friendly" and "open source".
Anyone who doesn't care about japanese text encoding is out of the targeted demographics (it still can be interesting in other contexts, but that might not be in the author's priorities). For anyone in the demographics however, it would be a solid replacement of Textedit or any other "casual" or prose oriented text editor.
I'm pretty effective with vim, so much that other 'normal' editors like sublime & other modern gui editors make me feel a little crippled. That is a problem, because you need to be flexible about things in life.
Has anyone succeeded in deliberately changing editors, even when not feeling like it's necessary? I'm especially curious how I could start using emacs, and actually get up to speed with it instead of using it as Notepad/TextEdit (as I would do if I started today)?
Has anyone succeeded in deliberately changing editors, even when not feeling like it's necessary?
This can only be answered through anecdote, so mine is: it's really tough.
I'm competent in both Vim and Emacs, with a mild preference for Vim. But I used Homesite in the very early days of the web and got used to that somewhat CUA/GUI style of editing; when I moved to BeOS (really, I did for a while) I used Pe, the programmers' editor there, and then to the Mac and BBEdit, then TextMate, then Sublime. Despite the fact that I moved across five editors and three platforms, the basics -- opening and saving files, simple navigation by character, line and board, using the clipboard, search/replace, and even basic navigation -- were for practical purposes identical across these editors. I think it's easy for experienced Vim/Emacs jockeys to downplay how important that is. It's the advanced features that make us love our editors, but sitting down in front of a new editor and realizing you're going to need to read a tutorial just to figure out how open a file and oh God what was the key that started the tutorial again is a hurdle which, in a world with a plethora of good editors that all use standard keys we've already known for the basics, often doesn't seem like it's worth jumping through.
I've actually put in the effort to try and customize both Emacs and Vim with all sorts of packages that add the features I miss from Sublime and predecessors. I think my Vim setup is probably pretty awesome, tweaked and re-tweaked through multiple iterations. But I've noticed that when I want to work on a big project, almost without thinking about it I'm still going to open either Sublime or BBEdit and be into it for a few hours before I think, "Man, this would have been yet another opportunity to get better with Vim. Oh well."
I didn't so much change editors as start using multiple editors. On OS X, I regularly use vim, TextMate, and BBEdit.
I find that TextMate looks the best. I simply enjoy typing code into TextMate more than I do in vim or BBEdit. Thus, when I'm doing a stretch of writing new code, or straightforward modification of existing code, I'll probably do it in TextMate (although some days it just feels like it is a vim day or a BBEdit day).
If I need to make a lot of related changes, I'll switch to vim, and use regular expressions or I'll record a macro to repeatedly apply.
If I'm doing something like making some modification at all places that use a particular database table, I'll probably go to BBEdit. I can do a search for that table and click "find all", and it gives a separate window showing all the matches, with an editing section in the bottom part that shows whichever search result I click. This lets me easily see all the places where the table is referenced, and easily edit them, and go back and forth as needed. It works similarly with the results of a multi-file search, which makes it nice when I'm trying to understand crusty old legacy code.
If I start a work session in TextMate, and switch to vim to do something with macros, I'll probably stay there and continue editing. When I exit the editor to test the code, then I'll probably head back to TextMate. Same if I go to BBEdit for something--I'll stay there until I need something that is better in vim.
I realize I'm not making full use of the capabilities of one or more of these editors. BBEdit can certainly do most of the things vim can do, and all of the things I use vim for, for instance, but I'm fine with simply popping into vim for those things.
I use Text Wrangler for quick access by SFTP to my code (open server / edit / save). I don't like the SFTP window much, but it does the job. TW is also very good for processing text: sorting, removing duplicates, applying regex-es, filtering and vertical columns.
I tried using Sublime and I did get along well with it for a few projects, but when I am jumping around on various servers, I prefer Text Wrangler's shorter setup. Why doesn't Sublime manage SSH better?
Ah I'm the same. I used Komodo IDE for big projects, Vim for stuff when I'm in a terminal or for Hack work (until I finish my Hack plugin for Sublime, anyway) and TextAdept for super quick text editing on big files.
> Has anyone succeeded in deliberately changing editors, even when not feeling like it's necessary? I'm especially curious how I could start using emacs, and actually get up to speed with it instead of using it as Notepad/TextEdit (as I would do if I started today)?
I used to use Textmate at the University. Then XCode at my first job. Then I learned Vim, since every hacker in the internet seemed to love it, the usual story... (big plus: many IDEs have very good Vim key bindings)
Then I simply wanted to know what Emacs would be like. I took a bit of a productivity hit for about a week or two, but not more. Over the next year or so I read the Emacs manual and dove deeply down the rabbit hole. It has been four years now. Somewhere along the way I picked up enough elisp to be dangerous.
TL;DR: Want to learn a new editor? Just do it. There's no magic to it. Do the tutorial, RTFM, take the short-term productivity hit.
I'm in the intermediate to advanced level of Vim user and I switched to emacs. It's easier than you might think thanks to evil-mode.
My emacs acts just like vim thanks to that mode. Literally every keybinding and combination I used works. I switched because configuring vim with vimscript is a pain and at the time of my switchover using other languages to configure was even worse. I like elisp as the config language. That's probably not exactly the question you were asking though since It's less like I switched editors and more like I upgraded ViM's configuration language.
Just like with web browsers, I use multiple editors all day long on OS X. Currently open, I have: Sublime 3, Textmate 2, BBEdit 11, Xcode 6, Rubymine 6, and (only because I visited this post and just downloaded it) CotEditor 2.
There is certainly a tradeoff in the sense that I don't tend to memorize all the features of every editor, so I may not be as effective in any of them as a power user who sticks to one of them. OTOH, the Mac has excellent basic text conventions for word/line/paragraph selection, indent/dedent, etc.
Also, I tend to use the different editors for different purposes. Batch find/replace? BBEdit. Objective-C? Definitely Xcode, it't the only native editor with even semi-reasonable autocomplete. Scripts and single-file text documents? These days Textmate 2 (used to be Sublime).
So you still end up knowing the shortcuts and advanced features that apply to your editing scenario, even though they may not be in the same editor. But you don't get the raw, low-level text editing power that comes with mastering something like vim (which I do use a lot, too, but with such polygamous editing habits, am unlikely to master).
The upside of using multiple editors is that you can pick the one that suits you best for the job at hand; another fringe benefit is that you also get to enjoy countless hours trying out every single new editor that comes out. ;-)
BBEdit's multi-file search and replace (and it's compare) alone are worth it. I keep coming back to BBEdit for search and replace, even if I prefer other editors for other things.
I use a lot of different editors too, rotating among favorites. The one thing I do not consistently use are modal keyboard-centric editors like vim and emacs. I get that some people like them, but they've never done much for me. (And yes, I do know how to use them. I'm old enough that I upgraded to vim early on.)
> The one thing I do not consistently use are modal keyboard-centric editors like vim and emacs.
As a vim-er and not an Emacs-er, asking genuinely and not out of snark, surely Emacs is eminently non-modal (at least, not modal in the same way that vim is)?
emacs has plenty of modes, although actually that's not really my big problem with emacs (or vim) when I think more about it. It's needing to remember stuff rather than recognize and select (which is the fundamental advantage of GUI, if you don't like remembering things).
Most of the stuff I see vim/emacs-ers boast about are easily achievable by me with a mouse or so obscure that I'd never remember them when I needed them. But that's me. Some people are good at and/or like remembering shortcuts.
This is not the sense in which vim is called a modal editor—at least, I think of it as meaningfully different. In different Emacs major modes, for example, the tab key might create different indentations; but, in different vim modes, the 'x' key might remove a character (in normal mode) or insert an 'x' character (in insert mode).
I think of the statement "vim is a modal editor" as "vim replaced key chords with mode toggles"—a different editor would replace "press 'x' in normal mode" by something like "press 'M-x'."
Again, I am certainly aware that Emacs modes can do much more than just offer context-sensitive indentation, but my impression (as a non-Emacs-er) is that they are usually meant to offer subtle customisation rather than full-scale re-engineering of the editor.
You never need to remember keyboard shortcuts for major modes. When you forget, you can always bring a "cheatsheet" using "C-h m" which lists all key bindings of current major modes and minor modes. Every time I'm new to a major mode, I always use this table. If you forget any key binding but remember prefix key, I press <prefix key> + C-h to bring all the key bindings that start with that <prefix key>. If you ever forget key binding but remember the command, use helm-M-x that list key bindings along side with the commands. DEMO: http://tuhdo.github.io/static/part3/helm-m-x.gif . In Emacs, I NEVER remember things consciously; I keep using something until it is recalled effortlessly. On the other hand, it's not like you don't have to remember things with those fancy GUIs. Take Eclipse as an example. You would have to steps through meaningless GUIs to configure something to work, and you have to remember those steps mechanically the next time you setup something. I would rather learn a consistent programming language with actual easy to remember rules to first configure simple things, and later extend my editor, rather than stepping through those meaningless GUIs.
And what you said that most of the stuff that are easily achievable with a mouse, try to do equivalent things like this in SECONDS: http://emacsrocks.com/. Well, that's why my co-workers work so hard why I have time to enjoy other things during my daily work.
What you said, like many other people who didn't learn Emacs properly or left it for so long that don't know what Emacs is currently capable of, is seriously outdated.
You should have a look at my post in this thread: https://news.ycombinator.com/item?id=8639804 to see what Emacs is capable of that I could never find in any other editors, and even IDEs.
> Well technically Emacs is just a Lisp interpreter with some text editing facilities by default. With evil-mode it is just as modal as vim throughout.
I don't mean to suggest that Emacs can't be made into a modal editor—saying "Emacs can't do that" is good only as a reverse-psychology tactic to convince someone to make Emacs do that—but rather that it is not "by its nature" such; that is, that someone is unlikely to choose Emacs, over vim say, because it can be made modal.
Emacs can make Vim a subset of it. You should check spacemacs: https://github.com/syl20bnr/spacemacs. It was made by Vimmers and is ambitious: it wants to replace not only the "editor" inside Emacs, but also rebind everything else to Vim's convention. Evil-mode can do everything in Practical Vim, I was told by a Vim user switched to Emacs.
Well, the EVIL-mode is used by a lot of people who want the features of GNU Emacs and a modal interface. If you search around there are several people with detailed reports why and how they switched to a modal GNU Emacs.
Yeah, that surprised a lot of my friends, too (especially considering my 2010 blog post[1] entitled "Mother fuck TextMate to hell").
But it won me over in a few of ways:
1) It's a native Mac app. An honest to goodness, OS X app with native widgets, text Services in the contextual menu, and an all-around attractive UI that works well with just about every OS feature.
2) It's open source now. Even though I haven't yet fixed any of my issues with it... I could.
This just came up recently and my previous comment was upvoted, so please forgive me for repasting a link to an old post of mine where I described switching from vim (~10 years experience) to emacs (now at ~5 years):
I succeeded. And haven't gone back. It took me about two weeks to transition. I had 10 years of vi(m) behind me when I gave emacs a go. I wrote about it back in 2008[0][1].
I still have the fundamental vi(m) motions in my bones... but I prefer emacs today.
I switched from Emacs to both LightTable and Atom full-time. While I'm much more efficient in Emacs, integration are the killer features in the other two, in a way that I didn't have my .emacs setup.
With LightTable, I do mostly WebGL and I often have a browser tab up with my live WebGL stuff all the time. This is super efficient and extremely nice.
With Atom, I do mostly web development. Quickly jumping between files (faster than I did in Emacs) and knowing which files have been changed (they're highlighted in the tree-view) is very helpful for all work-related things.
It's pretty easy actually. Just get drunk one night and bash your head against a wall few times. This will make you forget all the keyboard shortcuts and you're free to learn a new text editor.
Since learning VIM I have got (with no addition effort) better at learning keyboard shortcuts for all kinds of different apps I use. Vim (or Emacs etc.) literally makes you smarter.
I now use Ctrl-V or "+p depending in gViom depending on what mood I am in. Nice to have a choice.
Sublime Text has an excellent plugin called Vintageous that gives you a lot of Vim's functionality with some of the niceties of Sublime, worth a shot if you felt crippled by it.
I have never had success with these plugins. I apparently begin typing too fast after hitting Escape and invariably the plugin can't handle that and it enters things like ":w" as text instead of processing it as a command. Obviously this isn't a problem in Vi/Vim proper but all of the Vi*-style plugins for any of the IDE's or editors I've tried--from Eclipse to Sublime--always break.
I was mainly Java dev for 10+ years or so; I was a whiz at Eclipse. Then, one day, I forced myself to learn a Clojure. It just so happened the ecosystem mainly leveraged Emacs. And so, I forced myself to learn Emacs. It took a while - the key bindings, reading up on how to do various things, discovering great packages, learning enough Emacs Lisp to be dangerous.
It was very rewarding, and I use Emacs everyday now. Today, I can't imagine not using it.
My progression was Vim -> Emacs -> Sublime. Funnily enough, on systems with no Sublime I still tend to use Vim.
It took me about a month of consciously making myself work in Emacs to get a hang of it. But I don't use any major features, like macros.
Emacs is awesome for Python indenting, for example, but when I switched to a less elaborate indenting convention, I kind of just drifted away from Emacs.
Just noticed your comment there. And seriously impressive material there.
And I've settled with Sublime not because I think it's absolutely superior to Emacs. But mostly because, I've noticed, that I don't use the advanced features that often, and when I do, I always have to look them up in a cheat sheet or my O'Reilly book on Emacs. And Sublime is a bit jiffier on a Mac, then XEmacs or AquaEmacs.
I'm in the process of switching from vim to atom as my primary editor. Loving atom so far. The command palette makes it easy to be productive when you don't know the shortcuts yet, and it's also a very hackable editor.
I'll still use vim for quick tasks since it doesn't make me switch out of terminal context.
- code compilation: you can click on the error and it gets you to where you want; work with any build system, while other IDE only supports a specific build system, i.e. for Makefile project, you only get plain text error message. DEMO: http://tuhdo.github.io/static/c-ide/compilation-mode.gif.
- Jump to any file depends on context, even if the file path is in a plain ASCII text file; even if there's only a filename without any path information, as long as it's in your project, Emacs can jump to it fine: http://tuhdo.github.io/static/helm-projectile/helm-projectil...
- Switch between other files with same names but different extensions: http://tuhdo.github.io/static/helm-projectile/helm-projectil... Work not only for C/C++ but other languages, and is customizable. You don't have to configure anything, like adding include paths. Everything is automatically done for you.
RE: Has anyone succeeded in deliberately changing editors?
I am currently learning Vim and using it with the NERDTree plugin as a fairly nice environment to write Ruby on Rails code in my spare time. It is also nice as I have a low power PC running ubuntu in a virtualbox. So Eclipse is a no-no anyway.
At work I use Visual Studio but have a Vim open all the time for where the Vim advantages outweigh the visual studio advantages. Often this is in editing config and xml files. C# Code files are nicer to edit in Visual studio with autocomplete, debugging etc.
Main things I love about Vim - being able to split and tab quickly from the keyboard. And all those keyboard shortcuts to do practically anything. And it is fast. I really hate Eclipse now! Visual Studio is OK but Vim is so fast and lightweight.
Installing VsVim was thing that really helped me get comfortable with vim. I'd use it at home, but I write way more code in the ~40hrs/week I'm at work.
VsVim doesn't cover everything, so as you start to get more advanced in your vim usage you'll start to miss features (for me at the moment, it's only partial support for folding). But it really makes every day VS so much better.
I tried that, but with no easy way to turn it off (without uninstalling it) it feels a bit 'in the deep end'. Once I am happy with using Vim productively I may try it.
Another concern with this is pairing, as there is no easy way to turn it off. Although staying in insert mode and keeping the default bindings for VS may be OK.
it does allow you to easily default back to visual studio handling all of the commands. In fact, it's quite nice for a tweener vim user because you can have visual studio handle all the more complex keybindings that you don't recognize and just use it for the subset of commands you're comfortable with, and move from there
When I first broke into web development, my editors of choice were Coda, Dreamweaver and Visual Studio (I wonder if I am dating myself here). I made a mid-career move to (non-gui) Vim, mostly out of general interest. The ramp up to Vim coming from GUI-heavy editors was a long one, but I stuck with it and it was worth it for me.
So, it's definitely possible to switch, you just have to be able to deal with that ramp up.
I've been trying out vim for a while, hoping to get more productive, but the fact that "hjkl" is not "jkl;" -home keys- and that I have to reach all the way across the keyboard to hit [esc] every three seconds is not helping...
I pretty much use sublime text for everything these days.
You can also remap Esc to jj by adding the following to your vimrc
inoremap jj <Esc>
The hjkl thing feels weird for a long time but it becomes natural after a while. I used Sublime for a long time with the Vintage plugin (vim like movements and some other vim features) before moving to Vim and that made the transition much easier for me. I still like Sublime, but Vim's full integration with the terminal environment is hard to beat.
Out of the box, ctrl-[ is mapped to escape. It took me about a week to un-learn Esc, but it is one of the better vim decisions I've made (along with mapping j to gj and k to gk, and mapping tab to :bnext).
> but the fact that "hjkl" is not "jkl;" -home keys-
On American keyboards, anyway. That isn't how the keys are laid out on modern Dutch keyboards, though I don't know what they were like when Vim was created.
Vim inherited the keyboard mapping from vi. vi was designed on a QWERTY (American) keyboard, but the particular terminal that the author used had arrows printed on the hjkl keycaps.
My original reason for learning vim was so that I could be effective when shelled into a box. I quickly became much more productive with it than any other text editor I tried to use after. Atom caught my attention, but I would up installing the vim bindings and eventually switching back.
This is awesome, but I wish developers would charge for polished, full-featured software like this. The people who made this probably have full-time jobs; meanwhile, independent developers who want to break into this niche now have to compete with "free". This results in a market ruled by large corporations that can "subsidize" free software via the spare time of their employees.
Maybe I'm just being too grouchy. This editor looks impressive.
Well maybe that is the point. The developers get paid, somehow, so why do they need to get even more money? This way more people can use their software because it is free.
Yeah. I can definitely see the point. I also realize that open source software is often a political statement, and good for that. But at the same time, I want to see a world where a developer could earn money from making cool applications like this without relying on a large corporation for the bulk of their paycheck. It's what the free-to-play app store model is coalescing to, and I don't like it.
Sure, but what is a right price? Shall all code editors cost the same and differentiate on features? Otherwise it seems to me like a race to the bottom where CotEditor people charge $30 and indie developer charges $25. So what about the next indie developer then? $20?
And yes you are right, as developers we tend to publish useful stuff more often for free than not. But maybe it stems from our inability to market cool applications so that we get money for them.
Astounding. That's potentially the most harmful opinion a developer could possibly hold.
The single greatest benefit of having our skill set is that we are capable, in a way that few other people in the world are capable, of single handedly building products that we can sell for the kind of money that frees us from needing to work for other people. We can quite literally create our own destiny.
And you would throw that away.
I can't even begin to fathom why you would want to live in that world.
Money isn't what we're optimizing though. It's freedom.
Having a software product as income source means you don't have to have a day job working for somebody else. It means you can spend your time doing whatever you want, be that working on your own personal projects, surfing, traveling or, yes, earning more money. You can even choose to build open source Mac text editors and give them away for free.
It's your choice what to do with that freedom. The important point is that we, as software developers, are essentially handed that freedom by nature of our skill set.
That's a really cool thing. So while I can see an entitled end-user saying something like the grandparent's "you already have a job that pays you, so give us the output from your nights and weekends for free", it's surprising to see that attitude from somebody who would be most impacted, were that to become a reasonable expectation.
I'm not really sure how practical it is to sell an open-source desktop application; anyone can compile and run it for free and the 'sell support' model usually isn't viable for something as simple as a text editor.
You underestimate the difficulty of compiling from source for the layman. OSX and Windows do not come with compilers out of the box. The user would have to install them and the proper environment for them first. (cygwin, etc...) Then they'd have to get and install the dependencies properly. Finally they'd have to figure out the proper incantations to make it compile, which if you've never done it before can be extremely daunting. How on earth was I supposed to know what an LPATH is or pkgconfig? Not to mention the extremely verbose and scary looking errors from gcc.
That's assuming that it's a program written in C/C++. If it's another language then you might have another huge hurdle to go through. (Properly installing Go in my PATH took me a while). That's also assuming they don't rely on IDE-specific make files. A lot of the time OSX applications rely on xcode project files. The other day I was trying to compile an Android app before realizing that it was written in a language by Adobe which required the purchase of a full suite.
Open source can be really limiting if the developer doesn't make an effort to document the build process well and doesn't use open tools to create the product.
The problem is, only one person has to figure out how to build it, then if it's real free and open source software, they're legally allowed to distribute their own unofficial builds over the internet. The original XChat developer decided that it was too much effort to develop XChat for Windows, so he charged for it, which resulted in silverex's free X-Chat 2 builds and the HexChat fork.
I don't think users respond well to this either. You're essentially splitting your userbase into a group of people who know enough to build it themselves and receive it for free, and a group that have to pay, and I don't think people in the latter group appreciate being in that group.
Hmm I didn't think about that. I guess that's a genuine option for popular applications. Personally, for some unpopular applications I've tried to compile, I just gave up if the standard `./configure && make` didn't work.
As for your second point, I think it comes down to two things: if the user's time is more valuable than their money, and two, if they can get support for the paid product (at least that's how I've seen some products doing it), so it's not as if the paid is without it's benefits. Your Hexchat example shows how important it is to not alienate your users though.
How about releasing the source without any of the art assets or interface nibs? Full benefit of open source while still providing high value for money. (Sure, the geeks will go and create their own assets, but it won't be the same.)
Interesting idea, but I suspect that the first quality fork that provides a 'good-enough' version of those missing assets out of the box would start to steal the limelight from the main project, especially because the fork could pull in all the bug fixes and new features from upstream.
Welcome to the free market. If the price decreases, it means the offer is too large and it should happen.
I'm very afraid the government would one day impose a minimum price for everything, and poor families will never have a shot at any productive activity and will just stay poor forever.
In my country, they voted a law that bans free newspapers and imposes a minimum cost of about 50 cents. Why limit access to knowledge and the effects of a free market? This is the whole "job creator" logic all over again.
I like it. Obviously won't replace a programmer's favorite editor, but for quick things you need to write throughout the day (code or not) it's a good replacement for TextEdit.
I'm using Netbeans at work now, on a Mac, and the experience has been considerably less than ideal. The UI is almost, but not quite Mac-like (to be fair, when I've used it on Windows, the UI was almost-but-not-quite Windows-like) and I keep running up against things that seem like they should be configurable but are not.
It's like Netbeans was designed by people who had UIs described to them, then semi-randomly decided that was stupid and they could implement them better without doing any research about why those things were the way they were.
It works. It doesn't suck as much as it could. That's about the best I can say about it.
Not-quite-Mac-like is way worse than not-at-all-Mac-like.
Look at Sublime and Atom. Completely customizable and identical across platforms. I'd prefer that level of honesty to the fake-Mac interfaces that try and fail to look native.
I love NetBeans on Windows, but it's terrible on Mac if you're a Dvorak typist and you want to use keyboard shortcuts. For some reason, when using the Dvorak layout, NetBeans can't decide whether to interpret a key press as Dvorak or QWERTY when using shortcuts, and often it uses both. For example, the W key in QWERTY is a comma in Dvorak. If you press Cmd-, to invoke the Preferences dialog, it interprets this as both Cmd-, and Cmd-W, so it brings up the Preferences dialog and closes the current file.
IntelliJ has very good IDEs. But their IDEs would be even better were they native OS X applications. For example, you can't use the Mac OS X services like "Look up in a dictionary" in IntelliJ.
For me, it's the open and save dialogs that bother me most. I quite like the editor, especially as compared to Eclipse, but for source editing, I'd rather use one the OS X editors like TextMate or BBEdit.
Sublime is the best cross-platform app I've ever used. I can count on one finger the number of times I've used something that felt native on more than one platform.
The license is GPL v2; you might want to consider using “Version 2 of the GPL or any later version” as GPL v2 is unfortunately incompatible with the Apache license. Also, the GPL v3 is becoming more and more popular nowadays.
This means you could keep the project under GPL v2, but people would have the option of using a later GPL version.
I've never liked this idea. What's to keep the FSF from adding a "you give us royalty-free rights to all your patents for eternity" as a clause in GPL v4?
The author is never forced to use a later version. "Version 2 of the GPL or any later version" simply means that distributor (other than the author) can choose between using gplv2, gplv3, gplv4 and so on.
The author is always free pick any license of their choosing for work that they have themselves has authored.
This editor addresses my need for something simple but 'programmy' - I develop Xamarin Mac apps on OSX and have been frustrated not finding anything I like that is between TextEdit and Xamarin Studio in functionality and useability. Awesome!
The File Drop feature is interesting. I'm not sure what it would be useful for though—for me, anyway, it's faster to just type that kind of stuff out. Good to see something fully scriptable too.
Nice looking. But I can't use it as is now — it has no tabs/sidebar for more documents. TextWrangler FTW.
I actually run Notepad++ via Wine too for HTML. It's the only editor I've found that can expand and contract a hierarchy of *ML using plus and minus signs in the marginal of the editor. Difficult to explain, I guess you have to try it to understand.
It's indispensable and I can't be without it. I'd love to go native, but I haven't find an editor for OS X that does this.
Nice, but in the kind of dev work I do, I need to be able to work with text files that are hundreds of MB, even over a GB, in size, and CotEditor chokes on 200 MB text files...
Why do you have text files that are 200MB? Why don't you separate that into multiple files? 200MB of text? Moby Dick is 1MB in plain text. The Holy Bible is like 4MB in plain text. What is in your files? I think you may be doing something wrong.
We deal with data sets that are several GB in size, and so I'm already using just a subset of the data. These files are loaded by programs into memory and serve customers via a REST API, and it's not uncommon that we have to manually inspect or change the files from time to time.
Our use of large text files isn't only internal; our software also processes delimited text files for customers, and these can run into the same size ranges, and it's out of our control. But when the service bombs, we need to be able to prove to them that their file is malformed, and if it isn't, we have to fix our data or our code. That usually requires inspection of text files.
But that's all beside the point. This looks like a fine source editor for basic needs, but I wouldn't consider it a tool for general "plain-text" editing like it says on the site.
Whenever possible, the machine should accommodate the human rather than vice versa. Viewing a 200MB file in a text editor is not an outrageous request on a modern computer. Maybe he's not working optimally, but why should he change if his approach should work, and does work fine with other tools?
No single file of source code should ever be even close to 200MB, and no data file (CSV, XML, etc) of that size should be manually edited in a text editor.
Vim and Emacs are quite well-suited for textual manipulation of very large data files. Use of a macro is a very pleasant alternative to piping the file through sed/awk/etc. for a once-off transform.
This sed substitution thing seems to be a cute trend to express "fixed that for you". It goes nicely with programmer's propensity to express themselves in needlessly arcane ways.
recently I replaced OSX on my macbook to Ubuntu and I'm very pleased for the following reasons:
1. better key shortcuts: no hassle to maximize, windows ninja moves without additional software, can do every UI operation with keyboard (most common with cmd+num run/bring back app), fn + arrow works as cmd+arrow on osx, same key shortcuts, UI on all desktops I use everyday
2. easier software install: apt vs brew (ex. installing postgres was pain in ass for me recently on osx)
3. no OSX maximize button madness
4. default file manager is much better on Ubuntu (eg. easy way to modify current path with ctrl+l)
5. same dev machine OS as production - no additional steps for docker (boot2docker etc)
6. sublime works great
Ubuntu has good support for my (non-retina) macbook 2012 (no driver problems at all!)
All this on default Ubuntu installation - no special tweak (except enabling mac WIFI driver in UI driver configurator) - so it just works.
I do understand someone likes OSX specific UI etc. but for me Linux (Ubuntu) matured enough to be better dev machine than OSX
how is battery life? Last time I tried installing linux on a macbook pro (1) the machine ran hot all the time and (2) the battery life was seriously reduced compared to using os x.
I really have no idea why someone would downvote your honest answer.... This is getting out of hand.
Anyway, in my experience it's been about 50-70% worse battery life on ubuntu compared to OSX. Which, as you point out, is no issue if you don't need all 4 or 8 hours of the full potential of MacBook battery life. A meeting might last 2 hours for me at most, but if traveling, battery life is a deal breaker for me.
The second screen shows the search an replace dialogue, which is its own floating window. I can't tell from the screen shot whether it is modal.
Anyway, search is an incredibly crucial feature for navigation. It has to be fast, and non-modal. Even having it in a separate screen is suspect in my book.
Just a first impression: that Find box looks highly out of place within an OSX interface. Are those native yosemite UI controls? If so, that seems like one less reason to upgrade: terribly crowded buttons, for example.
I don't know how it could be easier: You position inside a word anywhere, press CMD+OPTION+G; the next word is already selected, you can already edit it, no need to bring up Find panel.
This doesn't seem to work well as it highlights multiple instances of the word I was on. The current instance and the next instance(but not all instances).
cmd + e will mark the current selection (or current word if there's no selection), cmd + g (or cmd + shift + g to go backwards) will find other instances of it. ctrl + cmd + g will find all instances of the current word, which you can edit simultaneously.
The distinguishing feature is it's horribly slow with large files. The performance is an order of magnitude slower than sublime text. And it doesn't auto-save unsaved work if it closes. Both deal breakers for me.
> There is no complex setting files require geek knowledge. You can access all your settings incl. syntax definitions and themes from a normal preferences window.
I think the clearest answer is: "It's not for you, then."
I've written and edited plenty of runtime configuration files, but there is this to say for GUI preference panes: you don't need to bother with learning a new language, even a simple one, for every other program. Set it up, and then use it. Maybe occasionally define a new text snippet.
I know many heavy users of editors and IDEs who are by no means power users, with their dotfiles on version control and everything. There is a distinct difference. In all honesty, I don't think either group is more productive than the other except on a very micro scale.
.png){kind=link}
Looking at the screenshots, I have to wonder why the developer chose to place the settings for line endings, encoding, and file content type in prime real estate: the top left corner. Something's wrong upstream if you have to deal with these settings. They've rarely, if ever, caused me problems and I don't want to see them. They just work 99% of the time. Maybe not so much for Japanese users.
I think the developers need to put on a their business hats and figure out who the target audience is and tailor their pitch to them. I don't seem much here that would change people's text editor habits away from Vi, Sublime, Atom, etc. That said, this definitely must have been a very good learning experience for the developer.