Re: UTF-8 Hardcopy in Windows, what works, what should! [Updated]
- Duke Winsor wrote:
> [It has been many years since I have subscribed to a mailing list, so...and before. Windows 3.1 already had a version of Notepad, albeit not
> 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
> 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.
necessarily a Unicode-enabled one.
> Therefore, it seemed reasonable toTry to modify your "start" command so that it is not detached from its calling
> 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.
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, preferablysee ":help :silent" maybe?
> temporarily, since it seems superfluous.
> 3. Tell me what is going on inside Vim to cause it to think it needs a2>&1 is a redirection too: in Unix-like shells, it means to redirect stderr
> temporary file, when the script demonstrably works without being able to
> access such a file.
> 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.
(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.
>see above, and also the various shell-something options
> These discoveries lead to one more request:
> 4. Where does the string "2>&1" come from? How can I suppress it?
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.
>Are you sure you aren't using a Unix-like Vim (such as Vim for Cygwin) with a
> Thanks again!
Dos-like shell (such as cmd.exe)? Check
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
Fortune's Real-Life Courtroom Quote #37:
Q: Did he pick the dog up by the ears?
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.