Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • A.J.Mechelynck
    ... ...and before. Windows 3.1 already had a version of Notepad, albeit not necessarily a Unicode-enabled one. ... Try to modify your start command so that
    Message 1 of 2 , May 5, 2007
    • 0 Attachment
      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>
      :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

      Best regards,
      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.
    Your message has been successfully submitted and would be delivered to recipients shortly.