When Ben and I first started to use Bespin, at the time that we developed Bespin we would argue, or “discuss” subtle nuance of the coding experience. This inspired us more in the creation of the project, as we want to create an editor that Web developers can tweak and change in the language, platform, and tools that they use in their own lives.
Making the time to trick out and customize your developer tool is crucial. We spend day after day in our tools, and if you don’t take the time to learn them and trick them out, you aren’t going to be as efficient and productive as you can be.
Developer tools are often expert systems, and so we want to make Bespin as extensible as possible. Common attributes are wrapped in settings, and one of them is called strictlines. It is one of the places that Ben and I differ on how we like our editors to work (and disagreeing is fine because we get to choose for ourselves!)
The default behavior of the Bespin editor right now is to have this setting turned off, and that means:
- You can click the mouse on ANY area that you can see in the editor and the cursor will go there and allow you to start typing.
- If you position yourself at the beginning of the line and hit the left arrow, you will not budge.
- If you position yourself at the end of the line and hit the right arrow, you will keep moving right
This is how IntelliJ IDEA works by default.
Contrast this to strictlines mode (where you have to explicitly set strictlines on). Now:
- If you click off to the right you will be placed at the last column of the row
- If you position yourself at the beginning of the line and hit the left arrow, you will go up a row and placed at the last character (so backwards).
- If you position yourself at the end of the line and hit the right arrow, you will move to the start of the next line (so forewards).
I prefer strictlines, and most editors seem to come with that mode on. I don’t like the feeling of being able to click anywhere and not knowing if there is space in the file over there or not. I like being able to hold down left and go through the lines backwards, and vice versa for heading right.
Below is a video showing the two modes so you can see them in action:
What do you think? What would you like to see as default? To vote, comment on the blog or get on Twitter and “@bespin set strictlines on|off”.
Vote on! :)
March 27th, 2009 at 9:39 am
+1 for strictlines on
March 27th, 2009 at 9:54 am
+1 strictlines for me as well! I like being able to tell what is real white-space.
March 27th, 2009 at 10:04 am
set strictlines on
March 27th, 2009 at 10:17 am
+100 for strictlines. ;-) Sorry, Ben. Dion is so, so right about this one.
What version of IntelliJ IDEA are you/he using. No version since 7.0 works as you describe by default.
March 27th, 2009 at 10:26 am
on !
March 27th, 2009 at 10:26 am
+1 strictlines.
March 27th, 2009 at 10:38 am
on please
March 27th, 2009 at 10:39 am
+1 for strictlines ON.
I didn’t know about the setting and I hated so much the default behavior.
Also, tab key should insert a tab character, not spaces. It may seem trivial, but people get used to these kind of things. It’s one of the first settings I change on any editor I use. It also has advantages: you’d be able to change tabsize on existing documents and save precious bytes.
March 27th, 2009 at 11:01 am
+1 for strictlines :)
March 27th, 2009 at 12:13 pm
strictlines on, please. (Incidentally, a lot of editors call this feature “virtual space”.)
On a related note: when you highlight the current line, please consider making the background slightly different for the part of the line that has text in it (including spaces). That would allow people to easily see if they have trailing spaces.
As well as a simple vote for strictlines on, I can give several reasons backing it up:
First, most text editors work that way. I don’t think Bespin should blindly follow the conventions of other editors if a better approach exists, but I do think Bespin should favor the common behavior by default when no one behavior proves obviously better. This holds especially true for fundamental editor functionality like cursor movement.
Second, the ability to click anywhere and start typing there might prove useful for drawing ASCII art/diagrams/tables, particularly if combined with overwrite mode, but for most normal uses of a text editor you’ll only ever need 1-2 spaces after the content of a line, which you can easily insert with the spacebar. Thus, with strictlines off, you have to click near the actual end of the line (and figure out how many spaces you included after the line), whereas with strictlines on you can click anywhere after the text of the line, a much larger target area. For this reason, I think strictlines on proves easier to use via mouse.
Third, I think you’ll find that most productive text-editor users want to avoid switching between mouse and keyboard unnecessarily, and will often avoid the use of the mouse entirely for most editing tasks. I think strictlines on proves far easier to use via keyboard as well. strictlines on provides several convenient keyboard navigation possibilities from near the beginnings or ends of lines. For instance, from the beginning of a line, you can press up to get the beginning of the previous line, or left to get the end of the previous line, making them equally convenient. With strictlines off, you have to press up and end to get to the end of the previous line.
Fourth, having strictlines off will tend to lead to more trailing spaces in files, which prove annoying in various different contexts, including diff/patch, emails, version control systems, searching, pattern matching, and simply navigating through the file.
March 27th, 2009 at 12:29 pm
In reply to comment 8 regarding tab/space behavior, I’d like to offer a two suggestions *without* taking a side in the tab/space debate.
First, from what I’ve seen, most people seem to want the tab key to act as the “do the right thing to indent” key. Regardless of whether you configure Bespin to use tab characters or spaces by default, I think the tab *key* should by default indent the line to the right place using the configured whitespace.
Second, please implement tab-based indentation *correctly*, which most editors do not. Consider for a moment a line of C code which calls fprintf(f, “some format string”, various, arguments); Assume you have a long format string and several arguments, so you go to a new line at some point, and you want to indent the subsequent arguments to match the f after the open paren. The *correct* tab-based indentation for these lines will have some number of tabs before the fprintf( on the first line, and the same number of tabs followed by eight spaces before the first argument on the second line. Every editor I’ve ever used incorrectly indents the second line with one additional tab rather than eight spaces, which assumes that a tab takes up the same amount of space as the eight-character string “fprintf(”. As a result of many years of this incorrect behavior, the ideal scenario of just adjusting the tab width to your preferred amount of indentation just doesn’t work on real files: you *must* use the tab width the author of the file used, usually eight characters.
(Full disclosure: I personally tend to prefer spaces for files I edit, but primarily only because no editors do tab-based indentation correctly as described above. If every editor had always done tab-based indentation correctly, I wouldn’t particularly care one way or the other. Sadly, even if all new text editors did tab-based indentation correctly, that still leaves all the existing text editors that people have become attached to.)
March 27th, 2009 at 12:32 pm
Strictlines on please!
March 27th, 2009 at 12:43 pm
+1 strictlines on
Also, I agree with Apostolos Tsakpinis about the tab key; however, I would make it changeable for those who like the tab key to insert spaces.
March 27th, 2009 at 1:18 pm
+1 set strictness on
March 27th, 2009 at 1:28 pm
+1 on
March 27th, 2009 at 3:27 pm
I’ve already voted on Twitter (strictlines on), but I’d just like to point out that I’ve already implemented tabs support in the latest version of Bespin. I don’t think it’s available on bespin.mozilla.com, but it has already been done. No more spaces where you don’t want them!
March 27th, 2009 at 3:44 pm
Looks like I’m in the minority here, and I use an editor that only supports strictlines (Zend Studio 5), but I vote for strictlines off in most cases.
If my cursor is in the middle of a line of text, and I press up to go to the blank line above it, then I want it to behave consistently. With strictlines on it would sometimes move to the left (no white space on the line) but sometimes it would stay in the same place.
I see strict lines a bit like the ’show non-printable characters’ option – most people aren’t that bothered what the characters are, so they hide them to give a simplier / cleaner interface. Likewise, most of the time I don’t care if there is trailing space or a line full of white space in a file, so why should it make my editor behave differently?
March 27th, 2009 at 10:23 pm
Oh, Ian Thomas’s comment made me think of another behavior Bespin should have with respect to lines and movement. Say you have three lines like this:
1234567890
123
12345
You have your cursor at the end of the third line, after the 5. You press up, so the cursor ends up at the end of the 3. (For the record, it would bug me a lot if it ended up two spaces after the 3; I hadn’t even thought of *that* problem with strictlines off.) Now, you press up again. Some editors would put you after the 3 in the first line. Vim, on the other hand, will put you after the 5 in the first line, because it remembered your position in the line even if your cursor position remains to the left of that due to a short line. However, if you moved up, left, up, you’d end up after the 2 in the first line. I find this behavior very intuitive when using up or down to move across many lines; without it, moving past an empty line will put your cursor at the beginning of the line.
March 28th, 2009 at 12:26 am
Definitely strictlines on!
(Though I have to wonder if Ben has a blog entry somewhere, where all the comments say “definitely strictlines off!” :-)
March 28th, 2009 at 5:40 am
yes, strictlines on !!!
and we could be even more strict: remove trailing whitespace on save by default !
March 28th, 2009 at 6:55 am
The latter. Strictlines on.
March 30th, 2009 at 10:37 am
+1 for strictlines on.
It’s so helpful to get to the last “real” position in a line either with the back key or with clicking the mouse right of it, I found lots of useless trailing whitespace this way (before I used an editor that even marked trailing whitespace) and it’s quite helpful when editing and you want to jump to the end of a line.
April 2nd, 2009 at 11:47 pm
Regarding comment 20: No, don’t remove trailing whitespace by default. While you shouldn’t have files with trailing whitespace in the first place, if you remove it by default you end up making whitespace-only changes in unrelated VCS commits, which you shouldn’t do.