---
 src/Tags.zig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/Tags.zig b/src/Tags.zig
index eb6c69e..c86d924 100644
--- a/src/Tags.zig
+++ b/src/Tags.zig
@@ -107,7 +107,7 @@ pub fn deinit(self: *Tags) void {
 /// allocates, and is slower, but is only temporary until a cross-platform "map file" function
 /// exists in the stdlib (or until someone implements it here)).
 fn mapFile(allocator: std.mem.Allocator, fname: []const u8) !?[:0]const u8 {
-    var file = try std.fs.cwd().openFile(fname, .{});
+    const file = try std.fs.cwd().openFile(fname, .{});
[message trimmed]

Fix a bug where the first commit in the log after clicking "Next" is the
same as the last commit on the previous page.
---
Rebased on master. Also slightly reworded the commit message and tweaked
the implementation from v1.

 gitsrht/blueprints/repo.py | 10 ++++++----
 gitsrht/templates/log.html |  4 ++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/gitsrht/blueprints/repo.py b/gitsrht/blueprints/repo.py
index ef379b2..f2f3fc4 100644
--- a/gitsrht/blueprints/repo.py
+++ b/gitsrht/blueprints/repo.py
[message trimmed]

On Tue, 15 Aug 2023 11:17 +0200, Peter Bridge wrote:
>Hi All, I am still busy on the PinePhone SoC in Zig.  I have a funny 
>pair of 32b hardware registers representing a u56 value, a chance for 
>me to play with another nice Zig feature :)
>
>My construct currently supports passing in the u32 address of each 
>register along with a value to poke() into memory.  I basically use a 
>struct wrapping '*volatile u32' created via @intToPointer on the 
>passed in comptime 32b address.
>
>My question is, does Zig support anyway to test this design?  ie 
>poke() a value in, then peek() to make sure it is correct.
>
>I tried passing in an address generated via @ptrToInt to a slice. But 

Version 0.4.1 of ijq has been released.

This is a small bug fix release. See the release notes here: https://git.sr.ht/~gpanders/ijq/refs/v0.4.1

Greg

On Mon, 01 Aug 2022 15:55 +0200, Peter Bridge wrote:
>Are these considered equal?
>
>const a = [_:0]u8{ '4', '2'};
>const b = [_]u8{ '4', '2'};
>
>I am not sure how I could even check the sentinels match, or if it 
>even matters :) but since I still have some custom string utils (some 
>with sentinels, and some without (wasm not C)), I want to also have 
>some tests to make sure they are adding/not adding sentinels in the 
>correct place.  But then I get index of of bounds...  Any tips on how 
>to test such functions please? Cheers Peter

"Equal" in what sense? They have different types, but they would compare

Version 0.4.0 of ijq has been released.

This is a minor feature release. See the [release notes][1] for a list
of changes.

Greg

[1]: https://git.sr.ht/~gpanders/ijq/refs/v0.4.0

---
 README.md                   |  2 +-
 contrib/vmt-completion.bash |  2 +-
 src/att.rs                  | 16 ++++++++--------
 src/cat.rs                  |  4 ++--
 src/mime.rs                 |  4 ++--
 src/pick.rs                 |  6 +++---
 src/show.rs                 |  4 ++--
 7 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/README.md b/README.md
index 5ecba13..77448c8 100644
--- a/README.md
+++ b/README.md
[message trimmed]

I forgot to bump the version number in the Makefile for 0.3.7, so
unfortunately that release is a dud. But it's just as well, because
there were two other (small) fixes I was able to squeeze in.

Packagers should please skip 0.3.7 and go straight to 0.3.8. The release
notes for 0.3.8 are listed here:

     https://git.sr.ht/~gpanders/ijq/refs/v0.3.8

These should effectively be combined with the release notes for 0.3.7
(listed in the prior email). Apologies for the confusion!

Version 0.3.7 of ijq has just been released. This is a minor bugfix
release.

As noted in a previous email on this list, the names of the pre-built
binaries that are automatically built in the build pipeline have
changed:

>This is just an FYI that the names of the binary release tarballs
>attached to releases on git.sr.ht will change from using "x86_64" to
>"amd64" beginning with the next release. The build pipeline now creates
>binary releases for Linux and macOS, and because the pipeline now
>builds multiple architectures I am using the terminology that `go
>build` itself uses to simplify things.

* Use Ctrl-F and Ctrl-B to move forward/backward one character
* Use Alt-F and Alt-B to move forward/backward one word
* Use Ctrl-A and Ctrl-E to move to the beginning/end of the input line
* Use Ctrl-K to delete all text from the cursor position to the end of
  the current line
---
 app.go           | 14 ++++++++++++++
 doc/senpai.1.scd | 22 ++++++++++++++++++++++
 ui/editor.go     | 15 +++++++++++++++
 ui/ui.go         |  4 ++++
 4 files changed, 55 insertions(+)

diff --git a/app.go b/app.go
index b044a06..768327f 100644
[message trimmed]