Highlighted text: non-standard behavior

Please post all questions and comments regarding Help & Manual 7 here.

Moderators: Alexander Halser, Tim Green

Rainer Oehry
Posts: 102
Joined: Sun Dec 10, 2017 12:47 pm

Highlighted text: non-standard behavior

Unread post by Rainer Oehry »

When I highlight some text in WORD/Wordpad/Editor/any other Windows text handling software I know of, and then press LEFT or RIGHT, the highlighting is removed and the cursor is set to the beginning or the end of the previously highlighted section. Eg., when I doubleclick a word, it gets highlighted, and when I press LEFT or RIGHT, the cursor is moved before the first character or after the last character of that word.

Not so in H&M: When a word is highlighted, LEFT puts the cursor before the last character of that word, and RIGHT puts the cursor one position to the right of the last character of the word, typically after the blank just before the first character of the next word.

Is there a reason for this inconsistent behavior in respect to the Windows standard?
Regards,

Rainer
Head of Technical Writing & Knowledge Management
TIG Technische Informationssysteme GmbH, Rankweil, Austria
User avatar
Tim Green
Site Admin
Posts: 23143
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Highlighted text: non-standard behavior

Unread post by Tim Green »

Hi Rainer,

I'd never noticed this. I'm asking our developers if it's a fixed feature of the editor in Help+Manual or not. :)
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Tim Green
Site Admin
Posts: 23143
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Highlighted text: non-standard behavior

Unread post by Tim Green »

Hi Rainer,

This is simply the way this editor works. Note also that there is no Windows "standard" for this, and Help+Manual isn't required to copy every single little quirk of Word. 8)
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Rainer Oehry
Posts: 102
Joined: Sun Dec 10, 2017 12:47 pm

Re: Highlighted text: non-standard behavior

Unread post by Rainer Oehry »

Well, Tim, it is possible that there is no official Windows "standard" for this, but every single piece of text-handling Windows software I know of, from any manufacturer worldwide, adheres to this non-standard. So it COULD make sense to handle it the same way, even though there is no obligation to do so …

May I draw your attention to another quirk in WORD?

When I have something like text1 text2 textWithLink text4 and I want to delete text2 textWithLink, in WORD I can place the cursor to the left of text2 and hit CTRL+DEL twice, and I have text1 text4 as expected.

In H&M, after the first CTRL+DEL, text2 is gone as expected, but not the trailing whitespace, as would be the case in WORD, and I have to enter CTRL+DEL again to get rid of the whitespace and position the cursor to the left of textWithLink. But then, with the next CTRL+DEL, I don’t delete textWithLink, as I would in quirky Windows, but instead I delete the character to the left of the cursor, in this case the trailing whitespace after text1. With the next CTRL+DEL, I delete the 1 from text1, and with every subsequent CTRL+DEL I move one character further to the left.

Probably there is no Windows "standard" either requiring CTRL+DEL to always delete the word to the right of the cursor, and dynamically redefining the CTRL+DEL key to delete the character to the left instead in certain situations is just the way the H&M editor works.

The question is: Does it make sense?
Regards,

Rainer
Head of Technical Writing & Knowledge Management
TIG Technische Informationssysteme GmbH, Rankweil, Austria
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: Highlighted text: non-standard behavior

Unread post by Martin Wynne »

Rainer Oehry wrote:but every single piece of text-handling Windows software I know of, from any manufacturer worldwide, adheres to this non-standard.
Hi Rainer,

Except those which use the same RichView editor as H&M. Here's a list of them:

http://www.trichview.com/applications/

Including some of mine, not listed. :)

regards,

Martin.
Rainer Oehry
Posts: 102
Joined: Sun Dec 10, 2017 12:47 pm

Re: Highlighted text: non-standard behavior

Unread post by Rainer Oehry »

Thank you, Martin, for this information. Apparently I have never used any of these programs …

Do you happen to know why this highlighting-and-cursor-moving business is handled differently from the Windows non-standard? Is there an advantage to the way this is handled in Windows?
Regards,

Rainer
Head of Technical Writing & Knowledge Management
TIG Technische Informationssysteme GmbH, Rankweil, Austria
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: Highlighted text: non-standard behavior

Unread post by Martin Wynne »

Rainer Oehry wrote:Do you happen to know why this highlighting-and-cursor-moving business is handled differently from the Windows non-standard?
Hi Rainer,

