It took me more than 1 hour to get type hints showing as inlay using OCaml LSP server.

I also got some from this thread: https://discuss.ocaml.org/t/inlay-hints-in-neovim/16547/7.

I am using:

• neovim v0.12.0-dev
• OCaml 5.4.1
• ocamllsp 1.26.0

Here is my working Lua config:

-- LSP config with inlay hints
vim.lsp.config('ocamllsp', {
  cmd = { 'ocamllsp' },
  filetypes = { 'ocaml', 'ocaml.menhir', 'ocaml.interface', 'ocaml.ocamllex', 'reason', 'dune' },
  root_markers = { 'dune-project', 'dune-workspace', '*.opam' },
  settings = {
    extendedHover = { enable = true },
    codelens = { enable = true },
    duneDiagnostics = { enable = true },
    inlayHints = {
      enable = true,
      hintFunctionParams = true,
      hintLetBindings = true,
      hintPatternVariables = true,
    },
    syntaxDocumentation = { enable = true },
    merlinJumpCodeActions = { enable = true },
  },
})

-- Force a codelens refresh to get type signatures for top-level definitions
vim.api.nvim_create_autocmd({ 'BufEnter', 'BufWritePost', 'InsertLeave' }, {
  pattern = { '*.ml', '*.mli' },
  callback = function()
    vim.lsp.codelens.refresh({ bufnr = 0 })
  end,
})

-- Refresh the codelens when opening a file
vim.api.nvim_create_autocmd('LspAttach', {
  group = vim.api.nvim_create_augroup('OcamlCodelensOnAttach', { clear = true }),
  callback = function(args)
    local client = vim.lsp.get_client_by_id(args.data.client_id)
    if client and client.server_capabilities.codeLensProvider then
      vim.lsp.codelens.refresh({ bufnr = args.buf })
    end
  end,
})

-- Enable the LSP server and inlay hints
vim.lsp.enable('ocamllsp')
vim.lsp.inlay_hint.enable(true)

I also learned that I need to keep a running build using a dune build -w process in order to have the LSP server gather the proper type information. Without it, you may see stale type info or no types at all.

Installing a Firefox extension requires a signed build (the .xpi file), and the process to get it signed is a bit cumbersome:

• It requires a Mozilla Addons account
• Each built version needs to be uploaded/validated/signed

I’ve tried to come up with a process to build and sign the extension in a way that can be “trusted”.

What I mean by trusted is how can I make people trust that the extension I provide was built using the code publicly available in the repo.

A common concept to help with that is “build provenance”, which is basically providing trustable metadata about the process.

The SLSA (Supply-chain Levels for Software Artifacts) security framework is trying to come up with some standard about build provenance, but I looked at it mainly for inspiration.

I am using Sourcehut builds for CI, which is a joy to work with and made the process quite easy.

Here’s my version of a simplified build provenance for the web extension:

• The whole build/signing/uploading happens in a public CI build run
  • This helps prove that the extension is built with the public code for a given tag
    • Mozilla provides an API to sign extensions
  • It prints the SHA-256 hash of the signed extension after signing/before uploading
    • Artifacts are stored in a Backblaze B2 bucket
  • It uploads the metadata in a bucket along with the build artifact:
    • date
    • artifact hash
    • CI job ID
• Anyone can look at the job run and confirm it generated/uploaded this specific build
  • The bucket is public and the download page will display the metadata

This process is way better than “trust me you can download this extension that I built locally on my machine”.

I will see how I can improve it over time but I feel like this is a good start!

In bigbrowser, a navigation trail starts when a tab is opened, and ends whenever that tab is closed, tracking all transitions in between. This led to weird behavior where I would follow links within a website, and then go to a totally different website by typing it into the address bar, and it would continue the existing trail.

I am updating bigbrowser to automatically reset trails based on the transition type.

• link: clicked on a link within a page
• auto_bookmark: clicked on a bookmark
• typed: typed url in the address bar
• …

And in bigbrowser’s case, I want to try starting a new trail on typed and auto_bookmark.

This information is gathered in the extension using the webNavigation API.

Aas usual there’s browser compatibility issues:

• Firefox doesn’t expose transitiontype in oncompleted events, only in oncommitted
• Firefox doesn’t support the auto_bookmark transition at all

Excited to see how it improves the trails!

I am working on the bigbrowser documentation website, and the page has a sticky navigation bar at the top.

Everything was working well until I decided to add a basic table of content. Clicking on a section would scroll to the correct location, but the section title was hidden behind the sticky navbar.

It turns out there’s a CSS property designed to help with this use case: scroll-margin-top.

It’s mainly used for “scroll snapping” (which I’d never heard of before either). This helps implement carousel-style scrolling where content “snaps” into place (the MDN page shows an example). But since it also affects anchored links scroll positions, that’s exactly what I needed.

Here’s the fix, it can be applied to headings directly, and anchored links will magically have a 80px margin top:

#docs h2[id],
#docs h3[id] {
    scroll-margin-top: 80px;
}

I had no idea that “offsetting” the scroll was natively supported in CSS, it’s quite nice not having to resort to any hack!

While reviewing the results of the content extractor (used to power the history search engine), I ended up with CSS rules as part of the extracted text.

.css-1x8m391 { fill: rgb(7, 79, 105); } extracted content

At first, I thought that the website somehow embedded CSS style outside of regular <style> tags.

It turns out that the indexed website is using XHTML (as in <html xmlns="http://www.w3.org/1999/xhtml" lang="en">) and uses some namespaced <style> tags: <a0:style>.

This is my first time stumbling upon namespaced tags while processing HTML documents.

bigbrowser uses html5ever for content extraction and the namespace is included as part of the tag local name.

This was kind of unexpected to me, but XHTML is XML and it makes sense for a “pure” HTML parser to parse the whole tag without parsing the namespace.

As a result, I ended up using tag_name_str.ends_with(":style") to detect style tags.