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

[vim-multibyte] Re: Screen is scrolled up by FEP.

Expand Messages
  • Yasuhiro Matsumoto
    ... I explain why I made this. When I edit command, ... ... If starting FEP, then ... ... it scroll text up. Still more, if typing some, then ... ... it make
    Message 1 of 7 , Feb 15, 2000
    • 0 Attachment
      Bram Moolenaar wrote:
      > It looks like this patch reserves one line for FEP. That's not very nice,
      > there is less room for the buffer text. And doesn't this cause problems when
      > scrolling text up?

      I explain why I made this.
      When I edit command, ...

      |~ |
      |~ |
      |~ |
      |~ |
      |:r C:\Winnt\..............|
      |...Sample\_ |
      ----------------------------

      If starting FEP, then ...

      |~ |
      |~ |
      |~ |
      |~ |
      |:r C:\Winnt\..............|
      |...Sample\_ |
      | [FEP]|
      ----------------------------

      it scroll text up.
      Still more, if typing some, then ...

      |~ |
      |~ |
      |~ |
      |:r C:\Winnt\..............|
      |...Sample\ |
      | Samp.txt_ [FEP]|
      ----------------------------

      it make text shift.

      This cause is that cursor can move to bottom line.
      If I use on full screen, then I must use on 80x25.
      So It is better that there is less room for the buffer text.
      --------------------------------------------------------

      But it is not necessarily that all FEP use bottom line.
      Certainly this is not perfect solution. X-(

      Then, How about the renaming that declare 'USE_CONSOLE_IME'.
      For example, changing one's name to 'USE_BOTTOM_LINE_FEP'
      I do not mind that this will be extension declare.

      > I recall this was changed before. Perhaps we should write down the arguments
      > and descisions before changing it again. That avoids that changes are made
      > while forgetting some implication.

      I think this small patch will be the solution for many FEP user.
      ----------------------------------------------------------
      BTW,
      I am introducing 'Vim' to my coworkers.
      Some ones said 'It is bravo!!'. :-)
    • Bram Moolenaar
      ... I wonder when you leave FEP. Does it stay there as long as you edit the command line, or is it just used to enter a few characters? In the last case, it
      Message 2 of 7 , Feb 16, 2000
      • 0 Attachment
        Yasuhiro Matsumoto wrote:

        > it scroll text up.
        > Still more, if typing some, then ...
        >
        > |~ |
        > |~ |
        > |~ |
        > |:r C:\Winnt\..............|
        > |...Sample\ |
        > | Samp.txt_ [FEP]|
        > ----------------------------
        >
        > it make text shift.

        I wonder when you leave FEP. Does it stay there as long as you edit the
        command line, or is it just used to enter a few characters? In the last case,
        it should be possible to redraw the command line when leaving FEP. You can
        use redrawcmd() for this. cmdline_row may need to be adjusted to compensate
        for the scrolling.

        If FEP stays there while editing the command line, you really need that extra
        line.

        > But it is not necessarily that all FEP use bottom line.
        > Certainly this is not perfect solution. X-(

        We can try to get close to perfect, perhaps.

        > Then, How about the renaming that declare 'USE_CONSOLE_IME'.
        > For example, changing one's name to 'USE_BOTTOM_LINE_FEP'
        > I do not mind that this will be extension declare.

        That would be possible, but it's better when it works for everybody without
        the need to dig around in the code and docs to find out about this #define.

        > > I recall this was changed before. Perhaps we should write down the
        > > arguments and descisions before changing it again. That avoids that
        > > changes are made while forgetting some implication.
        >
        > I think this small patch will be the solution for many FEP user.

        I was thinking of a list of decisions with arguments, especially for the
        multi-byte code. That's because I don't understand much of this myself, which
        has the risk that I break something when making changes.

        --
        hundred-and-one symptoms of being an internet addict:
        6. You refuse to go to a vacation spot with no electricity and no phone lines.

        /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
        \ \ Vim: http://www.vim.org ICCF Holland: http://www.vim.org/iccf / /
      • Yasuhiro Matsumoto
        ... After leaving FEP, scrolled text stay there until calling redrawcmd(). ########################################## Before starting FEP ... ( $ is
        Message 3 of 7 , Feb 16, 2000
        • 0 Attachment
          Bram Moolenaar wrote:
          > I wonder when you leave FEP.
          > Does it stay there as long as you edit the command line,
          > or is it just used to enter a few characters?
          > In the last case, it should be possible to redraw the command line when leaving FEP.
          > You can use redrawcmd() for this.
          > cmdline_row may need to be adjusted to compensate for the scrolling.

          After leaving FEP, scrolled text stay there until calling redrawcmd().
          ##########################################

          Before starting FEP
          |~ |
          |~ |
          |~ |
          |~ |
          |~ |
          |:r C:\Winnt\..............|
          |...............\$$$$$$$$_ |
          ----------------------------
          ( '$' is multi-byte )

          When starting FEP
          |~ |
          |~ |
          |~ |
          |~ |
          |:r C:\Winnt\..............|
          |...............\$$ |
          | $$$[FEP]|
          ----------------------------
          ( '[FEP]' is guide )

          When leaving FEP
          |~ |
          |~ |
          |~ |
          |~ |
          |:r C:\Winnt\..............|
          |...............\$$ |
          | $$$$$$_ |
          ----------------------------

          ##########################################

          It happen when starting FEP.

          Still more,
          it is impossible that get the event when starting( or leaving ) FEP.
          and it is impossible that overwrite character to '[FEP]'.

          > If FEP stays there while editing the command line, you really need that extra
          > line.
          > We can try to get close to perfect, perhaps.

          Multi-byte user often use file's name that have multi-byte character.
          So they use FEP many time while editing the command line.

          I know many FEP( DOS, Windows, UNIX etc ).
          and I think 'MS-DOS' is extra.

          Many FEP's guide efect screen(or terminal, window) directly.
          But 'MS-DOS's it efect screen-buffer( bottom line ).

          It is not common library that can control all FEP.

          > > Then, How about the renaming that declare 'USE_CONSOLE_IME'.
          > > For example, changing one's name to 'USE_BOTTOM_LINE_FEP'
          > > I do not mind that this will be extension declare.
          >
          > That would be possible, but it's better when it works for everybody without
          > the need to dig around in the code and docs to find out about this #define.

          How about this ?

          nmake -f Makefile.w32 FEP=yes
          --> Console version with FEP

          > > I think this small patch will be the solution for many FEP user.
          >
          > I was thinking of a list of decisions with arguments, especially for the
          > multi-byte code. That's because I don't understand much of this myself, which
          > has the risk that I break something when making changes.

          Hmmm ..., I want to hear other's idea.
        • Bram Moolenaar
          Yasuhiro Matsumoto wrote: [about FEP scrolling the screen up one line] ... Hmm, if it is impossible to detect entering/leaving FEP, many programs must have
          Message 4 of 7 , Feb 17, 2000
          • 0 Attachment
            Yasuhiro Matsumoto wrote:

            [about FEP scrolling the screen up one line]

            > it is impossible that get the event when starting( or leaving ) FEP.
            > and it is impossible that overwrite character to '[FEP]'.

            Hmm, if it is impossible to detect entering/leaving FEP, many programs must
            have problems with FEP scrolling up the screen one line! Perhaps there is
            some other solution.

            It might help if you can direct us to an explanation of how FEP works (in
            English please!).

            > Many FEP's guide efect screen(or terminal, window) directly.
            > But 'MS-DOS's it efect screen-buffer( bottom line ).

            Hmm, perhaps it's a bug in FEP?

            > > That would be possible, but it's better when it works for everybody without
            > > the need to dig around in the code and docs to find out about this #define.
            >
            > How about this ?
            >
            > nmake -f Makefile.w32 FEP=yes
            > --> Console version with FEP

            Still has the problem that the person compiling Vim has to know about this
            argument. And people using the distributed executable won't be able to do
            this. It's only a solution for a small group of people who know what they are
            doing (like you).

            --
            hundred-and-one symptoms of being an internet addict:
            23. You can't call your mother...she doesn't have a modem.

            /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
            \ \ Vim: http://www.vim.org ICCF Holland: http://www.vim.org/iccf / /
          • Yasuhiro Matsumoto
            ... Yes, many programs have this problems. X-( This is a reason that many competent programs can t distribute to multi-byte user. ( A few programs support some
            Message 5 of 7 , Feb 17, 2000
            • 0 Attachment
              Bram Moolenaar wrote:
              > Hmm, if it is impossible to detect entering/leaving FEP, many programs must
              > have problems with FEP scrolling up the screen one line! Perhaps there is
              > some other solution.

              Yes, many programs have this problems. X-(
              This is a reason that many competent programs can't distribute to
              multi-byte user.
              ( A few programs support some FEP. )

              > It might help if you can direct us to an explanation of how FEP works (in
              > English please!).

              FEP help multi-byte user when inputing multi-byte. This is indispensable
              for
              multi-byte user. For example, The path name of 'Windows-Desktop' is ...

              C:\Winnt\Profiles\.....\Desktop ( May be )

              But multi-byte user's it is not 'Desktop'. It have multi-byte character.
              So if I want to change directory 'Desktop' on console, I must use FEP.

              On my environment, FEP is entered with key 'Alt-Kanji'. ( 106keyboard )
              It is left with same key. But there is a few FEP used different key.

              When entering FEP, it show guide of FEP. Then most FEP use a bottom
              line.
              ( Some FEP may not use... )
              When entering FEP, If I type some keys, then it show temporary
              characters.
              After editing some temporary words and type 'Enter', FEP playback my
              written.
              While entering FEP, it use a bottom line for showing the status of FEP.

              If I move cursor to bottom line and enter FEP on console, it make force
              that
              scrolling the screen up one line for showing guide. But FEP don't put
              back
              when leaving.
              FEP is made by maker with unique method. So it have no limitation. and
              there is
              no common specifications.
              Certainly there is controler for some FEP, but it is a only that working
              some.

              Still more, there is different between 'DOS console' and 'Win32
              console'.
              DOS must screen size '80x25'. So guide on DOS use line 25 always. So if
              cursor is
              located at line 25, the screen scroll up with entering FEP.
              Against it, guide on Win32 use bottom line of console window. In short,
              FEP show
              guide at bottom of visible area.
              So if cursor is not located at bottom line of console and is located at
              bottom line
              of visible area, It is not happen. FEP make visible area scroll only.
              In other words, if reserving a bottom line for guide, the screen don't
              scroll up
              with entering FEP.

              This is a reason that I reserve a bottom line.

              Sorry, I cound not write english well. X-(

              > > Many FEP's guide efect screen(or terminal, window) directly.
              > > But 'MS-DOS's it efect screen-buffer( bottom line ).
              >
              > Hmm, perhaps it's a bug in FEP?

              This is a unique method by FEP maker.
              ( This may be a method by Microsoft )

              > > > That would be possible, but it's better when it works for everybody without
              > > > the need to dig around in the code and docs to find out about this #define.
              > >
              > > How about this ?
              > >
              > > nmake -f Makefile.w32 FEP=yes
              > > --> Console version with FEP
              >
              > Still has the problem that the person compiling Vim has to know about this
              > argument. And people using the distributed executable won't be able to do
              > this. It's only a solution for a small group of people who know what they are
              > doing (like you).

              I understand.
            Your message has been successfully submitted and would be delivered to recipients shortly.