Or alternatively you could ask Microsoft why Word doesn't adhere to the RichView standard?

In RichView CTRL+DEL removes a word or a space, one at at time, in the forward direction only.

CTRL+RIGHT ARROW or CTRL+LEFT ARROW jumps both in one go.

To do what you want, use SHIFT+CTRL+RIGHT ARROW or LEFT ARROW. Then DEL.

That requires an additional keypress, but on the other hand you have the option of going in either direction.

I'm happy with that.

regards,

Martin.
Rainer Oehry
Posts: 102
Joined: Sun Dec 10, 2017 12:47 pm

Re: Highlighted text: non-standard behavior

Unread post by Rainer Oehry »

Or alternatively you could ask Microsoft why Word doesn't adhere to the RichView standard?
Hi Martin,

yes, I could do that. We could also first compare the installed base.

And yes, I could do SHIFT+CTRL+RIGHT ARROW and then DEL, but what is the advantage over just entering CTRL+DEL twice? And why would I use SHIFT+CTRL+LEFT ARROW and then DEL, when I can just use CTRL+BACKSPACE?

In (non-)standard Windows, CTRL+DEL is supposed to delete the next word to the right, including whitespace, so that entering CTRL+DEL repeatedly removes one word at a time. With this alternative editor, I need two keyboard actions for every word, and if there is a blank left after deleting a word, DEL and CTRL+DEL do exactly the same - they delete the single blank character. CTRL+DEL should again delete the subsequent word and not just the next character, which could be achieved any time by pressing DEL alone, if this is what I want.

Astonishingly this is different for CTRL+BACKSPACE. In (non-)standard Windows this is supposed to delete one word to the left of the cursor, including whitespace, and therefore making it possible to remove consecutive words whith one keypress each. This situation is handled by the RichView editor in exactly the same way - CTRL+BACKSPACE deletes the word to the left including whitespace and lets me delete consecutive words with one (combined) keypress each.

And for me the most annoying deviation from what I expect is the switch of the CTRL+DEL functionality to deleting characters to the left instead of to the right, depending on the type of element to the right of the current cursor position. What's the reason for that?

I still don't see the advantage of this alternative - and inconsistent - behavior.
Regards,

Rainer
Head of Technical Writing & Knowledge Management
TIG Technische Informationssysteme GmbH, Rankweil, Austria
Simon_Dismore
Posts: 204
Joined: Thu Jul 13, 2017 2:57 pm

Re: Highlighted text: non-standard behavior

Unread post by Simon_Dismore »

Rainer Oehry wrote:every single piece of text-handling Windows software I know of, from any manufacturer worldwide, adheres to this non-standard. So it COULD make sense to handle it the same way, even though there is no obligation to do so
I tried a few just now: InDesign, VS Code, WebStorm, Sublime Text, Notepad++ and <textarea> in Chrome, Firefox and IE all behave the way you describe. I suppose it would make sense to follow suit.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: Highlighted text: non-standard behavior

Unread post by Martin Wynne »

Hi Rainer,

My view is simple. If you want something to work exactly the same as something else -- use that something else instead. I'm sure a usable Help system could be created in Word. I don't know because I never use Word.

H&M adopted the RichView editor (back in H&M4) because its internal format allowed it to be better customized for the specific task in hand -- creating inter-connected topic links and a multitude of inserted objects. I use RichView for the same reason. But that in turn makes it difficult for it to match some other editor formats. For example the handling of line wrapping within formatted text.

But if you don't claim that your software matches other software, I see no reason why users should expect it to. H&M is designed for a specific task, different from the others, and does that superbly.

regards,

Martin.
Rainer Oehry
Posts: 102
Joined: Sun Dec 10, 2017 12:47 pm

Re: Highlighted text: non-standard behavior

Unread post by Rainer Oehry »

Well, I myself use H&M as one of my primary tools, so obviously I am more happy with it than not, but this does not mean that I cannot try to get some annoying details improved, does it?

Whether whitespace should be deleted together with a word or not, could reasonably be disputed, I suppose, but the fact that the same key combination CTRL+DEL sometimes deletes characters to the right and sometimes to the left of the cursor is in my opinion simply a bug and not a feature, and I would like to know whether this behavior is really intended to be that way.
Regards,

