Check to see if you have "Verify open files after..." turned on. Try turning them all off and see if that changes. Often, when you switch windows, BBEdit goes back to the file on the disk to see if it's changed. If the disk has spun down, it takes a few seconds for it to come back up...
- B > I've been getting the dreaded spinning beachball of death for the past > couple of months as I work on my version of BBEdit 8.0.3. It occurs > sporadically, but at least 10 times a day. It just seemed to start one > day out of the blue and now as I'm coding, the cursor will pause, spin > for a few seconds (10 or so) and then return to normal. > > I don't know that it's directly related to BBedit, but that's where I > see it. Of course BBedit is the primary program that I use, so that's > not surprising. > > I'm on a G4 powerbook, OS X 10.3.9. > > Has anyone else experienced this? > > Thanks, > > John > > Custom Communications, Inc. > 145 Newbury St. > Portland, ME 04101 > 207-771-5510 > www.desktoppub.com > On Aug 9, 2006, at 12:32 PM, BBEdit-Talk List wrote: > >> BBEdit-Talk Digest #1722 >> >> 1) Re: Grep Help >> by David Kurtz <[EMAIL PROTECTED]> >> 2) Re: Grep help >> by Alan Storm <[EMAIL PROTECTED]> >> 3) Re: Grep help >> by Ronald J Kimball <[EMAIL PROTECTED]> >> 4) Re: Grep help >> by Charlie Garrison <[EMAIL PROTECTED]> >> 5) Re: Grep Help .. works with Replace and Find again >> by Alan Storm <[EMAIL PROTECTED]> >> 6) Re: Grep help >> by Seth Dillingham <[EMAIL PROTECTED]> >> 7) Re: Grep help >> by Ronald J Kimball <[EMAIL PROTECTED]> >> 8) Re: Grep help >> by Joao Carlos de Pinho <[EMAIL PROTECTED]> >> 9) Re: Grep help >> by Joao Carlos de Pinho <[EMAIL PROTECTED]> >> 10) Re: Grep help >> by Seth Dillingham <[EMAIL PROTECTED]> >> 11) Re: Grep help >> by Ronald J Kimball <[EMAIL PROTECTED]> >> 12) Re: Grep help >> by "Jared Earle" <[EMAIL PROTECTED]> >> >> From: David Kurtz <[EMAIL PROTECTED]> >> Date: August 8, 2006 2:12:12 PM EDT >> Subject: Re: Grep Help >> >> >> >> On Aug 8, 2006, at 9:09 AM, Ted Burger <[EMAIL PROTECTED]> wrote: >> >>> I have a LONG list of words: >>> >>> order_id >>> order_num >>> category >>> listingsize >>> boldtype >>> >>> I want to change it to: >>> >>> fieldname="order_id" postargumentname="order_id" >> [...] >>> I tried: >>> GREP is checked >>> Search: (.*) >>> Replace: fieldname="&" postargumentname="&" >>> >>> But I get: >>> fieldname="order_id" postargumentname="order_id"fieldname="" >>> postargumentname="" >> >> >> (.*) will match the end of line. In other words, it will match >> anything, including nothing. That's why you're seeing what appears to >> be a doubling up of keys with empty values. >> >> What you want is either of the following: >> >> (.+) # this matches *at least* one character >> ^(.*)$ # or here, grep knows you don't want the NULL >> >> >> >> From: Alan Storm <[EMAIL PROTECTED]> >> Date: August 8, 2006 2:12:14 PM EDT >> Subject: Re: Grep help >> >> >> On Tue, 8 Aug 2006, Ted Burger wrote: >> >>> Search: (.*) >>> Replace: fieldname="&" postargumentname="&" >>> >>> But I get: >>> fieldname="order_id" postargumentname="order_id"fieldname="" >>> postargumentname="" >> >> I'm not sure why your search is failing with replace all, but if you >> add >> the starts with/ends with meta characters to your regular >> expressions it fixes things up. >> >> Search: (^.*$) >> >> -- >> Alan Storm >> http://alanstorm.com/ >> >> >> >> From: Ronald J Kimball <[EMAIL PROTECTED]> >> Date: August 8, 2006 2:38:37 PM EDT >> Subject: Re: Grep help >> >> >> For the record, this is not a bug. Here's what happens: >> >> Text >> example >> >> Find >> (.*) >> >> The regex engine starts out trying to match at the beginning of the >> string, >> just before the first e. .* matches the e, then the x, and so on >> until it >> has matched 'example'. . can't match newline, and as that's the end of >> the regex, a successful match has been found. >> >> Then the regex engine tries to match from where it left off, between >> the >> second e and the newline. .* matches zero characters, then can't >> match the >> newline. As that's the end of the regex, another successful match has >> been >> found. >> >> Then the regex engine tries to match from where it left off, still >> between >> the second e and the newline. .* matches zero characters, then can't >> match >> the newline. That would be a successful match, but the engine has >> already >> found a zero-length match at this position. To avoid an infinite >> loop, the >> regex engine skips this match, advances one character, and tries again. >> >> Ronald >> >> >> >> From: Charlie Garrison <[EMAIL PROTECTED]> >> Date: August 8, 2006 2:38:44 PM EDT >> Subject: Re: Grep help >> >> >> Good morning, >> >> On 8/8/06 at 12:09 PM -0400, Ted Burger <[EMAIL PROTECTED]> wrote: >> >>> I am getting doubles of the 'Replace'. >>> Any thoughts? >> >> Instead of using this replace pattern: >> >>> Replace: fieldname="&" postargumentname="&" >> >> Use this: >> >> fieldname="\1" postargumentname="\1" >> >> >> Charlie >> >> -- >> Charlie Garrison <[EMAIL PROTECTED]> >> PO Box 141, Windsor, NSW 2756, Australia >> >> >> >> From: Alan Storm <[EMAIL PROTECTED]> >> Date: August 8, 2006 2:39:04 PM EDT >> Subject: Re: Grep Help .. works with Replace and Find again >> >> >> On Tue, 8 Aug 2006, David Kurtz wrote: >> >>> (.*) will match the end of line. In other words, it will match >>> anything, including nothing. That's why you're seeing what appears to >>> be a doubling up of keys with empty values. >> >> I thought the same thing at first. However, if that's the case, why >> doesn't the repeating happen if you go through each line individually >> using the Replace & Find again command? >> >> -- >> Alan Storm >> http://alanstorm.com/ >> >> >> >> From: Seth Dillingham <[EMAIL PROTECTED]> >> Date: August 8, 2006 3:24:58 PM EDT >> Subject: Re: Grep help >> >> >> On 8/8/06, Ronald J Kimball said: >> >>> For the record, this is not a bug. Here's what happens: >>> >>> Text >>> example >>> >>> Find >>> (.*) >>> >>> The regex engine starts out trying to match at the beginning of the >>> string, >>> just before the first e. .* matches the e, then the x, and so on >>> until it >>> has matched 'example'. . can't match newline, and as that's the end >>> of >>> the regex, a successful match has been found. >> >> [snip] >> >> I'm not trying to make a big issue out of this obviously, it's up to >> BareBones to say if this is actually a bug or not but just because >> you can >> explain what's happening doesn't mean it's not a bug. >> >> I think it's a bug. >> >> .* is supposed to match everything except newlines (unless you use the >> flag >> that says it matches newlines also). >> >> - Regular expressions are greedy by default, so the first thing >> that can >> be matched after a greedy, no-line-feed .* is the next line. >> >> - If you've matched everything except the carriage return, it >> doesn't >> make any sense to then match the "nothing" between the last >> character >> in the line and the carriage return. >> >> - The "everything" you matched already was supposed to include that >> "nothing" after the last character. >> >> Here's a perl example that shows how it should work. >> >> Create a test file called test.txt. Put a few lines in it, just one >> word per >> line (to keep it short and simple). Save it at ~/Desktop/test.txt >> >> Open terminal, and run these two lines: >> >> cd ~/Desktop >> perl -pi -e 's/(.*)/($1)/' test.txt >> >> The second line tells perl to run a search for every .*, and replacing >> each >> with the same text but wrapped in parentheses. >> >> Open the file in BBEdit again, and you'll see that each line is >> wrapped in >> parens, and that's the only change. >> >> So if a line contains just "foo", it will be replaced with "(foo)". >> >> Now change the file back to the way it was (without the parens), and >> run the >> same find-and-replace in BBEdit: >> >> - turn on grep >> - search for (.*) >> - replace with (\1) >> >> and click "replace all". You get an extra set of empty parens at the >> end of >> every line. >> >> This is a bug. (Never would have believed it if I hadn't seen it for >> myself! ;-) >> >> (Not that this is a big deal, since there seems to be a pretty easy >> workaround.) >> >> Seth >> >> >> >> >> From: Ronald J Kimball <[EMAIL PROTECTED]> >> Date: August 8, 2006 4:21:36 PM EDT >> Subject: Re: Grep help >> >> >> On Tue, Aug 08, 2006 at 03:24:58PM -0400, Seth Dillingham wrote: >>> Here's a perl example that shows how it should work. >>> >>> Create a test file called test.txt. Put a few lines in it, just one >>> word per >>> line (to keep it short and simple). Save it at ~/Desktop/test.txt >>> >>> Open terminal, and run these two lines: >>> >>> cd ~/Desktop >>> perl -pi -e 's/(.*)/($1)/' test.txt >> >> That's only doing a single replacement per line, because you left off >> the >> /g modifier. >> >> Try this instead: >> >> perl -pi -e 's/(.*)/($1)/g' test.txt >> >> >> It's not a bug. >> >> >> Ronald >> >> >> >> From: Joao Carlos de Pinho <[EMAIL PROTECTED]> >> Date: August 8, 2006 4:22:01 PM EDT >> Subject: Re: Grep help >> >> >> Em 8/8/06 3:38 PM, "Ronald J Kimball" <[EMAIL PROTECTED]> >> escreveu: >> >>> For the record, this is not a bug. >> >> >> To answer the original poster, I ran a test in Affrus using that >> pattern >> over a dummy text, and the results were exactly what I expected, ie, no >> duplicate pattern at the end. (And Seth Dillingham achieved the same >> results >> using Perl in Terminal.) >> >> That's why I said "It seems that you found a bug". >> >> >> But I'm not a grep expert. Far from it. >> >> >> >> João Carlos de Pinho >> São Paulo, Brazil >> >> >> >> >> >> From: Joao Carlos de Pinho <[EMAIL PROTECTED]> >> Date: August 8, 2006 5:16:02 PM EDT >> Subject: Re: Grep help >> >> >> Em 8/8/06 5:21 PM, "Ronald J Kimball" <[EMAIL PROTECTED]> >> escreveu: >> >>> That's only doing a single replacement per line, because you left off >>> the >>> /g modifier. >> >> >> Yes, your're right: it's not a bug. >> >> Believe it or not, when I made the test I even considered to use the /g >> modifier, but I eventually said to myself: "For what? In this case, it >> would >> not make any difference". Well, it makes all the difference. Lesson >> learned. >> >> >> Thanks for the explanation, Ronald. >> >> >> >> João Carlos de Pinho >> São Paulo, Brazil >> >> >> >> >> >> >> >> >> >> >> From: Seth Dillingham <[EMAIL PROTECTED]> >> Date: August 8, 2006 5:16:18 PM EDT >> Subject: Re: Grep help >> >> >> On 8/8/06, Ronald J Kimball said: >> >>> perl -pi -e 's/(.*)/($1)/g' test.txt >> >> OK, that one's even weirder than what BBEdit produces. ;-) >> >> Seth >> >> >> >> >> From: Ronald J Kimball <[EMAIL PROTECTED]> >> Date: August 9, 2006 9:21:03 AM EDT >> Subject: Re: Grep help >> >> >> On Tue, Aug 08, 2006 at 05:16:18PM -0400, Seth Dillingham wrote: >>> On 8/8/06, Ronald J Kimball said: >>> >>>> perl -pi -e 's/(.*)/($1)/g' test.txt >>> >>> OK, that one's even weirder than what BBEdit produces. ;-) >> >> Hehe! That's true. >> >> Given this input: >> >> foo >> bar >> >> It produces this output: >> >> (foo)() >> ()(bar)() >> () >> >> This happens because it's reading one line at a time. The regex >> matches >> the word, then the empty string before the newline, then the empty >> string >> *after* the newline. >> >> If you have it read in the whole input as one string you'll get the >> same behavior that occurs in BBedit: >> >> perl -pi -e 'BEGIN { $/ = undef } s/(.*)/($1)/g' test.txt >> >> Ronald >> >> >> >> From: "Jared Earle" <[EMAIL PROTECTED]> >> Date: August 9, 2006 11:21:24 AM EDT >> Subject: Re: Grep help >> >> >> On 8/8/06, Ted Burger <[EMAIL PROTECTED]> wrote: >>> Folks, >>> >>> I appear to be missing something. >>> >>> I have a LONG list of words: >>> >>> order_id >>> order_num >>> category >>> listingsize >>> boldtype >> >> Does BBEdit do Awk? :D >> >> awk '{print "fieldname="\"$0"\" postargumentname=\""$0"\""}' >> >> I'll grep my coat. >> >> -- >> Jared Earle :: There is no SPORK >> [EMAIL PROTECTED] :: http://www.23x.net >> The Spodcast :: http://spodcast.org >> >> >> -- >> ------------------------------------------------------------------ >> Please send bug reports to <[EMAIL PROTECTED]>, not to the list. >> List FAQ: <http://www.barebones.com/support/lists/bbedit_talk.shtml> >> List archives: <http://www.listsearch.com/BBEditTalk.lasso> >> To unsubscribe, send mail to: <[EMAIL PROTECTED]> > > -- > ------------------------------------------------------------------ > Have a feature request? Not sure the software's working correctly? > If so, please send mail to <[EMAIL PROTECTED]>, not to the list. > List FAQ: <http://www.barebones.com/support/lists/bbedit_talk.shtml> > List archives: <http://www.listsearch.com/BBEditTalk.lasso> > To unsubscribe, send mail to: <[EMAIL PROTECTED]> > -- ------------------------------------------------------------------ Have a feature request? Not sure the software's working correctly? If so, please send mail to <[EMAIL PROTECTED]>, not to the list. List FAQ: <http://www.barebones.com/support/lists/bbedit_talk.shtml> List archives: <http://www.listsearch.com/BBEditTalk.lasso> To unsubscribe, send mail to: <[EMAIL PROTECTED]>
