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
      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 ... ?
    • Bram Moolenaar
      ... Sounds like a very useful item. ... What we would need for the fileencodings option is a check if the proposed encoding fits with the bytes in the file.
      Message 2 of 6 , Jun 1, 2002
        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.

        --
        hundred-and-one symptoms of being an internet addict:
        80. At parties, you introduce your spouse as your "service provider."

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
      • 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 3 of 6 , Jun 2, 2002
          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.