Quick Question

[KevinH]

There may be a way for a TagLister object to build a cache and use it if no textChanged signal has happened. That might prevent wasted parsing for just cursor moving. Let me play around a bit.

[KevinH]

Okay, I found a way to greatly reduce the wasteful reparsing when nothing has changed but cursor moves. So that part of my worry has been solved. Leaving the cursor anywhere inside a tag will highlight it and its matching tag if any as requested.

DiapDealer is working on adding the required gui pieces and settings to enable and disable it.

If you do not like the background highlight colour used in dark mode, you can control that.

When in Dark Mode go to Sigil Preferences and under CodeView colours simply adjust the "Line# Background" highlight colour as this is used for highlighting the background of the line # area, highlighting Marked Text, and now for highlighting open and close tags.

For many it appears to be too close to the normal dark background colour, so changing it to be something a few shades lighter in the grey tones, will make it more visible. This will not change your light mode highlight colours.

Testing and feedback especially with really large xhtml files would be most welcome for those who build their own.

Hope this helps.

[DiapDealer]

In addition to lightening the "Line# Background" highlight color, I've found that changing the "Line Highlight" color to something else entirely helped me greatly. Trying to find 3 shades of gray/dark gray that offer enough contrast (where they all three collide in the opening tag) can be a bit tricky.

[BeckyEbook]

I also did tests in dark mode.
Finally, I changed the color of "Line Highlight" to the background color (#2a2a2a) and then it's quite pleasant to work.
Of course, if someone is used to highlight the line in which the cursor is currently located, it can be a little lost (if we are not in any tag then we can not see any highlight).

Therefore, I have a proposal to discuss.
Maybe alternatively instead of highlighting the line where the cursor is currently located – highlight only the background of the line number?
Something similar is implemented in Sublime Text, and the highlighting of matching tags is done there perfectly.

[KevinH]

Open/Close highlighting seems to work well now even with the line highlighted. So I have no plans to tweak things any further to match what other editors do. If you feel that change is important for the majority of current users, then please generate a pull request we can evaluate critically and we will think about adopting it. But no promises.

[Notjohn]

>I simply run mend and prettify so that indentation will show what goes with what.

Mend & Prettify is an elegant feature. I do it reflexively.

[Thasaidon]

Originally Posted by Notjohn

>I simply run mend and prettify so that indentation will show what goes with what.

Mend & Prettify is an elegant feature. I do it reflexively.

"Snap"

[BetterRed]

Originally Posted by BeckyEbook

Maybe alternatively instead of highlighting the line where the cursor is currently located – highlight only the background of the line number?
Something similar is implemented in Sublime Text, and the highlighting of matching tags is done there perfectly.

If a 'line of text' (e.g. a paragraph) flows over multiple lines within the code view window one would have to scan the entire paragraph to find the very thin Insertion cursor.

That would be less of a problem if the Sigil codeview window honoured the Windows Insertion cursor thickness setting. Notepad is the only text editor I have that honours it Interestingly it is honoured elsewhere - e.g. Sigil's metadata editor, calibre's comments editor etc.

BR

[KevinH]

There is no code that sets cursorWidth in the QPlainTextEdit used by CodeView or anyplace in Sigil. It literally is not set by any code in Sigil in any of the editor windows and just uses the Qt default. Editing in a TreeView just naturally defaults to using a larger cursor.

FWIW You should file a bug report to Qt about it adopting the Windows Insertion cursor thickness setting.

As for Sigil, if the default size is truly an accessibility problem, we may be able to add an environment variable to control doubling of the the current cursor width to 2 pixels (in Qt display scaled pixel units), at least for the CodeViewEditor. We use environment vars to disable cursor blinking for similar reasons.

[BetterRed]

@KevinH - if Becky's suggestion to highlight the file line number rather the displayed line is not adopted, or it's made an option then there's no need to do anything about cursor thickness on my behalf.

That said, I do see merit in Becky's suggestion. There are occasions when the display line highlighting irritates me - but right now I can't say when, where or why.

Wait - yes I can! I'd prefer it not be there when the code view window doesn't have keyboard focus.

BR

[KevinH]

FWIW, I played around with setCursorWidth in a QPlainTextEdit (ie. CodeViewEditor) but it would not change the thickness or width of the I-beam text insertion point cursor at all. It seems to be set by the QStyle property it inherits from the OS and appears to be unchangeable (at least on macOS). That said, MacOS Accessiblity features do seem to have an impact on it and using a larger font does seem to increase its size to make it easier to see.

Using the highlight line colour to increase the contrast seems to be the best way to make it more readily apparent.

So there would be no easy way to increase the I-beam insertion point visual thickness as it is determined by both the OS style setting and the current font and font size used as it must sit between adjacent characters.

[BetterRed]

@KevinH - given how many programs don't honour the Insertion cursor thickness setting in Windows I am not expecting you to spend much time on it. Where it is honoured, I've come to know that the insertion point is before the character under the thick vertical bar, viz:

**

The highlighting of the current display line when the CV window doesn't have focus is more of an issue for me. I like to use the Tab key to move between 'panels' - if the display line highlight was only shown when CV has KB focus I would know when I landed on it, as it is now I often inadvertently insert Tabs in the text.

** that's the calibre Comments editor, I think it's some sort of QT textedit widget. It seems to be browser based widgets that don't honour the cursor thickness setting - except Edge, which is based on Chrome

BR

[DNSB]

Originally Posted by BetterRed

that's the calibre Comments editor, I think it's some sort of QT textedit widget. It seems to be browser based widgets that don't honour the cursor thickness setting - except Edge, which is based on Chrome

Minor nit. Edge is based on Chromium which is what Chrome is also based on.

[KevinH]

Originally Posted by BetterRed

The highlighting of the current display line when the CV window doesn't have focus is more of an issue for me. I like to use the Tab key to move between 'panels' - if the display line highlight was only shown when CV has KB focus I would know when I landed on it, as it is now I often inadvertently insert Tabs in the text.
BR

I played around with this but dropping the highlight when focus is lost just does not work.

Every time a user clicks on a place in Preview to sync with CodeView the highlighting would be lost as Focus goes to Preview so you can not tell where you are after the sync (or that the sync even happened at all if no scrolling is involved). Similar problems happen with Find and Replace as it takes the focus but you can not easily see where you are finding and replacing as the highlight is lost.

I am afraid that is something that too many users rely on (ie - I do!) and so we will not drop current line highlighting when focus is lost as there are many outside windows can can and will interact with the CodeView window but are outside of focus.

Sorry, but your window manager should be making things clear when focus changes by dropping/showing the insertion point cursor. So looking to see when the blinking cursor is in a window is the best way to tell if that window is able to accept keyboard input.

If you have trouble seeing the cursor, please try using Windows Accessibility features to help make it more clear (that does work with macOS Accessibility settings so it should with Window's as well).

[KevinH]

If not, there is a QStyle pixel metric called PM_TextCursorWidth that I should be able to override to increase the insertion point thickness by overriding the style set value for each platform via an environment var setting that might have a chance of working.