Since there's no spec for global history and it's unlikely one will be introduced, the most practical solution to avoid flooding the browser history would be to debounce the changes.

This is the approach taken by Google Maps -- with maps being a well-known case where URL updates would clutter the history, as noted in the Bugzilla report.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=753264

Most browsers record every change in the global history regardless of whether `history.pushState` or `history.replaceState` is used. The HTML Spec[0] is explicit about session history but does not define how global history should behave.

I can understand why the spec makes no mention of this -- global history is a user-facing UI feature, similar to address bar autocomplete, and it makes sense for browsers to control this behavior. That said, I'm always annoyed when I look into my history tab after visiting a page like this (e.g. Vercel Domains[1]), and see my global history flooded with entries for each individual keystroke I've made, all in the name of "user experience".

In this particular case, it's just a fun gimmick, but for everyday websites I'd much prefer if they just debounced the updates to the URL to avoid cluttering the global history.

[0]: https://html.spec.whatwg.org/#navigation-and-session-history

[1]: https://vercel.com/domains

Just a small anecdote: At work, I found it frustrating not being able to quickly locate where views for Django API endpoints were, so I wrote a simple extension that took the output of django-extensions' show_urls, parsed it, and displayed a quick pick list of all API endpoints, upon which selecting an endpoint would open the file and reveal the exact line in which the view for it was defined.

Implementing this did not take much effort (in fact, TypeScript and JSDoc make everything a lot simpler as it's clear to see what each function in the API does and what arguments they accept), and now this is something I use almost every day and greatly improves my satisfaction when navigating the codebase if not my productivity in general.

I have tried looking into implementing something similar in Neovim and came across the API for telescope.nvim[2], but found it a lot less intuitive to use. I do think Vim/Neovim shines when it comes to text manipulation and extensions built around it, but when it comes to more complex UI that often deals a lot more with graphical elements (e.g. tree views, hover text, notifications), it's hard to beat VS Code.

[0]: https://code.visualstudio.com/api/references/vscode-api

[1]: https://github.com/microsoft/vscode-extension-samples

[2]: https://github.com/nvim-telescope/telescope.nvim/blob/master...

In zsh, the closest thing I've gotten to this was to bind Ctrl-\ to the `accept-and-hold` zle widget, which executes what is in the current buffer while still retaining it and the cursor position. That gets me close (no more ^P^B^B^B^B for editing), but I'd much rather see the result of the pipeline in real-time rather than having to manually hit a key whenever I want to see the result.

I just personally would feel more confident with using perl for anything to do with multi-file substitutions. In theory, ripgrep with `--passthru` and `-r` should work.

    $ rg --passthru search -r replace file.txt | sponge file.txt

    $ rg --passthru search -r replace file.txt | diff -u file.txt -

[0] https://joeyh.name/code/moreutils/

Comments URL: https://news.ycombinator.com/item?id=37991027

Points: 1

# Comments: 0

[0] https://hn.algolia.com/?q=zsh%20tricks%20you%20may%20not%20k...

Comments URL: https://news.ycombinator.com/item?id=35874136

Points: 1

# Comments: 1

It's an excellent resource for anyone curious to learn about their systems. I wish more organizations would embrace transparency and open-source principles as much as Wikimedia does.

But yes, the choice of scales for the graph was rather peculiar.

> Two of the three monkeys in the experiment generated recursive sequences more often than nonrecursive sequences ...

I'm no academic but aren't those extremely small sample sizes to make any reasonable deductions from? This looks to be even addressed in one of the papers cited...

> While a sample size of two is not enough to infer that any crow in the population may generate center-embedded recursive sequences, we present a "proof of existence" showing that this cognitive capacity is, in principle, within the reach of carrion crows.[0]

[0] https://www.science.org/doi/10.1126/sciadv.abq3356

    wget -q -O - http://kathack.com/js/kh.js http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js | xclip -sel c