Owen Leibman wrote:
[...]
> > What still isn't clear for me: If these files are in ASCII (or Latin1),
> > how does the EBCDIC sort ortder apply? There must be some conversion
> > happening somewhere. So, even though 'encoding' is latin1, the text is
> > actually in EBCDIC? If you use "ga" on the characters you mention, what
> > is the output?
>
> This is the difference between "character set" and "encoding".
> Both ISO8859-1 and IBM-1047 use the Latin1 character set; they just
> encode the characters differently.
> "ga" for "1" returns, as expected, the EBCDIC values: <1> 241, Hex
> f1, Octal 361
OK, so you do use the EBCDIC encoding for text. I assume 'encoding' is
still set to the default, latin1, even though you are not using latin1
encoding. Since this is a one-byte encoding this doesn't matter for
reading and writing, but it does mean character values are different
than expected.
I see that the regexp code also has special cases for EBCDIC. So that
implies that when Vim is compiled with EBCDIC it expects all text to be
EBCDIC encoded.
> > > If you feel that the EBCDIC sort should be returning the same order as
> > > ASCII, then the sort needs to be changed for EBCDIC.
> >
> > I'm fine with EBCDIC sort order when editing EBCDIC. But when editing
> > ASCII/Latin then that sort order is expected.
>
> On z/OS, IBM-1047 is the only encoding supported for vim.
> Any attempt to change it is met with "E519".
> We could probably do better than that, but it would (probably) be a
> big project. It would certainly have value, but the product as
> currently shipped on z/OS is "good enough".
> For now, an ASCII/ISO8859-1/UTF-8 file would have to be iconv'ed
> before we could use it with vim.
>
> Note that README_os390.txt gives specific instructions for performing
> this conversion on all the files that are shipped with vim before
> starting to configure and make it. So, in the case of the test files,
> that's where the conversion is happening.
It appears conversion between latin1 and EBCDIC is a 256 character
lookup table. So we could include that in Vim. Assuming text in a file
is stored as EBCDIC, we could always do this conversion when reading and
the reverse when writing. However, I assume all system calls also use
EBCDIC, so a file name would have the same problem. One can see in the
MS-Windows code how much effort it is to work with that, so we probably
don't want to do that.
> > > The existing tests are fine with minor modifications.
> > > I would prefer to modify Makefile to use test.ok in order to not have
> > > to add new tests.
> > > But adding clones of test55 or test57 would also be acceptable if
> > > there's a reason not to modify Makefile (which is my original
> > > question).
> >
> > Although that is probably the simplest way, it's postponing the work for
> > the conversion to new style tests (and increasing it).
>
> I will look into this.
> While I'm doing so, I would still appreciate an answer to the original
> question. Is testdir/Makefile correct when it uses $*.ok rather than
> test.ok in its diffs?
So far test.ok and $*.ok were always the same. Copying $*.ok to test.ok
was added later, so that tests could copy test.ok to test.out if needed.
I can't think of a reason why changing $*.ok to test.ok would be a
problem. It's just that we haven't needed that until now.
I suppose it's OK to change. But with a comment to explain what is
happening, otherwise it might be easy to miss for someone just looking
at the Makefile.
--
The term "free software" is defined by Richard M. Stallman as
being software that isn't necessarily for free. Confusing?
Let's call it "Stallman software" then!
-- Bram Moolenaar
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
