* Plain Text Only setting

[tatewise]

David, editing text in a long-text field offers two modes.

You can simply enter text directly into the small box shown in the Property Box or whatever dialogue you are using.
Whether that results in plain text or rich text depends on what is entered.
If only plain text characters are entered then it should result in a plain text field.
If formatted text is pasted in then it results in being converted to a Rich Text formatted field.

Alternatively, you can click on the [...] button to the right of that same small box.
In FH V6 that opens a floating resizable plain text editor box.
In FH V7 that opens a floating resizable Rich Text editor window with a word-processor style toolbar for bold, italic, etc, etc.
There is no plain text editor box in FH V7 unless you hold down Ctrl and Alt keys while clicking the [...] button. Then an FH V6 style plain editor box appears with a tick box saying Rich Text, which I suspect signals the presence of the _FMT 1 tag.

[Mark1834]

Once the Rich Text editor window is opened, whether on existing plain text or to enter plain text, then it is likely that a _FMT 1 tag gets appended. That changes the field from plain text to rich text as far as CP and Plugins are concerned...
Similarly, text that had been formatted rich text may have its formatting removed by the user editing the text. However, that may leave behind format wrappers on white space text and the _FMT 1 tag. Only a clear formatting option can comprehensively remove all format wrappers and the _FMT 1 tag to return the field fully to plain text.

No - Mike's description is incorrect, as can be readily verified by following changes to the GEDCOM file in a text editor.

If the Rich Text editor window is opened to edit plain text, and no rich text elements are added, the normal behaviour is to remain as plain text, with no formatting tags included in the GEDCOM file, and still reported by plugins as plain text. It may inadvertently pickup up superfluous formatting particularly, but not exclusively, in trailing spaces. That is the bug that started this entire discussion!

If rich text embellishments are removed, the normal behaviour is to revert to plain text, with no residual formatting tags, provided that the entire contents are free of rich text.

[ColeValleyGirl]

Alternatively, you can click on the [...] button to the right of that same small box.
In FH V6 that opens a floating resizable plain text editor box.
In FH V7 that opens a floating resizable Rich Text editor window with a word-processor style toolbar for bold, italic, etc, etc.
There is no plain text editor box in FH V7 unless you hold down Ctrl and Alt keys while clicking the [...] button. Then an FH V6 style plain editor box appears with a tick box saying Rich Text, which I suspect signals the presence of the _FMT 1 tag.

I'll add: if you only enter plain text into the V7 editor, you get a plain text field (except for bugs).

Thanks to Mike for pointing out the Ctrl+Alt+... option, which does generate a plain text note, unless you tick the rich text checkbox, which marks the content as rich text using:

Code: Select all

1 _TEXT
2 _FMT 1

even if no formatting is present.

If you use Ctrl-V to paste in this window, it pastes unformatted. (Note: Adrian).

Documenting that would (IMO) satisfy the need for an option to access the V6 plain text editor on demand, and to

Leaving us with the need for a paste plain text shortcut in the rich text editor, a documentation change and very little else?

[AdrianBruce]

But I do want the ability to alter what Ctrl+V does, via the default setting proposed.

There, I am not with you. Many of us know Ctrl-V to mean "dump whatever is on the clipboard into the application and let the application sort out what it all means" - I would not want to change that.

Likewise, slightly less widespread, but widely accepted is that Ctrl-Shft-V means "dump whatever is on the clipboard less any formatting into the application".

By following convention we know what to expect - which is important when pasting from websites and the result is not what you expect - you know what you wanted.
...

Hmmm. I'm not going to win this one, am I?

My problem with Ctrl+Shift+V being used as Paste Without Formatting is - how many people know that shortcut? How many FH users know that? Like I said, I know basically 4 keyboard shortcuts - Ctrl+C, Ctrl+V, Ctrl+X and Ctrl+Z. Watching fellow workers typing, I'd be surprised if many of them managed more than the first 3. I can only repeat that Ctrl+V altering its behaviour according to the origin of the stuff is standard MS Office (or Word, at least), so I'm bemused that such behaviour can be dismissed as not conventional Windows. (I'd agree that it's not consistent but then consistency never has been a strong point of IT software - not just MS). (I'd also have to admit that my fellow workers probably wouldn't know how to alter Ctrl+V behaviour in MS Word).

So basically, I have the situation where if I copy stuff from FreeBMD or the GRO site, my muscle memory sends me to Ctrl+V when I come to paste it into an FH note field. The GRO data pastes appallingly. See below:

