On 15-Sep-2006 at 12:31 -0400 Doug McNutt wrote:
> At 09:14 -0400 9/15/06, Jim Correia wrote:
> >"Saved State" means per file editing options that are saved with the
> >file, not whether the file has unsaved changes.
>
> That's a somewhat dangerous oversimplification that is confusing,
> especially to new users.
While "with" was probably not meant literally (as Rich states), I agree
that this behaviour may be very confusing if you don't know how it works.
Let me share a bit detail regarding this feature. I hope it will be
helpful for somebody:
> Other editors do in fact keep editing options "with the file". That's
> what Apple's resource forks were once used for.
Yes, from a user perspective, resource forks were a very smart thing.
Note that BBEdit 8 and 8.5 do still honour any state information that's
stored in resource forks. But if you resave the file with BBEdit 8 the
state storage will be converted to the database storage system (if I'm
not wrong). BBEdit 8.5 has improved with this respect (see below).
> Since version 8, or perhaps a bit earlier, BBEdit saves "state" in a
> database that is associated with each user so that it is possible for
> different programmers editing the same file at different times to
> retain different display options.
That's correct, version 8 started to use a database instead of resource
forks to store saved state. AFAIK, the state storage database keeps at
least 2500 entries but (opposed to state storage in resource forks) it
does not store saved state indefinitely.
However, using BBEdit 8 (or 8.5), there's a trick how you can prevent
particular files from loosing their state: Use the "Set Marker..."
feature to set a bookmark somewhere in the file. AFAIK, this will cause
saved state to be kept in the database indefinitely.
Using BBEdit 8.5, you can even switch back to the old state storage
system (i.e., saving state info inside resource forks). To do so, quit
BBEdit and enter following command on the command line:
defaults write com.barebones.bbedit State:UseResourceFork -bool YES
You should be aware of the implications, though. If you're mostly
sharing your files with programmers and upload/download files to/from
FTP or use your files mainly in conjunction with a source control
system, then it's probably a good idea to stay with the database storage
system.
If, however, you're using files mostly privately and keeping saved state
indefinitely is crucial to you (it isn't for everybody), then the old
storage system (resource forks) may be better suited to your needs.
It's also worth mentioning that the database storage system used in
BBEdit 8.5 is now able to maintain saved state even when renaming a
file. If you copy the file, the saved state info won't travel to the
file's copy, though. Opposed to this, saved state info that's stored in
resource forks will also be copied when making a copy of a file in the
Finder.
> That "feature" is helpful to groups but a bit unsettling to sole users
> who are surprised when the saved state for an old file is lost from
> the database for some reason - like using another application to copy
> the file and editing the result in BBEdit.
I agree that this can be a major hassle. Fortunately, BBEdit 8.5 now
gives you a choice. BIG kudos to the folks at Barebones for addressing
this!
Matthias
_____________________________________
Matthias Steffens [EMAIL PROTECTED]
http://www.extracts.de
--
------------------------------------------------------------------
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]>
