slow repeat rate in 10 on lion

[tpneumat]

Hi. New BBEDIT 10 is really nice! However, I have with just 1 issue
and it's almost a show stopper for me. The keyboard repeat rate is
too slow in the app. I have a screaming repeat rate, which I have set
to 15ms with KeyRemapForMacbook http://pqrs.org/macosx/keyremap4macbook/.
Works great in everything else, like terminal, etc. However, it
almost seems like BBEDIT is 'lagging' when I type and feels more like
the slow setting when using the default preferences in System-
>Keyboard. When there is more text on the page, it gets even slower.
I am wondering if there are some settings, etc that I can disable to
make it faster or some other tricks. I disabled everything I could
think of like spelling and auto balancing, but to no avail.

I have a early Macbook Pro 17 unibody and am now running Lion.
Running version 10.0.1 (3072) of Tue, 09 Aug 2011. CPU seems to show
some mild increase like 10% or so when holding down key and trying to
repeat quickly in BBEDIT. No other apps do this that I have seen so
far.

Thanks,

Jeremy

[Christopher Stone]

On Aug 31, 2011, at 14:59, tpneumat wrote:

The keyboard repeat rate is too slow in the app. I have a screaming repeat rate, which I have set to 15ms with KeyRemapForMacbook... Works great in everything else, like terminal, etc. However, it almost seems like BBEDIT is 'lagging'

______________________________________________________________________

Hey Jeremy,

I can confirm that this occurs on my Mid 2010 17" i7 MacBook Pro.

And I agree it's a bit frustrating.

--

Best Regards,

Chris

[tpneumat]

Glad I'm not the only one. The problem is also greatly exaggerated
when shift-arrow selecting text. It makes doing selections with
keyboard only almost impossible...which is a big deal in a text editor
for me, since I keep my hands off the mouse as much as possible.

On Aug 31, 5:29 pm, Christopher Stone <listmeis...@thestoneforge.com>
wrote:

[Seth Dillingham]

On 9/1/2011, tpneumat said:

>Glad I'm not the only one. The problem is also greatly exaggerated
>when shift-arrow selecting text. It makes doing selections with
>keyboard only almost impossible...which is a big deal in a text editor
>for me, since I keep my hands off the mouse as much as possible.

Holding down the option key when shift-arrowing to select might
help speed things up a bit, as it will jump across whole words.

And, of course, command-shift-arrow will do the whole line.

Other than for selecting text, why would you need a really fast
key repeat?

Seth

[Robert M. Münch]

On 2 Sep., 05:36, Seth Dillingham <s...@macrobyte.net> wrote:

Hi, I have the same problem it's not fast enough.

> Other than for selecting text, why would you need a really fast
> key repeat?

Well, to move the cursor around very fast ;-). If you have a lot of
code, it's just waste of time.

Robert

[Matias Bjarland]

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

[Christopher Stone]

Hey Matias,

You don't mention what version of BBEdit you're using (10.0 or 10.1) which is quite germane.

Have you enabled key-repeat on Lion?  The press-and-hold for accenting keys feature causes problems.

 defaults write -g ApplePressAndHoldEnabled -bool false

On Oct 09, 2011, at 10:41, Matias Bjarland wrote:

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

No disagreement from me.

I don't need syntax highlighting, fancy pants auto complete, connections to ftp servers, etc.

A programming editor without useful autocomplete is just junk, but YMMV.  :)

I have loved all BBedit versions prior to 10.

I wouldn't go that far, but I've used BBEdit since it debuted and have found it an increasingly useful tool.  It stays open 24/7 on my machine.

A few examples of things I think went wrong: 

• The selection key repeat issue. That they ship this just blows my mind.

I was quite unhappy with this but have decreased my sorrows by installing KeyRemap4MacBook and tweaking the settings.

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

I hate Gmail and find it nearly unusable, but obviously many people feel differently.  I access my Gmail account via IMAP and Apple Mail (although I still pine for Eudora).

Be sure to examine BBEdit's Expert Preferences in the help file (available from the Help menu).

• {snip} 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. 

• In project windows, the file list does not accept keyboard focus by default, unless the editing view is hidden. You can modify this so that the file list gets the focus whenever you click on it:

  defaults write com.barebones.bbedit ProjectsListCanAcquireKeyboardFocus -bool YES

• 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).

Yeah.  I'm not happy with this arrangement either.

• 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. {snip}

I too would like to have more choice on where things are located in the UI.

While on the subject of UI let me mention that I still dislike the morphing preferences, and if I'm not mistaken the preference search is not as complete as in BBEdit v9.

--

Best Regards,

Chris

[Matias Bjarland]

Hi Chris, 

thanks for the insightful input. Much appreciated! For reference, I was using 10.0.1 at the time of writing above. I did see the advanced settings but after not finding a number of the things I was looking for in there anymore I somewhat gave up on them. My bad. 

