User Activity

  • Posted a comment on ticket #748 on CLISP - an ANSI Common Lisp

    I have further explored the man page generation rabbit hole, and attached two fresh patches against current HEAD in the GitLab git repository. The XML source seems not to be used by the normal build scripts. Thus modifying doc/_clisp.1 seems closest to the practical source of the man page. The attached patch clisp-gitlab-manpage-formatting-fix-via-_clisp.1.patch against current GitLab HEAD does this for both current instances of the problem. But since the doc/_clisp.1 file seems to be generated from...

  • Posted a comment on ticket #748 on CLISP - an ANSI Common Lisp

    I have also opened a bug report regarding this issue at Ubuntu, because I originally encountered the issue with CLISP packaged in Ubuntu 20.04: https://bugs.launchpad.net/bugs/2022970

  • Posted a comment on ticket #749 on CLISP - an ANSI Common Lisp

    Hi Florian, I am not involved with the CLISP project, but it seems to me as if the project has switched to GitLab. It seems as if they imported issues from this tracker there at some point in time in the past (see https://gitlab.com/gnu-clisp/clisp/-/issues). The clisp.org (redirected to https://clisp.sourceforge.io/) and https://www.gnu.org/software/clisp/ sites still direct bug reporters here, to the SourceForge bug tracker. I do not see much activity here in the SourceForge project, but the GitLab...

  • Posted a comment on ticket #748 on CLISP - an ANSI Common Lisp

    Well, I have looked at the wrong repository, i.e., the one at SourceForge instead of the one at GitLab. The problem is still there, but the affected line in doc/_clisp.1 is 438, not 434. Thus the fix would be sed -i '438s/:\.PP/:\n.PP/' doc/_clisp.1 for the generated man page, and possibly sed -i '316s/:/:\n /' doc/clisp.xml.in for the XML source for (among other formats) the man page (same line as in SourceForge Mercurial repository). Since the generated doc/_clisp.1 man page is checked into the...

  • Posted a comment on ticket #748 on CLISP - an ANSI Common Lisp

    Going deeper down this rabbit hole…: doc/man.xsl seems to be the style sheet entry point this reference http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl that file invokes further XSL stuff, somewhere within must be defined how to write man macros, including .PP One might assume that the docbook transformation to man page format should ensure that formatting directives that need to be preceded by a newline are actually preceded by a newline. Thus one might assume that there...

  • Posted a comment on ticket #748 on CLISP - an ANSI Common Lisp

    OK, I think I found the problematic file: doc/clisp.xml.in. Comparing the domain encoding and on error sections it seems to me as if a newline should be inserted in front of <variablelist>: sed -i '316s/:/:\n /' doc/clisp.xml.in The attached patch shows the results of above command. Please note that I did not test this and thus do not know if it really fixes the issue. I have not yet attempted to build the clisp sources….

  • Posted a comment on ticket #748 on CLISP - an ANSI Common Lisp

    I have created the attached patch via sed -i '434s/:\.PP/:\n.PP/' doc/_clisp.1 followed by hg diff.

  • Posted a comment on ticket #748 on CLISP - an ANSI Common Lisp

    Well, it seems as if the file doc/_clisp.1 might be generated via XSLT transformations, but I have not yet found the source, nor have I found the relevant style sheet. The root cause for the issue might be found in either of them, or at least a workaround would likely pertain to the man page source or the style sheet. If I were told (e.g., via ticket comment) where to find those and how to generate just the doc/_clisp.1 file, I would be happy to look into finding a solution.

View All

Personal Data

Username:
auerswald
Joined:
2007-07-02 02:37:49

Projects

This is a list of open source software projects that Erik Auerswald is associated with:

Personal Tools