Claude Code's fullscreen TUI turns on full mouse tracking (normal, button-event,
any-motion and SGR), so Wezterm forwards every drag straight to the app and never
builds a selection of its own. You can get selection back by holding shift, which
is the default of bypass_mouse_reporting_modifiers, but then shift is spent:
while it's the bypass Wezterm handles the event itself, and the docs are explicit
that the event is "prevented from being passed to the application" and gets
treated as though shift was never pressed, so clicks in the TUI have nowhere to
go.
The keyboard half of this runs on the kitty keyboard protocol, which is what lets the TUI tell shift+enter from a plain enter and read modifier combinations a terminal wouldn't normally pass through. It's the same bargain as the mouse tracking: the terminal hands its input over to the app, keys and mouse both, so the defaults you lean on in an ordinary pane go quiet while you're in there.
Drop this into your ~/.wezterm.lua:
-- Keep SHIFT off the bypass so shift+click still reaches apps that grab the
-- mouse. Claude Code masks the modifier bits off the button byte, so it arrives
-- there as a plain click.
config.bypass_mouse_reporting_modifiers = "CTRL|ALT"
config.mouse_bindings = {
-- A mouse binding is only considered when the pane's mouse reporting state
-- matches, so ordinary bindings go dead inside an app that grabs the mouse.
-- These claim the left button back for selection while it does.
{
event = { Down = { streak = 1, button = "Left" } },
mods = "NONE",
mouse_reporting = true,
action = wezterm.action.SelectTextAtMouseCursor("Cell"),
},
{
event = { Drag = { streak = 1, button = "Left" } },
mods = "NONE",
mouse_reporting = true,
action = wezterm.action.ExtendSelectionToMouseCursor("Cell"),
},
{
event = { Down = { streak = 2, button = "Left" } },
mods = "NONE",
mouse_reporting = true,
action = wezterm.action.SelectTextAtMouseCursor("Word"),
},
{
event = { Drag = { streak = 2, button = "Left" } },
mods = "NONE",
mouse_reporting = true,
action = wezterm.action.ExtendSelectionToMouseCursor("Word"),
},
{
event = { Down = { streak = 3, button = "Left" } },
mods = "NONE",
mouse_reporting = true,
action = wezterm.action.SelectTextAtMouseCursor("Line"),
},
{
event = { Drag = { streak = 3, button = "Left" } },
mods = "NONE",
mouse_reporting = true,
action = wezterm.action.ExtendSelectionToMouseCursor("Line"),
},
{
event = { Up = { streak = 1, button = "Left" } },
mods = "NONE",
mouse_reporting = true,
action = wezterm.action.CompleteSelection("ClipboardAndPrimarySelection"),
},
{
event = { Up = { streak = 2, button = "Left" } },
mods = "NONE",
mouse_reporting = true,
action = wezterm.action.CompleteSelection("ClipboardAndPrimarySelection"),
},
{
event = { Up = { streak = 3, button = "Left" } },
mods = "NONE",
mouse_reporting = true,
action = wezterm.action.CompleteSelection("ClipboardAndPrimarySelection"),
},
-- CTRL+click to open a link needs claiming back as well, otherwise it reaches
-- the app as an ordinary click. Down and Drag go to Nop so the press, and any
-- wobble before the release, don't get through either.
{
event = { Down = { streak = 1, button = "Left" } },
mods = "CTRL",
mouse_reporting = true,
action = wezterm.action.Nop,
},
{
event = { Drag = { streak = 1, button = "Left" } },
mods = "CTRL",
mouse_reporting = true,
action = wezterm.action.Nop,
},
{
event = { Up = { streak = 1, button = "Left" } },
mods = "CTRL",
mouse_reporting = true,
action = wezterm.action.OpenLinkAtMouseCursor,
},
}If you already have a mouse_bindings table, add these entries to it rather than
replacing it. Setting mouse_bindings at all does not remove Wezterm's defaults,
your entries are merged over the top of them, so the bindings for panes that
aren't grabbing the mouse carry on working.
CompleteSelection puts it on the clipboard on release. ctrl+shift+c copies too, that's a Wezterm default.Every modifier combination works this way, so anything you rely on in a normal
pane needs an entry with mouse_reporting = true or it falls through to the app.
Bind the Down and Drag events alongside the Up one when you do, since a
matched binding is what stops Wezterm forwarding the event, and a click that
drifts a pixel between press and release sends motion events too.
The streak numbers are why there are quite so many entries in there. A double
click, per the docs, is a down-up-down sequence, so the gesture runs Down
streak 1, Up streak 1, then Down streak 2 (that last one is what selects the
word), and after it a Drag streak 2 for every movement. Leave that Drag entry
out and the word selects fine but dragging to extend it does nothing at all,
which is exactly the bug I had. Same again at streak 3 for lines. The Up streak
2 and 3 entries are in there so the release that ends those gestures doesn't get
forwarded to the app on its own, with no press in front of it.
Wezterm sends the real modifier state in the SGR report, and Claude Code masks
the modifier bits off the button byte (button & 3) before it decides which
button you pressed. A shift+left press is button 4, and 4 & 3 is 0, so it lands
as a plain left click. This is an implementation detail of the TUI (read out of
2.1.220), so it could change.
The cost is that a plain left click no longer reaches the TUI, it sets Wezterm's selection anchor instead. Everything else, wheel included, still goes to the app.
Middle click and the ALT block-select are both still unclaimed here, so inside the TUI they fall through. Middle click reads as a paste over there, since the same handler treats buttons 1 and 2 specially. The rule above applies if you'd rather have either of them back: give each one its own entry.
wezterm show-keys prints the resolved tables. The one you care about is
Mouse: mouse_reporting + alt_screen, which is the state a fullscreen TUI puts
the pane in:
Mouse: mouse_reporting + alt_screen
-----------------------------------
Down { streak: 1, button: Left } -> SelectTextAtMouseCursor(Cell)
Down { streak: 2, button: Left } -> SelectTextAtMouseCursor(Word)
Down { streak: 3, button: Left } -> SelectTextAtMouseCursor(Line)
Drag { streak: 1, button: Left } -> ExtendSelectionToMouseCursor(Cell)
...
The mouse_reporting field on mouse bindings needs Wezterm
20220807-113146-c2fee766 or newer. I tested all of this on
20240203-110809-5046fc22 (the flatpak), against Claude Code 2.1.220.
One thing to watch on Linux: your window manager may grab ctrl+alt+click before Wezterm sees it, so pick a different bypass combo if you need it and it does nothing.
CLAUDE_CODE_DISABLE_MOUSE=1 makes Claude Code emit no mouse tracking sequences
at all, so the terminal keeps the mouse and none of the above is needed. You lose
wheel scrolling in the TUI, since Wezterm maps the wheel to arrow keys in alt
screen. There's also CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1, which drops it to
normal plus SGR tracking, but reporting is still on so the terminal still won't
select for you.
ImportError: No module named 'click.repository'
It's most likely because you also have the ubuntu-sdk PPA installed, and a new version of python3-click has been pushed up that doesn't include the repository submodule that Snappy uses. I found unravelling the two project's dependencies to be non-trivial at the moment, so here's an alternative quick fix:
Run:
sudo apt purge -y python3-click
Create a new file at /etc/apt/preferences.d/snappy-ppa-1500, with these contents (telling apt that we prefer duplicate packages from the snappy-dev PPA).
Run:
sudo apt update
Run:
sudo apt install -y --force-yes snappy-tools
For the time being this should select the packages we need from the snappy-dev PPA, and giving us the right python3-click, complete with repository submodule.
The other alternative is to confine your Snappy experiments to an LXC or VM; or completely purge both PPAs and all the packages from them and reinstall just Snappy if you don't care about Ubuntu Touch or regular click package dev right now.
I'm sure the conflict will be fixed soon though. :-)
Deployments of a service have a number of different network dependencies that require verification:
Although many of these can be solved with smoke tests, it's not always immediately obvious that there is a problem, or what the problem is.
conn-check is a tool that started life inside Ubuntu One to verify connections between services and to S3 etc. post-deploy.
During a mini-sprint in Uruguay a few months ago we separated conn-check into it's own own package and open sourced it.
Since then we've been improving it and using it to verify deploys on our services (such as login.ubuntu.com).
conn-check takes a simple YAML config defining a list of checks to perform (udp, tcp, tls, http, amqp, postgres, mongodb, redis, memcache), and performs those checks asynchronously using Twisted's thread pool, and outputs the results in a Nagios check standard output, so conn-check can be run regulary as a Nagios check to continually verify network status between services (and alert on change, e.g. out of band firewall changes).
We have also released a separate package called conn-check-configs which provides tools for automatically generating conn-check YAML configs from a source such as a Django settings module or Juju environment status (we're currently using the Django settings export, with Juju env export being tested in a branch).
You can get conn-check by:
pip install conn-check
(You can sudo this to get it system installed, but personally I'd put it in a virtualenv or use pipsi.)
sudo add-apt-repository ppa:wesmason/conn-check
sudo apt-get update
sudo apt-get install conn-check
Expect to hear soon about some of the things I've been working on.
]]>If you fancy following along head on over and subscribe, or follow me on twitter where I will also post links to freshly archived mailshots.
]]>Normally this would have been the end of my quick perusal, until the next time I had reason to the use the service, but I noticed they had not only an API, but also Jabber/XMPP exposure for creating bots. Now my interest was piqued.**Looking at the existing third-party bots out there I found you had your choice of languages…as long as that choice was Ruby or Javascript. ;-)
Now I'm not averse to developing in either, but they're not my preferred languages by far (okay Javascript has a soft spot in my heart but I still haven't made the jump to server-side JS dev).
So with that I present hippybot
(Hip**chat Python Bot, geddit?)
Not to be confused with Hippy, a PHP library for the Hipchat API.
I wrote hippybot using the excellent python-jabberbot, a library that utilises the equally brilliant xmpppy to allow the creation of bots in an easy to understand and pythonic way (e.g. inherit from base class, set some connection strings, override event methods if need be, use decorators to extend commands the bot responds to).
How is this different from a regular Jabber bot? I've written some Hipchat-specific customisations into the bot:
I've added a simple plugin API to the bot, which consists of either creating a function in a module with a decorator, or a class in a module with as many decorated methods (each a different command to trigger the bot) as you like, and the ability to create aliases for commands and define whether a command is triggered by an at-sign mention or not (e.g. @hippybot do something!).
In the next release I plan to add a simple wrapper to Hipchat's API (already in master), better at-sign mention handling, and some more core plugins.
Feel free to check it out and for an example of the sorts of things you can do with a bot like this just check out some of the things Github's hubot does.
]]>
A quick recap for the uninitiated: dfs is a set of utilities for generating the mark up and Django template code to display all the fields in a Django Form, e.g. the task of displaying each input element, label text and error message is still given to Django, but we display the markup around those elements in the template itself.
The library offers a few variants on the Form.as_* methods, which will output mark up similar to those methods.
New in v1.1.0:
formscaffold), based on a script submitted by Chris Matthews.To use the new management command just add 'dfs' to your settings.INSTALLED_APPS tuple and the command will become available.
It's used like so:
./manage formscaffold my_app.forms MyCustomForm as_p
# or if using buildout
bin/django formscaffold my_app.forms MyCustomForm as_p
The above would generate the form using
tags, for the classMyCustomForm located in the module/package my_app.forms.
Please note, if your form requires any setup (e.g. values passing to the constructor or the instance) the above won't work, as it just creates a base instance from the class and passes that to the helper, you can still use dfs to do this from a Django app shell though (using ./manage.py shell).
vim & git on the command line, etc.)
I'm wondering if switching to a static file generator system like Blogofile might help me be more productive with the place, reducing my workflow on 1stvamp.org down to a vim → git problem.
]]>It makes threads of tweets, so you can send a full conversation to someone else (or include it in another tweet) to people rather than copying and pasting half a dozen different URLs for each one.
As for how my speech is going, I’ve written over half of it, but I’m now considering re-writing what I’ve got as I’m just not sure if it’s the way I want to go.
Jonty has suggested I write a bunch, plus a markov chaining tool, and generate a speech. Of course he also suggested I include lyrics from The Fresh Prince Of Bel-Air.
Whatever I come up with in the end, I’m sure it’ll be fine, as long as I thank the right people and hit the right sentiments.
"Now, this is a story all about how
My life got flipped-turned upside down
And I’d like to take a minute
Just sit right there…"
This is made possible by using the new late static binding and __callStatic magic method features. By using late static binding we can call a static method in the base ancestor class which assigns the lamba function passed in to a static hash of methods, indexed by the descendant class you called it via, using the new get_calling_class() function to get it’s class name and use that as the index.
We can use a separate hash of static methods to add static methods (which are just lambdas again) to the class by defining an extra __callStatic() magic method, that works just like the __call() method, but obviously for static calls.
test();// Should output:// default testecho ’2: ‘;$object->test(‘monkeys’);// Should output: monkeys testecho ’3: ‘;$object->test(‘chimps’);// Should output: chimps testecho ’4: ‘;$object2 = new MyOtherClass();// Should output: Instantiating “MyOtherClass”echo ’5: ‘;$object2->test();// Should output: default test2echo ’6: ‘;$object2->test(‘chimps’);// Should output: chimps test2echo ’7: ‘;$object2->test(‘conan’);// Should output: conan test2echo ’8: ‘;$object->test(‘conan’);// Should output: conan test?>
I’ve released OneVersion\DyanmicClass 1.0 out into the wild under the LGPL v2.1, so download and play at your own peril. ;-)
__call method..well, at least a hack to make something like this.
Effectively this is similar to traits/grafts, except you don’t have to define anything in a new class, you just extend the object itself when you come to use it.
You could also use a singleton within the Extensible class that keeps track of any added methods and propagates them to any other existing or new instances.
_methods, $name)) { call_user_func_array(array($this, $name), $args); } else { throw new Exception(‘Unknown dynamic method ‘ . $name . ‘ called in class ‘ . get_class($this)); } } function __set($name, $value) { if (is_callable($value)) { $this->_methods[$name] = $value; } }}class MyClass extends Extensible { function test() { echo ‘Non-dynamic method’; }}$object = new MyClass();$object->test2 = function () { echo ‘Dynamic method’;};// test() is defined within the static class definition$object->test();// test2() was created dynamically at runtime, but you call it just as// if it had been in the class definition$object->test2();?>
EDIT:
Incidentally this my first proper post sent via email. w00t.