~rockorager

St. Paul, MN

https://timculverhouse.com/

Trackers

~rockorager/vaxis

Last active 13 days ago

~rockorager/go-jmap

Last active 1 year, 3 months ago

~rockorager/shtc

Last active 1 year, 6 months ago

~rockorager/hutui

Last active 1 year, 9 months ago

~rockorager/tcell-term

Last active 2 years ago

#285 Add support for OSC52 escape sequence 5 days ago

Comment by ~rockorager on ~rjarry/aerc

Just applied it on vaxis. We'll need to update aerc at some point. Thanks!

#25 Scrollbar does not extend to lowest possible position. 12 days ago

on ~rockorager/vaxis

On Sat, Feb 01 2025 00:01 (+0000), ~rockorager wrote:

barH := (m.ViewHeight*h + m.TotalHeight/2) / m.TotalHeight
	if barH < 1 {
		barH = 1
	}
	barTop := (m.Top*h + m.TotalHeight/2) / m.TotalHeight

which scrolls smoothly from the very top to the very bottom. Hope this can be included.

Hmm - I think your original solution of floating point math is nicer. This is a bit too hacky.

Would you be interested in sending in a patch with the floating point code?

That really surprised me --- I think the code is very clean (maybe with a very short comment like

// effectively rounds (m.ViewHeight * h) / m.TotalHeight)

and very much in the spirit of the original code: That code already relied on a "floor" op implicit in integer division, my change turns that into an implied "round" op.

Here is my first version, starting from the same line (needs a "math" import):

barH := float64(m.ViewHeight)*float64(h) / float64(m.TotalHeight)
	if barH < 1 {
		barH = 1
	}
	barTop := float64(m.Top)*float64(h) / float64(m.TotalHeight)

	if m.Character.Grapheme == "" {
		m.Character = defaultChar
	}
	for i := 0; i < int(math.Round(barH)); i += 1 {
		cell := vaxis.Cell{
			Character: m.Character,
			Style:     m.Style,
		}
		win.SetCell(0, int(math.Round(barTop))+i, cell)
	}

It is, by comparison, extremely ugly, not to mention quite wasteful computing-wise. If you insist to use that, I would not want to be credited ;)

Anyway, both ways work, I should be happy either way!

#25 Scrollbar does not extend to lowest possible position. 13 days ago

Comment by ~rockorager on ~rockorager/vaxis

It works (in the sense that the bar reaches the window bottom), although it can look a bit jerky when scrolling longer: the bar might have just reached the penultimate position right before the last line enters the view, and then immediately the bar is moved again.

That would be good enough for me, BUT when I wrote this reply I realized that I could simply use the standard trick for rounding w/o floating point math, just replace the barH and barTop calculation by

barH := (m.ViewHeight*h + m.TotalHeight/2) / m.TotalHeight
	if barH < 1 {
		barH = 1
	}
	barTop := (m.Top*h + m.TotalHeight/2) / m.TotalHeight

which scrolls smoothly from the very top to the very bottom. Hope this can be included.

Hmm - I think your original solution of floating point math is nicer. This is a bit too hacky.

Would you be interested in sending in a patch with the floating point code?

#25 Scrollbar does not extend to lowest possible position. 13 days ago

on ~rockorager/vaxis

On Fri, Jan 31 2025 22:38 (+0000), ~rockorager wrote:

I'd prefer to avoid floating point math, if possible. I think another solution would be to add a check if the last item is in the view. Something like:

if m.Top + m.ViewHeight >= m.TotalHeight {
  // Anchor to bottom
}

Could you try that out and see if it meets your use case?

Understood. I replaced the barTop line by

var barTop int
	if m.Top+m.ViewHeight >= m.TotalHeight {
		// Anchor to bottom
		barTop = h - barH
	} else {
		barTop = m.Top * h / m.TotalHeight
	}

It works (in the sense that the bar reaches the window bottom), although it can look a bit jerky when scrolling longer: the bar might have just reached the penultimate position right before the last line enters the view, and then immediately the bar is moved again.

That would be good enough for me, BUT when I wrote this reply I realized that I could simply use the standard trick for rounding w/o floating point math, just replace the barH and barTop calculation by

barH := (m.ViewHeight*h + m.TotalHeight/2) / m.TotalHeight
	if barH < 1 {
		barH = 1
	}
	barTop := (m.Top*h + m.TotalHeight/2) / m.TotalHeight

which scrolls smoothly from the very top to the very bottom. Hope this can be included.

#25 Scrollbar does not extend to lowest possible position. 13 days ago

Comment by ~rockorager on ~rockorager/vaxis

I'd prefer to avoid floating point math, if possible. I think another solution would be to add a check if the last item is in the view. Something like:

if m.Top + m.ViewHeight >= m.TotalHeight {
  // Anchor to bottom
}

Could you try that out and see if it meets your use case?

#290 Empty emails are sent if the gpg agent fails to unlock the key a month ago

Comment by ~rockorager on ~rjarry/aerc

I'm unable to reproduce on master, both by using no password and using the wrong password 3 times. Each time I get the error gpg: failure to encrypt: FAILURE sign-encrypt 67109041. check public key(s)

Can you confirm on master branch that this still exists for you?

#23 Terminal mouse resize too fast for vaxis 2 months ago

Comment by ~rockorager on ~rockorager/vaxis

On Fri Dec 13, 2024 at 9:50 AM CST, ~sewn wrote:

View an image within senpai (sixel, foot) and resize the terminal using the mouse.

I can't repro using

foot version: 1.18.0-2-g62b0b65d4712 (Aug 02 2024, branch 'master') -pgo +ime +graphemes -assertions

What version, and DE/WM are you using?

-- Tim

#23 Terminal mouse resize too fast for vaxis 2 months ago

Comment by ~rockorager on ~rockorager/vaxis

Do you have a way to reproduce this?

#22 OSC 11 responds in wrong order 2 months ago

Comment by ~rockorager on ~rockorager/vaxis

Tim Culverhouse referenced this ticket in commit e2b805b.

REPORTED RESOLVED FIXED

#22 OSC 11 responds in wrong order 2 months ago

Comment by ~rockorager on ~rockorager/vaxis

Good catch...I see the issue already - when the terminal widget gets an OSC 11 query it queries the host terminal in a goroutine, and then responds. This will definitely get the ordering wrong.

This is problematic because I batch my queries on startup, and use the DA1 response as a sentinel between query response and user input. If I get DA1 before OSC 11, then I end up interpreting OSC 11 as user input.

I can (and will likely) modify my input loop to accomodate for this, but it's probably best to fix it here so that we can eventually rid the ecosystem of such kludges.

That sounds like it might cause issues elsewhere...I haven't seen any other terminals which would get this ordering wrong (I do queries in the same way). I'd caution against patching over this vaxis bug in your code...unless you have a nice way to do it which won't break other things :)

Thanks for the detailed report, I'll have this fixed shortly. Also...chawan is amazing, thanks for your work on it!