Gemini proposed this:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -r '\{\+|\+\}' '' | str join " " | str words | length

What I ended up doing:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -a "{+" "" | str replace -a "+}" "" | str replace -a ' ' "\n" | lines | length

I notice LLMs tend to err on the side of complexity. I don’t know if this is due to their training to spit out as many tokens as possible, but using regular expressions when a simple string replacement may suffice is a good sign that they may be adding more complexity than necessary.

Gemini proposed this:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -r '\{\+|\+\}' '' | str join " " | str words | length

What I ended up doing:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -a "{+" "" | str replace -a "+}" "" | str replace -a ' ' "\n" | lines | length

I notice LLMs tend to err on the side of complexity. I don’t know if this is due to their training to spit out as many tokens as possible, but using regular expressions when a simple string replacement may suffice is a good sign that they may be adding more complexity than necessary.

Gemini proposed this:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -r '\{\+|\+\}' '' | str join " " | str words | length

What I ended up doing:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -a "{+" "" | str replace -a "+}" "" | str replace -a ' ' "\n" | lines | length

I notice LLMs tend to err on the side of complexity. I don’t know if this is due to their training to spit out as many tokens as possible, but using regular expressions when a simple string replacement may suffice is a good sign that they may be adding more complexity than necessary.

Gemini proposed this:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -r '\{\+|\+\}' '' | str join " " | str words | length

What I ended up doing:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -a "{+" "" | str replace -a "+}" "" | str replace -a ' ' "\n" | lines | length

I notice LLMs tend to err on the side of complexity. I don’t know if this is due to their training to spit out as many tokens as possible, but using regular expressions when a simple string replacement may suffice is a good sign that they may be adding more complexity than necessary.

It proposed the following:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -r '\{\+|\+\}' '' | str join " " | str words | length

However, I ended up using this simplified version:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -a "{+" "" | str replace -a "+}" "" | str replace -a ' ' "\n" | lines | length

I’ve noticed that LLMs often lean toward overly complex solutions. I’m not sure if this is due to being trained to generate as many tokens as possible, but using regular expressions where a simple string replacement would suffice is often a sign of unnecessary complexity.

Gemini proposed this:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -r '\{\+|\+\}' '' | str join " " | str words | length

What I ended up doing:

git diff --word-diff=plain -- "*.md" | rg -o '\{\+(.*?)\+\}' | str replace -a "{+" "" | str replace -a "+}" "" | str replace -a ' ' "\n" | lines | length

I notice LLMs tend to err on the side of complexity. I don’t know if this is due to their training to spit as many tokens as possible, but using regular expressions when a simple single replace may suffice is a good sign that they may be adding more complexity than necessary.

virtualenv .venv
overlay use .venv/bin/activate.nu

• Reusing good software is easy; it is what allows you to build good things quickly;
• Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down; and
• The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.

These points lead me to view software development as more of a social profession than a purely technical one. Good software is a reflection of healthy interactions within an organization. When communication is difficult, it becomes much harder to accumulate knowledge about organizational needs, manage complexity, and effectively reuse software components.

I also looked at rustmark, but configuring it simply to list Markdown files felt like too much effort.

Ultimately, I decided to use dufs and view the files as plain text. It supports basic file operations and WebDAV, which is more than sufficient for my needs.

RandomColorScheme returns the name of a random colorscheme after searching through all available paths. SetRandomColorScheme sets the colorscheme to that choice. The keybinding is mapped to <leader>uR.

function RandomColorScheme()
  local color_schemes = vim.fn.globpath(vim.o.rtp, "colors/*.vim", false, true)
  for i, fullpath in ipairs(color_schemes) do
    color_schemes[i] = fullpath:match(".*/(.*).vim$")
  end

  -- Generate a random index
  local index = math.random(#color_schemes)

  local random_color_scheme = color_schemes[index]

  vim.notify("Random Color Scheme: " .. random_color_scheme)
  -- Select a random color scheme
  return random_color_scheme
end

function SetRandomColorScheme()
  vim.cmd("colorscheme " .. RandomColorScheme())
end

vim.api.nvim_set_keymap("n", "<leader>uR", ":lua SetRandomColorScheme()<CR>", { noremap = true, silent = true })

function CreateTimestampedFile()
  local zkdir = os.getenv("HOME") .. "/github.com/iesahin/garden/zk/"
  local timestamp = os.date("%Y%m%d%H%M%S")
  local filename = zkdir .. "/" .. timestamp .. ".md"
  vim.cmd("edit " .. filename)
end

vim.api.nvim_set_keymap("n", "<leader>F", ":lua CreateTimestampedFile()<CR>", { noremap = true, silent = true })

Now, I can just hit <leader>F (which is <Space>F in my setup) and immediately start adding a note to my zettelkasten.

vim.keymap.set({ "n", "i" }, "<F2>", '<esc><esc>yy:r!<c-r>"')

I type a command, like ls, on a line and hit <F2>. That line is copied, executed, and the output is read into the buffer just below it.

I use it for all sorts of tasks, from listing open PRs with gh to fetching website text with w3m. It has significantly improved my workflow, allowing me to use the shell effectively within textual notebooks.

bind-key -n S-F12 split-window -h -c "#{pane_current_path}" "gt c"

I just hit Shift-F12, and it opens a new pane in the current directory and runs the command.

vim.keymap.set({ "n" }, "<F1>", ":Telescope buffers<CR>", { noremap = true, desc = "Find buffer" })

Note that there may be thousands of dependencies (e.g., files for a step), and creating these channels beforehand is not feasible.

The Crossbeam library has Select which allows waiting for an arbitrary number of channels. Now, I need to figure out how to structure the threads and update their states. A minor task! 😆

I noticed there is an open-source vector database called Qdrant (pronounced quadrant) that can replace it.

There are other options like pgvector for PostgreSQL.

• Although there is a common format for the manifest file, Outlook and Word add-ins seem to require separate files. I haven’t seen any add-in in AppSource that serves as both a Word and an Excel add-in.

• Microsoft provides a tool called Script Lab that allows you to run arbitrary scripts and test APIs directly within Office.

• For authentication, it is recommended to open a browser window to your web app using the Dialog API.

• It is usually not possible to use iframes to obtain authentication tokens from the task pane or sidebar itself. See this answer for more details.

• It is possible to add elements to the right-click menu in Word for add-in commands.