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

"set ttym=" on slackware

Expand Messages
  • Elijah Griffin
    Hello, I ve been using set ttym= and set mouse= in my vimrc for a while. It clears the mouse setting in non-GUI vim so that my mouse continues to work the
    Message 1 of 7 , May 9 11:12 PM
      Hello,

      I've been using "set ttym=" and "set mouse=" in my vimrc for a while.
      It clears the mouse setting in non-GUI vim so that my mouse continues
      to work the way I expect it to.

      Recently I switched from a ubuntu based distro to a slackware based
      one, for reasons that are similar to my crudmudeonly continued use of
      non-GUI vim in black and white xterms. (This newfangled mouse stuff
      didn't exist in vim 3.0! Probably not 4.0 either, but I don't have a
      copy around to test with.)

      Curiously clearing ttym, that is "set ttym=", in my .vimrc has a very
      weird brokenness on slackware. I don't know if it is the fault of the
      build, something in the system, but I found it in both the 14.0 and
      14.1 distros. On slackware, the default vi is elvis, so the vim
      package may be less tested.

      Here's what happens when I use that setting. Immediately on startup,
      whether an empty buffer or an existing file, vim pauses for a short
      while then it acts like someone mashed on a function key. The screen
      would flash (visual bell) and I'd be left in a state expecting a move
      command for a change. For a long time I was not able to figure out
      exactly what it was, until I discovered it happens with vim run as ex:

      $ ex ~/.vimrc
      "~/.vimrc" 14L, 212C
      Entering Ex mode. Type "visual" to go to Normal mode.
      :^[[>41;297;0c

      The ^[ is an escape. This looks like an attempt by vim to send a
      control sequence to the terminal, and based on the ttym involvement
      it's likely a mouse state probe / initialization. Only the single
      line "set ttym=" in ~/.vimrc is necessary for this to happen.

      Has anyone else observed similar behavior? How can I figure out if
      it is vim or slackware? With no .vimrc I get:

      :set ttymouse mouse
      ttymouse=sgr
      mouse=a

      And the mouse does not cut-n-paste the way I expect.

      Elijah
      ------
      :version
      VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 2 2013 20:15:40)
      Included patches: 1-50
      Compiled by <volkerdi@...>
      Huge version without GUI. Features included (+) or not (-):
      +acl +farsi +mouse_netterm +syntax
      +arabic +file_in_path +mouse_sgr +tag_binary
      +autocmd +find_in_path -mouse_sysmouse +tag_old_static
      -balloon_eval +float +mouse_urxvt -tag_any_white
      -browse +folding +mouse_xterm -tcl
      ++builtin_terms -footer +multi_byte +terminfo
      +byte_offset +fork() +multi_lang +termresponse
      +cindent +gettext -mzscheme +textobjects
      -clientserver -hangul_input +netbeans_intg +title
      -clipboard +iconv +path_extra -toolbar
      +cmdline_compl +insert_expand +perl +user_commands
      +cmdline_hist +jumplist +persistent_undo +vertsplit
      +cmdline_info +keymap +postscript +virtualedit
      +comments +langmap +printer +visual
      +conceal +libcall +profile +visualextra
      +cryptv +linebreak +python +viminfo
      +cscope +lispindent -python3 +vreplace
      +cursorbind +listcmds +quickfix +wildignore
      +cursorshape +localmap +reltime +wildmenu
      +dialog_con -lua +rightleft +windows
      +diff +menu -ruby +writebackup
      +digraphs +mksession +scrollbind -X11
      -dnd +modify_fname +signs -xfontset
      -ebcdic +mouse +smartindent -xim
      +emacs_tags -mouseshape -sniff -xsmp
      +eval +mouse_dec +startuptime -xterm_clipboard
      +ex_extra +mouse_gpm +statusline -xterm_save
      +extra_search -mouse_jsbterm -sun_workshop -xpm
      system vimrc file: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
      2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
      fall-back for $VIM: "/usr/share/vim"
      Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -I/usr/local/include -O2 -U_F
      ORTIFY_SOURCE -D_FORTIFY_SOURCE=1
      Linking: gcc -Wl,-E -Wl,-rpath,/usr/lib/perl5/CORE -L/usr/local/lib -Wl,--as
      -needed -o vim -lm -lncurses -lelf -lnsl -lacl -lattr -lgpm -ldl -Wl,
      -E -Wl,-rpath,/usr/lib/perl5/CORE -fstack-protector -L/usr/local/lib -L/usr/li
      b/perl5/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -L/usr/lib/pytho
      n2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic

      --
      --
      You received this message from the "vim_use" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/d/optout.
    • Erik Falor
      ... I have been unable to reproduce the problem you are experiencing. I tried doing so by running Vim in this fashion: vim --noplugin -u NONE -c set ttym=
      Message 2 of 7 , May 11 10:02 PM
        On Sat, May 10, 2014 at 02:12:44AM -0400, Elijah Griffin wrote:

        > I've been using "set ttym=" and "set mouse=" in my vimrc for a while.
        > It clears the mouse setting in non-GUI vim so that my mouse continues
        > to work the way I expect it to.

        I have been unable to reproduce the problem you are experiencing. I
        tried doing so by running Vim in this fashion:

        vim --noplugin -u NONE -c 'set ttym= mouse='

        and ex with the same arguments.

        > Has anyone else observed similar behavior? How can I figure out if
        > it is vim or slackware?

        Could you supply a minimal .vimrc which contains exactly the settings
        that cause this problem for you?

        Also, would you please supply some other points of information that
        may be relevant? These include:

        1. Version of XTerm you are using
        2. Value of the TERM environment variable
        3. Values of your LINES and COLUMNS variables
        4. Architecture of your Slackware installation (i686 or x86_64)

        For my part, I ran the above test with
        1. xterm -v => X.Org 7.6.0(297)
        2. TERM=xterm
        3. LINES=49 COLUMNS=167
        4. Slackware 14.1 i686

        I expect that on your system you have similar values. Since you're
        seeing weird behavior we'll have to cover weird bases to explain it.

        --
        Erik Falor
        Registered Linux User #445632 http://linuxcounter.net
      • Elijah Griffin
        ... I will confirm it does not occur with -u NONE, with or without --noplugin. ... I sort of did: I can comment out every single line of my .vimrc except set
        Message 3 of 7 , May 11 11:20 PM
          Erik Falor wrote:
          > On Sat, May 10, 2014 at 02:12:44AM -0400, Elijah Griffin wrote:
          >> I've been using "set ttym=" and "set mouse=" in my vimrc for a while.
          >> It clears the mouse setting in non-GUI vim so that my mouse continues
          >> to work the way I expect it to.
          > I have been unable to reproduce the problem you are experiencing. I
          > tried doing so by running Vim in this fashion:
          > vim --noplugin -u NONE -c 'set ttym= mouse='

          I will confirm it does not occur with -u NONE, with or without
          --noplugin.

          > Could you supply a minimal .vimrc which contains exactly the settings
          > that cause this problem for you?

          I sort of did: I can comment out every single line of my .vimrc except

          set ttym=

          And that's all I need for it to happen. It does not occur after setting
          ttm during editing, so it does seem to be an interaction with something
          else running at startup. For example:

          $ HOME=/dev/null vim -c 'set ttym='

          will do it, and I'm pretty certain none of my dotfiles are involved in
          that.

          > Also, would you please supply some other points of information that
          > may be relevant? These include:
          >
          > 1. Version of XTerm you are using

          $ xterm -version
          X.Org 7.6.0(297)

          > 2. Value of the TERM environment variable
          > 3. Values of your LINES and COLUMNS variables

          $ echo TERM=$TERM LINES=$LINES COLUMNS=$COLUMNS
          TERM=xterm LINES=24 COLUMNS=80

          > 4. Architecture of your Slackware installation (i686 or x86_64)

          Slackware 14.1 i686

          > I expect that on your system you have similar values. Since you're
          > seeing weird behavior we'll have to cover weird bases to explain it.

          Thanks for looking into it.

          Elijah

          --
          --
          You received this message from the "vim_use" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/d/optout.
        • Erik Falor
          ... I have now reproduced the bug you re seeing by creating a .vimrc containing only that line. I can reliably reproduce the problem both in terminals xterm
          Message 4 of 7 , May 12 10:39 AM
            On Mon, May 12, 2014 at 02:20:47AM -0400, Elijah Griffin wrote:
            > Erik Falor wrote:
            > > On Sat, May 10, 2014 at 02:12:44AM -0400, Elijah Griffin wrote:
            > >> I've been using "set ttym=" and "set mouse=" in my vimrc for a while.
            > >> It clears the mouse setting in non-GUI vim so that my mouse continues
            > >> to work the way I expect it to.
            > > I have been unable to reproduce the problem you are experiencing. I
            > > tried doing so by running Vim in this fashion:
            > > vim --noplugin -u NONE -c 'set ttym= mouse='
            >
            > I will confirm it does not occur with -u NONE, with or without
            > --noplugin.
            >
            > > Could you supply a minimal .vimrc which contains exactly the settings
            > > that cause this problem for you?
            >
            > I sort of did: I can comment out every single line of my .vimrc except
            >
            > set ttym=

            I have now reproduced the bug you're seeing by creating a .vimrc
            containing only that line. I can reliably reproduce the problem both
            in terminals xterm and rxvt-unicode-256color. However, if I run Vim
            within GNU Screen I do not see the bad behavior. I have also
            reproduced the bad behavior on my Gentoo x86_64 box using Vim 7.4.258
            which I built myself. I am not convinced that this is a problem with
            Slackware's packaging of Vim.

            By invoking Vim with -u NONE I avoid the incorrect behavior. A trivial
            .vimrc combined with --noplugin still exhibits the bad behavior. By running
            'vim --noplugin -V2' I see that many scripts from /usr/share/vim are
            sourced. All of those scripts are avoided with -u NONE. I wonder now if
            the problem may be in one of those?

            I see only three changes in the hg changelog that seem to deal with the
            ttymouse option:

            changeset: 5076:19ed30f7cef7
            tag: v7-3-1281
            user: Bram Moolenaar <bram@...>
            date: Mon Jul 01 20:06:19 2013 +0200
            files: src/term.c src/version.c
            description:
            updated for version 7.3.1281
            Problem: When 'ttymouse' is set to "xterm2" clicking in column 123 moves
            the cursor to column 96. (Kevin Goodsell)
            Solution: Decode KE_CSI.

            changeset: 3980:aab4b29520e7
            tag: v7-3-745
            user: Bram Moolenaar <bram@...>
            date: Wed Dec 05 14:43:02 2012 +0100
            files: src/option.c src/proto/option.pro src/term.c src/version.c
            description:
            updated for version 7.3.745
            Problem: Automatically setting 'ttymouse' doesn't work.
            Solution: Reset the "option was set" flag when using the default.

            changeset: 3885:4ffb6f9b58e0
            tag: v7-3-699
            user: Bram Moolenaar <bram@...>
            date: Sun Oct 21 02:10:24 2012 +0200
            files: src/term.c src/version.c
            description:
            updated for version 7.3.699
            Problem: When 'ttymouse' is set to "sgr" manually, it is overruled by
            automatic detection.
            Solution: Do not use automatic detection when 'ttymouse' was set manually.
            (Hayaki Saito)


            I haven't looked into the source changes more closely than this, but I
            bring it up to point out that this may have been broken for quite some
            time.

            My conclusion is that either we're trying to use the ttymouse= setting
            in the wrong way, or a regression was added to Vim at some point in
            the past. Could you tell us what version of Vim you were using prior
            to switching to Slackware? That will help in pinpointing the patch
            that introduced this behavior. At least knowing which version of the
            distro you were on will be useful.

            --
            Erik Falor
            Registered Linux User #445632 http://linuxcounter.net
          • Christian Brabandt
            Hi Elijah! ... That is the xterm version string. I am not sure what happens and I don t know the code good enough. At a quick glance at term.c it looks like
            Message 5 of 7 , May 12 12:21 PM
              Hi Elijah!

              On Sa, 10 Mai 2014, Elijah Griffin wrote:

              > Hello,
              >
              > I've been using "set ttym=" and "set mouse=" in my vimrc for a while.
              > It clears the mouse setting in non-GUI vim so that my mouse continues
              > to work the way I expect it to.
              >
              > Recently I switched from a ubuntu based distro to a slackware based
              > one, for reasons that are similar to my crudmudeonly continued use of
              > non-GUI vim in black and white xterms. (This newfangled mouse stuff
              > didn't exist in vim 3.0! Probably not 4.0 either, but I don't have a
              > copy around to test with.)
              >
              > Curiously clearing ttym, that is "set ttym=", in my .vimrc has a very
              > weird brokenness on slackware. I don't know if it is the fault of the
              > build, something in the system, but I found it in both the 14.0 and
              > 14.1 distros. On slackware, the default vi is elvis, so the vim
              > package may be less tested.
              >
              > Here's what happens when I use that setting. Immediately on startup,
              > whether an empty buffer or an existing file, vim pauses for a short
              > while then it acts like someone mashed on a function key. The screen
              > would flash (visual bell) and I'd be left in a state expecting a move
              > command for a change. For a long time I was not able to figure out
              > exactly what it was, until I discovered it happens with vim run as ex:
              >
              > $ ex ~/.vimrc
              > "~/.vimrc" 14L, 212C
              > Entering Ex mode. Type "visual" to go to Normal mode.
              > :^[[>41;297;0c
              >
              > The ^[ is an escape. This looks like an attempt by vim to send a
              > control sequence to the terminal, and based on the ttym involvement
              > it's likely a mouse state probe / initialization. Only the single
              > line "set ttym=" in ~/.vimrc is necessary for this to happen.

              That is the xterm version string. I am not sure what happens and I don't
              know the code good enough. At a quick glance at term.c it looks like
              when setting the terminal options (set_termname) it resets 'ttym' option
              and clears the WAS_SET_FLAG and later on in check_termcode() it
              explicitly requests the xterm version info and tries to set ttym to sgr
              if WAS_SET_FLAG is reset.

              You might want to enable debugging in term.c and see, if the log can
              help you figuring out what was wrong.

              As a workaround, try to set the ttym setting in an VimEnter workaround.
              That might work better.

              Best,
              Christian
              --
              Beim Beginnen eine Unternehmung und unweit des Zieles ist die Gefahr
              des Mißlingens am größten. - Wenn Schiffe scheitern, so geschieht es
              nahe am Ufer.
              -- Ludwig Börne

              --
              --
              You received this message from the "vim_use" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_use" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
              For more options, visit https://groups.google.com/d/optout.
            • Elijah Griffin
              (Can I post to vim_dev? I m not subscribed. Let s find out.) ... I did just that today, after failing to find a distro built vim for which would not reproduce
              Message 6 of 7 , May 12 11:14 PM
                (Can I post to vim_dev? I'm not subscribed. Let's find out.)
                Christian Brabandt replied to me:
                >> $ ex ~/.vimrc
                >> "~/.vimrc" 14L, 212C
                >> Entering Ex mode. Type "visual" to go to Normal mode.
                >> :^[[>41;297;0c
                >> The ^[ is an escape. This looks like an attempt by vim to send a
                ...
                > That is the xterm version string. I am not sure what happens and I don't
                > know the code good enough. At a quick glance at term.c it looks like
                ...
                > You might want to enable debugging in term.c and see, if the log can
                > help you figuring out what was wrong.

                I did just that today, after failing to find a distro built vim for
                which would not reproduce the bug in the most stripped down form (no
                user dot files and "-c 'set ttym='").

                What I've learned:

                0) I can compile vim 7.1, 7.1, and 7.2, but they all die on startup.

                1) With vim7.3, unpatched source, it occurs with
                configure --with-features=huge ---disable-gui
                configure --with-features=big ---disable-gui
                but not
                configure --with-features=normal ---disable-gui

                2) It doesn't happen with
                vim -u NORC -c 'set ttym='

                It doesn't happen after
                root# chmod 000 /usr/share/vim/vimrc
                user$ mv ~/.vimrc ~/.vimrc.hold
                user$ vim -c 'set ttym='

                But if I have no system vimrc a user vimrc of just "set ttym="
                then it will happen. I haven't tried "set ttym=" in the system
                vimrc.

                3) With strace, I see that it happens after ~/.viminfo is read the
                second time. (Deleting ~/.viminfo doesn't change the behavior.)
                Simplifed the trace looks like:

                execve("/usr/bin/vim", ["vim", "-c", "set ttym=",
                "/home/testuser/.vimrc"], [/* 46 vars */]) = 0
                [much happens ...]

                write(1, " 1L, 10C", 8) = 8
                open("/home/testuser/.viminfo", O_RDONLY|O_LARGEFILE) = 3
                fstat64(3, ...}) = 0
                mmap2(NULL, 4096, ...) = 0xb76cc000
                read(3, "# This viminfo file was generate"..., 4096) = 4096
                [multiple reads omited...]
                close(3) = 0
                munmap(0xb76cc000, 4096) = 0
                select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
                select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
                select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
                getcwd("/tmp/vim-tests", 4096) = 15
                ioctl(1, SNDCTL_TMR_TIMEBASE ...}) = 0
                ioctl(0, SNDCTL_TMR_TIMEBASE ...}) = 0
                write(1, "\33[>c", 4) = 4
                select(1, [0], NULL, [0], {0, 0}) = 1 (in [0], left {0, 0})
                read(0, "\33[>41;297;0c", 4096) = 12
                select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
                select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
                select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
                write(1, "\33[1;1Hset sw=72\r\n\33[1m\33[34m~ "..., 1944) = 1944

                That's vim writing the size of the file out (" 1L, 10C"), opening
                and reading viminfo, checking the working directory for about the
                15th time, setting some tty ioctl()s, then it writes an escape
                sequence ("\33[>c"), detects (with select()) there is a response and
                reads that response in ("\33[>41;297;0c"), checks a few more times
                for input and then writes the file on the screen for the first time.

                The escape sequence "\33[>c" apparently prompts xterm to reply with
                a version escape sequence, which is read but not processed as a
                terminal response, and is instead treated as user input.

                I have not yet pinned down what function is sending that escape
                sequence. In my observations, .viminfo is read three times and written
                once. As mentioned, if .viminfo is missing the same actions occur,
                except that the open(...viminfo...) fails and the contents are not
                read, but this still happens after the second attempt to open it, with
                the same interleaves of write(1...), select(), and read(0...).

                My next plan of attack is stepping through the code after the open
                of .viminfo to try to find where it is happening, but I ran out of time
                today.

                Elijah

                --
                --
                You received this message from the "vim_use" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_use" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                For more options, visit https://groups.google.com/d/optout.
              • Elijah Griffin
                ... The escape sequence is sent by may_req_termresponse() called from main.c:895. The issue is not that the sequence is sent in error, it is that
                Message 7 of 7 , May 13 4:00 PM
                  Last night I wrote:
                  > 3) With strace, I see that it happens after ~/.viminfo is read the
                  ...
                  > That's vim writing the size of the file out (" 1L, 10C"), opening
                  > and reading viminfo, checking the working directory for about the
                  > 15th time, setting some tty ioctl()s, then it writes an escape
                  > sequence ("\33[>c"), detects (with select()) there is a response and
                  > reads that response in ("\33[>41;297;0c"), checks a few more times
                  > for input and then writes the file on the screen for the first time.
                  >
                  > The escape sequence "\33[>c" apparently prompts xterm to reply with
                  > a version escape sequence, which is read but not processed as a
                  > terminal response, and is instead treated as user input.
                  >
                  > I have not yet pinned down what function is sending that escape
                  > sequence.

                  The escape sequence is sent by may_req_termresponse() called from
                  main.c:895. The issue is not that the sequence is sent in error, it
                  is that check_termcode() in term.c is misparsing it.

                  ":set termcap" shows me:

                  --- Terminal codes ---
                  ... t_RV=^[[>c ...

                  That's the Request Version (or similar) code.

                  --- Terminal keys ---
                  ... <DecMouse> ^[[ ...
                  ... <NetMouse> ^[} ...
                  ... <Mouse> ^[MG ...

                  With no "ttym=", there is no entry for <DecMouse> under "Terminal keys",
                  there is only the single entry for <Mouse>. And the DecMouse escape
                  sequence starts the same as a version response string from xterm, so
                  key_name[0] gets set in check_termcode(). Then when it reaches:

                  4066 #ifdef FEAT_TERMRESPONSE
                  4067 if (key_name[0] == NUL)
                  4068 {
                  4069 /* Check for xterm version string: "<Esc>[>{x};{vers};{y}c". Also

                  the if key_name[0] == NUL is false and the response is not parsed.

                  And why is <DecMouse> in there? It's over in check_mouse_termcode()
                  in os_unix.c:

                  3478 # ifdef FEAT_MOUSE_DEC
                  3479 /* conflicts with xterm mouse: "\033[" and "\033[M" */
                  3480 if (!use_xterm_mouse()
                  3481 # ifdef FEAT_GUI
                  3482 && !gui.in_use
                  3483 # endif
                  3484 )
                  3485 set_mouse_termcode(KS_DEC_MOUSE, (char_u *)(term_is_8bit(T_NAME)
                  3486 ? IF_EB("\233", CSI_STR) : IF_EB("\033[", ESC_STR "[")));
                  3487 else
                  3488 del_mouse_termcode(KS_DEC_MOUSE);
                  3489 # endif

                  By setting ttym to the empty string, use_xterm_mouse() is false, the GUI
                  not in use, so it adds this bogus mouse escape sequnce that confuses
                  check_termcode().

                  What's the best fix then? I'm guessing a check for ttym_flags being non-zero
                  to each of the set_mouse_termcode() if statements in check_mouse_termcode().

                  Elijah

                  --
                  --
                  You received this message from the "vim_use" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_use" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                  For more options, visit https://groups.google.com/d/optout.
                Your message has been successfully submitted and would be delivered to recipients shortly.