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]> > <[email protected]> wrote: > > Den ons 29 apr. 2026 kl 19:23 skrev Timofei Zhakov <[email protected]> > <[email protected]>: > > On Wed, Apr 29, 2026 at 5:32 PM Branko Čibej <[email protected]> > <[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]> > <[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. > > > > 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. > 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. > > > 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 > > > Scope creep is the death curse of too many projects. > > -- Brane > > -- Timofei Zhakov
