CotEditor – Text Editor for OS X
coteditor.com
coteditor.com
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.
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.
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!
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.
[1]: https://www.dropbox.com/s/r2da0rc7spgpxqq/Screenshot%202014-...
The alextgordon fellow that replied to me upthread is one of the principal people behind it.
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)
CMD-SHIFT-P is CMD-SHIFT-D
Multicursor find is CTRL-F, CTRL-SHIFT-F and CTRL-ALT-F
I guess what it really needs are a set of sublime keybindings.
Maybe another suggestion would be executing (Python) programs in the main interface instead of executing them in the terminal.
To people not familiar with Mojibake, this is a Japanese word in 4 different encodings:
UTF-8: 煩わしい
ANSI: ç…©ã‚ã—ã„
SJIS: ”ς킵‚¢
EUC: Ûáªïª·ª¤
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.
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 now use Ctrl-V or "+p depending in gViom depending on what mood I am in. Nice to have a choice.
So, it's definitely possible to switch, you just have to be able to deal with that ramp up.
I pretty much use sublime text for everything these days.
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.
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.
More information at: http://en.wikipedia.org/wiki/Vi
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 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.
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.
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 only use Atom for coding and vim for just about everything else.
The most difficult part for me is that i'll open a file in vim and then consciously go "no" <close it> and fire it up in one of the other editors.
Why? because I like to keep my vim more clean. I've seen some of the really complex vim configs out there and they just didn't "do it" for me.
So if i want complex things like syntax highlighting I go with Atom.
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 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?
It was very rewarding, and I use Emacs everyday now. Today, I can't imagine not using it.
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. ;-)
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.)
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)?
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 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.
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.
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.
- File/directory browsing (think Norton Commander) - Email client (several of them) - Terminal (vt100) - Remote file browsing/editing (think WinSCP, Cyberduck) - Games (Sokoban, Tetris)
It's not "subtle".
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.
3) It's got momentum: https://github.com/textmate/textmate/commits/master
All in all it's close though, and I didn't consciously choose to use Textmate 2... I just found myself reaching for it more often.
I don't see the point in changing your editor if you don't feel it's necessary. Surely one should gain something from a change of editor...
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.
If you want that live web stuff, you can try skewer-mode: https://github.com/skeeto/skewer-mode
I still have the fundamental vi(m) motions in my bones... but I prefer emacs today.
[0] http://agentultra.com/2008/11/12/seeking-enlightenment-in-a-...
[1] http://agentultra.com/2008/11/19/seeking-enlightenment-in-a-...
- code navigation: jump to anywhere instantly. DEMO: http://tuhdo.github.io/static/c-ide/helm-gtags-jump-dwim.gif.
- code completion: context-sensitve completion. DEMO: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif.
- 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.
- code debugging: provides a frontend for GDB; DEMO: http://tuhdo.github.io/static/c-ide/gdb-many-windows.gif.
- Powerful automatic indentation: https://github.com/Bruce-Connor/aggressive-indent-mode. It does not only indent the current line, but the whole Semantic context around your cursor. Demos inside the homepage.
- Live grep: http://tuhdo.github.io/static/live_grep.gif.
- Access to a list of project with a few key strokes: http://tuhdo.github.io/static/helm-projectile/helm-projectil...
- Quickly access any file in your project, as large as Linux kernel, instantly, regardless of where you are in the project, and within a few keystrokes: http://tuhdo.github.io/static/helm-projectile/helm-projectil...
- 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...
- Copy files from anywhere to anywhere: http://tuhdo.github.io/static/helm-projectile/helm-projectil...
- Delete files anywhere; files are always at your finger tip to do whatever with them: 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.
- Jump to tag definition, from its own parser or external parser like GNU Global: http://tuhdo.github.io/static/c-ide/helm-gtags-jump-dwim.gif
- Do you like outline tree?: http://tuhdo.github.io/static/c-ide/sr-speedbar.gif
- Interactive outline tree: http://tuhdo.github.io/static/part3/helm-semantic-or-imenu.g...
- References retrieved from its Emacs internal parser: http://tuhdo.github.io/static/c-ide/semantic-symref.gif
- Beautiful compile output: http://tuhdo.github.io/static/c-ide/compilation-compile.gif
- Frontend support for GDB: http://tuhdo.github.io/static/c-ide/gdb-many-windows.gif
- Open man page for symbol at cursor: http://tuhdo.github.io/static/part3/helm-man-woman.gif
- Emacs open 39MB C file: http://tuhdo.github.io/static/performance.gif
- Emac opens multi-gigabtye file: http://www.emacswiki.org/VLF
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.
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.
Definitely not less than Sublime.
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'll still use vim for quick tasks since it doesn't make me switch out of terminal context.
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.
Maybe I'm just being too grouchy. This editor looks impressive.
(I don't know the developers)
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.
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.
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.
Some people crave the recognition a successful open source project gives.
Some want to learn something.
Some want to give a gift to the world.
Some don't want the hassle of supporting software.
Some believe "from each according to their ability, to each according to their need"
One explanation, like you point out, is that they are free to work on a project such as CotEditor because they are financially secure.
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.
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.
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.
But I won't be using Chocolat anymore, after they pulled a bait-and-switch so that Version 2 can't be used without you paying for version 3.
Bad dev, no cookie.
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.
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.
At least it's not Eclipse. So there's that.
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.
This means you could keep the project under GPL v2, but people would have the option of using a later GPL version.
The author is always free pick any license of their choosing for work that they have themselves has authored.
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.
s/I think you may be/You are/
Wrong tool for the wrong job.
A new law of the land!
Seriously, tools are meant to solve problems, not to dictate what problems people should solve.
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.
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
Have things improved? Might be time to try again?
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.
there is a big part of HN crowd whose whole life purpose is to downvote something they didn't like or don't understand
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.
One question: For a text-editor focused on programming, why doesn't it come with a monospace set as the default?
I wish getting out of the find text box was simpler and more intuitive.
Maybe it's just me.
I don't want to donwload and uploadmy files with an external program or to mount remote filesystems.
You cannot save this document with extension “.hs” at the end of the name. The required extension is “.(null)”.
A major 'distinguishing' feature IMO is that it's open source, and very actively under development.
Who is this for? This is not a feature I want.
It is, however, a perfectly valid preference to have.
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.
The key bindings and their customizability, standard or not, are part of the reason these tools are better than the HID-blessed equivalents.
This question is like whining about a F1 racer because it doesn't have windshield wipers.