Repository navigation
Fix split view errors and speed up rotation and text search #12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
f7a4499
3de8a13
582df77
3f0b979
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -188,8 +188,8 @@ func New(r render.Renderer, srv *server.Server, marks *bookmarks.Store, position | |
| } | ||
| } | ||
| } | ||
| if m.panes[1].book != nil { | ||
| m.split = true | ||
| if len(paths) > 1 { | ||
| m.split = true // a second book that failed to open still shows its error | ||
| } else { | ||
| m.webtoon = resumeWebtoon | ||
| } | ||
|
|
@@ -1366,28 +1366,36 @@ func (m Model) updateOCR(msg ocrMsg) (tea.Model, tea.Cmd) { | |
| m.find.running = false | ||
| return m, nil | ||
| } | ||
| if msg.err == nil { | ||
| key := p.book.Path + "\x00" + strconv.Itoa(msg.page) | ||
| m.ocrText[key] = msg.text | ||
| if strings.Contains(strings.ToLower(msg.text), m.find.term) { | ||
| m.find.hits = append(m.find.hits, msg.page) | ||
| } | ||
| } else { | ||
| m.find.skipped++ | ||
| } | ||
| m.find.scanned = msg.page + 1 | ||
| if m.find.scanned >= m.find.total { | ||
| m.find.running = false | ||
| m.status = fmt.Sprintf("search done: %d hit(s) for %q · n/p to jump", len(m.find.hits), m.find.term) | ||
| if m.find.skipped > 0 { | ||
| m.status += fmt.Sprintf(" · %d page(s) not searched", m.find.skipped) | ||
| for batch := 1; ; batch++ { // pages handled in this update | ||
| if msg.err == nil { | ||
| key := p.book.Path + "\x00" + strconv.Itoa(msg.page) | ||
| m.ocrText[key] = msg.text | ||
| if strings.Contains(strings.ToLower(msg.text), m.find.term) { | ||
| m.find.hits = append(m.find.hits, msg.page) | ||
| } | ||
| } else { | ||
| m.find.skipped++ | ||
| } | ||
| m.find.scanned = msg.page + 1 | ||
| if m.find.scanned >= m.find.total { | ||
| m.find.running = false | ||
| m.status = fmt.Sprintf("search done: %d hit(s) for %q · n/p to jump", len(m.find.hits), m.find.term) | ||
| if m.find.skipped > 0 { | ||
| m.status += fmt.Sprintf(" · %d page(s) not searched", m.find.skipped) | ||
| } | ||
| if len(m.find.hits) > 0 && m.active == m.find.pane { | ||
| return m.gotoHit(1) | ||
| } | ||
| return m, nil | ||
| } | ||
| if len(m.find.hits) > 0 && m.active == m.find.pane { | ||
| return m.gotoHit(1) | ||
| // Book text needs no OCR: read it here in batches instead of one message | ||
| // per page, and yield between batches so input and progress stay live. | ||
| next := msg.page + 1 | ||
| if batch == 64 || !p.book.IsTextPage(next) { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Knowledge Base Used: Prompt To Fix With AIThis is a comment left during a code review.
Path: internal/ui/ui.go
Line: 1394
Comment:
**Search batches can delay input** A text-heavy book can make one update extract and search 65 pages before the reader handles another key or redraws progress. The fixed page count does not limit how long that work takes when pages contain substantial text. Consider yielding after a time or work budget so a dense batch does not stall the interface.
**Knowledge Base Used:**
- [Terminal UI navigation](https://app.greptile.com/looneytunes/-/custom-context/knowledge-base/hawkff/cbzr/-/docs/terminal-ui-navigation.md)
- [OCR integration](https://app.greptile.com/looneytunes/-/custom-context/knowledge-base/hawkff/cbzr/-/docs/ocr-integration.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Owner
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Page geometry bounds the work here. A laid-out text page is 900×1200 px at 32 px, about 25 lines of 60 characters, so 64 pages is roughly 150 KB of string scanning per update, well under a millisecond. A clock read per page would add cost without a measurable gain. 3f0b979 corrects the count to 64. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That’s a fair correction. With |
||
| return m, m.ocrPage(msg.gen, next) | ||
| } | ||
| return m, nil | ||
| msg = ocrMsg{gen: msg.gen, page: next, book: p.book, text: strings.Join(p.book.PageText(next), "\n")} | ||
|
greptile-apps[bot] marked this conversation as resolved.
Resolved
|
||
| } | ||
| return m, m.ocrPage(msg.gen, msg.page+1) | ||
| } | ||
|
|
||
| func (m Model) gotoHit(dir int) (tea.Model, tea.Cmd) { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 Medium
ui/ui.go:1394updateOCRprocesses 65 contiguous text pages before yielding, so a 65th large page can keep input and progress blocked beyond the intended 64-page responsiveness bound. Because the current message is processed before checkingbatch == 64, change the threshold to63.🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 3f0b979: the counter now starts at 1 and counts pages handled, so an update yields after the 64th page.