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

Re: internalizing some external preliminary jobs

Expand Messages
  • Colin Keith
    ... Not as such. The autocmd event BufReadPre is called before the file is actually read, so you could cheat and use that to set the file encoding so that when
    Message 1 of 6 , May 31, 2002
    • 0 Attachment
      On Sat, Jun 01, 2002 at 10:18:20AM +0900, Hiroshi Iwatani wrote:
      > Do you mean that Vim can do a trial read of a file before
      > opening it as the editing target?

      Not as such. The autocmd event BufReadPre is called before the file is
      actually read, so you could cheat and use that to set the file encoding
      so that when vim loads the file, it knows how to handle the contents.


      au BufReadPre * :call IsISJS()

      The problem I can see is that because you need to read the file to determine
      the language encoding, you'll have to open it. That of course will trigger
      the above. In order to prevent loops, you'd need some flags set:

      function IsISJS()
      if exists('g:isisjs')
      return
      :endif

      let g:isijs=1
      ... do the actual check ..
      let g:isijs=0
      :endfunction


      Of course if you have that external program there's no reason you can't use
      that rather than having vim open then reopen it. Call it from a BufReadPre
      autocmd event ... ?
    • Hiroshi Iwatani
      Though I have yet to fully decipher Vim source code, it vaguely seems that the current implementation of the fileencodings option does not do its own effort in
      Message 2 of 6 , Jun 2, 2002
      • 0 Attachment
        Though I have yet to fully decipher Vim source code, it vaguely
        seems that the current implementation of the fileencodings option
        does not do its own effort in discerning the encoding of the
        file in hand, simply relying on the return values from the iconv
        instead. If it is as such, the true culprit of the option's
        maladroitness might be the GNU library.

        If Vim is to circumvent the situation, however, I believe a
        new specialized generic/general-purpose module should be
        established for finding out the encoding used in the file
        when he tries to open it as an editing target. To add a code
        specific to a particular language and encodings, which happen
        to be Japanese and its two major encodings in this case, into
        existing Vim souce file isn't felt as a better choice for the
        editor's long term health.

        Hiroshi Iwatani

        Bram Moolenaar wrote:
        > Hiroshi Iwatani wrote:
        >
        >
        >>The fileencodings option is a little bit shaky at least for
        >>the different Japanese encodings. Although Muraoka san has
        >>given a couple of nifty plugins to us, we'd like to have a
        >>more clear cut way for discernig types of Japanese charset
        >>used in a file.
        >>
        >
        > Sounds like a very useful item.
        >
        >
        >>Will you please give a glimpse on the attached bash shell
        >>script and C program. How could we implement an autocommand,
        >>a plugin, or whatever in order to embedd a similar functionality
        >>onto the Vim proper?
        >>
        >
        > What we would need for the 'fileencodings' option is a check if the
        > proposed encoding fits with the bytes in the file. Thus if the next
        > item in 'fileencodings' is "euc-jp", there would need to be a check if
        > all bytes fall within this encoding. Same for shift-jis. Can you turn
        > your issjis.c code into something that works like this? Adding this to
        > fileio.c would then cause the next item in 'fileencodings' to be tried
        > (rewinding the file) when the test fails.
        >
        > I would guess euc-jp can be tested by checking that after a byte in the
        > range 0xA1-0xFE another byte in this range follows. It's not clear to
        > me how to test for shift-jis.
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.