Rainer
Head of Technical Writing & Knowledge Management
TIG Technische Informationssysteme GmbH, Rankweil, Austria
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: Highlighted text: non-standard behavior

Unread post by Martin Wynne »

Rainer Oehry wrote:but the fact that the same key combination CTRL+DEL sometimes deletes characters to the right and sometimes to the left of the cursor is in my opinion simply a bug and not a feature
Hi Rainer,

I can't replicate that? :? CTRL+DEL always works forwards for me.

I know there are some behaviours in RichView which Alexander and Tim would prefer worked differently. But ultimately it is for Sergey to decide. The fact that they have remained unchanged for many years suggests that the internal format makes them very difficult to implement.

For me, all this pales into insignificance compared to the lack of Overwrite mode. But I can live with it. Alexander tried to fudge it at one time, but it was not very successful.

regards,

Martin.
Rainer Oehry
Posts: 102
Joined: Sun Dec 10, 2017 12:47 pm

Re: Highlighted text: non-standard behavior

Unread post by Rainer Oehry »

Martin Wynne wrote:For me, all this pales into insignificance compared to the lack of Overwrite mode.
OMG! Never noticed that … because I never use it. Well, our individual requirements differ quite substantially, obviously …

Please try the following:

Enter "text1 text2 textWithLink text3" and make "textWithLink" a link to any topic (the same effect occurs with images and condition markers, too).

Now try to delete "text2 textWithLink" by placing the cursor to the left of "text2" and hitting CTRL+DEL repeatedly.

After the first CTRL+DEL, "text2" is gone as expected. My cursor is now in the middle of two single whitespaces - the trailing whitespaces from "text1" and "text2".

After the next CTRL+DEL the single whitespace to the right is gone and the cursor is located immediately to the left of "textWithLink".

Then, with the next CTRL+DEL, I don’t delete "textWithLink", but instead I delete the whitespace character to the left of the cursor (the still trailing whitespace after "text1"). With the next CTRL+DEL, I delete the "1" from "text1", and with every subsequent CTRL+DEL I delete one character further to the left.

Is this really supposed to work like that?
Regards,

Rainer
Head of Technical Writing & Knowledge Management
TIG Technische Informationssysteme GmbH, Rankweil, Austria
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: Highlighted text: non-standard behavior

Unread post by Martin Wynne »

Rainer Oehry wrote:OMG! Never noticed that … because I never use it. Well, our individual requirements differ quite substantially, obviously …
Hi Rainer,

You obviously don't often need to update numeric data in tables. :)
Enter "text1 text2 textWithLink text3" and make "textWithLink" a link to any topic (the same effect occurs with images and condition markers, too).
Now try to delete "text2 textWithLink" by placing the cursor to the left of "text2" and hitting CTRL+DEL repeatedly.
After the first CTRL+DEL, "text2" is gone as expected. My cursor is now in the middle of two single whitespaces - the trailing whitespaces from "text1" and "text2".
After the next CTRL+DEL the single whitespace to the right is gone and the cursor is located immediately to the left of "textWithLink".
Then, with the next CTRL+DEL, I don’t delete "textWithLink", but instead I delete the whitespace character to the left of the cursor (the still trailing whitespace after "text1"). With the next CTRL+DEL, I delete the "1" from "text1", and with every subsequent CTRL+DEL I delete one character further to the left.
Yes, I'm seeing that too. It is obviously a bug. I'm wondering why it has not been reported before? In my case it's because I rarely or never use CTRL+DEL. Having put the caret at the start of the text I want to delete, I simply hold down the DEL key until it's gone. Or select a much bigger chunk of text first.

I suggest you post this in the Bug Reports section.

regards,

Martin.
Rainer Oehry
Posts: 102
Joined: Sun Dec 10, 2017 12:47 pm

Re: Highlighted text: non-standard behavior

Unread post by Rainer Oehry »

Whenever I reported bugs in the editor, I was told that the editor is a third party product that cannot be altered, so basically it is take it or leave it.

I was just in the mood today to do some nudging and give it another shot, but without much hope.

But thank you anyway for verifying the behavior I was complaining about; it is always good to make sure it is not a local problem of my individual installation.

And you are right, I rarely need to update numeric data in tables. Can't that be automated by a script?
Regards,

Rainer
Head of Technical Writing & Knowledge Management
TIG Technische Informationssysteme GmbH, Rankweil, Austria
Post Reply