Screenshot 2022-12-13 171315.jpg (17.12 KiB) Viewed 1264 times

The FreeBMD paste isn't perfect because it's got spurious link words in but it's a table with the right landscape format. (Yes, table!!! That's what they're called when printers set them up!!! )

Screenshot 2022-12-13 171357.jpg (15 KiB) Viewed 1264 times

Basically, I was trying to tame the garbage that Ctrl+V currently creates when pasting in, particularly when pasting in GRO stuff. But if I can't get Ctrl+V's default behaviour altered on a user-by-user basis - how do I tame the garbage? I know how MS Word does it - you get a little control after the paste that will allow you to choose a different paste behaviour for that paste if you realise that you got garbage. Can the FH Rich Text Editor do that? Or preview the paste before it's done?

Or am I stuck with trying to overcome my muscle memory of Ctrl+V and instead do a right-click followed by the desired paste option?

[NickWalker]

OK in replying to this I am struggling without specific screen shots and a copy of V7

FH 7 treats the text as plain text until an operation carried out by the user causes it to require a formatting tag within the text (in angle brackets such as <b>) As soon as the text gains a formatting tag FH is required to mark this as being rich text, otherwise it wouldn't know that these tags should be rendered.

If the text is edited later so that the formatting is removed such that there is no requirement for angle bracket tags anymore then the text reverts to being plain-text.

[Mark1834]

Thanks to Mike for pointing out the Ctrl+Alt+... option, which does generate a plain text note, unless you tick the rich text checkbox, which marks the content as rich text using:

Code: Select all

1 _TEXT
2 _FMT 1

even if no formatting is present.

Interesting - if you clear the checkbox while rich text is displayed, it removes the actual formatting and displays the format codes instead as plain text (similar to the rich text GetText() function). That could be very useful for ad-hoc removal of superfluous formatting.

[NickWalker]

My problem with Ctrl+Shift+V being used as Paste Without Formatting is - how many people know that shortcut?

