Linux Productivity Magazine
August 2013
Bluefish: Quality and Speed
Copyright (C) 2013 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Linux Productivity Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.
Bill Gates and Steve Jobs spent a fortune convincing us that the only way we're capable of working is with a mouse. If you want to know why they did that, just follow the money. -- Steve Litt
CONTENTS
NOTE:
This web page is a package deal, with the other part of the package being the Using Bluefish to Make Web Pages page, which tends to be more technically oriented. The page you're reading right now is more about why Bluefish is so wonderful.
After sixteen years, I finally got sick of the complications of WYSIWYG HTML editors. WYSIWYG editor free software projects going out of business, forks, bugs, non-availability. Because Netscape Composer was maddeningly buggy on Linux, it was touch and go in 2001, when I converted to Linux. But I kept on, year after year, distro after distro, fork after fork, bug after bug, using WYSIWYG HTML editors, because I truly believed I couldn't achieve decent writing productivity without one.
Doooooh!
No doubt this would have continued forever, except this year, with Ubuntu's dropping of Kompozer, the time seemed close when there would be no decent WYSIWYG editor at all. I tried Bluegriffon, close but no cigar, and besides, it wasn't in OpenSuSE's standard package list. I tried Vim plus Snipmate. That worked well until it didn't. You might have noticed I wrote very little content for Troubleshooters.Com for several months. I just had no decent tool.
A few days ago I tried Bluefish, the HTML tag editor with context sensitive coloring and autocompletion. I'd tried it in the 1990's and hated it. I'd tried it again early in 2013 and hated it because the font was too small :-) When I tried it a few days ago, I had a lot more motivation to find something worthwhile, so I figured out how to make the fonts big enough, and how to fix a few other perceived "problems".
So I used Bluefish to write a document about the Openbox window manager. At first it was slow going, but the more practice I got, the faster things became. Then I wrote a technical document on Bluefish, and managed to slam out 2800 words in four and a half hours. Maybe others can write faster, but for me, that's smokin! That's every bit as good as the productivity I get on LyX and got on Kompozer before Kompozer became scarce. That's with less than a week of practice on Bluefish.
Writing web content has gotten fun again, and I've been writing web pages for several days, just for the fun of it. But you know what was not fun? Working on my Kompozer-authored documents. The Troubleshooters.Com What's New list was an utter mess, with <br> tags all over the place, and other tags and attributes just thrown around like toys in a five year old's room. Using Vim regex I fixed it, and then touched up the result with Bluefish. It now passes the tidy -eqnew tc_whatsnew.htm command with zero errors and zero warnings.
I'd already wrote a technical document about Bluefish, so now I'm writing a document in praise of it. Bluefish is a precise fit with Linux: Concise syntax, keyboard friendly, faster than a speeding bullet. So if you're looking for an excellent free software HTML authoring tool to use on Linux, kick back and enjoy this issue of Linux Productivity Magazine.
Steve Litt is the author of the Universal Troubleshooting Process Courseware. Steve can be reached at his email address.
This isn't a technical document. If you'd like a technical document on Bluefish, go to http://www.troubleshooters.com/linux/bluefish/index.htm. The document you're reading right now is where you learn Bluefish's benefits, the optimal mindset for using Bluefish, and a few tips.
Steve Litt is the acting president of the Greater Orlando Linux User Group. Steve can be reached at his email address.
This issue of Linux Productivity Magazine is my proof of concept for Bluefish as a professional web dev tool. Look at this Linux Productivity Magazine. Compare it to the June 2012 Linux Productivity Magazine. I styled the current one to look as much like the June 2012 one as possible, but I wrote this one, from scratch, with Bluefish, using CSS for all specification of appearance. When you compare the two in a browser, I think you'll find them quite similar.
Note:
The one thing from the old magazine I didn't imitate was the square note box, like this one, because every issue used a different kind of note. So I just made my own note style, with CSS, for this issue.
And please notice how all the Notes in this issue have an identical appearance. This comes from keeping appearance in the CSS styles, and writing the note with pure content. More on styles-based authoring in this HTML Refresher article, and the Go Styles-Based or Go Home article in this document.
Next, compare the HTML comprising the two. They couldn't be more different. The July 2012 mag's HTML is a mishmash of tags. It uses <br> tags to space out paragraphs, for gosh sakes. Different article titles were spaced differently because the WYSIWYG would get caught in a state where it couldn't space the current one the same as the past ones, unless I first edited with Vim. Oh, and check this out:
slitt@mydesk:/tjunct$ tidy -eq lpm/201206/201206.htm line 154 column 1 - Warning: inserting implicit <p> line 1086 column 3 - Warning: missing <li> line 1507 column 3 - Warning: missing <li> line 44 column 1 - Warning: <table> proprietary attribute "nosave" line 44 column 1 - Warning: <table> lacks "summary" attribute line 46 column 5 - Warning: <tr> proprietary attribute "nosave" line 47 column 7 - Warning: <td> proprietary attribute "nosave" line 78 column 1 - Warning: <table> proprietary attribute "nosave" line 78 column 1 - Warning: <table> lacks "summary" attribute line 80 column 5 - Warning: <tr> proprietary attribute "nosave" line 81 column 7 - Warning: <td> proprietary attribute "nosave" line 101 column 1 - Warning: <table> proprietary attribute "cols" line 101 column 1 - Warning: <table> lacks "summary" attribute line 116 column 1 - Warning: <table> lacks "summary" attribute line 463 column 1 - Warning: <table> lacks "summary" attribute line 542 column 1 - Warning: <table> lacks "summary" attribute line 612 column 1 - Warning: <table> lacks "summary" attribute line 645 column 1 - Warning: <table> lacks "summary" attribute line 698 column 1 - Warning: <table> lacks "summary" attribute line 774 column 1 - Warning: <table> lacks "summary" attribute line 828 column 1 - Warning: <table> lacks "summary" attribute line 851 column 1 - Warning: <table> lacks "summary" attribute line 1270 column 18 - Warning: <span> attribute "dir" has invalid value "auto" line 107 column 71 - Warning: trimming empty <span> line 154 column 1 - Warning: trimming empty <p> line 276 column 1 - Warning: trimming empty <h1> line 322 column 1 - Warning: trimming empty <h1> line 582 column 1 - Warning: trimming empty <h1> line 960 column 1 - Warning: trimming empty <h1> line 1270 column 18 - Warning: trimming empty <span> line 1507 column 3 - Warning: trimming empty <ul> line 1507 column 3 - Warning: trimming empty <li> line 1505 column 1 - Warning: trimming empty <ul> slitt@mydesk:/tjunct$
Compare this to the new one (not yet completed, but you get the idea):
slitt@mydesk:/tjunct$ tidy -eq lpm/201308/201308.htm slitt@mydesk:/tjunct$
In other words, I wrote it a completely different (and better) way, and yet managed to get it to look pretty much like the old ones. That speaks volumes about both CSS and Bluefish.
With Bluefish plus CSS making appearance customization so easy, I'll almost certainly change the look of future Linux Productivity Magazines. But this issue proves that the appearance didn't change just because I used a different tool and rewrote from scratch.
Steve Litt is the author of Twenty Eight Tales of Troubleshooting. Steve can be reached at his email address.
After a week with Bluefish, I would never go back to any WYSIWYG editor. Things had gotten so bad that I was scared to edit my WYSIWYG created files, because the WYSIWYG editor would write stuff willy nilly, goof up code inside <pre>/</pre> pairs, within the code weld together <h1> items with the content preceding and following them, and just generally wreck havoc with the HTML code for my web pages. Meanwhile, even editing in Vim was a mess and a half, because the HTML was all strung together without meaningful whitespace, and formatting was done by ad-hoc assemblages of tags rather than with CSS.
Some would suggest I run Tidy on the web pages to fix them up. But would you really want to run a formatter/fixer on code so badly out of whack? I might lose content. Personally, I'd require human intervention to make sure whole chunks of content didn't become invisible.
When people wrote me discussing a typo on a page, I had to evaluate whether I wanted to risk wrecking the page in order to fix the typo, and a lot of times the answer was "no". Those days are gone, at least for future pages.
With CSS based pages, I can change their appearance by changing the CSS. Right now I'm trying to learn more CSS, and what each CSS attribute makes my pages look like, so I'm hard-coding the CSS into each page. But there very well may come a day when I have a standard CSS page for all or a lot of my newly made web pages. To change all my newly-built pages, I'd just change the standard CSS
But that doesn't help with my pre-Bluefish pages. Each one would take from a half hour to two hours to fix up, and there are nearly 1000 of them, starting with the original 25 T.C pages (click for example), constructed with Frontpage in the summer of 1996. How do you like the graphical title, the dingy yellow background, and the wallpaper graphic listing the step number? :-). Then there were the turn-of-the-century pages (example) whose titles sported graphics derived from modified Micrografx Windows Draw clip art.
Some of the craziness isn't visible in the browser. Many of the tables rows in my pages sport a nosave="" in order to work around turn-of-the-century Netscape Composer and early Mozilla Compozer bug that insisted on turning all your relative links absolute.
I'm writing this paragraph a few days later, after bringing the Troubleshooters.Com Linux Quick Hacks page into some remote kind of validity. What a miserable job that was, fixing code written in a succession of WYSIWYG tools, first on Windows, then on Linux, each adding its own little screwup to the mix. It took me two hours, and I didn't even finish fixing the problems in <pre>/</pre> pairs. And believe me, this was one of T.C's simpler pages, and the T.C probably has 1000 pages, almost all written in various WYSIWYG editors. After my fixing of Linux Quick Hacks page, one thing I know for sure is I'll never go back to WYSIWYG HTML editing.
Steve Litt is available to select clients to personally teach the Universal Troubleshooting Process Course. Steve can be reached at his email address.
I love Bluefish to death and would never go back to Kompozer, Bluegriffon, any of the Netscape Gold descendents (including Seamonkey Composer), nor Vim with plugins. I write web pages just as fast in Bluefish as I did in Kompozer, and the result is a lot more valid, a lot more portable, and a lot easier to modify.
But you can't please all the people all the time, and Bluefish is the wrong product for some people. Here are some of the negative indicators for Bluefish use. If any of these apply to you, I'd advise against Bluefish:
If any of the preceding apply to you, you can quit reading this document now: It won't do you any good. Productive Bluefish usage requires a mindset conflicting with each of the preceding thought patterns.
Steve Litt is the author of The Key to Everyday Excellence. Steve can be reached at his email address.
Here are some of the benefits you get from Bluefish:
Steve Litt has written a large collection of Lyx documentation. Steve can be reached at his email address.
Here are some beliefs that are compatible with productive use of Bluefish. Adopt them:
If you wanted to work slowly, you can choose from zillions of HTML editors. But your time is valuable, and if you're a typical Troubleshooters.Com reader, you're probably highly paid for your time, and those paying you expect high efficiency. You'll consider only tools that can keep up with your typing speed. You'll consider only tools requiring absolutely no thought, so that you can keep your mind on what you're writing. Which is where your mind belongs.
And you're not content just to have such a tool. You tweak the tool so you can output faster. And you tweak your work habits so you can output faster with the tool you chose. Life's too short, and your time's worth too much, to do things any other way.
Bluefish is lightning fast. Always look for ways to make it even faster.
Bill Gates and Steve Jobs spent a fortune convincing us all that the only way we're capable of working is with a mouse. If you want to know why they did that, just follow the money.
You know better. You know that in the time it takes to reach for a mouse, click some menu items, and get back to typist home position, you could have invoked a keyboard-friendly menu, chosen what was needed, have an extra sentence typed, all as muscle memory, with no attention diverted from your writing.
You also know that switching back and forth between keyboard and mouse is horribly inefficient, and life's better when you choose one or the other. And you know that when you're writing a 5000 word web page, you need the keyboard. The mouse; not so much.
Bluefish is designed from the ground up to be keyboard friendly. You almost never have to use a mouse in Bluefish, so learn the keyboard techniques to make you a content-fountain.
I'm quite sure that, with my whole five days of Bluefish experience, I haven't scratched the surface of timesaving Bluefish features. Of course, I already use zencoding and autocompletion to make authoring lightning fast. But if you ask me a month from now, I'm sure I'll tell you I was slow as molasses when writing this document today.
Never quit looking for faster ways to use Bluefish. Faster authoring means more free time and more money.
If you started making web pages in 1995, then unless you have a spectacular memory, you sat there with an HTML manual in your lap, typing tags in Vim or Emacs or Notepad. And if you're anything like me, then subtly, that's the way you've always viewed HTML authoring. As something slow, cumbersome, and frustrating. Bluefish will change that view, pronto.
As you start to type your tags, Bluefish displays a list of tags conforming to the letters you typed, often with their most used attributes. As you begin to type an attribute within a start tag, Bluefish displays a list of attributes conforming to the letters you typed, and as you arrow between items on that list, Bluefish tells you the possible values of the attribute you highlighted. 1995 is long gone. Today, with Bluefish, it's difficult to make a mistake coding HTML, and if you do, no problem, because tidy -eq myfile.html command finds your errors.
Bluefish's syntax help is so good that you learn HTML as you author. As a matter of fact, you can use Bluefish to learn HTML. You could type each letter in the alphabet, one at a time, and disply Bluefish's list of tags or attributes for that letter.
The bottom line is this: Bluefish eliminates your need to memorize massive lists of tags and attributes, makes learning HTML easy, and therefore makes HTML authoring easy.
Bluefish is a spectacular tool, but it does only so much. Here are some more tools that make it even more productive:
Firefox has an Auto-Reload addon that makes Bluefish work almost WYSIWYG, because it causes Firefox to update its rendering of your file every time your file gets saved. Put Bluefish on the left, Firefox on the right, and feel the power.
The Firefox Auto-Reload addon is available at https://addons.mozilla.org/en-US/firefox/addon/auto-reload/
Various browsers have ways of rendering invalid HTML with common sense, but wouldn't it be nice to know your HTML files are valid, so they'll presumably look the same in all valid browsers? There's an HTML beautifier program called tidy that can validate as well as, or more to the point, instead of beautifying. The way you do this is with the following command:
tidy -eq myfile.html
If your HTML has no errors or warnings, tidy is silent. Otherwise, it articulates every error or warning, with its line number, so that you can find the line in Bluefish and fix it.
Note:
Bluefish actually has tidy built in, accessible from the menu system. However, I personally was unable to find a way to make it, or the other syntax checkers Bluefish incorporates into the menu system, work. As time progresses, I'll probably figure out a way to do it, but for now, take comfort in the fact that a standalone tidy can do all the HTML syntax checking you need.
<h1> tags are typically used as headings for sections or chapters, and so they need a unique ID so that cross references can point at them and tables of contents can point to them.
Note:
Using <a name="myrefpoint"></a> is sooooo 1998. Cross reference anchors belong in the tag's ID, not in an <a> item.
Therefore, your <h1> tags will probably look something like this:
<h1 id="what_i_did_last_summer">What I Did Last Summer</h1>
To make creation of cross references easier, the tag's id should be something that resembles the actual text of the section or chapter heading. Some WYSIWYG editors make an id based on the heading text, and that's a huge time and brain saver. Bluefish doesn't do that, so I used the Lazarus RAD environment to create a little program that you paste the text into, and it spits out, all highlighted and ready to copy, something like this:
id="what_i_did_last_summer"
So you just mouse into the <h1> tag, paste, and bang, you're done. It's a little quicker and a lot easier on your brain than would be making your own id every time.
As far as I can tell, Bluefish itself has nothing to make a table of contents. So I wrote a quick and dirty Python program to read a Bluefish-created HTML file, and assemble the id attributes in all the <h1> tags, and makes a <ul> based table of contents consisting of links. That way you don't need to perform 15 minute, mistake prone process of going through the whole file, hand assembling the table of contents.
Steve Litt is the author of Troubleshooting: Just the Facts. Steve can be reached at his email address.
I'm a production man. Go fast or go home. Life's too short for slow, and the slow guys fill the unemployment lines. If you're going to use Bluefish, use it speedily. Luckily, Bluefish was built for speed.
Zencoding tops the list of Bluefish's shortcuts. It's what enables you to punch out more content per day with Bluefish than with the WYSIWYG editors. Use zencoding right, and you'll never type an angle bracket again, at least not as part of an HTML tag. Here's a proof of concept example. In the Body part of your HTML document, not within any container, type the following:
p#myid.myclass
Press Ctrl+Shift+Enter, and look what you get:
<p id="myid" class="myclass"></p>
The cursor is between the start and end tags, ready for you to whomp out some more content. In zencoding, # means "id", and . means class.
Pro Tip
Because zencoding requires you to type out the entire class, make class names short.
Want to whip out the skeleton of a 4 item numbered list in a few keystrokes? Do this:
ol>li*4
Bang! Look what you produced, and of course with your cursor between the begin and end tags of the first list item:
<ol> <li></li> <li></li> <li></li> <li></li> </ol>
In zencoding, the right angle bracket signifies that what's right of it is a child of what's left of it, and an asterisk means "times", in the preceding case, times four. Worksaver!
You know the biggest time waster in Kompozer, LibreOffice, and especially LyX? Character styles. You must either come off home typing position to grab the mouse, or you must go through a wrist-twisting sequence of keystrokes that Emacs would be proud to require. Not so in Bluefish. Let's assume you've CSS-defined a <span> class called emph, obviously for emphasis. Now, as you type, just type the following and press Ctrl+Shift+Enter:
span.emph
Wham, all the HTML is created, and you're between the tags, ready to type the emphasized text. Much, much, much faster than LyX, Kompozer or LibreOffice. But wait, there's more...
The shortcut in the preceding paragraph is fast, but it could be a lot faster. Notice that once you finish writing between the tags and want to skip past the closing tag, you have to take your right hand off home position and use the cursor key to pass the close tag. Oh no you don't! There's a zencoding function called "Next Edit Point", which you can access via the menu as Alt+z,n. But that's not much better than the cursor key.
That's OK, hover the mouse over Zencoding->Next Edit Point, and press a convenient keystroke combo to represent it. I used Ctrl+Shift+i. Now that key combo appears as the menu's shortcut, so that on new-construction zencoding you can use that keystroke to skip past the end tag. Note however, that this doesn't always work. For some reason, it doesn't work if there is text following the end tag. That's OK, 90% of the time you'll be using this feature before you've written anything past the end tag.
Pro Tip
Hotkeys normally don't survive past your session. If you want them to, and if you haven't accidentally (or on purpose) assigned any bogus hotkeys, menu Edit->Preferences->User Interface->Shortcut keys, and click the button that reads "Save user customized menu accelerators now". Once you've done that, your hotkey will be available in future sessions.
I could go on and on about zencoding. Read about it on Wikipedia and elsewhere, because I've just scratched the surface. But I need to comment on some of Bluefish's other timesavers.
If you want to change all your <h2> to <h3> for a specific interval, just highlight that interval, press the Ctrl+h key to get advanced find and replace, and operate it. Obviously you need to back up before doing this, in case something goes wrong.
Search and Replace is either inconsistent, buggy, or has surprising behavior, because a lot of times it will tell you there's no selection, even though you know you made the selection. So far it seems to me like, to get it to work, you must make the selection be linewise, and not character wise, and you must invoke it with Ctrl+H, not with the mouse and menu. Like other intermittent problems, as you get more experience, you'll subconsciously operate it in a manner most likely to bring success.
I've talked so much about this already, that I'll just mention you should use this liberally when you forget exact keywords. If autocompletion doesn't seem to be happening, try these things:
Use zencoding to go fast, but use autocompletion when you're not sure of syntax. One helps you type faster, the other helps you get past time consuming confusion. Together, they make quite a pair.
You know what a pain in the posterior it is to make an HTML comment? On the menu, Tags->Comment. Better yet, this comes with the hotkey Ctrl+Alt_C, so use it!
Bluefish has so many timesavers that there's no way you learn them all in a day or a week or a month. Learn the low hanging fruit like zencoding and autocompletion as soon as possible, and then keep on learning as time goes on.
Steve Litt is the author of several human performance books. Steve can be reached at his email address.
If you've read my philosophy, you know. If you've talked to me personally, I've told you. If you're on the LyX mailing list, you've heard it again and again. I believe in Styles Based Authoring (SBA for short), and nothing but Styles Based Authoring.
The easiest way to begin defining SBA is to define its opposite, fingerpainting. Fingerpainting is the kind of authoring in which, as the author types elements of text, he includes appearance information. Bold, italics, small caps, big, small, center, just throw them in there with the text. Try to remember the appearance you gave to the last emphasized text so you can give the same appearance the next time. Try to arrange the note boxes all the same. And once you're done with your first draft, don't change appearances, because you'll need to do a global search, and then hand-replace. This is fingerpainting.
Styles Based Authoring is the opposite. Include no appearance information with any text element. Instead, for each text element, assign a style, based solely on the usage of the text element, to the element, and use the style itself to specify all appearance information.
Pro Tip
With HTML, each text-containing tag has a style, either a default style, or a style you assigned in the CSS in the styles area of the document header. So you needn't assign a style attribute to the tag default. For instance, probably 80% of the paragraphs in this document are delineated by a <p>/<p> pair. No need to include a class= in the start tag, you're just using the tag default. This makes authoring much easier for 80% of the paragraphs in this document, which increases overall authoring speed. For each kind of tag, if one usage predominates, let that be the default.
You can change the appearance of any tag default, to your heart's content, in CSS.
So, with HTML, many tags in the text in the body contain just the class= attribute. No tags contain anything about fonts, justification, margins, padding, color, or any other appearance. Just class, and that class is defined in the CSS in the <head>/</head> section. And of course, the default tags, like <p>, have no attributes at all. Besides the class= attribute, the only attribute I regularly use on tags in the body is the id= attribute, which I use whenever I need to crossreference to this element from elsewhere.
Similarly, in LyX or LaTeX Styles Based Authoring, appearance altering code isn't intermingled with the text. Instead, the text has commands or environments applied to it, and those commands or environments perform as styles, and are defined in the Document Header.
In the same way, in MSWord or LibreOffice, Styles Based Authoring means that in no instance to you highlight a word and change its appearance. Instead, you highlight the word and apply a character style. Or you highlight a paragraph and apply a paragraph style. The styles themselves are available for creation or editing in the program's Styles facility.
Here are just a few reasons why Styles Based Authoring is necessary with any document over 10,000 words:
Helpful Hint
Sometimes you don't want to take much time creating a new style, because it will make you forget what you were writing about. No problem. Quickly (like in 1 to 2 minutes) create a stub style that's different enough from standard paragraphs and text that you can recognize it as different, and start applying that style to text as appropriate.
Then, when you're not writing, go back and tweak the style definition so it looks like you want it in the text. This is expecially important in LyX and LaTeX, where getting a style to look just the way you want it can take hours, or occasionally, more than a day.
The bottom line is this: If you write anything more complicated than a shopping list or a two page letter, use Styles Based Authoring. Leave the fingerpainting to the turkeys.
Steve Litt is the author of Rapid Learning for the 21st Century. Steve can be reached at his email address.
If you want the speed of a WYSIWYG combined with the HTML validity of a text editor plus HTML checker, you want Bluefish. It has a significant learning curve, but after 2 days of use your productivity will be close enough to that of a WYSIWYG that you won't be tempted to go back. And with Bluefish, you can keep getting faster.
Don't open your Bluefish created HTML files, or any other tag-editor created HTML files, with a WYSIWYG web editor. WYSIWYG web editors trash perfectly valid HTML files.
Steve Litt is the originator of the Universal Troubleshooting Process. Steve can be reached at his email address.