Greg Hurrell [Tue, 28 Dec 2021 12:21:22 +0000 (13:21 +0100)]
Merge branch 'pull/50'
Closes: https://github.com/wincent/terminus/pull/50
* pull/50:
docs: update AUTHORS and HISTORY sections
feat: add iTerm2 to the SGR Protocol supported list
Neui [Sat, 9 Feb 2019 13:03:15 +0000 (14:03 +0100)]
fix(vim): execute Focus* in Vim terminal to fix ??? chars
Seems to be caused by sending a raw `<f20>` and `<f21>` to the terminal.
Since gvim also executes the Focus* while in terminal, this is
replicated here. As a side effect of removing the default mapping of
`<f20>` and `<f21>`, this fixes weird ??? characters in vim terminals.
Greg Hurrell [Fri, 20 Oct 2017 14:45:41 +0000 (07:45 -0700)]
Suppress E11 error when focusing command-line window
Not sure whether this is the "right" fix or not (that is, whether we
should aim to avoid triggering the autocmd at all rather than merely
suppressing the error), but going to give this a try.
Greg Hurrell [Thu, 13 Oct 2016 01:44:32 +0000 (18:44 -0700)]
Implement throttling using timers
This ends up sucking more than you would think. I set this up with a
500ms time interval, and observed that actual time elapsed was typically
several seconds and was as high as 9 seconds. According to the help,
this is expected:
{time} is the waiting time in milliseconds. This is the
minimum time before invoking the callback. When the system is
busy or Vim is not waiting for input the time will be longer.
So, might end up adding a setting for this and letting the user choose
between responsive resizing and responsive focus/blur.
Greg Hurrell [Thu, 13 Oct 2016 00:38:52 +0000 (17:38 -0700)]
Work around missing/late FocusGained/FocusLost events
I've noticed that FocusGained/FocusLost events can be slow to arrive,
and sometimes may not arrive at all, when they are the result of
creating or destroying a new tmux pane.
Unsure of why this might be -- it could be a bug in tmux, Vim, iTerm, or
my own config -- I asked on the tmux issue tracker:
https://github.com/tmux/tmux/issues/577
As noted there, you can easily verify that tmux is always sending the
right focus events by doing this in a pane:
printf '\033[?1004h'; cat
(ie. enable focus reporting in that pane and then have `cat` echo back
whatever events it gets back on the input stream). When you do this, you
can clearly see the right sequences coming back (`Esc[O` and `Esc[I`) as
soon as you create a split (shifting focus to it) or destroy it
(shifting focus back).
So I then started looking into Vim itself. I tried various tweaks of
`'timeout'`, `'timeoutlen'`, `'ttimeout'`, `'ttimeoutlen'` and co. I
also checked out `'updatetime'`, `'nolazyredraw'`, `'esckeys'` and
various other suspects. Additionally, I tried binding directly to
`Esc[O` rather than those virtual function keys, reordering the
autocommands to make the Focus ones run first, and disabling other
autocommands that might be interfering.
I added logging to Vim itself and recompiled it, and found that none of
the focus-related code is invoked in the terminal, which is why the
`Esc[O` stuff needs to be bound. I tried two other plug-ins that do
focus managment (Vitality[0] and vim-tmux-focus-events[1]) and found
that they exhibited the same behavior. I even tried Neovim, which has
built in focus support, and saw that it was also affected; additionally,
I looked at the implementation[2] and saw that it was implemented by
peeking ahead in the input stream, which would suggest that even if a
similar implementation were added to Vim, then we'd still have the same
problem because something else is at play.
Ruled out iTerm by doing a `touch ~/.vim/.assume-iterm` and running in
Terminal.app. Focus mostly works there, but notably, it is not immune to
this issue either.
Confirmed that I could fake focus events by doing something like this:
tmux send-keys -t dot:1.1 Escape '[I'
But that didn't really help me much as my growing suspicion was that
something about the split creation/destruction was leading to a
VimResized event which was somehow interrupting the detection and
processing of the focus key sequence (although changing the timeouts and
even disabling timeouts entirely had no effect).
So all this leads me to this hack: we subscribe to VimResized events,
and when we get one, we check if we have focus; depending on whether we
do or don't we fire the corresponding FocusGained/FocusLost autocommand.
If we can't determine that for whatever reason, we do nothing.
The problem here is we slow down resizes. I would have liked to throttle
the events with `CursorHold`, but that doesn't really work because if
the user is idle those events get paused until the next key press. So, I
am going to commit this "eager" version, and then add a better,
throttled version in the next commit that uses timers (available in Vim
version 8, so will need feature detection).
Greg Hurrell [Wed, 12 Oct 2016 01:08:48 +0000 (18:08 -0700)]
Add empty .watchmanconfig
Allows a Watchman instance configured with `enforce_root_files` to watch
this directory even if `root_files` does not contain any of the files in
the directory. (Necessary to get around undesired corporate
`/etc/watchman.json` config.)
You might also need to stop Zsh from imposing a delay with:
KEYTIMEOUT=1
And ditto for tmux:
set -s escape-time 0
But neither of those was necessary for me.
So, fix the delay by setting up a function-key binding, and while we're
at it, reduce the `'ttimeoutlen'` from 50 to 10ms, as it's 2016 and
"10ms should be enough for anybody" (ie. almost an entire frame of
16.67ms at 60fps).
Greg Hurrell [Tue, 11 Oct 2016 02:01:54 +0000 (19:01 -0700)]
Merge branch 'pull/17'
Closes: https://github.com/wincent/terminus/pull/17
* pull/17:
doc: add Jon Parise to the AUTHORS section in the docs
Typo fix: 'typemouse' -> 'ttymouse'
Prefer 1337 iTerm escape sequences over deprecated 50 sequences
Noticed while perusing the iTerm docs the other day that the \e]50 escape
sequences are deprecated because of a clash with Xterm, so let's use the newer
1337 sequences when they are available.
Greg Hurrell [Sun, 27 Dec 2015 08:28:24 +0000 (09:28 +0100)]
Silence annoying "No matching autocommands" output
Not sure if there was ever a good reason for this not to be `silent`, as
all the other instances of `:doautocmd` were, but this seems a harmless
fix, and it addresses an annoying issue.
This flaw originally came into my dotfiles repo in:
Greg Hurrell [Thu, 22 Oct 2015 13:57:30 +0000 (06:57 -0700)]
doc: Qualify statement about Terminal.app support
I haven't used Terminal.app in El Capitan, so I have no idea if any of
this has changed, or will change in the future. Let's weaken the
strength of the claim a little bit accordingly.
Greg Hurrell [Thu, 15 Oct 2015 01:18:50 +0000 (18:18 -0700)]
Accept tmux TERM as synonym for screen
Just moved to the `master` branch (pre-2.1) of the tmux repo, and saw
that it is now recommending[1] people set up a `tmux` terminfo entry if
they want to enjoy italics support (and of course, I do).
So, this commit replaces the `s:screen` variable with `s:screenish`, and
it will be true for either screen or tmux.
Joe Lencioni [Sat, 26 Sep 2015 12:34:19 +0000 (05:34 -0700)]
Guard against "Unknown option: t_SR" for older Vim
After updating from 928b3bfb to 10564cb4 I started getting the following
error when starting Vim:
> Error detected while processing
> /path/to/.vim/bundle/terminus/plugin/terminus.vim:
> line 58:
> E355: Unknown option: t_SR
It appears that the t_SR reference was added by 640509f8.
I was running an old version of Vim for some reason (7.4.488) and
upgrading (to 7.4.873) made this message disappear. It looks like `t_SR`
was added in patch 687 [0], so we can be more hospitable to people who
aren't on the latest by adding a guard for this patch.
Try to make things a little clearer with respect to support for the
different kinds of terminals. I don't want to entirely purge the docs of
all references to iTerm (because that's still my principal test
environment), but I do want it to be clear that you don't have to use
iTerm.
Note that there is one place here where I am simplifying things in the
name of readability, while sacrificing a little bit of precision:
namely, I talk about cursor shape values getting passed through as-is to
iTerm and Konsole, and don't mention the re-mapping that occurs for the
benefit of VTE terminals. If this ever ends up confusing anybody, I'll
amend it.
Note that this PR sets up the `t_{EI,SI,SR}` variables unconditionally,
even when not running inside iTerm. I think this should be ok (tested in
a non-iTerm, non-VTE terminal ie. Apple Terminal.app).
Originally submitted at: https://github.com/wincent/terminus/pull/8
* pull/8:
doc: mention VTE terminals in HISTORY section
Prefer single quotes
Rename s:replace to s:start_replace for consistency
Use consistent `let` styling
doc: further flesh out docs for TerminusReplaceCursorShape
Add support for terminals with VTE support
Add documentation of replace cursor shape
Originally submitted at: https://github.com/wincent/terminus/pull/7
* pull/7:
doc: Further note Konsole support
doc: Update AUTHORS and HISTORY sections for pull #7
Sort exists() checks
Break up a long line
Add support for KDE Konsole
There are a lot of potentially confusing references to iTerm in here
now (confusing because we effectively treat Konsole as equivalent to
iTerm). I'll clean those up in a future commit once the other in-flight
PR has landed.
git.wincent.com / terminus.git / log
