On Mon, May 18, 2026 at 9:42 AM Branko Čibej <[email protected]> wrote:
> 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]> >> <[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. > > > > 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. > > That's an interesting idea, but realistically it might be too much work to mock child's stdin and stdout. But I like the idea of launching $PAGER and giving it control of the entire terminal. Okay, it messes up overlays, but it'd be a good decision for bootstrapping purposes. We can always figure out a better way later. There might be a little issue on Windows that [as far as my research has gone] 'more' is a shell command, not an executable just like 'cd' and 'dir'. They are implemented by cmd and only it. It shouldn't be an issue because there is a workaround to use 'cmd /c more ...'. > > > >> 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. > > Thanks, that's the most important thing. -- Timofei Zhakov
