+1 on this. If you need to ask why you would need a fast key repeat your editor usage pattern is quite different from that of every developer I know. Which is totally ok, I'm just saying that programmers tend to care about the performance of their text editor.
I have very few prime requirements on a text editor: be able to open arbitrarily large files, be blazingly fast, be very configurable, be able to perform batch operations on a large number of files, have regex search and replace. That's pretty much it. I don't need syntax highlighting, fancy pants auto complete, connections to ftp servers, etc. That's what I have IDEs and other tools for. With a text editor I need to be able to open a hundred files, keep track of which files are which, do some operations on them *fast*, close the files, open a bunch of other ones, etc. I have loved all BBedit versions prior to 10. I mean really loved. One of the reasons I really like working on my mac book used to be BBedit. With version 10 I feel like Bare Bones has switched tracks. Perhaps their marketing department had a bigger say this time? Whatever the case, the feeling I get is that they changed the target audience from technical people to something else. A few examples of things I think went wrong: - The selection key repeat issue. That they ship this just blows my mind. I suspect the slow rate is caused by parsing for syntax highlighting or similar, but I really couldn't care less. If the editor fails on the prime requirements, none of the extra bells and whistles matter. - The removal of a ton of the configuration options. Sure, make the config UI more user friendly, but taking config options away? Why? Look at google applications like GMail which I suspect most people would agree are quite well designed from a usability perspective. The settings are not in your face...but if you really want them they are there for you to find. - The new "open documents" file navigation which is ordered by file name. Recently I had to open about 200 files all called MANIFEST.MF. Trying to get any work done on these files in the new 10 UI was just hopeless. The old 9 document navigation was great as it used a most-recently-opened approach to the ordering. With the new open documents setup I need to count rows...this is the 56th MANIFEST.MF file...57th, 58th, 59th, open. Oh and you can not keyboard navigate (as in press the up and down arrow keys) to change the selection in the open documents drawer. So you have to mouse click on the 50 files leading up to the one you are looking for to make sure you have the right one. - The alternative of course is to use the "recent documents" drawer. But they chose to limit the size of that window to about a 10th of my available screen height. And it is not configurable (if it is, please somebody correct me). Try loading 200 files into the recent documents drawer and see how usable it is. With my current settings it shows about seven documents at a time. I would love to just not show the open documents drawer and only display the recent documents drawer using the full height of the window. Not possible as far as I know. - I work best when visual clutter is at the minimum. Because of this I tend to always have the document selector on the right hand side. This so that I can always find the code at the left edge of the window, independent of how long the file names of the open files are or if I'm even displaying the document selector. In previous versions of BBedit it was possible to configure your document navigation to either side. Not so anymore. Guess that was judged "non user friendly". Hans Dokter, creator of the gradle build framework put this very succinctly: "There are always requirements a build framework can not anticipate. It should therefore provide the users with a set of tools to support whatever requirements or problems they might encounter in their enterprise". I think the same goes for a text editor. If you streamline the user experience of the editor too much you are essentially dictating to your users how they should go about performing their daily jobs. If you take away configurability, you take away the ability to tackle unforeseen usage scenarios. For all the years of delivering a great product, I would like thank the team at Bare Bones. Lets hope these issues are transitory and caused by the release of a major version and that Bare Bones is true to their legacy, welcomes input from their users, and fixes some of the usability issues in upcoming releases. -- You received this message because you are subscribed to the "BBEdit Talk" discussion group on Google Groups. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at <http://groups.google.com/group/bbedit?hl=en> If you have a feature request or would like to report a problem, please email "[email protected]" rather than posting to the group. Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>
