On 10. 5. 26 21:28, Timofei Zhakov wrote:
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 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.
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.
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
