St. Paul, MN
Comment by ~rockorager on ~rjarry/aerc
Just applied it on vaxis. We'll need to update aerc at some point. Thanks!
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.TotalHeightwhich 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!
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.TotalHeightwhich 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?
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.TotalHeightwhich scrolls smoothly from the very top to the very bottom. Hope this can be included.
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?
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?
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
Comment by ~rockorager on ~rockorager/vaxis
Do you have a way to reproduce this?
Comment by ~rockorager on ~rockorager/vaxis
Tim Culverhouse referenced this ticket in commit e2b805b.
REPORTED RESOLVED FIXED
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!