Visibility of special codes

[BetterRed]

I'll never be more than a casual user of the editor to fix format and layout 'glitches', essentially fine-tuning. For content editing, general layout etc I'll always prefer a something like MS Word or Atlantis.

I've been following the nbsp and nnbsp codes thread with interest.

One of the annoyances I have with the editor is when I'm scanning the preview and edit windows I cannot see a distinct representation of special characters, preferably the edit window along with all the other 'technical' stuff.

I appreciate I can move the cursor to the yellow lozenge and I'll see the precise name of what's behind it in the status line. But I find it tiresome to have pick up the mouse and position the cursor to the lozenge, besides not all special characters appear as a yellow lozenge (e.g. nnbsp), they're 'invisible', admittedly when I move the cursor 'there' they show in the status line, but...

I don't care how these things are represented internally, I leave that to Kovid and other's folks better judgement.

What I yearn for is a button that would unhide the special characters and show them as highlighted decipherable mnemonics, something like this where the background colour is specific to displaying special character mnemonics. Ideally the mnemonics would be the same as what's in the Special Character tables and other resources.

I'm puzzled as to how other people cope without something like I propose. One of the perennial complaints about word processors is that they selectively hide special characters, it surprises me that this seems to be the case in this editor. I would rank a feature such as this much higher than I would a spell checker or macros.

But maybe it's already possible - I frequently find that things I wish were in calibre, are already there

BR

[theducks]

The ENTITY NAME for the character under (before) the cursor shows on the right side of the status line

[BetterRed]

Originally Posted by theducks

The ENTITY NAME for the character under (before) the cursor shows on the right side of the status line

Please read what I wrote

Originally Posted by BetterRed

I appreciate I can move the cursor to the yellow lozenge and I'll see the precise name of what's behind it in the status line. But I find it tiresome...

Sorry I don't use the aficionado lingo, but I find its most often used to obscure the essence of the matter at hand. The phrase 'the precise name' is drawn from the rich corpus of the English language as used by literate humans, ENTITY NAME is jargon used by illiterate computer software

BTW on my computer I have to put the cursor after the yellow lozenge to see what it is in the status line!

BR

[eschwartz]

See here: https://www.mobileread.com/forums/sho...d.php?t=234044

Originally Posted by kovidgoyal

There is no "view" in the editor. The only way to get the editor to display hidden characters is to actually replace the hidden characters with whatever symbolic character you need. At that point you have to keep track of every such replacement, so you can undo them when saving the text.

Or re-implement the entire QPlainTextEdit control from scratch to support a special rendering mode for non-visible characters.

One hackish way that you *may* be able to achieve this is to use a special font that has a symbol glyph for hidden characters. However, that will only work if Qt text layout engine allows the font to determine the rendering of non-visible characters, which may not be the case.

Originally Posted by kovidgoyal

No, QPlainTextEdit does not expose detailed change information. You know when the text changes, not exactly what the change was. And in any case maintaing two copies of the text that would need to be synchronized would double memory consumption and be very slow.

The only workable solution is for this is to change the rendering code to simply render invisible characters visibily. But that requires modifying the guts of Qt's text rendering system and is waaaay too much work.

[BetterRed]

Originally Posted by eschwartz

See here: https://www.mobileread.com/forums/sho...d.php?t=234044

Thanks mate, so I have to use the same feeble techniques in an editor written in 2014, that I have been using in various incarnations of Microsoft Word and similar products for the last 35 years. Computers might have got faster, and user interfaces full of more glitz and bling, but the underlying deficiencies persist.

Its sort of like --- oh, well if MS does it like that it must be the right way do it. Back in the old days it used to be said that no one ever got fired for buying IBM...

I have a vague memory of a word processor that displayed special chars as mnemonics - might have been Multimate or Wang. It wasn't Xerox Star because I had the same gripe about it when I did some work for them in 1979. MS developed WSIWYG Word after they filched Simonyi from Xerox in '81!

Let's blame Xerox for Everything.

BR

[roger64]

Originally Posted by theducks

The ENTITY NAME for the character under (before) the cursor shows on the right side of the status line

Technically, as all the characters used by the Editor are UTF-16 (correct me if I am wrong), could you still call any of them an "ENTITY"? What is displayed in code view can at the best be considered as the ghost of an entity, as an ectoplasm, nor named nor numbered... Their real new names are \u00a0 or \u202F and they need to be treated fairly as they just got the Unicode nationality.

