Hey Jean!

I think I fixed coreutils fold ... for now. See below;

----- '<Esc>:read !fold -s -w 60 squirrels.utf8' starts
UTF-8 messaging can be fun for the whole family, especially
Fidonet.

Case in point is when you find squirrels in your pants and
lack a suitable search for a solution within the Fidonet
family. With UTF-8 enabled then one could send a single
message with, "I've got squirrels in my pants", "Jag har
ekorrar i mina byxor", "-u -+-|-+-A -# -e-e-#-+-#-a -#-|-+-|-#", "+e-c-e -a+|+>++-a-U+++| -a-a++ -C+#++-a+|++-i+++| ++++-a" and "Ich habe Eichh||rnchen in
meiner Hose", within a single message which covers five
languages thus vastly increasing your coverage when
searching for a solution to this most perplexing situation.

So, what are you waiting for? Enable UTF-8 Fidonet text
messaging today and join in on the fun.
----- '<Esc>:read !fold -s -w 60 squirrels.utf8' ends

I went with 60 columns to make sure that it looks okay on displays that don't count multibyte characters as one character. Let us call that magic.

Life is good,
Guy Robot

... There are 209 days until the next cybertoast.
--- GNU bash, version 4.4.12(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Pointy Stick Society - Ladysmith BC, Canada (1:153/7001.250)

Hey Guy!

Let us call that magic.

Sure. Note that this was the first one that has made the circuit in quite some
time now so perhaps it does have a magical quality.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Guy!

06 Jun 2017 10:18, Guy Robot wrote to Jean Eugene Robert-Houdin:

I went with 60 columns to make sure that it looks okay on displays
that don't count multibyte characters as one character. Let us call
that magic.

feel free to make msged unicode compatibel, its a opensource problem, just like
kernel.org is

sadly you are right, but just show unicode works, does not help where unicode is not supported


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.3-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hey Benny!

feel free to make msged unicode compatibel

That will take a bit of doing. Offhand I think a modified MSG format would be the place to start so that there is a text message structure that could be encorporated into msged and the ilk. I've played with a purely text based MSG format for ages now and it is the basis for what I am doing in vim as we speak.

does not help where unicode is not supported

I believe that squish and jam are the problem at the moment ... probably always
were as far as a purely text based messaging format is concerned, including (especially?) where utf-8 compatibilty is concerned.

For now I am most concerned about bringing the coreutils' i18n compatibility up
to date. Hopefully that won't take too long and in the meantime I am playing around with a FTN-ish wireless mesh idea using the node and a point system (Guy
Robot) that deploys binkd for transfers. I was going to look at hpt later on and I suspect that would be the start of a utf-8 compatible Fidonet messaging system.

What do you think?

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 2017 Jun 06 22:34:02, you wrote to Benny Pedersen:

does not help where unicode is not supported

I believe that squish and jam are the problem at the moment ...
probably always were as far as a purely text based messaging format is concerned, including (especially?) where utf-8 compatibilty is
concerned.

why would you think that? they don't care one iota about the contents of the message body... they are just storage formats... nothing more...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... "Selamat hari Christmas dan Selamat Tahun Baru." - Malay Christmas
---
* Origin: (1:3634/12.73)

Hey mark!

why would you think that?

At the moment all the tools being deployed here for Fidonet messaging are text based and squish, jam, and MSG formats interfere with these tools, which in their defense have gotten utf-8 fidonet messaging to work as well as it does. It is the *BEST* thing going at the moment given the evidence provided. Nobody
else has outdone it although a few have come close. WeBeBashing is and was simply the best.

they don't care one iota about the contents of the message body

WeBeBashing does care about the contents of the message body including utf-8 characters. Text messaging is what it is all about.

they are just storage formats... nothing more...

And they should remain there. No proper text messaging editor should need to deal with any of that. Having said that, I have been using a modified MSG format to create and read fidonet messages. Without the binary crap that makes
up the first 14 bytes of the MSG format it has worked well thus far and makes it very easy for tacking on the crap just prior to shipping off to the mothership.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

07 Jun 17 07:17, you wrote to mark lewis:

And they should remain there. No proper text messaging editor should need to deal with any of that. Having said that, I have been using a modified MSG format to create and read fidonet messages. Without the binary crap that makes up the first 14 bytes of the MSG format it has worked well thus far and makes it very easy for tacking on the crap just prior to shipping off to the mothership.

Why do you think the message editors are doing something different?

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hey Kees!

Why do you think the message editors are doing something
different?

Mainly from past experience using those editors but also from reading source code and from comfiguration files. At present I am using vim with WeBeBashing and the only format I am deploying is the modified MSG format which could easily be set up with any text editor. I personally prefer using the best which happens to be vim.

----- '<Esc>:read !vim --version | head -n3' starts
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jun 4 2017 05:00:07)
Included patches: 1-586
Compiled by root@lilmikey
----- '<Esc>:read !vim --version | head -n3' ends

As you can see it is a very recent build. Offhand I think I preferred 7.4 but maybe I just need to get used to the newest version. One thing I've noticed it
is much leaner than the previous versions, or at least 7.4.

Bottomline is that the editor cannot deal with either squish or jam formats without some filter in between. Also I've noticed that when viewing those files in vim utf-8 characters are improperly displayed. Viewing raw squish files - raw pkt's as well - works best in mcedit from my observations thus far.

How about you? What would you recommend especially considering proper handling
of utf-8?

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

07 Jun 17 15:03, you wrote to me:

How about you? What would you recommend especially considering proper handling of utf-8?

