Hi Diogo,
I really appreciate your idea to reduce code complexity, this is always
something that I strive for in my projects. In this case however, I
don't think the reduction in complexity will result in a gain in
productivity. If we decouple stumpwm.texi from the source, we'll have
to maintain the docstrings and the documentation. As it stands right
now, adding a function to the manual is a fairly straightforward
procedure of flagging the right symbols and the makefile creates the
appropriate stumpwm.texi file.
A clear benefit from this is that you don't need to be able to compile
stumpwm to make the info manual, which bit me when I tried to provide
archive of past manuals for the github.io page. This is a fairly minor
issue though, since going forward we'll have the manuals each time
there's a major release.
I think a more productive change to StumpWM (in terms of code
complexity) would be repackaging the useful bits of stumpwm into
external packages.
Cheers,
Dave
PS. I'm replying here because of the wider audience, and I would
appreciate it if the discussion of this topic continued on
stumpwm-devel.
"Diogo F. S. Ramos" <d...@riseup.net> writes:
> To generate the info manual, StumpWM first processes `stumpwm.texi.in',
> scrapping the lisp source code, producing `stumpwm.texi', so it later
> can be compiled by `makeinfo'.
>
> I think we can reduce the complexity of this process by removing the
> scrapping phase and separate the manual from function docstrings, which
> IMO have separate purposes.
>
> I opened a pull request on github so we could have some concrete picture
> if there is interest in discussing this.
>
> _______________________________________________
> Stumpwm-devel mailing list
> Stumpwm-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
_______________________________________________
Stumpwm-devel mailing list
Stumpwm-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
