Yam 2.5+: formatting text only works on single line

Screen capture of soft styles in MUI text editor config panel - Moved from SF. Original author: pwrx55eju

Screen grab of yam dev 2.6 text styles - Moved from SF. Original author: pwrx55eju

YAM (or better TextEditor.mcc) does not allow styles for multiple words
anymore. If you want several words to be printed in i.e. bold, then you
must surround each single word by "*" instead. Further more you can have
only one style at a time. That means something like bold AND italic is
impossible. This had been implemented since September 2007. However, I just
marked some text in YAM's write window, partly plain, partly bold and then
clicked on "Italic". That caused all marked words to be surrounded by "/"
afterwards. The "*" characters for bold had been replaced by "/" and the
former plain words got them added. Nothing wrong from my point of view.

The fact that changing the soft style only works on one single line is due
to that fact that YAM and TE.mcc still cannot reflow text properly. As you
know soft styles are done by inserting special characters which in turn
will modify the length of a line and hence might make a reflow necessary.
So I'd call this just a limitation, but not a bug.

Moved from SF. Original poster: damato

This is perfectly normal. Since YAM 2.5 mixed soft-styles are not
supported anymore because of their complexity.

Please consult the following FAQ items for more information:

​http://faq.yam.ch/content/3/41/en/why-isn_t-yam-able-to-mark-whole-sentences-as-bold_italic_underline-and-just-highlights-single-words-wasn_t-that-possible-already.html?highlight=bold
​http://faq.yam.ch/content/3/42/en/when-displaying-an-email-with-embedded-soft_styles-such-as-bold_italic-etc-the-mail-will-be-displayed-with-the-style-markers-_*_-as-well-why.html?highlight=bold

Moved from SF. Original poster: damato

Okay. Let's put the question another way, then: Shouldn't
Yam be able to COMPLETELY turn off text styles and text
"highlighting" both when editing a new outgoing message
as well as reading a message?

They can be turned off for reading of emails, but not
completely turned off when editing.

The problem disappears on an 8-color screen. However, on
an ECS system I find even that too slow for my liking.

The difficulty is more obvious to me, I suppose, because
I am running Yam on a 4-color workbench screen, and it's
very annoying to have complete parts of messages become
invisible. For that reason I liked it when I could
highlight entire blocks of text and change the color.

Example:

When replying to the following line contained in an
incoming message,

​http://eab.abime.net/showthread.php?t=38548

when editing a reply the URL becomes invisible because
it is the same color as the workbench background color.
That because it now appears in the editor as,

​http://eab.abime.net/showthread.php?t=38548

I would like to also have the option to turn off text
soft styles when editing.

With Yam 2.4p1 it was possible to make all text readable.
So that's really where my "bug report" is coming from.

Moved from SF. Original poster: pwrx55eju

Ok. it may be a possibility to provide a functionality to completely
disable text highlighting, even in the write window. But this
is the only solution I could really think of. Because what you are
describing seems to me to be a work-around for another problem you have:
You are just having 4 colours on the screen and you want to have text
highlighting completly disabled.

So I am sorry, but the only solution I could think of is to provide you a
checkbox where you can disable the text highlighting
even in the write window. There does not seem to be any other possibility.

Moved from SF. Original poster: damato

Ok. it may be a possibility to provide a functionality to completely disable text highlighting, even in the write window. But this is the only solution I could really think of...

That would work fine. It would also be consistent behavior - if one can disable text soft-styles in the read window one should also be able to do the same in the write/edit window. How that is accomplished is another question.

...Because what you are describing seems to me to be a work-around for another problem you have: You are just having 4 colours on the screen and you want to have text highlighting completly disabled.

It's a perfectly legitimate mode of using Workbench, so if one is going to operate Yam in this perfectly legitimate way, then the coloring is a problem and so it would be nice to disable when that difficulty exists

Yet another work-around is to edit the text in an external editor.

So I am sorry, but the only solution I could think of is to provide you a checkbox where you can disable the text highlighting even in the write window. There does not seem to be any other possibility.

Well, that would actually work better than always highlighting the text and changing color as I did with 2.4p1.

Moved from SF. Original poster: pwrx55eju

Ok. the night upcoming nightly build should finally implement the text
style settings as discussed.

