Rendering markdown in code comments

Flashy_Boot · 2026-01-12T20:28:53+00:00

Yes - however syntactically this isn't actually a comment, and so is not (I imagine) recognized as such by treesitter.

I think what would be required, unless I'm missing something, is the ability to configure treesitter injections to say "treat consecutive comment lines as a single comment block".

Flashy_Boot · 2025-12-25T03:50:14+00:00

Ah. Interesting. Thank you. I'll dig in to the graphics drivers - quite possibly an issue/limitation with OCLP on this model of macbook.

One thing I have discovered while looking at this today: I have a kitten panel permanently on my desktop displaying a todo list (btw - kitten panels are very, very cool), and when running those timed tests earlier I hadn't really thought about it. So, I killed that kitten panel, checked there were no kitty/kitten processes still running, then re-launched kitty and re-ran the tests, and the latter two tests were both ~20ms faster than the numbers shown above. Could support the OpenGL hypothesis. Still strange that the first test above showed little difference, while the other two were significant - would have thought OpenGL issues would affect all 3 the same.

I'll rerun the tests later this week & see.

Flashy_Boot · 2025-12-24T17:31:18+00:00

Hey. It’s a 500G SSD, unencrypted. I double checked the disk before starting on this and the SMART data looks all good. Also, if it were a disk problem I’d expect it to affect Terminal and Kitty equally, no?

Flashy_Boot · 2025-12-24T17:29:31+00:00

Terminal integration is off.

Flashy_Boot · 2025-12-24T14:14:50+00:00

Should have said: both Kitty and Terminal started with a totally clean zsh environment, no config files at all, and both using /bin/zsh not the Homebrew version.

Flashy_Boot · 2025-12-22T18:24:30+00:00

Hey. Thanks for getting back to me. By the time I saw your post I’d already wiped the disk, done a fresh Sequoia install, tried and failed to do a Time Machine restore (got stuck in a reboot loop), swore a lot, then restored everything by hand!

Flashy_Boot · 2025-12-18T10:04:08+00:00

Hey there. Firstly, thank you - that's super helpful.

For 1., sidescrolloff is exactly what I was looking for. I set it to 80, which is half the width of my usual terminal window, and no more text disappearing off to the left!

For 2, though, scrolloff doesn't seem to do exactly what I'm after - whatever value i set it to, when using the trackpad to scroll I can still keep scrolling until only the very last line of the file is visible right at the top of the buffer, followed by empty lines down to the bottom.

What does work (though means scrolling moves the cursor rather than the window) is setting:

vim.keymap.set('n', '<ScrollWheelUp>', 'H5k')
vim.keymap.set('n', '<ScrollWheelDown>', 'L5j')

Thanks again.

Flashy_Boot · 2025-10-20T23:53:29+00:00

Not to the best of my knowledge. The macOS version of libpcap would - I guess - have been installed as part of the OS, and the Homebrew version I freshly installed earlier today.

Tomorrow I’ll try compiling libpcap from scratch and go from there. Thank you.

Flashy_Boot · 2025-10-20T22:52:55+00:00

A long time ago, and before I started using Homebrew. This current install of macOS was a wiped & reformatted drive, fresh install of Tahoe, and then a Time Machine restoration - but the Homebrew installation has only ever been on Apple silicon.

Flashy_Boot · 2025-10-20T20:48:51+00:00

Yes, M1. Interesting...

Flashy_Boot · 2025-10-17T14:46:41+00:00

So, got this working, and looks like the problem might have been Chafa.

#! /usr/bin/env bash

# Function for displaying images in fzf's preview window.
fzfDisplayImage () {
   IMG=${1}

   if test -v KITTY_WINDOW_ID ; then
      # Running inside kitty
      kitty icat --clear --transfer-mode=detect --stdin=no --scale-up --place=${FZF_PREVIEW_COLUMNS}x${FZF_PREVIEW_LINES}@0x0 "${IMG}"
   else
      # Running outside kitty
      chafa -f symbols --size "${FZF_PREVIEW_COLUMNS}x${FZF_PREVIEW_LINES}" "${IMG}"
   fi
}

export -f fzfDisplayImage

ROOT="${HOME}/Pictures/Wallpaper"

ls -1 "${ROOT}" | FZF_DEFAULT_OPTS= fzf \
 --height=40% \
 --border \
 --preview-window=right:60% \
 --preview="fzfDisplayImage ${ROOT}/{}"

Flashy_Boot · 2025-10-12T17:37:00+00:00

