CSS Code Hint should be able to add a space after colon

[dangoor]

When a property is selected, a ":" is automatically added but most CSS source files that I've seen actually use a colon followed by a space before entering the value.

[redmunds]

I disagree about auto-inserting a space after : because this is optional and not everyone does that. It would be a nice preference to have.

I also disagree that typing a ; should auto-insert a newline as some people prefer all of their declarations on a single line. This might also make a good preference.

Yesterday, I posted a test branch to allow you to tweak the settings: https://groups.google.com/forum/?fromgroups=#!topic/brackets-dev/yg6FtseEgZQc Please try it out.

[walesmd]

Personally, anytime the editor gets to "touchy" with my source it throws me off. I've only been digging through Brackets for one day, so no direct experience, but indirectly it took me many, many weeks to get used to Sublime Text 2 after years of Notepad++.

I would recommend watching the user to see what they do naturally after the colon (:). When I launch Brackets for the first time in a CSS File, I'm not going to pay attention to what it's doing. I'm going to start hammering away at 120WPM in the same habitual pattern that has developed over the past XX years. Set a soft-default once Brackets gets it right the first time, without the user manually going back to stylize a line, and keep it that way until the user "corrects" Brackets 2-3 times in a row (which we can presume is a change in stylistic preference from the user).

After the semicolon (;) not so much - a lot of variables at play. I'm trying to focus on my hand position now as I type, without actually affecting that position, and my right pinky hovers over return virtually non-stop. Semicolon-Return should be a very comfortable and natural roll of the fingers, index to pinky.

[dangoor]

I agree about making this a preference, and certainly like the idea of "learning" the value of that preference as suggested by @walesmd.

Assuming there isn't one on file, I'll split off a separate bug about the position of the code hint popup, because that is definitely a bug rather than a difference in behavior.

[walesmd]

My apologies @dangoor - it was fairly late when I originally replied to this and looking back over it I believe I may have focused on what was primarily a minor aspect of the original post (auto-characters) and completely misread the hinting discussion as auto-adding newlines.

I definitely agree with the hint position being a bug; only place that makes sense to me would be a position relative to the carat's current position (rather than carat's last position, which is what I believe you are describing in this instance).

[dangoor]

@walesmd your comments were fine! It was my original bug report that was at issue because there really are two things being discussed (one is a change in behavior, which is what the comments have been on, the other is a bug)

[dangoor]

I filed #2691 for the dialog positioning problem and changed the description of this bug to purely focus on adding a space after the inserted colon. I totally agree with other comments here that it would be good to have this be a pref of some sort.

[gruehle]

Reviewed - low priority.

[dangoor]

Moved to the CSS Code Hinting card

[peterflynn]

@walesmd: also note sometimes it's possible to "have it both ways" and behave nicely regardless of what the user is used to typing. You see this often with auto-inserting closing quotes, for example: if the user manually types a closing quote anyway (due to being in that habit from older, lamer editors), the cursor just passes over the already-auto-inserted quote without entering a duplicate. The same sort of "type-through" behavior could be used for auto-inserting a space after the ":" too.

[redmunds]

@peterflynn Those are different cases because closing quotes are required where the space following ":" in a declaration is optional. So, if user doesn't want the space, they will have to manually delete it.