Now it is possible to enable/disable the text style and text color
settings for both the read and write
window separately. Also switching on demand should work.

Moved from SF. Original poster: damato

I checked out the nightly build from 10-Oct-2008. Text colors
can be enabled/disabled. Likewise text styles. But on my
system text styles aren't displayed entirely correctly.
That is, bold will appear bold, but the style delimiters
are also displayed. Likewise for italic.

See uploaded screen grab

Mui Texteditor class is TextEditor.mcc 15.27 [020]
TextEditor.mcp 15.27 [020] (22/06/200.

This is on A3000 Desktop with A3640 and OS3.9

Moved from SF. Original poster: pwrx55eju

This behaviour is intended. See
​http://faq.yam.ch/content/3/42/en/when-displaying-an-email-with-embedded-soft_styles-such-as-bold_italic-etc-the-mail-will-be-displayed-with-the-style-markers-_%2A_-as-well-why.html
for the details.

Moved from SF. Original poster: thboeckel

On 2008-10-14 thboeckel wrote:

Date: 2008-10-14 01:09
Sender: thboeckel
This behaviour is intended. See
​http://faq.yam.ch/content/3/42/en/when-displaying-an-email...
for the details.

Okay. I didn't realize that this was now the intended behavior.
I was comparing it to 2.4p1 where it did NOT display the delimiters.
Well, at least now the colored text can be turned on and off.

Yes, now that I've read the FAQ, I've encountered that very problem
where the delimiters happen to coincide with intentional text and
so those characters get "eliminated" when you change the style of
a selected block of text.

I can't say that I like it. I prefer to have styled text off anyhow,
and with the delimiters now visible it just look messy, albeit now
you can see what style was intended without having to remember what
they were. Also, one can never be sure that the other end can see
the intended effect. One is better off to just use uppercase where
text emphasis is needed.

I suppose soft styles could be extended, use escape characters, even
ansii codes, but no doubt the problem is compatibility across
platforms. It all seems rather pointless to me. Undoubtedly that
is why so many resort to html to provide text formatting. That, too,
in my estimation is so much "abused" to have so much bloated
markup code when a simple message would suffice.

I don't like the current behavior; I understand the reason for it;
I don't have a suggestion for a better solution.

I DO LIKE that it can now be turned off. That is much appreciated.

Moved from SF. Original poster: pwrx55eju

More on text styles:

Am I missing something re. the FAQ on soft styles? Or perhaps
you are overlooking? Allow me to explain:

Do I correctly understand the Yam uses the mui text editor class?
If so, why doesn't Yam handle the soft styles in the same way
the text editor class is capable of doing?

I've uploaded the gif image "SGrab_702x332x2_MuiSettings.GIF".
This is a screen capture of experimenting with the mui settings for
Yam 2.6 dev, and you can see the first line of the paragraph text
where I've applied soft styles. The interesting thing is that I
can include delimiter characters with the styled text, and they
have no effect on the operation of soft styles, nor are they stripped
when the soft style is changed.

The reason the delimiters have no effect and are unchanged/not stripped
when the soft style is set/unset, is that the text editor class uses
escape characters to set/unset the soft styles.

To illustrate, using the "[" to represent the escape character,
the first paragraph line shown in the screen capture is:

The gadget [u[boffers[n[u [ithe[n application [b*using it*[n the
[i/chance/[n to

In other words ESC-u turns on underline and the next ESC-u turns it
off; ESC-b sets boldface, ESC-n unsets it; ESC-i sets italic and
ESC-n turn it off.

The content of the first line with the soft styles included, as
copied to the clipboard, is represented with this AREXX code,

x='54686520676164676574201B751B626F66666572731B6E1B75201B69
7468651B6E206170706C69636174696F6E201B622A7573696E6720697
42A1B6E20746865201B692F6368616E63652F1B6E20746F'x
say x

That is, if you copy the first line of the sample text and paste
it into a text editor, such as QED or Turbotext, that is what you
will see.

I don't know if the mui config panel is doing some fancy console
gymnastics to merely REPRESENT what the text editor class is doing.
If so then I'm way off base here.

But if it IS representing EXACTLY what it actually does, then why
can't yam use the escape characters? Is that incompatible across
other platforms? Perhaps you would say that the '1B'x (escape char.)
would get stripped in a 7-bit system, but couldn't yam represent
the escape character with "=1B" and so the codes would survive a
7-bit environment?

Now, before you go into a long explanation I am going to GUESS that
while this is something that the text editor class CAN DO, that those
codes are not compatible with mailbox systems? Or cannot be guaranteed
to function as intended on other platforms?

Just thought I would bring this up in case it has been overlooked.

Moved from SF. Original poster: pwrx55eju

Another observation re. soft codes:

If the line of formatted text is highlighted and copied
from the mui text editor config panel (shown in the screen
grab), then pasted into Editpad, the text is formatted with
soft styles just as it is in the text editor config window.
However Editpad has no means of setting/unsetting these
soft styles; at least, I don't know how to do it.

Also, pasting that soft-styled text into a shell window
has no effect, so evidently those are not ansii codes? Or
else the clipboard is stripping off the escape characters.
Multiview also does not show the softstyles when loaded
with shell command,

run multiview clipboard

But they are there because they appear when pasting that
copied text into a text editor such as QED or Turbotext.

Moved from SF. Original poster: pwrx55eju

Is this bug still valid? Even after rereading it I still do not know
exactly what the problem is. YAM 2.6 offers the option to disabled text
styles and colors if one really doesn't like them. The reason why the
markers are always being shown has been explained several times. So where
is the problem?

Moved from SF. Original poster: thboeckel

On 2009-10-23 thboeckel wrote:

Is this bug still valid? Even after rereading it I still do not know
exactly what the problem is. YAM 2.6 offers the option to disabled text
styles and colors if one really doesn't like them. The reason why the
markers are always being shown has been explained several times. So

where

is the problem?

I'm not sure if you're directing the question to me or someone else.
It's been so long since there's been any activity on this thread that
I've pretty much forgotten the train of thought. It's about a year since
the last comment.

As I recall, you explained that it is necessary for Yam 2.5+ to display
the delimiters along with the styled text. I don't like it, it seems
pointless
to use styled text when it introduces characters that disrupt the flow of
text,
but that apparently is how it works.

I also noted that within the mui config window, when the sample text is
displayed in the text editor class "page", the text is displayed as
styled
text WITHOUT showing any formatting characters. Also, when viewing
demo files found in the distribution, any styled text in those windows is

also displayed without showing any formatting characters.

My question is: when used within YAM, why can't the Mui TextEditor
class exhibit the same text formatting behavior (formatting codes
invisible)
as it does within the editor's mui config page and as it does in the mui
text editor class demo page.

I presume it has something with the fact that mui text editor uses escape
characters
to signify the beginning/end end of formatted text, whereas the escape
characters are
not allowed within the body of a "text" message.

Moved from SF. Original poster: pwrx55eju

You are still failing to see that mail texts are different from arbitrary texts. Within a specific scope you can use arbitrary styles, colors, anything, just display them and hide the meta information behind them from the user.

But mails are read on far more systems than just AmigaOS and not every mail client is able to display text styles at all. Think about simple text terminals. But style markers can be displayed on *any* system. YAM just adds some fancy styles and colors to these markers.

And what's even more important: YAM must *NOT* delete any characters from a mail because it may have no idea what exactly it is deleting. What if the deleted characters are more important than anything else around them? You just cannot tell. Imagine the character "e" would have a specific meaning within the mail text (just like "*" now has). With your wished approach this would reduce your name to "rnst". Think about it!

The explanation in the FAQ may sound weak to you, but we cannot implement stuff into a mail client which will make it incompatible to thousands of other clients just because you don't like a specific feature. Disable styles and colors, that's all we can offer.

Moved from SF. Original poster: thboeckel

On 2009-10-30 Thore Böckelmann (thboeckel) worte:

You are still failing to see that mail texts are different from arbitrary texts. Within a specific scope you can use arbitrary styles, colors, anything, just display them and hide the meta information behind them from the user.

On the contrary, I am quite aware that mail/arbitrary texts differ. But I don't have any information about the specifics of how that is implemented in Yam, in what ways that implementation is constrained by MUI, nor am I familiar beyond a user level how mail system protocols work.

But mails are read on far more systems than just AmigaOS and not every mail client is able to display text styles at all. Think about simple

text

terminals. But style markers can be displayed on *any* system. YAM just adds some fancy styles and colors to these markers.

I'm also quite familiar with other mail/terminal systems on various and alternative platforms in addition to AmigaOS, such as packet (ham) radio. My amateur radio call-sign is VE4CJ, so you see I'm no stranger to things technical. I have also done a fair bit or programming with various flavours of Basic, Unfortunately I'm a little too busy these days to spend much time testing or giving feedback.

And you might be interested to know that at present I am primarily running an "Amiga" with a custom rom under E-UAE on my iMac But I look forward to the time the Natami will be available (see ​http://www.natami.net/ ).

And what's even more important: YAM must *NOT* delete any characters

from

a mail because it may have no idea what exactly it is deleting. What if

the

deleted characters are more important than anything else around them?

You

just cannot tell. Imagine the character "e" would have a specific

meaning

within the mail text (just like "*" now has). With your wished approach this would reduce your name to "rnst". Think about it!

Agreed. Most certainly YAM should not delete any characters. And Yam did exhibit that undesirable behaviour in the past, which was not good. And there are problems with displaying styled text when you actually want to insert the styled text markers as non-interpreted text. For instance, if one wishes to include an ARexx script within a message while display styled text is turned on, then the ARexx comment markers become interpreted as styled text.

But there's nothing wrong with configuring or making configurable how yam internally interprets and DISPLAYS those characters, especially if that is a setting one can toggle on/off and especially if yam does not modify the underlying text when interpreting styled text markers. And there should also be a means of toggling on/off how yam should treat such text when saving it. For instance, in addition to the option of saving the message as the raw message source code, one should also have the option of saving the message text as displayed, but with the option of styled text on or off (in other words, with or without the text markers).

Now, the question is - how does one distinguish between styled text markers and instances where those same markers are intended to be inserted as literal, non-interpreted text? Moreover, if one should intentionally wish to insert literal text characters that coincide with the opening pair of styled text markers, but there are no complementary characters to close off that unintentional mark, then the rest of the text will inadvertently be interpreted as styled text!

Now here is something I am not clear on: is Yam's method of displaying styled text something that is unique to Yam? Or are the styled text markers also a method used on other platforms and email clients, other than Amiga?

If the styled text markers are a method that are used on other platforms and we are trying to retain compatibility, then no doubt there are constraints that affect what you can/can't do with how yam also uses them.

But if the method is unique to yam, then why not use an escape character sequence to better ensure that the styled text markers are correctly inserted? I presume ascii character 27 is not allowable within the text of a plain text message, so it would not be permissible as an escape character. For instance in the Amiga Shell the sequence "*E[" is interpreted as the escape character. Perhaps that sequence could be used within yam for the same purpose, to be interpreted as styled character delimiters when "show styled text" is toggled on. The downside of such an approach is that it would simply look even more messy on a system or email client where the method is not understood.

The explanation in the FAQ may sound weak to you, but we cannot

implement

stuff into a mail client which will make it incompatible to thousands of other clients just because you don't like a specific feature. Disable styles and colors, that's all we can offer.

You don't have to expend a lot of time and energy to try and convince me of it. My feedback on this matter is simply an attempt to give some constructive input. Since I have neither the time nor inclination to get involved in this project at the source code level, I'll have to trust you to have investigated what is practical or not in this matter, and have you have selected the best approach under the circumstances.

It is DEFINITELY a good idea to be able to toggle on/off show styled text, both when reading and when composing emails, and when saving displayed message text.

Moved from SF. Original poster: pwrx55eju

Replying to pwrx55eju:

Now here is something I am not clear on: is Yam's method of displaying styled text something that is unique to Yam? Or are the styled text markers also a method used on other platforms and email clients, other than Amiga?

If the styled text markers are a method that are used on other platforms and we are trying to retain compatibility, then no doubt there are constraints that affect what you can/can't do with how yam also uses them.

It is more or less a semi-standard that test like *bold* and /italic/ will be displayed in the corresponding soft style but the displaying text gadget keeps the soft style characters displayed. This is also done for example in Thunderbird or other modern email clients.

So sorry, but the current behaviour is perfectly valid and the expected behaviour and making it user-selectable would just add another point of user confusion.