JNRowe

chubot has written an interesting document¹ exploring more of the nuance with test/[/[[, and many of the other entries in that blog have intriguing explanations of the oddities of our shells(a random example²).

¹ https://www.oilshell.org/blog/2017/08/31.html

² https://www.oilshell.org/blog/2016/11/18.html

There is JSON Feed¹ already. One of the spec writers is behind https://micro.blog, which is the first place I saw it(and also one of the few places I've seen it). I don't think it is a bad idea, and it doesn't take all that long to implement it given the sane and quite readable specification.

I have long hoped it would pick up steam with the JSON-ify everything crowd, just so I'd never see a non-Atom feed again. We perhaps wouldn't need sooo much of the magic that is wrapped up in packages like feedparser² to deal with all the brokeness of RSS in the wild then.

¹ https://www.jsonfeed.org/

² https://github.com/kurtmckee/feedparser

An excerpt from the FAQ¹:

    "Please don't post job ads as submissions to HN."

¹ https://news.ycombinator.com/newsfaq.html

This was discussed a couple of years ago with lots of comments¹. I'm unsure how much has changed in the meantime, as the top couple of pages of commits on GH are upstream emacs changes. Would make me happy to see it progressing though, as(like with neovim) the tugs in different directions allows things to be tested out that might not make it past the original mail to a developer list in the upstream projects.

Edit: I decided to have a quick poke around, and there are ~40 non-upstream commits this year. About half of those are minor cleanups and cargo dependency updates.

¹ https://news.ycombinator.com/item?id=26453174

If you're looking for a general solution to that specific type of problem, then dateutils¹ is really useful. It deals with conversions, durations, matching, repeats, etc. It also has a clear and well defined date input format, and being a collection of command line tools it is easy to mangle it in to other tools.

¹ http://www.fresse.org/dateutils

I've mentioned this in previous posts here, but I write zsh scripts utilising all the extras that zsh gives(alternate form syntax, extensive extended globbing, zsh module support for extra functionality). It sounds stupid but it makes it really obvious that what you're writing isn't a generic shell script, and you can forgo having to think too much about whether something will work in modern bash, or MacOS pre-GPL3 bash, or {b,d,k,z}ash as /bin/sh symlink.

I definitely get the argument about shellcheck though, it would be nice if it supported zsh.

In that fun way that shells are, for bare redirection it depends.

In bash/ksh, it matches frou_dh's explanation. In zsh, it depends on how you've set the various *NULLCMD options and parameters. In csh, it is an error.

Even in zsh, when configured to behave like `cat file` it still doesn't quite do that as it won't concatenate files as it only passes the first shell word following the `<` to `cat`(or whatever you've set NULLCMD to). Guess that means you could be evil by making a wrapper that allows weird Unicode separators to pass multiple files in one word to get the concatenation back ;)

Yeah, you could use that as in "sqlite3 t.db 'SELECT format(…) FROM pragma_…' .dump" to create a file that sets application_id/$others and then dumps the tables, which would make restoration from the dump file work in more cases.

It is just another thing to be aware of if you're trying to store your database in your git repository with a filter, and want it to roundtrip correctly.

The argument people often make is that it was iconic in earlier revisions, but has become more difficult as the network has been extended¹. If you look at the historical versions², there definitely feels to me like there is a tipping point where it became more challenging to scan.

I believe there is a genuine beauty when you're in the network and have the lovely design on shorter sections(Olympia branch on Piccadilly/District springs to mind), or the simplistic single line vertical maps on the entrance to individual lines.

Having helped tourists navigate the hotspots it becomes clear that the people most in need of a map often aren't helped by the current complexity in parts. Renaming stations might be a nice idea too. Imagine hearing the Covent Garden message if you're a foreign tourist, or British but new to the word alight ;)

¹ https://londonist.com/2016/05/the-history-of-the-tube-map

² https://www.tube-history.uk/tube-maps.php

Not as far as I'm aware. You can query much of that stuff using the CLI with the .dbinfo command, but support for that appears to be dependent on build options so may not be available. Another option might be to provide multiple commands("sqlite my.db 'PRAGMA user_version' .dump"), but you'd have to remember to update scripts if you suddenly started using other things in your app too.

I'll note that the metadata is handled correctly by the CLI's .backup command or you can "VACUUM INTO <somewhere>"¹, so if you're just attempting to use .dump for the sake of backup there are probably better options available anyway.

But yeah, I was surprised when I chased down a bug that was caused by a missing application_id following a restore from .dump output. I did a search at the time and noticed it had been reported to the sqlite folks on their forums a few times, so presumably I'm missing the reasoning behind not including it.

¹ https://www.sqlite.org/lang_vacuum.html

Fellow shell trivia enthusiast, hi!

    $ bash -c 'realpath /dev/stdin <<< small'
    /proc/79631/fd/pipe:[5282632]
    $ bash -c 'realpath /dev/stdin <<< $(printf "%65536s")'
    /tmp/sh-thd.yZ2L6p (deleted)

You can see the cutover on buffer size from my install of bash 5.2.15. Anything under 64k of here-string will still use a pipe.

In case you weren't aware, you can also force a "real" file with zsh process substitution by using =(…)¹. It can be useful when the tool you're using doesn't behave correctly with <(…), if it wishes to seek across it for example. Sadly, =(…) isn't supported in bash [yet?].

¹ In your case it still wouldn't hit a disk as it is in /tmp, but it at least becomes seekable.

There is another difference that users may care about here. zsh will create a temp file for each here-string in the here-string version, and bash may do too¹. Whether those files hit a disk is a matter of system configuration, and whether such a disk is magically quick or swirling rust is a different issue too.

[Just noting that the implementation here isn't equivalent for nerdsnipe-ery, not arguing for real attempts at optimisation of simple pipelines.]

¹ Always with older versions, only for large strings with newer versions.

You have to be careful with this, as using .dump as your filter will not necessarily get you an equivalent database on restore. For example, .dump will not include database metadata such as application_id¹ or user_version²(perhaps other things too but these are the ones that have bitten me before).

The custom diff driver in the OP will not reflect changes to those values either obviously, but at least it won't lose them in the actual database file stored in the git repository.

¹ https://sqlite.org/pragma.html#pragma_application_id

² https://sqlite.org/pragma.html#pragma_user_version

Oops, poorly worded and using internal terminology. I'll try again ;)

We use some internal tooling to make things work, but the concepts are generic git and $forge.

Push a comment: I'll make a hand-wavy suggested edit, then a vim mapping basically performs a ":`<,`>w !curl". If you only used GitHub, then piping to something like "gh pr comment"¹ could perform a similar-ish role(albeit a little weaker).

Pull comments: We automate merges so that PR text(including replies) are available in the repo. For the general discussion they're attached as notes², and for code comments(including --fixup commits) they're processed to assign the correct attribution via trailers³ to the original commit at merge time. Most of the attribution functionality could be re-implemented with "git rebase --autosquash" and by providing a "git interpret-trailers" wrapper as $EDITOR.

¹ https://cli.github.com/

² https://git-scm.com/docs/git-notes

³ https://git-scm.com/docs/git-interpret-trailers

The Wikipedia page may be a more accessible summary¹.

¹ https://en.wikipedia.org/wiki/FOAF

That kinda feels like how I review with vim.

* A little scripting around opening the PR, which basically performs a "vimdiff <(git show baseref:file) file"-style dance on the changes(see :h diff). Using vim's tabs is great for this as they're really only views, so you can hold individual buffers open in distinct states at the same time.

* Scroll locking still works as expected in the main view, but you can avoid it in a separate tab when needed.

* [c and ]c move between hunks from the set of changes as they exist in the PR not in the working directory.

* dp and dg allow you to mark hunks as "done" by pushing/pulling the hunk in to the read-only diff buffer so that they're now hidden from the highlighted changes in the live buffer.

* Changes you make in the live buffer are available to commit directly, or push as a comment.

* All your regular editor things work as expected in the current state of the tree; go to definition, build integration, popup docs, etc.

Working like this means you're viewing changes against the PR's base, but have a clean working directory. That, to me, feels like a significant improvement over matklad's solution of having the working directory be in an unclean state to view the changes.

The environment I work in makes this behaviour super nice as changes will often be added with a --fixup commit, and then the tooling mangles them back together with a git-interpret-trailers call to attribute the fixup commit's author to the original commit at merge time. It also pulls text comments out of the PR and attaches a Reviewed-by trailer where appropriate, or the +1 equivalent to tack an Acked-by trailer on.

The beauty of that feature is the system to implement it - extfs(EXTernal virtual File System) - is built with simple scripts, so you can add your own little tools to make other things navigable beyond the ~40 that come bundled.

There is a simple introduction in /usr/lib/mc/extfs.d/README, or https://github.com/MidnightCommander/mc/blob/master/src/vfs/... .

Some comments on the TC write up¹ a few days ago².

¹ https://techcrunch.com/2023/09/21/oh-gitness-harness-launche...

² https://news.ycombinator.com/item?id=37598082

I'm a big fan of moonscript, but occasionally wish it was still being improved and worked on. Yuescript¹ looks like it fixes most of my bugbears with moonscript, and is for the most part a faster² drop-in replacement.

There was s little discussion here ~18 months ago³, but it will feel largely circular if you look at it as people are suggesting fennel there ;)

¹ https://github.com/pigpigyyy/Yuescript

² This probably only matters if you have tonnes of moonscript, not just a little neovim/mpv/awesomewm config or something.

³ https://news.ycombinator.com/item?id=29903133

A link to that discussion for those of us who missed it - https://news.ycombinator.com/item?id=37385716

A much less thorough round-up of 29.1 was discussed here a little while ago¹, with many of great comments².

¹ https://emacsredux.com/blog/2023/07/30/emacs-29-1-released/

² https://news.ycombinator.com/item?id=36929514

Full agreement, and with the addition of xpk¹/xfd² as natural extensions to that extensibility too. I see things like xfd supporting xz¹, and I'm simultaneously amazed that it exists and happy that I don't need to do xz {,de}compression on 68k ;)

I guess we have the essence of something similar-ish with libarchive⁴, but nobody(including me) has pushed the extra mile to get file dialogs to support random compression and decompression formats.

Beyond OT: I didn't realise how much stuff was still going on at aminet, but I love love LOVE that people are still dropping new car sets for Geoff Crammond's F1GP.

¹ http://aminet.net/package/util/pack/xpk_User

² http://aminet.net/package/util/pack/xfdmaster

³ http://aminet.net/package/util/pack/xfd_lzma.lha

⁴ https://www.libarchive.org/

mupdf is the mupdf of epub; it supports epub and other formats beyond pdf¹. When I've had really large files I've used mupdf to read them a few times, as it seems to be far better at handling them than other tools.

¹ https://mupdf.com/

Hmm, that is odd about fbreader. I have the Debian package¹ installed that is Open Source², but looks like recent versions are no longer Open Source. Hadn't noticed that before.

Might also argue that nov.el³ is high quality and cross platform, but I'm not sure my definition of cross platform would necessarily align with other peoples ;)

¹ https://packages.debian.org/trixie/fbreader

² https://metadata.ftp-master.debian.org/changelogs//main/f/fb...

³ https://depp.brause.cc/nov.el

I think https://news.ycombinator.com/item?id=23660910 may be a trap street^wlink to see who is watching :)

Bash has a range of modifiers for history expansion. You can "cd !$:t" to execute "cd <final argument of last command, basename only>" for your git example. zsh, somewhat predictably, has a superset of bash's modifiers so it works there too.

That is the difference between the up-line-or-history and up-line-or-search functions that I linked above. The default Up binding is the -history function, whereas the -search function in unbound by default. There are pattern variants too, if you don't like the prefix only checks.

If you also need to mimic the fish behaviour of C-r mid-command because your suggestion wasn't correct, then that does need a custom function to bind to C-r as you have to provide ${L,}BUFFER to populate the search pattern like fish does.

I'm unsure what specific behaviour you want from zsh and the up key, but it provides more than one up-line-*¹² function out of the box. Also, you can add any behaviour you wish with a custom zle function. That said, I understand some people prefer to just use something with the default settings.

¹ https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html#...

² https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html#...

That is a recent(-ish) addition¹, arriving in 3.1. Your interpretation of recent may be a different length to mine, but one Debian release in this instance ;)

¹ https://github.com/fish-shell/fish-shell/pull/6140

I did jury duty at the Crown Court a few years ago, and met a Debian maintainer and MSR researcher over the course of a week. And far more oddly, I met a friend of one of the Dasher developers who saw me using it to reply to some mail because my keyboard had broken.

In a jury lounge with around fifty randomly selected strangers this doesn't seem probable, and I can't imagine a similar outcome if I'd been at Bedford(which I think is the next closest crown court).

I'm more accepting of bumping in to fellow travellers at the curry house or pub, because we're choosing to go where others suggest. Still, Cambridge is joyously weird.

Note to self: Probably should have used the jury duty downtime to meet some interesting "normal" people though.