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

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

Expand Messages
  • 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
    Message 1 of 2 , May 5, 2007
    • 0 Attachment
      [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!
    • 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 2 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>
        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.
      Your message has been successfully submitted and would be delivered to recipients shortly.