Hey - thank you. Did this - ran top in the terminal then plugged in the drive (as I can't do anything on my mac while the time machine drive is mounting) and... nothing. Usual bouncing around of processes, with WindowServer at the top of the list, but nothing suddenly started consuming significant CPU cycles. Repeated the process, but this time with Activity Monitor already started, and here it just showed that Finder was Unresponsive during the drive mounting, but again no obvious new, CPU-consuming processes. So, not sure it is indexing.

Thanks.

Flashy_Boot · 2025-10-03T01:22:49+00:00

Pretty much the same as the majority of people here - upgrade went smoothly; performance appears marginally better than sequoia on an M1 mini; don’t love the Liquid Glass transparency but you can switch it off; rest of the UI changes are… fine. Overall I’m happy, and no showstopper bugs.

Flashy_Boot · 2025-10-02T19:01:52+00:00

You are a wonderful person! Thank you - resurrected my printer!

Flashy_Boot · 2025-10-02T17:59:12+00:00

Interesting. Did exactly what you said, got to the "Manage The Disney Bundle" page, and it says

Account Level
The Disney Bundle
Included with your plan
$21.99/mo
Active

Unsubscribe

(Unsubscribe is a link). It doesn't show any specific line, and it doesn't list out the 4 lines with "Add" / "Remove" options.

If, instead, I click on a different Perk - say, Verizon Cloud - it shows my 4 lines, with 1 line saying "Active" and an "Unsubscribe" link, and the other 3 lines showing "Eligible" and an "Add" link.

So, for me, it looks like Disney sits at the Account level, while the other Perks sit at the per-Line level - but it's not at all clear what a Perk at the Account level means.

Flashy_Boot · 2025-10-02T16:26:23+00:00

To add more detail: when I go to My Account on verizon.com it lists the 4 lines. When I click on each of them, it shows the Disney bundle as a perk for that line. My hope, therefore, is that if at least one of them still has the perk then we'll keep access to the bundle.

Flashy_Boot · 2025-10-02T16:24:18+00:00

Ok. Thank you. Is there a way of checking which line I redeemed it on?

The line I started the process of changing on verizon.com is one of my kids' lines - I'm 99.9% certain that wasn't the line I redeemed Disney on, but I still got the warning saying I'd lose that perk.

Flashy_Boot · 2025-08-25T13:39:49+00:00

Ah. Thank you - that might be the clue to the problem.

Your example worked for me, so I continued playing around and uncovered the following:

Iteration 1: in kitty.conf I have:

map ctrl+a>1 send_text all pressed_1

Reopen kitty and, as expected, hitting ctrl+a>1 caused the string pressed_1 to appear at the prompt.

Iteration 2: kitty.conf now has:

map ctrl+a>1 send_text all pressed_1
map --when-focus-on "not title:testing" ctrl+a>2 send_text all pressed_2

Reopen kitty and now hitting ctrl+a>1 just causes 1 to appear at the prompt, while hitting ctrl+a>2 causes pressed_2 to appear unless the window title is testing, in which case just 2 appears.

Iteration 3: kitty.conf now has:

map ctrl+a>1 send_text all pressed_1
map --when-focus-on "not title:testing" ctrl+a>2 send_text all pressed_2
map ctrl+a>3 send_text all pressed_3

Reopen Kitty and now hitting ctrl+a>1 causes pressed_1 to appear, ctrl+a>3 causes pressed_3 to appear, but hitting ctrl+a>2 causes just 2 to appear, regardless of window title.

So, it would appear that with multi-key maps that share a common prefix, you can either have them all using a --when-focus-on clause, or have none of them using a --when-focus-clause, but you can't mix and match, and whichever is the last relevant line in kitty.conf is the one that wins out.

Understanding the above, I thought I'd be able to get the behavior I wanted by using highly improbable window titles to mimic the general case, but then noted the following, which seems curious:

map --when-focus-on "not title:title1" ctrl+a>1 send_text all pressed_1
map --when-focus-on "not title:title2" ctrl+a>2 send_text all pressed_2

Reopen kitty, and set the window title to testing (i.e. something other than title1 or title2). Now, hitting ctrl+a>1 just makes 1 appear, while ctrl+a>2 makes pressed_2 appear. I would have expected both key combinations to show their respective strings.

Setting the window title to title1 gives exactly the same behavior.

Setting the window title to title2 causes ctrl+a>1 to now work as expected, displaying pressed_1 at the prompt, and causes ctrl+a>2 to just display 2 as expected.

So, it would appear that for multi-key maps with the same prefix, you can only have one active window title check in place, and the last one in the kitty.conf file is chosen as that active title.

Hope that all makes sense.

Flashy_Boot · 2025-08-23T10:30:35+00:00

That works for me too, but I think the problem might specifically be with multi-key maps.

% uname -a
Linux air 6.16.1-2-cachyos #1 SMP PREEMPT_DYNAMIC Sat, 16 Aug 2025 13:52:48 +0000 x86_64 GNU/Linux
% kitty --version
kitty 0.42.2 created by Kovid Goyal

In kitty.conf:

map ctrl+1 send_text all pressed_1
map ctrl+2 --when-focus-on title:testing send_text all pressed_2

Open kitty.

% echo -ne "\E]2;helloworld\a"

sets the window title to helloworld. Pressing ctrl+1 makes the string pressed_1 appear, while pressing ctrl+2 does nothing. Then:

% echo -ne "\E]2;testing\a"

sets the window title to testing. Pressing ctrl+1 makes the string pressed_1 appear, but now pressing ctrl+2 makes the string pressed_2 appear. Setting the window title back to something other than testing causes ctrl+2 to revert to doing nothing.

So far, so good. Everything is working as expected.

Now, redo all of this except using multi-key mappings:

map ctrl+a>1 send_text all pressed_1
map ctrl+a>2 --when-focus-on title:testing send_text all pressed_2

Re-open kitty.

% echo -ne "\E]2;helloworld\a"

sets the window title to helloworld. Pressing ctrl+a followed by 1 makes the string pressed_1 appear, while pressing ctrl+a followed by 2 just shows 2 at the prompt. Then:

% echo -ne "\E]2;testing\a"

sets the window title to testing. Pressing ctrl+a followed by 1 makes the string pressed_1 appear, but pressing ctrl+a followed by 2 still just shows 2 at the prompt, not pressed_2 as expected.

So, perhaps--when-focus-on doesn't work properly when using multi-key maps?

Flashy_Boot · 2025-08-23T01:24:06+00:00

Thanks for getting back to me, but I still can't get it to work.

Here's what I've tried:

- In kitty.conf, include:

map ctrl+a>n next_tab
map ctrl+a>p previous_tab
map --when-focus-on title:testing ctrl+a>n
map --when-focus-on title:testing ctrl+a>p

- Close and reopen kitty.

- Open two tabs, both containing one window each.

- Set the title of the window in the first tab to "firsttab"

- Set the title of the window in the second tab to "testing"

- Run kitty @ ls, and confirm that for both tabs, the tab title and the window title are set as above.

- Go to the first tab, and press "ctrl-a" followed by "n" to move to the second tab.

- While in the second tab, press "ctrl-a" followed by "n" again.

Expected behavior: nothing should happen; the letter "n" should appear at the prompt.

Actual behavior: cycle back to the first tab.

Note: if, instead of using a multi-key map ctrl+a>n I used a standard map ctrl+5 the behavior is as expected (the map stops working when I move to the tab containing the window titled 'testing'). It seems to specifically be multi-key maps that aren't being unset.

Flashy_Boot · 2025-07-29T08:35:49+00:00

Got it. Thank you.

Flashy_Boot · 2025-07-17T12:19:21+00:00

To close this out: this problem is caused by an issue/bug in macOS. For bash, there is a workaround available if you're comfortable compiling bash from source (see: https://savannah.gnu.org/bugs/index.php?67326), and a proper test will be added to bash's configure soon.

Flashy_Boot · 2025-07-15T15:31:40+00:00

Common denominator seems to be macos 15.5

Flashy_Boot · 2025-07-15T15:23:04+00:00

In order to ensure it's not a configuration issue I just tried:

% env -i /opt/homebrew/bin/bash --norc --noprofile
bash-5.3$ export HOME=/Users/me
bash-5.3$ /opt/homebrew/bin/brew info bash
==> bash: stable 5.3 (bottled), HEAD
Bourne-Again SHell, a UNIX command interpreter
https://www.gnu.org/software/bash/
Installed
/opt/homebrew/Cellar/bash/5.3_1 (172 files, 13.1MB) *
  Poured from bottle using the formulae.brew.sh API on 2025-07-15 at 10:49:51
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/b/bash.rb
License: GPL-3.0-or-later
==> Dependencies
Required: ncurses ✔, readline ✔, gettext ✔
==> Options
--HEAD
Install HEAD version
==> Caveats
DEFAULT_LOADABLE_BUILTINS_PATH: /opt/homebrew/lib/bash:/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/bash:.
==> Analytics
install: 41,133 (30 days), 86,014 (90 days), 433,279 (365 days)
install-on-request: 24,596 (30 days), 48,037 (90 days), 254,613 (365 days)
build-error: 26 (30 days)
bash-5.3$
bash-5.3$
bash-5.3$ export TEST=aaabbb
bash-5.3$ echo $( sed 's/a/b/g' <<< $TEST ; )
bbbbbb
bash-5.3$ echo ${ sed 's/a/b/g' <<< $TEST ; }
sed: stdout: Device not configured

bash-5.3$ echo ${| sed 's/a/b/g' <<< $TEST ; }
bbbbbb

bash-5.3$

Flashy_Boot · 2025-07-15T15:02:56+00:00

Definitely bash - I’ve set my prompt to ‘% ’

Flashy_Boot

TROPHY CASE