Call for Project Maintenance

[pspeder]

This is a really cool project, built on a good philosophy. Thank you to all who have contributed to what the project currently is!

It appears, however, that this project has gone quite stale: 51 issues and 16 open PRs, but no commits accepted, nor any comments from author in 4-ish years(!)

I get that the author, @martanne, is probably busy and that this is FOSS[1], and fear that this will come across more negatively than intended. Here goes:

Since this is a fairly popular tool, with a fairly active community (77 forks and 16 open PRs, as mentioned), I would love to see these resources utilised to keep dvtm better maintained. I reckon it could be done with minimal effort from the original author (or, indeed, a (few) maintainer(s) from the community, who share and respect the author's view on the project's future).

What I am envisioning is that you:

• ask for volunteers on the project's README to help triage issues, do code reviews,
• set up automated integration tests/CI. If necessary, ask community for donations to finance this.
• Maybe you need help with something else regarding this project? Ask, please!

With that, I suppose that the amount of work that would need be done by the author, would be:

• decide on/setup guidelines for what kind of changes should be accepted by maintainers (one-time cost)
• sign-off on code-reviewed, ready-to-go PRs.
• pushing releases back to community

I don't pretend that this is free (in a time-spent-on-it sense), but I truly believe that people are willing to give a lot of help to cool projects such as this and that (this community, in particular) has a lot of skill to contribute.... and would, if only it was better maintained/there was a chance that their work would be used.

Obviously, all of this is just suggestions.

Thank you again for a great project and all the work that has gone into it thus far!

[1]: meaning that I can clone it and do whatever changes I want and need, insofar as my capabilities allow me. These changes I can, then, (choose to) share in a GitHub-fork somewhere and hope that somebody can benefit from them. It seems more likely, though, that most people will only look at the original repo.

[gridsystem]

I would love to see someone put together a well organised and well maintained fork of this repo.

Maybe with a new name (to establish itself as not just another fork) and a new mission - to incorporate new features, to add more customisation options, to test for compatibility with new OS versions.

I used day in and day out for a few years until I switched to tmux. I'm basically using a trimmed down tmux which I've configured to only use dvtm features.

I'd switch back in a heartbeat if I knew the setup would have longevity and flexibility.

[martanne]

Hi, I'm sorry that I neglected dvtm maintenance.

The main reason being that it mostly works for my use case and I spent my limited time on vis. People there tend to complain about window management, hence we might eventually introduce a client/server architecture which would also revive dvtm activity.

From my point of view dvtm has some known issues which in ideal world would be fixed:

• coordination with abduco to properly reinitialize session state
• broken input handling, we should probably switch to libtermkey
• better color support, this is often requested but doesn't really work well with ncurses
• some terminal emulation bugs, these could either be fixed by improving the existing implementation or switching to a more established terminal emulation library like libvterm or by reusing st(1) code. The latter is however not really suited for multiplexing and embedding because it depends on global state.
• sixel support? This is a bit of a gimmick, but could be an interesting hack.

So yeah support to work towards these goals is welcome. I personally don't think that further fragmenting the already small community with a fork is beneficial, but you are of course free to do so anyway.

[rpmohn]

I would definitely contribute to such an effort, I just can't be the leader of it at this time. I have off and on looked at switching the backend to libtermkey and libvterm, which would take care of input handling, terminal emulation, and truecolor support. If someone else can get it started I will join in!

As to the vis client/server architecture reviving dvtm, what's the timeline for that? I feel like that collaboration would give dvtm a better chance at longevity.

[KAction]

Hi.

For what it worth, I collected some of the patches available that are obviously fine, setup CI build and took liberty to call it dvtm-0.15.1.

https://sr.ht/~kaction/dvtm

I do not promise very active development, but I definitely have resources to discuss and apply patches. I used to maintain Debian package of dvtm, so probably I have some clue.

[martanne]

Thanks for stepping up. I will try to review and merge back your changes during the weekend/early next week.

[martanne]

I merged the obvious stuff, dropped the README changes and need to take another look at the {s,r}mam capabilities.

I don't like the "compatibility mode" you introduced in d55678de99e09ff50f6839122544a262743415af. While we try to not deliberately break existing configurations, adding such workarounds negates the core benefit of our configuration scheme: simplicity.

The Makefile variable references you changed in 83c6d1496a05dad62d12100cdfc5bfc22a5dac16 are equivalent, meaning that it is solely a style preference. You will have to motivate your change a bit more.

Thanks!

[KAction]

If you consider breaking old configs fine -- I do not object. I just wanted to be as conservative as possible.

[KAction]

As for Makefile syntax -- looks like your are right: https://builds.sr.ht/~kaction/job/454548

[jarun]

Hey guys! Great to know people are interested in continuing the development of this project. The nnn team prefers dvtm as the terminal multiplexer because it's quite lightweight and well-featured.

It would be great if you can support split windows like tmux which would help us to show previews on-the-fly in dvtm.

Another request would be to allow showing the window list at the bottom (not sure if it's supported already).

Wish you all the best!

[KAction]

Window list? If you mean tag list, it is already supported by #define BAR_POS. As for split-window, you already can create new windows (or buffers, do not recall proper terminology) using control pipe. Here is patch I prepared long time ago to make everything accessible via keys accessible via pipe. https://salsa.debian.org/debian/dvtm/-/blob/master/debian/patches/fifo-bind-everything.patch

Keep in mind, though, that dvtm does not export (AFAIK) concept of buffer identity.

[jarun]

Here's what we do with tmux to open a new split window with some variables. -d ensures the new window doesn't become the current window:

tmux split-window -e "NNN_FIFO=$NNN_FIFO" -e "PREVIEW_MODE=1" -d"$SPLIT" "$0" "$1"

As for split-window, you already can create new windows (or buffers, do not recall proper terminology)

An example would really help.

[KAction]

Sure.

Here is video: https://asciinema.org/a/eaRQOoZEnjLr2wEPmT1syooin of following command: ./dvtm -c /tmp/dvtm.fifo -m ^y.

For this to work, you need to have more commands bound in commands variable in config, like following:

static Cmd commands[] = {
        /* create [cmd]: create a new window, run `cmd` in the shell if specified */
        { "create", { create,   { NULL } } },
        /* focus <win_id>: focus the window whose `DVTM_WINDOW_ID` is `win_id` */
        { "focus",  { focusid,  { NULL } } },
        /* tag <win_id> <tag> [tag ...]: add +tag, remove -tag or set tag of the window with the given identifier */
        { "tag",    { tagid,    { NULL } } },
        { "focusprev", { focusprev, { NULL } } },
        { "focusprevnm", { focusprevnm, { NULL } } },
        { "focusnext", { focusnext, { NULL } } },
        { "focusnextnm", { focusnextnm, { NULL } } },
        { "killclient", { killclient, { NULL } } },
        { "zoom", { zoom, { NULL } } },
};

[KAction]

Keep in mind that if user does some window management between "dvtm.pre" and "dvtm.post", chaos will happen.

[GReagle]

I am willing to look through Issues and label them (bug or new feature request for example) and ask follow-up questions and so forth. If this would be helpful, may I have permission/privilege to do so? You can see my comments in a couple of the issues to get an idea of what I would do.

[GReagle]

For those of you looking for other options, mtm https://github.com/deadpixi/mtm is small and useful.

[jarun]

No, mtm isn't anything brighter: https://github.com/deadpixi/mtm/issues/30

[kuator]

Maybe, someone would be interested: https://github.com/wez/wezterm/issues/274