1. 19 Jun, 2020 1 commit
  2. 17 Jun, 2020 4 commits
    • Hiltjo Posthuma's avatar
    • Hiltjo Posthuma's avatar
      LICENSE: bump years · 81067c65
      Hiltjo Posthuma authored
    • Hiltjo Posthuma's avatar
      remove sixel stub code · f74a9df6
      Hiltjo Posthuma authored
      Remove stub code that was used for an experiment of adding sixel code to st
      from the commit f7398434.
    • Hiltjo Posthuma's avatar
      fix unicode glitch in DCS strings, patch by Tim Allen · 818ec746
      Hiltjo Posthuma authored
      Reported on the mailinglist:
      I discovered recently that if an application running inside st tries to
      send a DCS string, subsequent Unicode characters get messed up. For
      example, consider the following test-case:
          printf '\303\277\033P\033\\\303\277'
        - \303\277 is the UTF-8 encoding of U+00FF LATIN SMALL LETTER Y WITH
          DIAERESIS (ÿ).
        - \033P is ESC P, the token that begins a DCS string.
        - \033\\ is ESC \, a token that ends a DCS string.
        - \303\277 is the same ÿ character again.
      If I run the above command in a VTE-based terminal, or xterm, or
      QTerminal, or pterm (PuTTY), I get the output:
      ...which is to say, the empty DCS string is ignored. However, if I run
      that command inside st (as of commit 9ba7ecf7), I get:
      ...where those last two characters are \303\277 interpreted as ISO8859-1
      characters, instead of UTF-8.
      I spent some time tracing through the state machines in st.c, and so far
      as I can tell, this is how it works currently:
        - ESC P sets the "ESC_DCS" and "ESC_STR" flags, indicating that
          incoming bytes should be collected into the strescseq buffer, rather
          than being interpreted.
        - ESC \ sets the "ESC_STR_END" flag (when ESC is received), and then
          calls strhandle() (when \ is received) to interpret the collected
        - If the collected bytes begin with 'P' (i.e. if this was a DCS
          string) strhandle() sets the "ESC_DCS" flag again, confusing the
          state machine.
      If my understanding is correct, fixing the problem should be as easy as
      removing the line that sets ESC_DCS from strhandle():
      diff --git a/st.c b/st.c
      index ef8abd5..b5b805a 100644
      --- a/st.c
      +++ b/st.c
      @@ -1897,7 +1897,6 @@ strhandle(void)
      	case 'P': /* DCS -- Device Control String */
      -		term.mode |= ESC_DCS;
      	case '_': /* APC -- Application Program Command */
      	case '^': /* PM -- Privacy Message */
      I've tried the above patch and it fixes my problem, but I don't know if
      it introduces any others.
  3. 01 Jun, 2020 1 commit
  4. 30 May, 2020 4 commits
    • Hiltjo Posthuma's avatar
      config.def.h: add an option allowwindowops, by default off (secure) · a2a70449
      Hiltjo Posthuma authored
      Similar to the xterm AllowWindowOps option, this is an option to allow or
      disallow certain (non-interactive) operations that can be insecure or
      NOTE: xsettitle() is not guarded by this because st does not support printing
      the window title. Else this could be exploitable (arbitrary code execution).
      Similar problems have been found in the past in other terminal emulators.
      The sequence for base64-encoded clipboard copy is now guarded because it allows
      a sequence written to the terminal to manipulate the clipboard of the running
      user non-interactively, for example:
      printf '\x1b]52;0;ZWNobyBoaQ0=\a'
    • Hiltjo Posthuma's avatar
      FAQ: add some details about the w3m img hack · 0f8b4065
      Hiltjo Posthuma authored
      ... and an example patch to switch from double-buffering to a single buffer.
    • Hiltjo Posthuma's avatar
      tiny style fix · e6e2c619
      Hiltjo Posthuma authored
    • Hiltjo Posthuma's avatar
      Partially add back in "support REP (repeat) escape sequence" · 94b8ec00
      Hiltjo Posthuma authored
      Add the functionality back in for xterm compatibility, but do not expose the
      capability in st.info (yet).
      Some notes:
      It was reverted because it caused some issues with ncurses in some
      configurations, namely when using BSD padding (--enable-bsdpad, BSD_TPUTS) in
      ncurses it caused issues with repeating digits.
      A fix has been upstreamed in ncurses since snapshot 20200523. The fix is also
      backported to OpenBSD -current.
  5. 24 May, 2020 1 commit
  6. 16 May, 2020 4 commits
    • Hiltjo Posthuma's avatar
      Revert "support REP (repeat) escape sequence" · 475a0a36
      Hiltjo Posthuma authored
      This reverts commit e8392b28.
      There is currently a bug in older ncurses versions (like on OpenBSD) where a
      fix for a bug with REP is not backported yet. Most likely in tty/tty_update.c:
      Noticed while using lynx (which uses ncurses/curses).
      To reproduce using lynx: echo "Z0000000" | lynx -stdin
      or using the program:
      	WINDOW *win;
      	win = initscr();
      	return 0;
      This prints "ZZZZZZZ" (incorrectly).
    • Avi Halachmi (:avih)'s avatar
      support REP (repeat) escape sequence · e8392b28
      Avi Halachmi (:avih) authored
      The sequence \e[Nb prints the last printed char N (more) times if it's
      printable, and it's ignored after newline or other control chars.
      This is Ecma-048/ANSI-X3.6 sequence and not DEC VT. It's supported by
      xterm, and ncurses uses it when possible, e.g. when TERM is xterm* (and
      with this commit also st*).
      xterm supports only codepoints<=255, possibly due to internal limits.
      We support any value/codepoint which was placed in a cell.
      To test:
      - tput rep 65 4 -> prints 'AAAA'
      - printf "\342\225\246\033[4b" -> prints U+2566 1+4 times.
    • Roberto E. Vargas's avatar
      Add rin terminfo capability · f8afebdf
      Roberto E. Vargas authored
      Tianlin Qu discovered that st is missing rin (scroll back #1 lines).
    • k0ga's avatar
      Make shift+wheel behaves as shift+Prev/Next · bda9c9ff
      k0ga authored
      St uses a very good hack where mouse wheel genereates ^Y and ^E,
      that are the same keys that less and vi uses for backward and
      fordward scrolling. Scroll, as many terminal emulators, use
      shift+Prev/Next for scrolling, but it is also using ^E and ^Y
      for scroling, characters that are reserved in the POSIX shell
      in emacs mode for end of line and yanking, making scroll unsable
      in st.
      This patch adds a new hack, making shift+wheel returning the
      same sequences than shift+Prev/Next, meaning that scroll or
      any other similar program will not be able to differentiate
      between them.
  7. 12 May, 2020 3 commits
  8. 09 May, 2020 5 commits
    • Hiltjo Posthuma's avatar
      code-style: add fallthrough comment · 914fb825
      Hiltjo Posthuma authored
      Patch by Steve Ward, thanks.
    • Hiltjo Posthuma's avatar
      optimize column width calculation and utf-8 encode for ASCII · cde480c6
      Hiltjo Posthuma authored
      In particular on OpenBSD and on glibc wcwidth() is quite expensive.
      On musl there is little difference.
    • Hiltjo Posthuma's avatar
      fix for incorrect (partial) written sequences when libc wcwidth() == -1 · 8211e36d
      Hiltjo Posthuma authored
      Fix an issue with incorrect (partial) written sequences when libc wcwidth() ==
      -1. The sequence is updated to on wcwidth(u) == -1:
      	c = "\357\277\275"
      but len isn't.
      A way to reproduce in practise:
      * st -o dump.txt
      * In the terminal: printf '\xcd\xb8'
      - This is codepoint 888, on OpenBSD it reports wcwidth() == -1.
      - Quit the terminal.
      - Look in dump.txt (partial written sequence of "UTF_INVALID").
      This was introduced in:
      "	commit 11625c71
      	Author: czarkoff@gmail.com <czarkoff@gmail.com>
      	Date:   Tue Oct 28 12:55:28 2014 +0100
      	    Replace character with U+FFFD if wcwidth() is -1
      	    Helpful when new Unicode codepoints are not recognized by libc."
      Remove setting the sequence. If this happens to break something, another
      solution could be setting len = 3 for the sequence.
    • Hiltjo Posthuma's avatar
      tiny code-style and typo-fix in comment · 87545c61
      Hiltjo Posthuma authored
    • Avi Halachmi (:avih)'s avatar
      auto-sync: draw on idle to avoid flicker/tearing · 1d590910
      Avi Halachmi (:avih) authored
      st could easily tear/flicker with animation or other unattended
      output. This commit eliminates most of the tear/flicker.
      Before this commit, the display timing had two "modes":
      - Interactively, st was waiting fixed `1000/xfps` ms after forwarding
        the kb/mouse event to the application and before drawing.
      - Unattended, and specifically with animations, the draw frequency was
        throttled to `actionfps`. Animation at a higher rate would throttle
        and likely tear, and at lower rates it was tearing big frames
        (specifically, when one `read` didn't get a full "frame").
      The interactive behavior was decent, but it was impossible to get good
      unattended-draw behavior even with carefully chosen configuration.
      This commit changes the behavior such that it draws on idle instead of
      using fixed latency/frequency. This means that it tries to draw only
      when it's very likely that the application has completed its output
      (or after some duration without idle), so it mostly succeeds to avoid
      tear, flicker, and partial drawing.
      The config values minlatency/maxlatency replace xfps/actionfps and
      define the range which the algorithm is allowed to wait from the
      initial draw-trigger until the actual draw. The range enables the
      flexibility to choose when to draw - when least likely to flicker.
      It also unifies the interactive and unattended behavior and config
      values, which makes the code simpler as well - without sacrificing
      latency during interactive use, because typically interactively idle
      arrives very quickly, so the wait is typically minlatency.
      While it only slighly improves interactive behavior, for animations
      and other unattended-drawing it improves greatly, as it effectively
      adapts to any [animation] output rate without tearing, throttling,
      redundant drawing, or unnecessary delays (sounds impossible, but it
  9. 29 Apr, 2020 1 commit
  10. 27 Apr, 2020 1 commit
  11. 19 Apr, 2020 1 commit
  12. 11 Apr, 2020 10 commits
  13. 10 Apr, 2020 1 commit
  14. 02 Apr, 2020 1 commit
    • Avi Halachmi (:avih)'s avatar
      mouseshortcuts: fix custom modifier on release · 28ad2883
      Avi Halachmi (:avih) authored
      This line didn't work at mshortcuts at config.h:
        /*  mask       button   function  arg       release */
          { ShiftMask, Button2, selpaste, {.i = 0}, 1 },
      and now it does work.
      The issue was that XButtonEvent.state is "the logical state ... just prior
      to the event", which means that on release the state has the Button2Mask
      bit set because button2 was down just before it was released.
      The issue didn't manifest with the default shift + middle-click on release
      (to override mouse mode) because its specified modifier is XK_ANY_MOD, at
      which case match(...) ignores any specific bits and simply returns true.
      The issue also doesn't manifest on press, because prior to the event
      Button<N> was not down and its mask bit is not set.
      Fix by filtering out the mask of the button which we're currently matching.
      We could have said "well, that's how button events behave, you should
      use ShiftMask|Button2Mask for release", but this both not obvious to
      figure out, and specifically here always filtering does not prevent
      configuring any useful modifiers combination. So it's a win-win.
  15. 18 Feb, 2020 1 commit
    • Ivan Tham's avatar
      Remove explicit XNFocusWindow · 51e19ea1
      Ivan Tham authored
      XCreateIC ICValues default XNFocusWindow to XNClientWindow if not
      specified, it can be omitted since it is the same.
      From the documentation
      > Focus Window
      > The XNFocusWindow argument specifies the focus window. The primary
      > purpose of the XNFocusWindow is to identify the window that will receive
      > the key event when input is composed.
      > When this XIC value is left unspecified, the input method will use the
      > client window as the default focus window.
  16. 02 Feb, 2020 1 commit
    • Quentin Rameau's avatar
      x: fix XIM handling · 26cdfebf
      Quentin Rameau authored
      Do not try to set specific IM method, let the user specify it with
      If the requested method is not available or opening fails, fallback to
      the default input handler and register a handler on the new IM server
      availability signal.
      Do the same when the input server is closed and (re)started.