UTF-8 Hardcopy in Windows, what works, what should!

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

UTF-8 Hardcopy in Windows, what works, what should!

Duke Winsor
[It has been many years since I have subscribed to a mailing list, so
I'm not sure what I should expect.  I submitted this, except for the
update at the bottom, about 8 hours ago.  It has not yet appeared on
http://tech.groups.yahoo.com/group/vim-multibyte/ so I am resubmitting.]

Greetings, Bram!  I have solved my problem for myself, but the more
general solution has an undesirable side effect.  Let's see if someone
can help!

INTRODUCTION.  Vim 7.0.152 running through Cream 0.38 has a plugin to
enter Esperanto characters (just 12 of them), but they are not in the
extended latin set, so they are composed as UTF-8, and I would like to
print them (:hardcopy), though I can copy and paste the text, so this is
not a big issue.  Anyway, this seemed like a useful exercise for
learning about Vim plugins.

OBJECTIVE.  Vim 7 in Windows lets the user do this (set encoding=utf-8 /
set guifont=courier_new:h12 / set keymap=esperanto).  The last command
sets up a really elegant keyboard handler.  (If you're used to Linux and
Xmodmap, you have no idea how hard Microsoft has made it to map keys!)
Unfortunately, when the ":hardcopy" command is invoked, the printer
interprets the text as individual bytes, and the UTF-8 information is
lost.  I queried both Bram and the author of the Esperanto plugin.
Neither was aware of a solution.  I have searched the Vim archives to no
avail.

SOLUTION USING PYTHON.  There is a plugin for running Python scripts by
Frederick Young which shows how to call Python and pass the name of the
buffer.  The Windows Python distribution includes a GUI called "Idle"
that prints its output window.  A quick test demonstrated that it can
print UTF-8 characters correctly.  I adapted the Vim plugin to call a
small fragment of Idle, and it indeed does the job.  I can now print
UTF-8 text on my computer, which has both Vim and Python.

GENERALIZATION.  It turns out that the key piece of code is a "system"
call on "notepad," a small utility program that has come with Windows
all the way back to Windows 95.  Therefore, it seemed reasonable to
bypass Python completely and make the system call to 'notepad' directly
from Vim.  This script works:

command HN call system ('start /min notepad /p "' . bufname('%') . '"')

Indeed, this one-line command correctly prints out the contents of the
buffer when the ":HN" command is invoked.  The relatively complex quote
structure ensures that the command executes correctly even if the buffer
name contains embedded blanks.  However, I also get a bright red line in
the command window reading:

E484: Can't open file C:/DOCUME~1/lim/LOCALS~1/Temp/VIo130.tmp

HELP REQUESTED.  The command works as desired.  This is a successful
method for obtaining a UTF-8 hardcopy in Windows, and it does not
require Python.  However, I have absolutely no clue what causes the
error message.  I have tried wrapping the command in a function. I have
tried breaking the "system" call arguments up and using variables.  No
matter how I recode it, I get the same message.  When the call is inside
a function, the error message is preceded by "Error detected while
processing function ..." and followed by multiple lines of "Press ENTER
or type command to continue"  I request:

1. Give me some idea how to modify the script to prevent the error.
(preferred)
2. Tell me how to suppress the printing of the message, preferably
temporarily, since it seems superfluous.
3. Tell me what is going on inside Vim to cause it to think it needs a
temporary file, when the script demonstrably works without being able to
access such a file.

Thanks!

docduke

UPDATE: I have tried a number of variations on the text string argument
to "system."  Two of them turned out to be malformed.  The result was
that two DOS windows were left on my desktop.  Here is one of the
resulting strings, processed by Vim and passed to the command
interpreter, separated into 3 parts by pipes (|) I have inserted here:

C:\WINNT\system32\cmd.exe /c | command start /min
c:/winnt/system32/notepad /p "EoKeys" |
 >C:/DOCUME~1/lim/LOCALS~1/Temp/VIo174.tmp 2>&1
shell returned 1

The text between the pipes is what I supplied to the Vim system call.
The text before and after that is apparently what Vim and/or Windows
added before executing the call.  The final line is apparently the
system reporting the return code.  Note that the part of the command
string after the second pipe consists of three syntactic entities: ">",
a fully qualified file path, and "2>&1".  The first is a redirection,
standard in DOS.  The second is a name like the ones that have been
causing the error messages, and the third probably does not belong
there.  I suspect it is from your linux Vim incarnation, inserted in the
"system" call string by a piece of code that is misbehaving.

These discoveries lead to one more request:

4. Where does the string "2>&1" come from?  How can I suppress it?

Thanks again!
Reply | Threaded
Open this post in threaded view
|

Re: UTF-8 Hardcopy in Windows, what works, what should!

A.J.Mechelynck
Duke Winsor wrote:

> [It has been many years since I have subscribed to a mailing list, so
> I'm not sure what I should expect.  I submitted this, except for the
> update at the bottom, about 8 hours ago.  It has not yet appeared on
> http://tech.groups.yahoo.com/group/vim-multibyte/ so I am resubmitting.]
>
> Greetings, Bram!  I have solved my problem for myself, but the more
> general solution has an undesirable side effect.  Let's see if someone
> can help!
>
> INTRODUCTION.  Vim 7.0.152 running through Cream 0.38 has a plugin to
> enter Esperanto characters (just 12 of them), but they are not in the
> extended latin set, so they are composed as UTF-8, and I would like to
> print them (:hardcopy), though I can copy and paste the text, so this is
> not a big issue.  Anyway, this seemed like a useful exercise for
> learning about Vim plugins.
>
> OBJECTIVE.  Vim 7 in Windows lets the user do this (set encoding=utf-8 /
> set guifont=courier_new:h12 / set keymap=esperanto).  The last command
> sets up a really elegant keyboard handler.  (If you're used to Linux and
> Xmodmap, you have no idea how hard Microsoft has made it to map keys!)
> Unfortunately, when the ":hardcopy" command is invoked, the printer
> interprets the text as individual bytes, and the UTF-8 information is
> lost.  I queried both Bram and the author of the Esperanto plugin.
> Neither was aware of a solution.  I have searched the Vim archives to no
> avail.
>
> SOLUTION USING PYTHON.  There is a plugin for running Python scripts by
> Frederick Young which shows how to call Python and pass the name of the
> buffer.  The Windows Python distribution includes a GUI called "Idle"
> that prints its output window.  A quick test demonstrated that it can
> print UTF-8 characters correctly.  I adapted the Vim plugin to call a
> small fragment of Idle, and it indeed does the job.  I can now print
> UTF-8 text on my computer, which has both Vim and Python.
>
> GENERALIZATION.  It turns out that the key piece of code is a "system"
> call on "notepad," a small utility program that has come with Windows
> all the way back to Windows 95.

...and before. Windows 3.1 already had a version of Notepad, albeit not
necessarily a Unicode-enabled one.

> Therefore, it seemed reasonable to
> bypass Python completely and make the system call to 'notepad' directly
> from Vim.  This script works:
>
> command HN call system ('start /min notepad /p "' . bufname('%') . '"')
>
> Indeed, this one-line command correctly prints out the contents of the
> buffer when the ":HN" command is invoked.  The relatively complex quote
> structure ensures that the command executes correctly even if the buffer
> name contains embedded blanks.  However, I also get a bright red line in
> the command window reading:
>
> E484: Can't open file C:/DOCUME~1/lim/LOCALS~1/Temp/VIo130.tmp
>
> HELP REQUESTED.  The command works as desired.  This is a successful
> method for obtaining a UTF-8 hardcopy in Windows, and it does not
> require Python.  However, I have absolutely no clue what causes the
> error message.  I have tried wrapping the command in a function. I have
> tried breaking the "system" call arguments up and using variables.  No
> matter how I recode it, I get the same message.  When the call is inside
> a function, the error message is preceded by "Error detected while
> processing function ..." and followed by multiple lines of "Press ENTER
> or type command to continue"  I request:
>
> 1. Give me some idea how to modify the script to prevent the error.
> (preferred)

Try to modify your "start" command so that it is not detached from its calling
process. Not sure how to do it but maybe "start /?" could tell you. Come back
if it doesn't work.

> 2. Tell me how to suppress the printing of the message, preferably
> temporarily, since it seems superfluous.

see ":help :silent" maybe?

> 3. Tell me what is going on inside Vim to cause it to think it needs a
> temporary file, when the script demonstrably works without being able to
> access such a file.
>
> Thanks!
>
> docduke
>
> UPDATE: I have tried a number of variations on the text string argument
> to "system."  Two of them turned out to be malformed.  The result was
> that two DOS windows were left on my desktop.  Here is one of the
> resulting strings, processed by Vim and passed to the command
> interpreter, separated into 3 parts by pipes (|) I have inserted here:
>
> C:\WINNT\system32\cmd.exe /c | command start /min
> c:/winnt/system32/notepad /p "EoKeys" |
>  >C:/DOCUME~1/lim/LOCALS~1/Temp/VIo174.tmp 2>&1
> shell returned 1
>
> The text between the pipes is what I supplied to the Vim system call.
> The text before and after that is apparently what Vim and/or Windows
> added before executing the call.  The final line is apparently the
> system reporting the return code.  Note that the part of the command
> string after the second pipe consists of three syntactic entities: ">",
> a fully qualified file path, and "2>&1".  The first is a redirection,
> standard in DOS.  The second is a name like the ones that have been
> causing the error messages, and the third probably does not belong
> there.  I suspect it is from your linux Vim incarnation, inserted in the
> "system" call string by a piece of code that is misbehaving.

2>&1 is a redirection too: in Unix-like shells, it means to redirect stderr
(handle 2) to wherever stdout (handle 1) is going. (You see there the parency
between Dos 2.0 and higher, and Unix: in both, file descriptors 0-2 are stdin,
stdout and stderr in that order. Or maybe it traces back via Dos 1.0 and CP/M,
I'm not sure.)

If stdout is later redirected, stderr does not follow it, so to redirect both
you would use "program > filename.log 2>&1". This is exactly what happens in
your case, albeit with a more complicated output filename.

>
> These discoveries lead to one more request:
>
> 4. Where does the string "2>&1" come from?  How can I suppress it?

see above, and also the various shell-something options

        :set wildmenu
        :help 'shell<Tab>
or
        :help 'shell<Ctrl-D>

where each <> notation means one keystroke.

Checking those lets me believe that you have 'shellredir' set to ">%s 2>&1"; I
don't know whether cmd.exe recognises it.

>
> Thanks again!
>

Are you sure you aren't using a Unix-like Vim (such as Vim for Cygwin) with a
Dos-like shell (such as cmd.exe)? Check

        :echo has("unix")

If you are (i.e., if the answer is nonzero), I would recommend that you avail
yourself of a native-Windows version of vim and/or gvim, such as those
available at
https://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721


Best regards,
Tony.
--
Fortune's Real-Life Courtroom Quote #37:

Q:  Did he pick the dog up by the ears?
A:  No.
Q:  What was he doing with the dog's ears?
A:  Picking them up in the air.
Q:  Where was the dog at this time?
A:  Attached to the ears.