On 18. 5. 26 09:04, Timofei Zhakov wrote:
On Sun, May 17, 2026 at 11:28 PM Branko Čibej <[email protected]> wrote:On 10. 5. 26 21:28, Timofei Zhakov wrote:On Wed, Apr 29, 2026 at 9:18 PM Daniel Sahlberg <[email protected]> <mailto:[email protected]> wrote:Den ons 29 apr. 2026 kl 19:23 skrev Timofei Zhakov<[email protected]> <mailto:[email protected]>:On Wed, Apr 29, 2026 at 5:32 PM Branko Čibej<[email protected]> <mailto:[email protected]> wrote:On 29. 4. 26 17:09, Timofei Zhakov wrote: On Tue, Apr 21, 2026 at 7:02 AM Branko Čibej<[email protected]> <mailto:[email protected]> wrote:On 20. 4. 26 18:40, Timofei Zhakov wrote: Hello all, Thanks to everyone following svnbrowse. I believe this project has come to a state of a decently stable milestone. It is capable for general browsing around in a tree and overall interactivity feels good. However, there are a few things which need some further attention. 1. Opening a file would crash the entire application; I don't know what the best way to display them would be. You could do worse than take a page from Norton Commander for DOS. https://en.wikipedia.org/wiki/Norton_Commander It was THE file browsing/display/edit tool back in the day, and still a good example of how a TUI should be designed. -- BraneI believe it would show the file in an editor/viewer. It is a good user experience, but also requires downloading the file which might be complicated to implement. It also introduces an unbounded operation. "Unbounded" in the sense that it can take a long time, or take a lot of space? The file size is known in advance, and we have cancellation callbacks with which we can implement timouts. Other than that:Both of them I wish we could avoid. The complication would be in a sense that a whole text file viewer would need to be implemented. Also how does it deal with binary files? I guess special handling forsvn:mime-type. It's doable though. We just need to decide how specifically those should be handled.I think both "download" (=svn export) and "view" (=svn cat) would be valuable options. Don't know exactly how much we need to special-case binary files in "view", it probably depends on what protections ncurses bring towards displaying text that could mess up the terminal. If I have committed a binary file and I want to view it - why not?I fully agree with this being a nice thing to have. As I said, I just want to be more realistic and think about how we'd implement and maintain this in the real world. The original "less" is around ~15 files of code, and sure not all of its functionality is what we need plus also we have libsvn_subr with some useful stuff not to be written twice, but there is still some complexity of making own text pager.There is nothing stopping you from launching an external pager, you can even restrict it to a "window" within your TUI. On Unix, the defaults would be 'more' or 'less'; on Windows, probably 'more', which is of course as usual functionally deficient. Maybe better options exist. In any case, implementing one from scratch is ... ahem ... Not Optimal.Can you? It'd be nice if it's possible, but I'd need to research how to put it in a window inside of another application.
Probably, by intercepting SIGWINCH and playing with geometry query responses. But that's not really a priority. Just launching $PAGER as a child process would be good enough. You may or may not have to redraw the TUI once the pager exits.
If you start implementing a pager in svnbrowse, I shall have Words to say. :)By the way, about "download" as you call it, there was a tool called ghgrab [1] (that I also took inspiration from when bringing svnbrowse here). It focuses on this functionality in particular. So I guess this means that this functionality might be demanding.Demanding? You mean people might want to have it? Then it would be "in demand". Just making sure I understand you.Sorry, English is not my first language. Yes people would want to open files sometimes, this is what I meant.
Nor mine. Just want to make sure there aren't misunderstandings. -- Brane