[theducks]

I am glad you folk have memorized the UTF-16 chart.
I have NOT. Never will. No Way. Sorbet in H3ll before it happens.

The character Name is of great significance to us mere mortals.

[DiapDealer]

You're under no obligation to let calibre replace your named/numbered entities with unicode characters (visible or invisible). Just turn off the editor preference that changes entities to characters immediately after typing them and remember not to use the "Fix HTML" or "Beautify" tools. Concessions always need to be made when you want a program to automatically correct/tidy some code (and I'm not suggesting there's anything wrong with needing to do so) for you. But I rarely have broken or unreadable (x)html that I open in an ebook editor anyway.

The ability to open ... edit ... save ... without the editor making any behind the scenes (and silent) changes whatsoever (yes, I know I have to be sure to turn off the metadata update when opened inside calibre) is one of this editors greatest strengths, I think.

Also, note that even if I do allow calibre to replace my entities with unicode characters, I still clearly see a yellow background around characters (in the edit/code window) that are considered "special." Sticks out like a sore thumb to my eyes (but I can understand the frustration if some characters lack this distinction). More so than the original entity did, in fact. If it's not clear to me what it is at a glance, I can "zoom" further with the cursor.

The narrow non-breaking space, the thin-space, the zero-width joiner, the soft-hyphen and other such characters/entities have played havoc with editors/devices for a long time--many don't support some or all of them at all. I'm sure if there were a simple solution, it would be implemented already.

[roger64]

Originally Posted by theducks

The character Name is of great significance to us mere mortals.

I looked for the utf-16 code because I did not want to die ignorant. Of course a name is human friendly and these characters have names too.

But you missed my point: I just wanted to remark that it's a character name, not an entity name. One is called no-break space, the other narrow no-break space. We shorten that to nbsp and nnbsp, but now, in the UTF-16 only bright new world - if you selected that option - there are no more entities.

Temporarily highlighting characters

This is a modest proposal following BetterRed thoughts.

We all have used underground in unknown cities. Hopelessly lost, we look our way on the huge wall map, figuring 300 subway stations. We select the name of the target station, and suddenly we can see our itinerary highlighted : six stations on the blue line, change, four on the red line and done. Everything is clear. OK. End of highlighting. New customer.

Originally Posted by DiapDealer

The narrow non-breaking space, the thin-space, the zero-width joiner, the soft-hyphen and other such characters/entities have played havoc with editors/devices for a long time--many don't support some or all of them at all. I'm sure if there were a simple solution, it would be implemented already.

Why this underground idea above could not be applied by the Editor to unicode characters of every kind? Ctrl+N, we know there are 1407 nbsp. Fine. Ctrl+H, they are temporarily highlighted, as long the search box is unmodified or that the Ctrl+H is not pressed again.

Importantly, invisible characters could be pinpointed this way by adding a temporary highlighted character that could not be mistaken for another one. At long last, we could see the invisible man...

This could be helpful to many beginners.

[DiapDealer]

Originally Posted by roger64

Why this underground idea above could not be applied by the Editor to unicode characters of every kind?

There's probably no reason why it couldn't be applied... in theory. In practice, it's usually because .... well, frankly because Qt.

[BetterRed]

It's all moot anyway - unless someone is prepared to carry out significant work on modifying Qt, or Kovid swaps out Qt for ????.

I get the feeling that the odds of either happening, in my lifetime at least, is somewhere south of Viktor Yanukovych chances of regaining his presidency :lol:

==============

I'd settle for all the special characters like nbsp, and nnbsp, shy etc being displayed as a yellow lozenge

It would also be good if I could discern the presence of the lozenges when the line was highlighted because its the current line. I recall Kovid indicating he hopes to provide customised 'theming'. So, if that happens then I guess this annoyance would be addressed within a theme spec.

BR

[roger64]

Originally Posted by DiapDealer

There's probably no reason why it couldn't be applied... in theory. In practice, it's usually because .... well, frankly because Qt.

If there is no entity in the code, I mean if we deal only with Unicode characters, maybe even Qt would comply?

[DaleDe]

Originally Posted by theducks

I am glad you folk have memorized the UTF-16 chart.
I have NOT. Never will. No Way. Sorbet in H3ll before it happens.

The character Name is of great significance to us mere mortals.

See the wiki for Named character references for all the names used in HTML5, a superset of entity names.

Dale

[roger64]

delete