For reading you need some routine that presents folders and files,
It should dissect the header into readable for and extract the body and
tail of the message. You can choose to present the kludges and the
Seen-by's etc. Probably use "less" or "view" to make it readable.

For writing som filter to collate the header and kludges. An editor with
UTF-8 capabilities to write the body, and some filter to create the tail.

Filally there is the tricky part, that the message has to be store in your
message store. msgbase is easy, squish and Jamm maybe less so.

There are plenty of tools, that embed a text file directly into a pkt.
Putting that pkt in your inbound or a special directory. If you are
lucky the tosser kan do the storing and dispatching. You may have to use
some tricks, to get a copy for your own use.

The msg format is the quick solution. Justy find the first free number.

In principle you need two filters. One to extract a message from a message
store and create a format you want to handle. The second one to convert
your format to the message store.

In between you can do anything you like. Reading from message store is
not to intricate, you can take some shortcuts there. Writing is more
difficult, as you have to find space and adapt indexes and links.

If you build your pre and post filter in C or C++ the is the nice smapi
library of the husky project. That covers the three message stores mentioned
above.

As I have written before, I have built a message reader for squish in python,
I do not think the it will be a problem to write message susing the same
libraries I use for presentation.

My hurdle is still writing back to the message base.
I have now started routines to read from Jamm instead. I have the impression
that writing to Jamm is less intricate and there is better documentation.
But until that has been done, I am stuck. I am only in python mode during
a fortnight a year. ;)

Another place where some progress can be made is with smapinntpd/jammnntpd.
It currently has the xlat translations, but those can be replaced.
The main drawback is that you are then confronted with the limitations of
usenet messages.

You missed it in the IPv6 echo, but I did post a part of a poem in runes some
time ago. That was early March. I had a nice exchange with Konstatin Kuzov.

I am still looking for the holy grail.



Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hey Kees!

For reading you need some routine that presents folders and files

There is only one file for incoming msg's. At present I am using a bash script
to display the msg's by it's line number in that file. For example 'msg-read.sh 1' displayed the msg I am replying to.

For writing som filter to collate the header and kludges.

Another bash script. I call the one that is being employed to create this reply 'myreply.sh'. After vim is finished doing it's part the script will add the header and kludges which will later get bundled into a pkt along with other
waiting msg's if there are any.

Filally there is the tricky part, that the message has to be
store in your message store.

I just keep backups of the original pkt's. That way if there was any prblems with them I can pass the word along if needed. I don't have a BBS anymore - not since the mid to late 1990's - so I don't really need any additional storage. Raw pkt's are fine. No?

smapi library of the husky project

Yep. I am well aware of it along with the other libs required to compile hpt.
I see you're using hpt according to your TID.

I am still looking for the holy grail.

[bad heavy French accent mode on]
We've already got one. It is very nice.
[bad heavy French accent mode off]

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

06 Jun 2017 22:34, Maurice Kinal wrote to Benny Pedersen:

feel free to make msged unicode compatibel

That will take a bit of doing. Offhand I think a modified MSG format would be the place to start so that there is a text message structure that could be encorporated into msged and the ilk.

change to html, with all readers support ?

I've played with a
purely text based MSG format for ages now and it is the basis for what
I am doing in vim as we speak.

if we change lets change in a good way, not make we need another encoding format, there is already to many to choice from :(

does not help where unicode is not supported

I believe that squish and jam are the problem at the moment ...
probably always were as far as a purely text based messaging format is concerned, including (especially?) where utf-8 compatibilty is
concerned.

if squish is the problem, is smapi lib not a problem ?

if we take email:

quotedprinteble with unicode, at the same time so unicode only see 7bit, wtf ?

its time to let programmers wake up :=)

For now I am most concerned about bringing the coreutils' i18n compatibility up to date.

you dont need that, tidy is you friend :)

Hopefully that won't take too long and in
the meantime I am playing around with a FTN-ish wireless mesh idea
using the node and a point system (Guy Robot) that deploys binkd for transfers.

most fun come when it have colors, or led lights :=)

I was going to look at hpt later on and I suspect that
would be the start of a utf-8 compatible Fidonet messaging system.

yes change smapi lib to support unicode will be the first start, later get rid of programs not using smapi lib api

What do you think?

thanks i do think :=)

are you sure latin1 is more correct then latin-1 ?, imho amiga have always being latin-1

maybe i just need to start amiga up again


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.4-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hey Benny!

change to html, with all readers support

Speaking for myself, I decided against html back in the late 1980's when I ran across it on a dumb terminal on VAX/VMS. It looked like hell. Way worse than some fidonet abandonware rendering unwrapped text. However I think it might be
a better choice for most given what they have in the way of useable apps on modern OS's.

if we change lets change in a good way, not make we need another
encoding format

I've always used ascii but now that I've been playing with utf-8 I would (and have) promote it's usage rather than all of the official, supported 8 bit encodings. Failing that I am sticking with 7 bit ascii.

you dont need that, tidy is you friend

Heh, heh. I still don't have it onboard although I have looked at it in the past. I think it might be abandonware but don't quote me on that.

are you sure latin1 is more correct then latin-1

Yes. According to https://en.wikipedia.org/wiki/ISO/IEC_8859-1 the official aliases are: iso-ir-100, csISOLatin1, latin1, l1, IBM819, and CP819. Also try "grep ISO-8859-1// /usr/lib/gconv/gconv-modules" as that will list the ones supported by iconv.

amiga have always being latin-1

Then amiga has always been wrong.

maybe i just need to start amiga up again

Knock yourself out. Personally I avoid moving backwards especially when backwards was wrong when it was considered forwards. There is usually a good reason for abandonware being abandoned. Not always but usually.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.4.12(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)