I have since upgraded to 10.1 (3110) and performed the configuration changes you mentioned (some of them via the 'secrets' app which is sometimes useful for these things). The selection speed seems better now. As for the rest, I will have to live with the updated editor for a few days to get a feel but my initial gut feeling is that BBedit is in the running again...I had already somewhat given up and switched to TextMate as a primary editor but I will now use both for a while and see where it lands.

While on the subject of TextMate vs BBedit. I did a quick comparison on opening a large number of small files. I did a: 

> find . -type f -name MANIFEST.MF > list.txt

and 

> cat list.txt | xargs bbedit

> cat list.txt | xargs mate 

respectively. 

For the non *nix shell damaged, this just means that I did a search for all files called MANIFEST.MF in all subdiretories of the current directory. I stored the resulting list of paths in a file called 'list.txt'. The list contained 208 files. I then asked first the BBedit and then the TextMate command line executable to open all those files. 

In BBedit this took about 35 seconds. In TextMate about one second. I'm sure there are some relevant reasons like the fact that BBedit actually displays each file and loads them all into memory etc. But still, 35 seconds is a long time to wait for opening up a bunch of files which are all smaller than 1k in size. 

[David Alexander]

On Mon, 10 Oct 2011 14:40:02 -0700 (PDT), Matias Bjarland
<mbja...@gmail.com> wrote:

>While on the subject of TextMate vs BBedit. I did a quick comparison on
>opening a large number of small files. I did a:
>
>> find . -type f -name MANIFEST.MF > list.txt
>
>and
>
>> cat list.txt | xargs bbedit
>> cat list.txt | xargs mate
>

>In BBedit this took about 35 seconds. In TextMate about one second.

You should have ran the test a second time. The first time you ran
the bbedit command all the files were read from disk. The second time
when you ran textmate all the files were read from system cache
memory. You should have ran the bbedit command a second time to see
what difference, if any, there was.

[Christopher Stone]

On Oct 10, 2011, at 16:40, Matias Bjarland wrote:

In BBedit this took about 35 seconds. In TextMate about one second. I'm sure there are some relevant reasons like the fact that BBedit actually displays each file and loads them all into memory etc. But still, 35 seconds is a long time to wait for opening up a bunch of files which are all smaller than 1k in size. 

______________________________________________________________________

Hey Matias,

It would be useful to know how many files you opened, so it would be possible to test under similar circumstances.

I'm also interested in what results you get if you repeat the experiment as David has suggested.

--

Best Regards,

Chris

[Matias Bjarland]

Hi again guys. So as per request I redid the test. Below are the results:

>  find . -type f -name MANIFEST.MF > filelist.txt

>  wc filelist.txt 

     208     208    8161 filelist.txt

>  time cat filelist.txt | xargs bbedit 

real 0m34.592s

user 0m0.107s

sys 0m0.068s

>  time cat filelist.txt | xargs bbedit 

real 0m23.855s

user 0m0.092s

sys 0m0.084s

>  time cat filelist.txt | xargs mate

real 0m0.769s

user 0m0.057s

sys 0m0.018s

>  time cat filelist.txt | xargs mate

real 0m0.272s

user 0m0.038s

sys 0m0.013s

So 208 small files. All on a pretty fast mac book pro with a blazingly fast SSD (not the stock one...a fast one). 

Now I would like to point out that BBedit actually displays each file. As in actually rendering the window with the visible part of the contents of the file. TextMate does not do this. TextMate only creates a "project" and loads the files into the document navigator on the left. So some could argue that TextMate is not really opening the files and I would tend to agree. But BBedit takes about the same amount of time even the second time...and I did not close BBedit between the runs. In other words, it took BBedit 23 seconds to just "re-open" the files it already had open. They were already in memory, in the document navigation, etc. And during all those 35 seconds BBedit was unresponsive as it was busy opening files, rendering the document navigation, rendering files, etc.  

And it strikes me that I don't really care if TextMate does not "really open the files". I will not be looking at all 208 of them simultaneously. So for me as a user it is more efficient to get lightning fast response time and then click (open) the files in the order and pace that works for me. In this particular instance TextMate won a round in my eyes.

Opinions welcomed. 

[Rich Siegel]

On Wednesday, October 12, 2011, Matias Bjarland <mbja...@gmail.com> wrote:

> Opinions welcomed.

cat filelist.txt | xargs bbedit --project

Enjoy,

R.
--
Rich Siegel Bare Bones Software, Inc.
<sie...@barebones.com> <http://www.barebones.com/>

Someday I'll look back on all this and laugh... until they sedate me.

[Christopher Stone]

On Oct 12, 2011, at 18:55, Matias Bjarland wrote:

Hi again guys. So as per request I redid the test. Below are the results:

______________________________________________________________________

Hey Matias,

time ls -1 | xargs bbedit --project

 real   0m0.413s

 user   0m0.044s

 sys    0m0.028s

i7 MacBook Pro with a 7500rpm drive.

--

Best Regards,

Chris

[Matias Bjarland]

Excellent catch! Thanks guys. 

[Robert Muench]

Was this key repeat issue now solved? If, how? I still have much to
slow key repeat rates in BBEDit.