Thoughts and questions on v10
Jay
not getting it. I've used BBEdit for years and usually eagerly buy up
the latest version as soon as it ships, but so far, I can't justify
the purchase.
I primarily do HTML, PHP, and JS development with BBEdit and it seems,
unless I'm missing something, that version 10 is far more cumbersome
to use than version 9 for a lot of my tasks. The prime example being
the HTML editing tools.
For most tags in 9, the modal dialog boxes provided the majority of
the necessary options (the prime example being the image box). It also
did the niceties of auto-calculating the image size for you, after
inputting all the needed options. From what I can see in V10, the
prime option is to use the inline editor, which only prompts to type
the alt and src attributes, and does not auto-fill dimensions.
The other suggestion I've seen is to drag and drop the image file into
the HTML file, and it will auto-fill the dimensions. But, if you've
set the file type to PHP (like I do for files that have headers and
includes), this doesn't work (i.e., BBEdit does nothing). So, in this
case, the only option is to use the inline palette, which requires
more clicks (and doesn't do the auto-calculation).
The new non-modal tag editors also have one really annoying aspect in
that they do provide a listing of every possible attribute that
applies to a tag in a drop-down menu, but the drop-down menu requires
me to scroll up and down, even though the menu should easily fit on my
screen. I'm not sure if this is a developer tool limitation or not,
but if it can be changed, I'd vote to do so.
Find and replace also seems less functional in version 10... maybe
it's just my workflow, but I much prefer the old modal find & replace
window, for two main reasons. First, the existence of the keyboard
shortcuts to toggle options (Command-G to toggle Grep, Command-T to
toggle start at top). And second, what happened to Start at Top?
Losing that is a major bummer to the way I work. Also, losing the
ability to trigger a multi-file search from inside of the regular find
box is a bummer; I do that a lot when I make one change, and then
realize I probably need to make it across a bunch of files.
I've also noticed that the full screen mode in Lion seems buggy. Every
time I try it, at some point, the ability to mouse to the top of the
screen to reveal the menu bar stops working. BBEdit also assigns the
system keyboard shortcut for enter/exit full screen to another
command, so no dice there. The only option seems to be quitting and
restarting.
Am I missing something? Are there workarounds or better ways to deal
with these things that I'm missing?
Steve Kalkwarf
> the necessary options (the prime example being the image box). It also
> did the niceties of auto-calculating the image size for you, after
> inputting all the needed options. From what I can see in V10, the
> prime option is to use the inline editor, which only prompts to type
> the alt and src attributes, and does not auto-fill dimensions.
The gear widget at the top-right of the editor fills in "common" attributes. You can click it, or type Command-M to populate the list with them.
I'm not 100% sure how we handle dimensions if you type the image tag. If we are not computing the dimensions, I can see an argument for doing so. I can also see arguments against it.
> The other suggestion I've seen is to drag and drop the image file into
> the HTML file, and it will auto-fill the dimensions. But, if you've
> set the file type to PHP (like I do for files that have headers and
> includes), this doesn't work (i.e., BBEdit does nothing). So, in this
> case, the only option is to use the inline palette, which requires
> more clicks (and doesn't do the auto-calculation).
Can I ask why you set the file type to PHP? Setting it to HTML, then letting BBEdit figure out which parts are PHP should work.
> The new non-modal tag editors also have one really annoying aspect in
> that they do provide a listing of every possible attribute that
> applies to a tag in a drop-down menu, but the drop-down menu requires
> me to scroll up and down, even though the menu should easily fit on my
> screen. I'm not sure if this is a developer tool limitation or not,
> but if it can be changed, I'd vote to do so.
When I wrote that stuff, my expectation was that people would be using autocomplete to get the attribute names, and only using the list of items if they were unsure what the attribute they needed was called. Does that not work for you?
> Find and replace also seems less functional in version 10... maybe
> it's just my workflow, but I much prefer the old modal find & replace
> window, for two main reasons. First, the existence of the keyboard
> shortcuts to toggle options (Command-G to toggle Grep, Command-T to
> toggle start at top).
There are new key equivalents, which are documented in the manual, and can be changed in the preferences.
> And second, what happened to Start at Top?
You would be astounded how many times we had to answer the question "I chose replace all, but only some of the strings were replaced. WTF?"
In the new windows (I hesitate to say "new", because they've been the default windows for several years) Replace All does what it says it will. If you need "Replace from here to the end", there's a command on the menu for that, which has no key assigned by default. You can add one if you like.
I typically have "Wrap Around" enabled, and that works for my needs.
> Losing that is a major bummer to the way I work. Also, losing the
> ability to trigger a multi-file search from inside of the regular find
> box is a bummer; I do that a lot when I make one change, and then
> realize I probably need to make it across a bunch of files.
Because they are "windows" and not "dialogs", you can have them both open at once. If you type "Command-F", but find you really wanted multi file search, just type "Command-Shift-F, and the other window will appear, pre-poulated with the settings from the first window. Or, if that's too much cognitive load (Seriously -- I'm not making fun of anyone), simply change the Find multiple key equivalent to Command-M.
> I've also noticed that the full screen mode in Lion seems buggy. Every
> time I try it, at some point, the ability to mouse to the top of the
> screen to reveal the menu bar stops working. BBEdit also assigns the
> system keyboard shortcut for enter/exit full screen to another
> command, so no dice there. The only option seems to be quitting and
> restarting.
If you had any existing key accelerators, we went out of our way to preserve then, and _not_ commandeer keystrokes used by the system. If you want the system defaults, you can either manually re-apply them, or do what I did, and "Restore Defaults" in the Menus & Shortcuts pref pane, then add back the customizations you use. Obviously, if you have a lot of customizations, that's a drag. In my own case, I think I added or changed about half a dozen.
> Am I missing something? Are there workarounds or better ways to deal
> with these things that I'm missing?
Hopefully some of the above will prove helpful?
Steve
NotInUse
either. I realize is a Cocoa build though, so it does take a lot more
effort to recode everything. What I wonder is why it was released so
crippled. I'd have rather of waited another year for v10 and not be
missing anything. I guess the Cocoa build has to start somewhere. As
it is, I'll probably be using v9.6 for at least another 6 months while
the BB folks add features back to v10.
BBEdit has always been one of those apps I download/purchase as soon
as there is an update because each version is an improvement. Sad to
say v10 was the huge step backwards due to missing features. I can't
see how BBEdit 10 will gain many NEW users. If I saw only version
10... I'd have never purchased it. There are free apps that do a
better job with PHP/HTML/CSS/Javascript than v10 does at the moment.
And, of course, it may depend on end user use as well. v10 may be a
heck-of-an-app for *nix or Ruby files. I wouldn't know.
John Delacour
>Find and replace also seems less functional in version 10... maybe
>it's just my workflow, but I much prefer the old modal find & replace
>window, for two main reasons.
BBEdit Help says:
The old modal Find dialog is deprecated and no longer supported.
However, if you still prefer to use it, it can be enabled with this
command in a Terminal window:
defaults write com.barebones.bbedit FindDialog:UseOldSk00lFindDialog -bool YES`
I presume the final backtick is an error and meaningless.
JD
Steve Kalkwarf
Sorry. This is no longer supported in BBEdit 10.
Steve
NotInUse
This would possibly work, and does for straight html. Doesn't work for
xHTML because the doctype declaration is generally presented after a
few PHP commands so it's not the first line of the file for BBEdit to
read. Not an issue for HTML5, but full HTML5 use is still a ways out.
There used to be a pref which automatically added the closing slashes
for xHTM, that seems to have gone.
Jay
> The gear widget at the top-right of the editor fills in "common" attributes. You can click it, or type Command-M to populate the list with them.
of a bummer. Maybe it's just my install, but the widget doesn't
remember the setting I last used for it. So, for instance, I insert an
image using it, click it to insert a class or ID (which I do a lot,
inserting images that become controls for jQuery events). The next
time I go to insert an image, it doesn't remember that I had expanded
the widget to show the additional options, which does drive me a bit
nutty since 95% of the time, I want to continue using the same
settings. The modal windows were at least good in that they had all
the options on them (although bad in that they were modal).
At a minimum, I'd love to see that widget recall its last state;
ideally, it would be wonderful to be able to set the attributes that
the widget shows by default (so for an img, I could set ID as always
there, for instance).
> I'm not 100% sure how we handle dimensions if you type the image tag. If we are not computing the dimensions, I can see an argument for doing so. I can also see arguments against it.
sizes. It's lazy as an HTML coder to leave them out and let the
browser jump content all over the place during page load. The "old"
BBEdit did it using the equivalent insert method (hitting Command-
Contol-I), so I don't see why the new one shouldn't (unless, of
course, the user manually overrides it and enters his/her own values).
>
> Can I ask why you set the file type to PHP? Setting it to HTML, then letting BBEdit figure out which parts are PHP should work.
>
XHTML, so I set the default to PHP. A subsequent comment also points
out some XHTML glitches, but I don't honestly recall having those
issues. I also liked the old code highlighting better (i.e. that the
PHP open tag would highlight in red with the doc mode set to PHP, made
it easier to track down included files in the middle of the code).
Given all of this, I guess I'll try flipping the standard doc mode to
HTML, and dragging and dropping images in, and see if I can adjust to
that. But keep my vote in mind if you do want to make some more
changes. :-)
>
> When I wrote that stuff, my expectation was that people would be using autocomplete to get the attribute names, and only using the list of items if they were unsure what the attribute they needed was called. Does that not work for you?
>
sense to show the full list as well when clicking on the drop-down
menu. It may come down to preference. My feeling is that if the full
menu will fit on the screen, I'd rather see it, rather than have to
scroll it, during those inevitable "what the heck is the name of that
stupid attribute that I use all the time but now for the life of me
can't remember" moments (often tied to early mornings or late nights).
Especially with the move to add HTML5 elements into BBEdit (which, by
the way, is awesome and I love), it's really helpful for me to
reinforce some of the new syntax that I'm not yet 100% familiar with
yet.
> There are new key equivalents, which are documented in the manual, and can be changed in the preferences.
Keys-G, etc but apparently not. I got spoiled by the old interface
showing the key commands when you held down command, I guess.
> You would be astounded how many times we had to answer the question "I chose replace all, but only some of the strings were replaced. WTF?"
>
> In the new windows (I hesitate to say "new", because they've been the default windows for several years) Replace All does what it says it will. If you need "Replace from here to the end", there's a command on the menu for that, which has no key assigned by default. You can add one if you like.
>
> I typically have "Wrap Around" enabled, and that works for my needs.
>
tried working with wrap around, but I just find it annoying sometimes
when I'm searching for something that I know is above the insertion
point (for example, the first H1 in a header of a page), when there
are subsequent identical tags below it (again, more H1s). It's
annoying to have to tick through the later ones until the wrap around
kicks in, which is why I always loved being able to just tick Command-
T. If I could put in a vote, I'd love it if Start at Top returned as
an explicitly set option, but I suppose I could learn to live without
it.
> Because they are "windows" and not "dialogs", you can have them both open at once. If you type "Command-F", but find you really wanted multi file search, just type "Command-Shift-F, and the other window will appear, pre-poulated with the settings from the first window. Or, if that's too much cognitive load (Seriously -- I'm not making fun of anyone), simply change the Find multiple key equivalent to Command-M.
the old modal interface. I guess I don't understand what necessitated
the change (something in the rewrites requiring it, or was it deemed
more usable this way?), but I find it less usable. Again, I guess it's
something I could learn to live with.
> If you had any existing key accelerators, we went out of our way to preserve then, and _not_ commandeer keystrokes used by the system. If you want the system defaults, you can either manually re-apply them, or do what I did, and "Restore Defaults" in the Menus & Shortcuts pref pane, then add back the customizations you use. Obviously, if you have a lot of customizations, that's a drag. In my own case, I think I added or changed about half a dozen.
that's having problems with full screen, or my particular Lion install
(I've noticed some general wonkery around the edges), this will at
least get me out of full screen.
I'll give it another go. Like I said, there are things I'd vote
differently on, but I also may find in a few days that I'm totally
committed to the new way of doing things. Thanks again for the help,
Steve.
dinkypumpkin
> BBEdit has always been one of those apps I download/purchase as soon
> as there is an update because each version is an improvement. Sad to
> say v10 was the huge step backwards due to missing features. I can't
feel like some useful features have been lost where HTML editing is
concerned. As a UI construct, the markup panel is a step forward from
the modal dialogs, but it lacks their "handiness". Some of that has
been mentioned here: no calc of image size, no capture of highlighted
URLs for anchors, no sticky option selections, no URL list, no colour
pickers for attributes, etc. I know I sound like a dinosaur
contemplating the oncoming asteroid, but producing HTML in volume is a
pretty mechanical chore, and those were all features that made the job
a bit easier in v9. OTOH, the markup panel is pretty easy to work
with, sensitive to the doc type (a nice thing), autocomplete works
well, and it's not hard to imagine that some of the old "handiness"
could be spliced in. I hope it will be. The model of working created
by the markup panel is of a piece with the loss of most of the old
HTML-related palettes, i.e., a shift from mouse to keyboard. In v9,
you could churn out a heck of a lot of HTML with the palettes and
modal dialogs and do very little typing. I'll miss that lazy man's
option, but I reckon my fingers can take the strain.
> And, of course, it may depend on end user use as well. v10 may be a
> heck-of-an-app for *nix or Ruby files. I wouldn't know.
the $40. Even if I have to go elsewhere for HTML work, BBEdit still
handles all my scripting work quite well.
Rich Siegel
>The gear widget brings up another point that I've noticed that's kind
>of a bummer. Maybe it's just my install, but the widget doesn't
>remember the setting I last used for it.
Part of the confusion there, I think, is that it isn't a
setting. Rather, it's an action button, which for the particular
tag in question, fills in a set of "reasonable" attributes. So,
try looking at it through a new lens and see if that helps.
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.