I meet lots of people every day who have no idea about ctrl+v but I use it frequently in various applications. Likewise I use ctrl+shift+v frequently, although naturally the requirements to paste text without formatting are far less. So we definitely need ctrl+shift+v to fit in with other applications (including the web version of Office applications - I'm sure the windows app versions will catch up soon).

I'd have no issue with having an option to always paste text plainly. Surely that's what we're suggesting when we've said there needs to be a 'no rich text' mode?

[ColeValleyGirl]

Ctrl+V altering its behaviour according to the origin of the stuff is standard

Shouldn't that be: according to the destination of stuff?

[AdrianBruce]

Ctrl+V altering its behaviour according to the origin of the stuff is standard

Shouldn't that be: according to the destination of stuff?

Err. Yes. Probably.

[AdrianBruce]

...
I'd have no issue with having an option to always paste text plainly. Surely that's what we're suggesting when we've said there needs to be a 'no rich text' mode?

Not sure now if that's agreed - Helen (sorry!) seemed to be arguing that it could cause issues if the paste was meant to be rich but the mode was set to plain ... That's not me being awkward, I'm genuinely unclear what the consensus is.

[NickWalker]

The 'consensus' seems to keep changing. Before I left work I thought we'd got to a place where there was some agreement but by the time I got back home from work it seems to have shifted again. I can't keep up

[tatewise]

I'd have no issue with having an option to always paste text plainly. Surely that's what we're suggesting when we've said there needs to be a 'no rich text' mode?

Recent discussions have been suggesting that a 'no rich text' (i.e. 'plain text only') mode is not needed if CP fix all the bugs.
A new Ctrl+Shft+V shortcut, and existing right-click Paste Unformatted Text, and the Crtl+Alt [...] plain text edit are enough.

I agree Nick, I thought we were near a consensus, but then it all changed again.

[NickWalker]

Recent discussions have been suggesting that a 'no rich text' (i.e. 'plain text only') mode is not needed if CP fix all the bugs.
A new Ctrl+Shft+V shortcut, and existing right-click Paste Unformatted Text, and the Crtl+Alt [...] plain text edit are enough.

I agree Nick, I thought we were near a consensus, but then it all changed again.

Well if that's now the consensus then I think I agree with Adrian that users should be able to set 'paste unformatted' as an option in FH settings.

[ColeValleyGirl]

Helen (sorry!) seemed to be arguing that it could cause issues if the paste was meant to be rich but the mode was set to plain

I was more worried about not being able to paste plain text if the default mode was set to rich.

Re consensus, let's try again:

• MANDATORY/CURRENT BEHAVIOUR: Text formatting should only be introduced by the user (including by pasting formatted text from the clipboard or using formatted Autotext). If all visible text formatting is removed, the note should revert to plain text. (This seems to be the current design, but any bugs making this behaviour unreliable must be fixed)
• MANDATORY: Keyboard shortcut should be provided for pasting unformatted text in rich or plain text mode.
• NICE TO HAVE: An option to revert to plain text only, hiding the rich text formatting capability in the editor. [Is this satisfied by documenting the option to open a plain text editor via the Ctrl+Alt+... route? If this plain text editor is open, Ctrl+V pastes plain text.]
• NICE TO HAVE: A simple method of converting a rich text note to a plain text note. (The simple Select All-Cut-Paste Unformatted method exists already, which is why I've marked this NICE TO HAVE).
• MANDATORY: A one-off mechanism to remove formatting errors introduced by the bug(s) in the Rich Text functionality that introduce unwanted/unexpected rich text elements. We will need a list of the known problems.

plus a separate request to:

• Have the option to modify the behaviour of standard keyboard shortcuts e.g. Ctrl-V to always paste unformatted

[ColeValleyGirl]

Re Segoe: https://fhug.org.uk/forum/viewtopic.php ... 06#p131706

I wonder if there's a similar explanation for Cambria Math...

[AdrianBruce]

Okay - that seems fine, Helen.

Re the last bit about the separate request to adjust Ctrl V behaviour. I remember now why I wrote adjust according to origin. If I set Ctrl V to Paste Unformatted, in order to tame the GRO indexes, I would only want that Paste Unformatted to apply when pasting from outside FH.

If I pasted a Rich Text note from one FH note to another, I'd want that to keep the formatting. That's why MS Word has different defaults depending on where you're pasting from.

[ColeValleyGirl]

Adrian, that sounds like a new wish list request to thrash out the details would be helpful? We always run the risk of trying to lump too much into a single request...

[tatewise]

Yes, it is a recurring theme of this discussion where mixed plain text and rich text features are required simultaneously.
Which mode is applied in any one circumstance depends on the conditions.

[AdrianBruce]

Adrian, that sounds like a new wish list request to thrash out the details would be helpful? We always run the risk of trying to lump too much into a single request...

Agreed - see viewtopic.php?f=43&t=21294

[davidf]

That's why MS Word has different defaults depending on where you're pasting from.

How does the clipboard tell MS Word where it got its contents?

[AdrianBruce]

...
How does the clipboard tell MS Word where it got its contents?

Bill Gates magic... (PS - I may have mentioned this frivolous aside before but when I was a little lad, Bill Gates lived next door to us - he had a window cleaner's round and looked like Ted Bovis of Hi-De-Hi. He's come on a bit since then...)

Seriously - I remember in the depths of my fallible memory something about issues that could arise with copy and paste and two Office programs behaving differently as sources for the clipboard, because they populated the metadata on the clipboard differently. In fact, even deeper in the memory, they were putting multiple sets of metadata on the clipboard to allow the recipients to paste different versions of the same data, depending on taste. The order of the different metadata may have been important???? Clearly the copying program putting stuff onto the clipboard has no knowledge of the program that will be pasting it, so needs to supply flexible "stuff", possibly in multiple formats even???

[ColeValleyGirl]

Thinking some more about this, and in an effort to get to a point where I can actually raise the Wish List entry....

Comments, additions, etc. requested.

MANDATORY/CURRENT BEHAVIOUR: Text formatting should only be introduced by the user (including by pasting formatted text from the clipboard or using formatted Autotext). If all visible text formatting is removed, the note should revert to plain text. (This seems to be the current design, but any bugs making this behaviour unreliable must be fixed)

It's looking as if the introduction of unexpected formatting (e.g. Segoe, Cambria Math) is either a feature or a bug in the Microsoft Rich Edit control used by both FH and AS (Nick W has reproduced the problem within AS). My suspicion (and hope) is that it's a feature that can be worked around with a control configuration change, but only time will tell; worst case, it's a bug and resolving it is dependent on Microsoft.

I don't intend to include in the Wish List item 'the code for pasting unformatted text should work' because that's a truism.

MANDATORY: A keyboard shortcut (Ctrl+Shift+V) should be provided for pasting unformatted text in rich or plain text mode.

This seems to be uncontroversial!

NICE TO HAVE: An option to revert to plain text only, hiding the rich text formatting capability in the editor, both on demand and as default. [Is this satisfied by documenting the option to open a plain text editor via the Ctrl+Alt+... route? If this plain text editor is open, Ctrl+V pastes plain text.]

On reflection, I think this should be MANDATORY. It could be met by (1) better documentation on how to access the existing plain text editor and a simpler method of accessing it on demand; and (2) a preference setting to make it the default Note editor. If Plain Text is selected as preferred, the Rich Text editor should still be available on demand and it's behaviour should be unaffected by the preference. (My thinking: both editors should be easily acceptable and their behaviour should always be predictable, and independent of the preference setting. The preference setting only affects which editor opens by default).

The plain text editor does have some limitations -- it is very much a V6 feature. As well as lacking all the formatting options (as desired) it also has no easy way of inserting AutoText. In addition, it there's no way to access it when Working with AutoText, and so no simple way to create plain AutoText. Is it agreed that those limitations should be addressed?

NICE TO HAVE: A simple method of converting a rich text note to a plain text note. (The simple Select All-Cut-Paste Unformatted method exists already, which is why I've marked this NICE TO HAVE).

Again I now think this should be MANDATORY; the Ctrl+A Ctrl-X Ctrl+Shift+V method isn't appropriate for bulk conversions. The mechanism provided should allow conversion either in bulk (for all notes, or a selected set of notes) as well as for individual notes. It should strip all formatting and render the content of the plain text note as close as possible to the rich text original, indicating where characters have been omitted for lack of font support.

MANDATORY: A one-off mechanism to remove formatting errors introduced by the bug(s) in the Rich Text functionality that introduce unwanted/unexpected rich text elements. We will need a list of the known problems.

I now don't think this should be a wish List item -- it ought to be included in the CO activity to resolve the 'unexpected formatting' problem -- it isn't a feature request.

[davidf]

Helen,

I may be getting lost between threads but have we established why we need:
"Plain Text" in a "Plain Text Field" (i.e. no _TEXT, _FMT 1 etc),
rather than just being able to hold
unformatted text in a "Rich Text Field"?

If we can only tell the difference by going to the GEDCOM, why should it matter?

[ColeValleyGirl]

Helen,

I may be getting lost between threads but have we established why we need:
"Plain Text" in a "Plain Text Field" (i.e. no _TEXT, _FMT 1 etc),
rather than just being able to hold
unformatted text in a "Rich Text Field"?

If we can only tell the difference by going to the GEDCOM, why should it matter?

We already have 2 constructions in the Gedcom, one for Plain Text:

Code: Select all

0 @N5@ NOTE This should be plain text
1 CONT 
1 CONT And more plain text
1 CHAN
2 DATE 14 DEC 2022
3 TIME 10:08:13

and one for Rich Text:

Code: Select all

0 @N6@ NOTE <fs="+4"><b>1841 UK Census</fs></b>
1 CONT 
1 CONT <table="3905|1175|950|1730|5015">
1 CONT <row> Name | Sex | Age | Occupation | Where Born </row>
1 CONT <row>  |  |  |  |  </row>
1 CONT </table>
1 CONT 
1 _TEXT
2 _FMT 1

Both those are the result of entering text into the rich text editor. Having different constructions alerts a receiving programme that one of them is standard Gedcom and one isn't. (It also helps identify notes that need converting if requested on export, and most importantly tells FH how to interpret the text contents when displaying it.

Code: Select all

0 @N6@ NOTE <fs="+4"><b>1841 UK Census</fs></b>
1 CONT 
1 CONT <table="3905|1175|950|1730|5015">
1 CONT <row> Name | Sex | Age | Occupation | Where Born </row>
1 CONT <row>  |  |  |  |  </row>
1 CONT </table>
1 CONT 

is displayed very differently to the rich text equivalent.

However, the storage format is irrelevant to the wish list item, because it's an implementation detail -- as you rightly say, users don't need to know about it (but FH definitely does).

What's being asked for is for the plain text editor to be treated as 'an equal partner' to rich text, and for the ability to choose a default editor for convenience (while retaining access to the other one). Using exclusively plain text gives certainty about what will be exported/displayed, and using the plain text editor to manipulate plain text eliminates the risk of introducing inadvertent formatting (via user error or otherwise).

[tatewise]

Helen, those latest Wish List proposals look remarkably like my proposed Wish List entry posted on Mon 12th Dec 2022 22:40 in viewtopic.php?f=43&t=21280&start=50#p131602

Just needs the plain text Autotext features resolved.