Legend: (A) Added, (C) Copied, (D) Deleted, (M) Modified, (R) Renamed,
(T) Type changed, (U) Unmerged, (X) Unknown, (B) Pairing
Broken
===========================
Fixed aliases processing.
Author: Vitaliy Aksyonov <18148062+vitaliy-aksyonov@users.noreply.github.com>
Date: 2023-10-30 14:03:12 -0600
Committed by: Vitaliy Aksyonov <18148062+vitaliy-aksyonov@users.noreply.github.com>
Files:
M golded3/geline.cpp
M golded3/gepost.cpp
===========================
fix Codacy issues
Author: Vitaliy Aksyonov <18148062+vitaliy-aksyonov@users.noreply.github.com>
Date: 2023-10-30 14:03:12 -0600
Committed by: Vitaliy Aksyonov <18148062+vitaliy-aksyonov@users.noreply.github.com>
Files:
M golded3/geline.cpp
===========================
detect zero conversion
LoadCharset now detects when import and export charsets are the same. Restore previous charset will work faster.
Author: Vitaliy Aksyonov <18148062+vitaliy-aksyonov@users.noreply.github.com>
Date: 2023-10-30 14:03:12 -0600
Committed by: Vitaliy Aksyonov <18148062+vitaliy-aksyonov@users.noreply.github.com>
Files:
M docs/notework.rus
M docs/notework.txt
M golded.spec
M golded3/gecmfd.cpp
M golded3/geedit.cpp
M golded3/geline.cpp
M golded3/gelmsg.cpp
M golded3/gemlst.cpp
M golded3/gemnus.cpp
M golded3/gepost.cpp
M golded3/geprot.h
M golded3/gesoup.cpp
M goldlib/gall/gespell.cpp
M srcdate.h
--- hpt/lnx 1.9.0
* Origin: Moscow, Russia (2:5020/1042.3)
detect zero conversion
LoadCharset now detects when import and export charsets are the same.
Restore previous charset will work faster.
@PID: GED+LNX 1.1.5-b20231028
@CHRS: UTF-8 4
--- GoldED+/LNX 1.1.5-b20231030
Wondering if any one of these commits changed something in regards to[..]
a workaround a small (probably very small) handful of people have been using since about as far back as I can remember.
basically irrelevant. This makeshift conversion table doesn't seem to[..]
be working any more for that purpose.
When posting outgoing messages with 'xlatexport utf-8' is there an
easy way to hard code using the proper 'CHRS: UTF-8 4' kludge instead
of it using the level 2 parameter?
Wondering if any one of these commits changed something in regards to
a workaround a small (probably very small) handful of people have been using since about as far back as I can remember.
I'm currently using all available conversions (xlatcharset) to utf-8, with:
xlatimport utf-8
This has been swapped back and forth between cp437 and utf-8. It seems most messages without a CHRS kludge are in the CP437 realm, but having
a utf-8 terminal still doesn't display a lot of cp437 characters
properly even with the conversion tables, and I understand why (256 character limit).
xlatexport utf-8
xlatlocalset utf-8
Then I'm using a conversion table simply named utf_utf.chs with the following:
[begin utf_utf.chs]
; This file is a charset conversion module in text form.
;
100000 ; ID number (when >65535, all 255 chars will be translated) 0 ; version number ; 4 ; level number ; UTF-8 UTF-8 ; END
[end utf_utf.chs]
This was only to trick Golded into using the 'CHRS: UTF-8 4' kludge, otherwise it would always post with 'CHRS: UTF-8 2', which is
basically irrelevant. This makeshift conversion table doesn't seem to
be working any more for that purpose.
Using tmux with Golded, and an external editor (nano or vim) this has allowed me to read and write utf-8 messages properly for quite some
time (and really, nothing has changed recently except the CHRS kludge.
;))
I guess, instead of asking for this workaround to work again (if any
of the above has actually done something to break/fix this; however
you want to look at it), maybe I should be asking the question to
actually change/fix the issue instead.
When posting outgoing messages with 'xlatexport utf-8' is there an
easy way to hard code using the proper 'CHRS: UTF-8 4' kludge instead
of it using the level 2 parameter?
Hi. Yes. "Zero conversion" change broke it. Anyway it's used
incorrectly now. Because in the code GoldED uses level from conversion table, but it has nothing to do with charset level itself.
I'm still working on encoding conversions code and will do more
changes. I will try to restore that behavior for backward
compatibility.
Just in case - you understand, that GoldEd can't properly work with
UTF-8 local charset if any international character used?
Hi. Yes. "Zero conversion" change broke it. Anyway it's used
incorrectly now. Because in the code GoldED uses level from
conversion table, but it has nothing to do with charset level
itself.
I'm still working on encoding conversions code and will do more
changes. I will try to restore that behavior for backward
compatibility.
Thank you!
Just in case - you understand, that GoldEd can't properly work
with UTF-8 local charset if any international character used?
Do you have any examples?
As I mentioned, I'm using Golded with tmux, and besides CP437 ANSI or 'high ascii' characters (which is a little better when I use
'xlatimport CP437', I'm seeing characters like cyrillic, umlauts, dieresis, etc just fine. Granted, once you get into Chinese or
Japanese, there may be issues. But I haven't seen much if any of that
in Fidonet, so I'm not too worried about it. When posting using an external editor, I am only limited to what the font I use actually supports. Otherwise I can write the previously mentioned things just
fine as well.
Привет, Nicholas!
05 Nov 23 19:03, Ñ‚Ñ‹ пиÑал(а) мне:
My plan is to enhance conversion code which uses iconv in linux
builds. And then you won't need any translation tables for charsets
known by iconv. It will take some time, because changes are not so
small.
Just in case - you understand, that GoldEd can't properly work
with UTF-8 local charset if any international character used?
Do you have any examples?
GoldEd charset translation code can translate one byte encodings to multibyte, but not the opposite.
So if you write your message in CP437 and export it to UTF-8 - it will work fine if such translation table exists. Now imagine that your
local charset is CP437 and message is in UTF-8. That won't work
because translation tables size is only 256 bytes and UTF-8 code may
have up to 6 bytes per code point.
External editor solves some issues, but not all. Would be cool to have UTF-8 used for internal string representation, but that's huge work.
What is your XLatLocalSet, XLatImport, XLatExport?
???A???????B, Nicholas!I may not be able to read some of the above, but it sure looks nice!
05 Nov 23 19:03, ?B?? ??????????(??) ??????:
;)
My plan is to enhance conversion code which uses iconv in linuxWould you suggest going back to the b20231028 code then until you're
builds. And then you won't need any translation tables for
charsets known by iconv. It will take some time, because changes
are not so small.
done messing around with it?
Just in case - you understand, that GoldEd can't properly work
with UTF-8 local charset if any international character used?
Do you have any examples?
GoldEd charset translation code can translate one byte encodings
to multibyte, but not the opposite.
So if you write your message in CP437 and export it to UTF-8 - itAh yes. Understood. My local charset is UTF-8. Sometimes I try to do translations of incoming messages, but that's about it.
will work fine if such translation table exists. Now imagine that
your local charset is CP437 and message is in UTF-8. That won't
work because translation tables size is only 256 bytes and UTF-8
code may have up to 6 bytes per code point.
External editor solves some issues, but not all. Would be cool toIt solves most, at least for Fidonet messaging. Most messages are US-ASCII, CP437/850, CP866, or UTF-8, which I can handle here just
have UTF-8 used for internal string representation, but that's
huge work.
fine.
What is your XLatLocalSet, XLatImport, XLatExport?
All are currently set to UTF-8. However, sometimes I like to test XLatImport CP437. It helps on some messages, but since my locale is completely UTF-8 it isn't perfect, usually when related to ANSI escape sequences.
Hello Nicholas.
06 Nov 23 16:25, you wrote to me:
???A???????B, Nicholas!
05 Nov 23 19:03, ?B?? ??????????(??) ??????:
I may not be able to read some of the above, but it sure looks
nice! ;)
Sorry. Forgot to switch my template. :)
Would you suggest going back to the b20231028 code then until
you're done messing around with it?
Yes. Actually, I have an easy fix which will work with your setup
without issues. Will try to deliver it today.
Ah yes. Understood. My local charset is UTF-8. Sometimes I try to
do translations of incoming messages, but that's about it.
I use KOI8-R in my case to be able to read russian messages.
I see. And you use that fake conversion table from/to UTF-8, right? If
you do - my next small fix will help you for sure.
???A???????B, Nicholas!
05 Nov 23 19:03, ?B?? ??????????(??) ??????:
I may not be able to read some of the above, but it sure looks
nice! ;)
Sorry. Forgot to switch my template. :)
Well, it displayed fine when you originally wrote it. Now you quoted
your original text with US-ASCII CHRS kludge and broke it! ;)
Would you suggest going back to the b20231028 code then until
you're done messing around with it?
Yes. Actually, I have an easy fix which will work with your setupOk. I've temporarily checked out the commit prior to the "Zero
without issues. Will try to deliver it today.
Conversion" commit, but I can easily go back to normal. Gives me a
chance to learn a little more about git than just to clone and pull
(I'm not a programmer). ;)
Ah yes. Understood. My local charset is UTF-8. Sometimes I try
to do translations of incoming messages, but that's about it.
I use KOI8-R in my case to be able to read russian messages.It seems CP866 and KOI8-R translate to UTF-8 nicely, at least what
I've seen here on Fidonet.
I see. And you use that fake conversion table from/to UTF-8,Yes. The fake conversion table is only to correct my CHRS kludge. Otherwise, it doesn't nothing else.
right? If you do - my next small fix will help you for sure.
???A???????B, Nicholas!
05 Nov 23 19:03, ?B?? ??????????(??) ??????:
I may not be able to read some of the above, but it sure looks
nice! ;)
Sorry. Forgot to switch my template. :)
Well, it displayed fine when you originally wrote it. Now youNevermind. I messed it up when I quoted your CP866 message with UTF-8,
quoted your original text with US-ASCII CHRS kludge and broke it!
;)
as you were explaining to me before when I asked for examples. ;)
I think fixing the iconv support would be far superior to these translation tables. As of the last time I tried compiling with that
option (years ago) it was labeled experimental for a reason. I had to
go back to not using it quickly!
External editor solves some issues, but not all. Would be cool to have UTF-8 used for internal string representation, but that's huge work.
Ok. I've temporarily checked out the commit prior to the "Zero
Conversion" commit, but I can easily go back to normal. Gives me a
chance to learn a little more about git than just to clone and pull
(I'm not a programmer). ;)
External editor solves some issues, but not all. Would be cool toSo how about the vice versa way? Take a fully utf compatible editor
have UTF-8 used for internal string representation, but that's
huge work.
and inject goldeds fidonet features into it?
Ok. I've temporarily checked out the commit prior to the "ZeroHow did you do that? I'm not a programmer either, I know only git
Conversion" commit, but I can easily go back to normal. Gives me
a chance to learn a little more about git than just to clone and
pull (I'm not a programmer). ;)
clone, stash and pull. :)
BTW, The level 4 is back!
Git is somewhat complex, but once you got the idea - you may do a lot
of cool things which other code versioning systems cant. Like reorder commits, move one branch on top of another, etc.
If you need some help with that - I'll be glad to do it. It's just not right echo area for those questions. You may shoot me netmail too.
You may convert any charset to UTF-8 actually. And it would be really
cool to have UTF-8 support in GoldEd. I'm still learning the code.
Will try to improve things in that area.
I see. And you use that fake conversion table from/to UTF-8,
right? If you do - my next small fix will help you for sure.
Ivonv support do work in some cases, but it doesn't cover all the
cases and you still need translation tables, which is odd. My plan is
to use iconv without translation tables.
To set correct charset level in kludge I may need to introduce new configuration parameter, because iconv know nothing about FidoNet
charset levels obviously.
Ok. I've temporarily checked out the commit prior to the "Zero
Conversion" commit, but I can easily go back to normal. Gives me
a chance to learn a little more about git than just to clone and
pull (I'm not a programmer). ;)
How did you do that? I'm not a programmer either, I know only git
clone, stash and pull. :)
BTW, The level 4 is back!
2) Is this where iconv support would be beneficial, when an incoming message has a CP866 kludge, iconv would translate it to UTF-8 on my end
so that it is readable and writable, and then translate it back to CP866 when the reply is sent? Or would it still stay UTF-8 because I'm forcing it on export?
it's nice that the fido message has a hint, but if it's wrong, or you
know a whole ftn is in russian for example, it would be useful to set
that whole net or a specific person that is misconfigured to default
to what you want instead.
Git is somewhat complex, but once you got the idea - you may do aI probably won't ever be reordering or anything super technical, but I googled the easiest way, and 'checkout' seemed to do the trick. Then I just went back to the master branch using the same option.
lot of cool things which other code versioning systems cant. Like
reorder commits, move one branch on top of another, etc.
If you need some help with that - I'll be glad to do it. It'sI may have to take you up on that offer some day. Thank you! ;)
just not right echo area for those questions. You may shoot me
netmail too.
You may convert any charset to UTF-8 actually. And it would be
really cool to have UTF-8 support in GoldEd. I'm still learning
the code. Will try to improve things in that area.
So here's a question or two for you. As of right now I'm using:
xlatimport cp437 (because most incoming messages missing a CHRS kludge falls under this)
xlatexport utf-8 (because that's what I can write with)
xlatlocalset utf-8 (because this is my local setup, 'locale' gives en_US.UTF-8 for everything)
Basically I'm forcing the use of utf-8 when exporting messages, but we have already witnessed that that doesn't work when you write to me
using CP866 and I reply back to you.
1) Is there a way for me to reply to you with the same charset (or
closest translation) that you're using automatically? Or would I have
to change my config file every time I reply to a different CHRS
kludge?
2) Is this where iconv support would be beneficial, when an incoming message has a CP866 kludge, iconv would translate it to UTF-8 on my
end so that it is readable and writable, and then translate it back to CP866 when the reply is sent? Or would it still stay UTF-8 because I'm forcing it on export?
I see. And you use that fake conversion table from/to UTF-8,
right? If you do - my next small fix will help you for sure.
We can consider this message my first test using the latest commit. ;)
Hope it works!
it's nice that the fido message has a hint, but if it's wrong, or
you know a whole ftn is in russian for example, it would be
useful to set that whole net or a specific person that is
misconfigured to default to what you want instead.
Agreed. I believe that was part of Michiel's recent request to make it configurable and usable (multiple times even) via the 'group' keyword.
Ivonv support do work in some cases, but it doesn't cover all theI think when I tried it last (years ago) it broke more things than it fixed.
cases and you still need translation tables, which is odd. My
plan is to use iconv without translation tables.
I will definitely follow your work and help with testing where I can!
To set correct charset level in kludge I may need to introduce
new configuration parameter, because iconv know nothing about
FidoNet charset levels obviously.
Is the level parameter even needed? I don't think anything actually
uses it for whatever intended purpose it once had. If it wasn't there
to begin with, I would have never saw the change, and you could have continued with your work without distraction. ;)
Would iconv improve this situation - yes! You'll be able to convert
from multibyte charsets. Sure, some symbols may be lost if they don't exist in target charset. For example if I convert from UTF-8 to
KOI8-R, I'd lose German umlauts. :)
Would iconv improve this situation - yes! You'll be able toDefinitely answered any questions I may have had, and also confirmed
convert from multibyte charsets. Sure, some symbols may be lost
if they don't exist in target charset. For example if I convert
from UTF-8 to KOI8-R, I'd lose German umlauts. :)
how I viewed those three xlat settings. You also made me a firm
believer that iconv could quite possibly completely replace these character translation tables once and for all! ;)
I'm not sure how much time that change take. Don't have too much free
time now. I'll post update here.
| Sysop: | Luis Silva |
|---|---|
| Location: | Lisbon |
| Users: | 763 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 167:59:46 |
| Calls: | 111 |
| Files: | 46,971 |
| Messages: | 11,177 |