On Wed, Apr 29, 2026 at 9:18 PM Daniel Sahlberg <[email protected]> wrote: > > Den ons 29 apr. 2026 kl 19:23 skrev Timofei Zhakov <[email protected]>: > > > > > > On Wed, Apr 29, 2026 at 5:32 PM Branko Čibej <[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]> 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. > >>> > >>> -- Brane > >> > >> > >> I 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 for svn: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. 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. The only question is what the UI of choosing a path for an exported file (or directory?) should be. [1] https://github.com/abhixdd/ghgrab/tree/main -- Timofei Zhakov
