[live preview] Navigate source by clicking in preview

[0b10011]

This is a long shot, but it would be a nice feature to be able to click in the live preview and have the cursor placed in the appropriate spot in the source in Brackets. (Disabled by default is more than okay.)

A simple(r) way to do this would be to require the selection to start and end in the same text node. Then, you won't have to worry about creating an unbalanced selection in the source (eg, start tag selected, but not the end tag). Another option would be to disallow uncollapsed selections.

Using multiple selections/cursors, it could also be possible to only select text in the source (and maybe <br> and <img>?), ignoring tags entirely. But this could get extremely tricky and error-prone.

Anyway, just a suggestion :)

[peterflynn]

Great suggestion. We're tracking that idea here in our feature backlog: Jump to HTML Code in Brackets by Selecting in Browser (Live Development). Please upvote to help raise its priority.

I'm not entirely clear on your other suggestions about selection. Are you looking for commands that jump the cursor to the next tag, skipping over any plain text in between? If you want to fully restrict what can be selected at all, what would you picture happening if the user clicks directly on other text -- where would the cursor go? Also, how would you picture toggling such a mode on/off?

[0b10011]

I'm not entirely clear on your other suggestions about selection. Are you looking for commands that jump the cursor to the next tag, skipping over any plain text in between?

I was actually thinking that HTML shouldn't be selected when making a selection in the preview. Or, if it was, only select tags that are fully selected. For example ({ is start selection, } is end selection):

Foo ba{r.

Foo bar

Foo} bar.

Would result in:

Foo ba{r.

<h4> Foo bar</h4>

Foo} bar.

Whereas:

Foo bar.

Foo ba{r

Foo} bar.

Would result in:

Foo bar.

<h4> Foo ba{r}</h4>

{Foo} bar.

This would help prevent unbalanced sources if a user were to make the selection and hit Backspace/Delete.

If you want to fully restrict what can be selected at all, what would you picture happening if the user clicks directly on other text -- where would the cursor go?

I would see the selection being restricted to text and empty elements (br, img, hr, etc). So, no matter where the user clicks, the selection should go to the place in the text clicked, or to the start/end of the nearest text node.

Also, how would you picture toggling such a mode on/off?

For me, having a separate shortcut or a setting in preferences would be fine. I would tend to use this mode for editing typos in prose, especially with a non-technical person standing over my shoulder (they tend to hate looking at source code and like to see exactly what it looks like).

Another option would be to have a button to toggle it on top of the content of the page (position:fixed), probably with a configurable position (and z-index?).

[0b10011]

Additionally, if the text-only selection route is taken, it would probably be a good idea to set a flag to collapse the selections into the first selection if something is typed or Backspace is pressed, or the last selection if Delete is pressed. This would make it feel more like a WYSIWYG editor (without all of the pitfalls of WYSIWYG editors).

(I actually do something like this in CodeMirror by hiding formatting characters and doing creative things with key handling. And it's worked rather well for the past couple of years without any complaints from non-tech users.)