The current behavior is that the cursor goes to the very end of the HTML.
My suggestion is that when your cursor is in the WYSIWYG field, and you open the HTML editor, the cursor should be in the place within the HTML that corresponds to the place it was in the WYSIWYG field.
Example (| represents the cursor):
Lorem |ipsum
Lorem |<b>ipsum</b>
I don’t know how feasible it is, but I think it would be very useful.
This would be a nice improvement. One question to think about in the implementation would be the following: If the HTML text box is open, then would the cursor move around as you edit the WYSIWYG text?
I think it would make sense, since any content changes made in the WYSIWYG are immediately reflected in the HTML (and vice versa). It would follow that principle if the cursor was always synced, too.
But perhaps it is more difficult to implement.
I still think about this feature every time I have to fix some HTML in an Extra field with a lot of text.
If the text in a field is very long, it doesn’t appear when I open the HTML editor; furthermore, my current position within the text is not preserved, forcing me to search for it all over again.
If any proposals for improving the HTML editor are being considered, I would ask that you take into account the need for a better user experience when working with very long blocks of text. It would be very helpful to at least display the current line of text or the code for the current line.
That is indeed the case when switching via a hotkey.
On Windows 10, the cursor position doesn’t change for me. I’ve found a workaround: I switch using the TAB key (and SHIFT+TAB to go back). In theory, when a window gains focus, it should display the specific part of the text where the cursor is located—but that doesn’t happen! I can shift the focus—using the left or right arrow keys (while holding SHIFT if I need to maintain a text selection)—which forces the view to jump to the relevant area. However, that’s not something everyone would figure out on their own. If there were at least two separate windows—one for the code and one for the text—I could manually scroll through each and compare them.
In this add-on (https://ankiweb.net/shared/info/1066987105), I implemented a way to at least inspect the underlying code—for instance, to see if something is just a standard space or some other HTML markup—providing at least a basic level of confidence in the code. I’m aware that there are add-ons that fully replicate a WYSIWYG editor, but for my needs, a simple adjustment—scrolling to the area where the cursor is currently positioned—would suffice. Is it really worth creating an entire add-on for just that? It didn’t seem like a complex enough feature to warrant a dedicated add-on.
