Re: Texinfo in descriptions?

[Alex Kost]

Ludovic Courtès (2015-09-07 00:31 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-09-06 16:51 +0300) wrote:
>>
>>> Alex: We should maybe disable the paragraph filling code in guix.el so
>>> that it doesn’t mess up with formatting?
>>
>> I don't mind (if you remember I didn't actually like such filling¹, and
>> I've never used it).  So we can change the default value of
>> ‘guix-package-info-fill-heading’ variable.
>
> Yes, though ideally the elisp code would provide Scheme code the current
> value of ‘fill-column’ so that text is filled using the right width.
> WDYT?

Do you mean that ‘package-description-string’ should take an optional
'fill-column' argument, so that it can be called from the elisp side?

If so, I'm afraid currently there is no way to have such fine tuning for
the received package parameters.  The package (or generation) data is
received all at once using ‘guix-get-entries’, for example:

(guix-get-entries guix-current-profile 'package 'name '("r"))
(guix-get-entries guix-current-profile 'generation 'last '(3))

As you can see there is no place to specify fill-column there.  But I
have noted this thing, perhaps it will become possible one day.

-- 
Alex

Re: Texinfo in descriptions?

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-09-07 00:31 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> Ludovic Courtès (2015-09-06 16:51 +0300) wrote:
>>>
 Alex: We should maybe disable the paragraph filling code in guix.el so
 that it doesn’t mess up with formatting?
>>>
>>> I don't mind (if you remember I didn't actually like such filling¹, and
>>> I've never used it).  So we can change the default value of
>>> ‘guix-package-info-fill-heading’ variable.
>>
>> Yes, though ideally the elisp code would provide Scheme code the current
>> value of ‘fill-column’ so that text is filled using the right width.
>> WDYT?
>
> Do you mean that ‘package-description-string’ should take an optional
> 'fill-column' argument, so that it can be called from the elisp side?

Yes.

> If so, I'm afraid currently there is no way to have such fine tuning for
> the received package parameters.  The package (or generation) data is
> received all at once using ‘guix-get-entries’, for example:
>
> (guix-get-entries guix-current-profile 'package 'name '("r"))
> (guix-get-entries guix-current-profile 'generation 'last '(3))
>
> As you can see there is no place to specify fill-column there.  But I
> have noted this thing, perhaps it will become possible one day.

Oh I see.  Thanks for checking anyway.

Ludo’.

Re: Texinfo in descriptions?

[Alex Kost]

Ludovic Courtès (2015-09-06 16:51 +0300) wrote:

> Alex: We should maybe disable the paragraph filling code in guix.el so
> that it doesn’t mess up with formatting?

I don't mind (if you remember I didn't actually like such filling¹, and
I've never used it).  So we can change the default value of
‘guix-package-info-fill-heading’ variable.

[1] https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00387.html

-- 
Alex

Re: Texinfo in descriptions?

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-09-06 16:51 +0300) wrote:
>
>> Alex: We should maybe disable the paragraph filling code in guix.el so
>> that it doesn’t mess up with formatting?
>
> I don't mind (if you remember I didn't actually like such filling¹, and
> I've never used it).  So we can change the default value of
> ‘guix-package-info-fill-heading’ variable.

Yes, though ideally the elisp code would provide Scheme code the current
value of ‘fill-column’ so that text is filled using the right width.
WDYT?

Ludo’.

Re: Texinfo in descriptions?

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> l...@gnu.org (Ludovic Courtès) writes:

[...]

>>> +++ b/gnu/packages/databases.scm
>>> @@ -578,7 +578,7 @@ columns, primary keys, unique constraints and 
>>> relationships.")
>>> ("postgresql" ,postgresql)))
>>>  (home-page "http://search.cpan.org/dist/DBD-Pg;)
>>>  (synopsis "DBI PostgreSQL interface")
>>> -(description "")
>>> +(description #f)
>>
>> Weird, and doesn’t really match the commit log.  Maybe this hunk can be
>> removed?
>
> I get an error with "guix package -s perl-dbd-pg" without this change

[...]

> In guix/ui.scm:
>  859: 4 [package->recutils # # 80]
>  790: 3 [texi->plain-text "description: Project-Id-Version: guix-packages 
> 0.8\nReport-Msgid-Bugs-To: l...@gnu.org\nPOT-Creation-Date: 2015-07-21 
> 21:35+0200\nPO-Revision-Date: 2014-12-20 22:00+0100\nLast-Translator: Rémy 
> Chevalier \nLanguage-Team: French 
> \nLanguage: fr\nMIME-Version: 1.0\nContent-Type: 
> text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\n"]
> In unknown file:
>?: 2 [call-with-input-string "description: Project-Id-Version: 
> guix-packages 0.8\nReport-Msgid-Bugs-To: l...@gnu.org\nPOT-Creation-Date: 
> 2015-07-21 21:35+0200\nPO-Revision-Date: 2014-12-20 
> 22:00+0100\nLast-Translator: Rémy Chevalier 
> \nLanguage-Team: French 
> \nLanguage: fr\nMIME-Version: 1.0\nContent-Type: 
> text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\n" ...]
> In texinfo.scm:
> 1131: 1 [parse #]
>  965: 0 [loop # (*fragment*) ...]
>
> texinfo.scm:965:23: In procedure loop:
> texinfo.scm:965:23: Throw to key `parser-error' with args `(#f "Unknown 
> command" gnu)'.

It looks as though (P_ "") returns the header of the PO file, an indeed

This also happens on ‘master’ for all the supported languages:

--8<---cut here---start->8---
$ ./pre-inst-env guix package --show=perl-dbd-pg
name: perl-dbd-pg
version: 3.5.1
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: perl-dbi-1.631 perl-dbi-1.631 postgresql-9.3.8
location: gnu/packages/databases.scm:562:2
homepage: http://search.cpan.org/dist/DBD-Pg
license: GPL 1+
synopsis: DBI PostgreSQL interface
description: Project-Id-Version: guix-packages 0.8.1 Report-Msgid-Bugs-To:
+ l...@gnu.org POT-Creation-Date: 2015-01-27 00:07+0100 PO-Revision-Date:
+ 2015-02-05 09:41-0300 Last-Translator: Felipe Castro 
+ Language-Team: Esperanto  Language:
+ eo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8
+ Content-Transfer-Encoding: 8bit X-Generator: Poedit 1.6.10
--8<---cut here---end--->8---

Here’s a reduced case (where bindtextdomain is passed by $localedir):

--8<---cut here---start->8---
$ echo $LANGUAGE
eo
$ ./pre-inst-env guile -c '(bindtextdomain "guix-packages" 
"/home/ludo/soft/share/locale") (setlocale LC_ALL "") (pk (gettext "" 
"guix-packages"))'

;;; ("Project-Id-Version: guix-packages 0.8.1\nReport-Msgid-Bugs-To: 
l...@gnu.org\nPOT-Creation-Date: 2015-01-27 00:07+0100\nPO-Revision-Date: 
2015-02-05 09:41-0300\nLast-Translator: Felipe Castro 
\nLanguage-Team: Esperanto 
\nLanguage: eo\nMIME-Version: 
1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 
8bit\nX-Generator: Poedit 1.6.10\n")
--8<---cut here---end--->8---

Same with the ‘gettext’ command:

--8<---cut here---start->8---
$ TEXTDOMAINDIR=$HOME/soft/share/locale gettext guix-packages ""
Project-Id-Version: guix-packages 0.8.1
Report-Msgid-Bugs-To: l...@gnu.org
POT-Creation-Date: 2015-01-27 00:07+0100
PO-Revision-Date: 2015-02-05 09:41-0300
Last-Translator: Felipe Castro 
Language-Team: Esperanto 
Language: eo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Generator: Poedit 1.6.10
--8<---cut here---end--->8---

Although libc’s manual doesn’t mention it (info "(libc) Translation with
gettext"), gettext(3) states:

  When an empty string is used for msgid, the functions may return a
  nonempty string.

I have changed ‘P_’ to return the empty string when passed the empty
string.  I left ‘_’ and ‘N_’ unchanged because they normally shouldn’t
end up being passed the empty string.

>> Could you look into it?
>
> Here is "something" that seems to work. The idea is to append
> "description: " to package description before 'stexi->plain-text' fills
> the text.

Sounds reasonable.

> From 88f95bf594ded0e63b842e23bc06cbcd250d9660 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin 
> Date: Fri, 7 Aug 2015 00:10:43 +0200
> 

Re: Texinfo in descriptions?

[Mathieu Lirzin]

l...@gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin  skribis:
>
>> From e691c2080929dd1390184ab4669de8b2695a237f Mon Sep 17 00:00:00 2001
>> From: Mathieu Lirzin 
>> Date: Fri, 7 Aug 2015 00:10:43 +0200
>> Subject: [PATCH] ui: Add package-description-string.
>>
>> Provide support for Texinfo's markup in package description.
>>
>> * guix/ui.scm (%text-width, %initial-indent): New parameters.
>>   (package-description-string): New variable.
>>   (package->recutils): Use them.
>> * emacs/guix-main.scm (%package-param-alist): Use it.
>> * gnu/packages/databases.scm (perl-dbd-pg): Adapt to Texinfo's markup.
>> * gnu/packages/perl.scm (perl-devel-globaldestruction)
>>   (perl-devel-lexalias, perl-exporter-lite): Likewise.
>> * gnu/packages/python.scm (python2-empy): Likewise.
>
> [...]
>
>> +++ b/gnu/packages/databases.scm
>> @@ -578,7 +578,7 @@ columns, primary keys, unique constraints and 
>> relationships.")
>> ("postgresql" ,postgresql)))
>>  (home-page "http://search.cpan.org/dist/DBD-Pg;)
>>  (synopsis "DBI PostgreSQL interface")
>> -(description "")
>> +(description #f)
>
> Weird, and doesn’t really match the commit log.  Maybe this hunk can be
> removed?

I get an error with "guix package -s perl-dbd-pg" without this change

--8<---cut here---start->8---
Backtrace:
In unknown file:
   ?: 19 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 18 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 17 [eval # #]
In ice-9/boot-9.scm:
2401: 16 [save-module-excursion #]
4050: 15 [#]
1724: 14 [%start-stack load-stack ...]
1729: 13 [#]
In unknown file:
   ?: 12 [primitive-load "/home/mthl/src/gnu/guix/scripts/guix"]
In guix/ui.scm:
1058: 11 [run-guix-command package "-s" "perl-dbd-pg"]
In ice-9/boot-9.scm:
 157: 10 [catch srfi-34 # ...]
 157: 9 [catch system-error ...]
In guix/scripts/package.scm:
 995: 8 [#]
 967: 7 [process-query (# # # # ...)]
In ice-9/boot-9.scm:
 157: 6 [catch system-error ...]
In srfi/srfi-1.scm:
 619: 5 [for-each # ...]
In guix/ui.scm:
 859: 4 [package->recutils # # 80]
 790: 3 [texi->plain-text "description: Project-Id-Version: guix-packages 
0.8\nReport-Msgid-Bugs-To: l...@gnu.org\nPOT-Creation-Date: 2015-07-21 
21:35+0200\nPO-Revision-Date: 2014-12-20 22:00+0100\nLast-Translator: Rémy 
Chevalier \nLanguage-Team: French 
\nLanguage: fr\nMIME-Version: 1.0\nContent-Type: text/plain; 
charset=UTF-8\nContent-Transfer-Encoding: 8bit\n"]
In unknown file:
   ?: 2 [call-with-input-string "description: Project-Id-Version: guix-packages 
0.8\nReport-Msgid-Bugs-To: l...@gnu.org\nPOT-Creation-Date: 2015-07-21 
21:35+0200\nPO-Revision-Date: 2014-12-20 22:00+0100\nLast-Translator: Rémy 
Chevalier \nLanguage-Team: French 
\nLanguage: fr\nMIME-Version: 1.0\nContent-Type: text/plain; 
charset=UTF-8\nContent-Transfer-Encoding: 8bit\n" ...]
In texinfo.scm:
1131: 1 [parse #]
 965: 0 [loop # (*fragment*) ...]

texinfo.scm:965:23: In procedure loop:
texinfo.scm:965:23: Throw to key `parser-error' with args `(#f "Unknown 
command" gnu)'.
--8<---cut here---end--->8---


It's not directly related to texinfo description since

 (package-description-string perl-dbd-pg) => "" 

but caused by the fact there is this in "po/packages/fr.po"...

--8<---cut here---start->8---
msgid ""
msgstr ""
"Project-Id-Version: guix-packages 0.8\n"
"Report-Msgid-Bugs-To: l...@gnu.org\n"
"POT-Creation-Date: 2014-11-10 15:37+0100\n"
"PO-Revision-Date: 2014-12-20 22:00+0100\n"
"Last-Translator: Rémy Chevalier \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
--8<---cut here---end--->8---

which fails to be parsed by texinfo. 

What is your recommandation about this?

>
>> +(set! (@@ (texinfo plain-text) wrap*)
>> +  ;; Monkey patch this private procedure to let 'package->recutils'
>^
> Please prepend “XXX” here to make the kludge more visible.  (Eventually
> we should fix it in Guile.)

Done.

> I tried adding an @itemize list in a description and noticed that the
> initial indent is not working the way I thought:
> [...]

I should have test such case before proposing a patch sorry about that.

> I wonder if using ‘fill-paragraph’ instead of ‘fill-string’ would solve
> this.

I don't remember exactly the result I got with that but it wasn't
convincing.

> Could you look into it?

Here is "something" that seems to work. The idea is to append
"description: " to package description before 'stexi->plain-text' fills
the text.

>From 88f95bf594ded0e63b842e23bc06cbcd250d9660 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Fri, 7 Aug 2015 00:10:43 +0200

Re: Texinfo in descriptions?

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> From e691c2080929dd1390184ab4669de8b2695a237f Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin 
> Date: Fri, 7 Aug 2015 00:10:43 +0200
> Subject: [PATCH] ui: Add package-description-string.
>
> Provide support for Texinfo's markup in package description.
>
> * guix/ui.scm (%text-width, %initial-indent): New parameters.
>   (package-description-string): New variable.
>   (package->recutils): Use them.
> * emacs/guix-main.scm (%package-param-alist): Use it.
> * gnu/packages/databases.scm (perl-dbd-pg): Adapt to Texinfo's markup.
> * gnu/packages/perl.scm (perl-devel-globaldestruction)
>   (perl-devel-lexalias, perl-exporter-lite): Likewise.
> * gnu/packages/python.scm (python2-empy): Likewise.

[...]

> +++ b/gnu/packages/databases.scm
> @@ -578,7 +578,7 @@ columns, primary keys, unique constraints and 
> relationships.")
> ("postgresql" ,postgresql)))
>  (home-page "http://search.cpan.org/dist/DBD-Pg;)
>  (synopsis "DBI PostgreSQL interface")
> -(description "")
> +(description #f)

Weird, and doesn’t really match the commit log.  Maybe this hunk can be
removed?

> +(set! (@@ (texinfo plain-text) wrap*)
> +  ;; Monkey patch this private procedure to let 'package->recutils'
   ^
Please prepend “XXX” here to make the kludge more visible.  (Eventually
we should fix it in Guile.)

I tried adding an @itemize list in a description and noticed that the
initial indent is not working the way I thought:

--8<---cut here---start->8---
$ ./pre-inst-env guix package --show=emacs-let-alist
name: emacs-let-alist
version: 1.0.4
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: emacs-no-x-24.5
location: gnu/packages/emacs.scm:491:2
homepage: http://elpa.gnu.org/packages/let-alist.html
license: GPL 3+
synopsis: Easily let-bind values of an assoc-list by their names
description: This package offers a single Emacs Lisp macro, `let-alist'.  This
+ macro takes a first argument, whose value must be an alist (association list),
+ and a body.
+ 
+ des* iption: one
+ 
+ des* iption: two
+ 
+ des* iption: three
+ 
+ description: The macro expands to a let form containing the body, where each
+ dotted symbol inside body is let-bound to their cdrs in the alist.  Only those
+ present in the body are let-bound and this search is done at compile time.
--8<---cut here---end--->8---

Notice how “description:” is repeated for each @item and for the next
paragraph.

I wonder if using ‘fill-paragraph’ instead of ‘fill-string’ would solve
this.

Could you look into it?

Sorry for not noticing earlier!

Thanks,
Ludo’.

Re: Texinfo in descriptions?

[Mathieu Lirzin]

l...@gnu.org (Ludovic Courtès) writes:

> One last thing (I swear!).
>
> AFAICS ‘stexi->plain-text’ already does paragraph filling, so the call
> above is redundant (and could break the rendering.)
>
> However, the width of the rendered text is fixed, unlike what
> ‘string->recutils’ did so far.  To work around that, we’ll have to
> monkey-patch the ‘wrap*’ procedure of (texinfo plain-text), along these
> lines:
>
>   (define %text-width
> (make-parameter (or (and=> (getenv "WIDTH") string->number)
> 80)))
>
>   (set! (@@ (texinfo plain-text) wrap*)
> (lambda strings
>   ... #:line-width (%text-width) ...))
>
> and then in ‘package->recutils’, we need to ‘parameterize’ that.
>
> We need a similar hack for #:initial-indent, that would allow us to
> mimic the 3rd argument of ‘fill-paragraph’.

Thanks for noticing this problem.  Here is an updated patch.  

>From e691c2080929dd1390184ab4669de8b2695a237f Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Fri, 7 Aug 2015 00:10:43 +0200
Subject: [PATCH] ui: Add package-description-string.

Provide support for Texinfo's markup in package description.

* guix/ui.scm (%text-width, %initial-indent): New parameters.
  (package-description-string): New variable.
  (package->recutils): Use them.
* emacs/guix-main.scm (%package-param-alist): Use it.
* gnu/packages/databases.scm (perl-dbd-pg): Adapt to Texinfo's markup.
* gnu/packages/perl.scm (perl-devel-globaldestruction)
  (perl-devel-lexalias, perl-exporter-lite): Likewise.
* gnu/packages/python.scm (python2-empy): Likewise.
---
 emacs/guix-main.scm|  2 +-
 gnu/packages/databases.scm |  2 +-
 gnu/packages/perl.scm  |  6 +++---
 gnu/packages/python.scm|  2 +-
 guix/ui.scm| 47 +-
 5 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/emacs/guix-main.scm b/emacs/guix-main.scm
index fe224fb..73173f2 100644
--- a/emacs/guix-main.scm
+++ b/emacs/guix-main.scm
@@ -281,7 +281,7 @@ Example:
 (license   . ,package-license-names)
 (source. ,package-source-names)
 (synopsis  . ,package-synopsis)
-(description   . ,package-description)
+(description   . ,package-description-string)
 (home-url  . ,package-home-page)
 (outputs   . ,package-outputs)
 (non-unique. ,(negate package-unique?))
diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index cbac16e..1710d0e 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -578,7 +578,7 @@ columns, primary keys, unique constraints and relationships.")
("postgresql" ,postgresql)))
 (home-page "http://search.cpan.org/dist/DBD-Pg;)
 (synopsis "DBI PostgreSQL interface")
-(description "")
+(description #f)
 (license (package-license perl
 
 (define-public perl-dbd-sqlite
diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index f784798..0236d05 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -1665,7 +1665,7 @@ particular command is available.")
 (home-page "http://search.cpan.org/dist/Devel-GlobalDestruction;)
 (synopsis "Provides equivalent of ${^GLOBAL_PHASE} eq 'DESTRUCT' for older perls")
 (description "Devel::GlobalDestruction provides a function returning the
-equivalent of \"${^GLOBAL_PHASE} eq 'DESTRUCT'\" for older perls.")
+equivalent of \"$@{^GLOBAL_PHASE@} eq 'DESTRUCT'\" for older perls.")
 (license (package-license perl
 
 (define-public perl-devel-lexalias
@@ -1909,7 +1909,7 @@ constructors, which speeds code up at runtime by a significant amount.  String
 eval is not without its issues however - it's difficult to control the scope
 it's used in (which determines which variables are in scope inside the eval),
 and it's easy to miss compilation errors, since eval catches them and sticks
-them in $@ instead.  This module attempts to solve these problems.  It
+them in $@@ instead.  This module attempts to solve these problems.  It
 provides an eval_closure function, which evals a string in a clean
 environment, other than a fixed list of specified variables.  Compilation
 errors are rethrown automatically.")
@@ -1953,7 +1953,7 @@ in your modules in a \"Java-esque\" manner.")
 (description
  "Exporter::Lite is an alternative to Exporter, intended to provide a
 lightweight subset of the most commonly-used functionality.  It supports
-import(), @EXPORT and @EXPORT_OK and not a whole lot else.")
+import(), @@EXPORT and @@EXPORT_OK and not a whole lot else.")
 (home-page (string-append "http://search.cpan.org/~neilb/;
   "Exporter-Lite-" version))
 (license (package-license perl
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 940efec..07275d7 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -1171,7 +1171,7 @@ other Python program.")
  

Re: Texinfo in descriptions?

[Mathieu Lirzin]

l...@gnu.org (Ludovic Courtès) writes:

> AFAICS ‘stexi->plain-text’ already does paragraph filling, so the call
> above is redundant (and could break the rendering.)
>
> However, the width of the rendered text is fixed, unlike what
> ‘string->recutils’ did so far.  To work around that, we’ll have to
> monkey-patch the ‘wrap*’ procedure of (texinfo plain-text), along these
> lines:
>
>   (define %text-width
> (make-parameter (or (and=> (getenv "WIDTH") string->number)
> 80)))
>
>   (set! (@@ (texinfo plain-text) wrap*)
> (lambda strings
>   ... #:line-width (%text-width) ...))
>
> and then in ‘package->recutils’, we need to ‘parameterize’ that.
>
> We need a similar hack for #:initial-indent, that would allow us to
> mimic the 3rd argument of ‘fill-paragraph’.
>
> Could you try it?

With my limited knowledge, it's not trivial to implement such thing. But
I will try to do something and hopefully learn new things! :)

--
Mathieu Lirzin

Re: Texinfo in descriptions?

[Ludovic Courtès]

Mathieu Lirzin  skribis:

>> Any performance figures?  For instance, time of ‘guix package -s’ before
>> and after?
>
> With the updated patch I have obtained the following results for command
>
>   time ./pre-inst-env guix package -s e
>
> - without patch:
> real  0m25.381s
> user  0m8.740s
> sys   0m0.184s
>
> - with patch:
> real  0m24.556s
> user  0m10.448s
> sys   0m0.220s

Sounds good.

[...]

> +(define (package-description-string package)
> +  "Return a plain-text representation of PACKAGE description field."
> +  (and=> (package-description package)
> + (compose stexi->plain-text texi-fragment->stexi P_)))
> +
>  (define (string->recutils str)
>"Return a version of STR where newlines have been replaced by newlines
>  followed by \"+ \", which makes for a valid multi-line field value in the
> @@ -786,10 +795,8 @@ followed by \"+ \", which makes for a valid multi-line 
> field value in the
>"Write to PORT a `recutils' record of package P, arranging to fit within
>  WIDTH columns."
>(define (description->recutils str)
> -(let ((str (P_ str)))
> -  (string->recutils
> -   (fill-paragraph str width
> -   (string-length "description: ")
> +(string->recutils
> + (fill-paragraph str width (string-length "description: "

One last thing (I swear!).

AFAICS ‘stexi->plain-text’ already does paragraph filling, so the call
above is redundant (and could break the rendering.)

However, the width of the rendered text is fixed, unlike what
‘string->recutils’ did so far.  To work around that, we’ll have to
monkey-patch the ‘wrap*’ procedure of (texinfo plain-text), along these
lines:

  (define %text-width
(make-parameter (or (and=> (getenv "WIDTH") string->number)
80)))

  (set! (@@ (texinfo plain-text) wrap*)
(lambda strings
  ... #:line-width (%text-width) ...))

and then in ‘package->recutils’, we need to ‘parameterize’ that.

We need a similar hack for #:initial-indent, that would allow us to
mimic the 3rd argument of ‘fill-paragraph’.

Could you try it?

> From 3c69e9f79f4d5bd5a75d4c083769caf32c1a63ec Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin 
> Date: Thu, 27 Aug 2015 17:51:11 +0200
> Subject: [PATCH] website: packages: Support Texinfo's markup.
>
> * website/www/packages.scm (package->sxml): Adapt to new Texinfo's
>   markup in package description.

LGTM!

Thanks,
Ludo’.

Re: Texinfo in descriptions?

[Alex Kost]

Mathieu Lirzin (2015-08-28 00:04 +0300) wrote:

 l...@gnu.org (Ludovic Courtès) writes:

 With Benno being OK, we should start looking at implementing the change.
 The various parts that I can think of are:

   • Having a ‘package-description-string’ procedure that would return
 the description rendered as a string, using the (stexi) modules.

   • ‘--search’ could use the raw description (including markup).
 However, ‘package-recutils’ must use ‘package-description-string’
 or similar.

 Here is a first attempt.  It doesn't feel right to me but fornow I don't
 know what to do without duplicating code or reorganizing the world.  The
 problem is that translations are handle in (guix ui) so we need to
 regenerate texi-plain-text.

I don't understand what you mean by 'regenerate texi-plain-text'.

 -  (define (description-recutils str)
 -(let ((str (P_ str)))
 +  (define (description-recutils str)
 +(let ((str (texi-plain-text (P_ str

IIUC there is no need to use 'texi-plain-text' here.  Instead you can
replace 'package-description' with 'package-description-string' in the
body of 'package-recutils'.  Or did I miss anything?

Also I think the same replacement should be done in (guix scripts lint)
and (guix scripts package).

The rest looks absolutely fine for me.
-- 
Alex

Re: Texinfo in descriptions?

[Alex Kost]

Ludovic Courtès (2015-08-30 20:23 +0300) wrote:

 Mathieu Lirzin m...@openmailbox.org skribis:

 From e98c0ec3b609c077bf471cf838f12f54a89a0226 Mon Sep 17 00:00:00 2001
 From: Mathieu Lirzin m...@openmailbox.org
 Date: Fri, 7 Aug 2015 00:10:43 +0200
 Subject: [PATCH] packages: Add package-description-string.

 * guix/packages.scm (package-description-string): New variable.
 * guix/utils.scm (texi-plain-text): Likewise.
 * guix/ui.scm (package-recutils): Use it.
 * gnu/packages/perl.scm (perl-devel-globaldestruction)
   (perl-devel-lexalias, perl-exporter-lite): Adapt to Texinfo's markup.
 * gnu/packages/python.scm (python2-empy): Likewise.

 LGTM.

 We must also make sure that the Emacs UI (and guix-web, but that’s a
 different repo) use ‘package-description-string’ instead of
 ‘package-description’.

 For Emacs, I think it’s enough to
 s/package-description/package-description-string/ in guix-main.scm.
 Alex?

Yes, and there is only one 'package-description' in guix-main.scm.

-- 
Alex

Re: Texinfo in descriptions?

[Mathieu Lirzin]

Here is an updated patch.

l...@gnu.org (Ludovic Courtès) writes:

 Mathieu Lirzin m...@openmailbox.org skribis:

 From e98c0ec3b609c077bf471cf838f12f54a89a0226 Mon Sep 17 00:00:00 2001
 From: Mathieu Lirzin m...@openmailbox.org
 Date: Fri, 7 Aug 2015 00:10:43 +0200
 Subject: [PATCH] packages: Add package-description-string.

 * guix/packages.scm (package-description-string): New variable.
 * guix/utils.scm (texi-plain-text): Likewise.
 * guix/ui.scm (package-recutils): Use it.
 * gnu/packages/perl.scm (perl-devel-globaldestruction)
   (perl-devel-lexalias, perl-exporter-lite): Adapt to Texinfo's markup.
 * gnu/packages/python.scm (python2-empy): Likewise.

 LGTM.

 We must also make sure that the Emacs UI (and guix-web, but that’s a
 different repo) use ‘package-description-string’ instead of
 ‘package-description’.

 For Emacs, I think it’s enough to
 s/package-description/package-description-string/ in guix-main.scm.
 Alex?

Added.


  5 files changed, 20 insertions(+), 5 deletions(-)

 I like that it’s all it takes.  :-)

5 files changed, 18 insertions(+), 11 deletions(-)
Can you say less?! :)

 Any performance figures?  For instance, time of ‘guix package -s’ before
 and after?

With the updated patch I have obtained the following results for command

  time ./pre-inst-env guix package -s e

- without patch:
real0m25.381s
user0m8.740s
sys 0m0.184s

- with patch:
real0m24.556s
user0m10.448s
sys 0m0.220s

This test has revealed one missing modification for perl-dbd-pg
package description.

 What about moving ‘package-description-string’ to (guix ui) and have it
 do both rendering and translation?

 If an application really needs rendered-but-not-translated stuff, it can
 always use (compose texi-fragment-text package-description); I think
 that’d be an unusual use case anyway.

Yeah that's a nice minimal solution! Thanks.

From bb1ce4f315912e49d4416c2ed213f5f93e802db1 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin m...@openmailbox.org
Date: Fri, 7 Aug 2015 00:10:43 +0200
Subject: [PATCH] ui: Add package-description-string.

Provide support for Texinfo's markup in package description.

* guix/ui.scm (package-description-string): New variable.
  (package-recutils): Use it.
* emacs/guix-main.scm (%package-param-alist): Likewise.
* gnu/packages/databases.scm (perl-dbd-pg): Adapt to Texinfo's markup.
* gnu/packages/perl.scm (perl-devel-globaldestruction)
  (perl-devel-lexalias, perl-exporter-lite): Likewise.
* gnu/packages/python.scm (python2-empy): Likewise.
---
 emacs/guix-main.scm|  2 +-
 gnu/packages/databases.scm |  2 +-
 gnu/packages/perl.scm  |  6 +++---
 gnu/packages/python.scm|  2 +-
 guix/ui.scm| 17 -
 5 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/emacs/guix-main.scm b/emacs/guix-main.scm
index fe224fb..73173f2 100644
--- a/emacs/guix-main.scm
+++ b/emacs/guix-main.scm
@@ -281,7 +281,7 @@ Example:
 (license   . ,package-license-names)
 (source. ,package-source-names)
 (synopsis  . ,package-synopsis)
-(description   . ,package-description)
+(description   . ,package-description-string)
 (home-url  . ,package-home-page)
 (outputs   . ,package-outputs)
 (non-unique. ,(negate package-unique?))
diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index cbac16e..1710d0e 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -578,7 +578,7 @@ columns, primary keys, unique constraints and relationships.)
(postgresql ,postgresql)))
 (home-page http://search.cpan.org/dist/DBD-Pg;)
 (synopsis DBI PostgreSQL interface)
-(description )
+(description #f)
 (license (package-license perl
 
 (define-public perl-dbd-sqlite
diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index f784798..0236d05 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -1665,7 +1665,7 @@ particular command is available.)
 (home-page http://search.cpan.org/dist/Devel-GlobalDestruction;)
 (synopsis Provides equivalent of ${^GLOBAL_PHASE} eq 'DESTRUCT' for older perls)
 (description Devel::GlobalDestruction provides a function returning the
-equivalent of \${^GLOBAL_PHASE} eq 'DESTRUCT'\ for older perls.)
+equivalent of \$@{^GLOBAL_PHASE@} eq 'DESTRUCT'\ for older perls.)
 (license (package-license perl
 
 (define-public perl-devel-lexalias
@@ -1909,7 +1909,7 @@ constructors, which speeds code up at runtime by a significant amount.  String
 eval is not without its issues however - it's difficult to control the scope
 it's used in (which determines which variables are in scope inside the eval),
 and it's easy to miss compilation errors, since eval catches them and sticks
-them in $@ instead.  This module attempts to solve these problems.  It
+them in $@@ instead.  This module attempts to solve these problems.  It
 provides an eval_closure function, which 

Re: Texinfo in descriptions?

[Ludovic Courtès]

Mathieu Lirzin m...@openmailbox.org skribis:

 From e98c0ec3b609c077bf471cf838f12f54a89a0226 Mon Sep 17 00:00:00 2001
 From: Mathieu Lirzin m...@openmailbox.org
 Date: Fri, 7 Aug 2015 00:10:43 +0200
 Subject: [PATCH] packages: Add package-description-string.

 * guix/packages.scm (package-description-string): New variable.
 * guix/utils.scm (texi-plain-text): Likewise.
 * guix/ui.scm (package-recutils): Use it.
 * gnu/packages/perl.scm (perl-devel-globaldestruction)
   (perl-devel-lexalias, perl-exporter-lite): Adapt to Texinfo's markup.
 * gnu/packages/python.scm (python2-empy): Likewise.

LGTM.

We must also make sure that the Emacs UI (and guix-web, but that’s a
different repo) use ‘package-description-string’ instead of
‘package-description’.

For Emacs, I think it’s enough to
s/package-description/package-description-string/ in guix-main.scm.
Alex?

  5 files changed, 20 insertions(+), 5 deletions(-)

I like that it’s all it takes.  :-)

Any performance figures?  For instance, time of ‘guix package -s’ before
and after?

 That was my first solution before realizing that this will lead to a
 problem that this unrealistic example illustrates.

   ;; with fr_FR.UTF-8 locale

   (package-description foo)
   = socks @code{foo}.

   (package-description-string foo)
   = socks `foo'.\n\n

   (N_ (package-description foo))
   = chaussettes @code{foo}.

   (N_ (package-description-string foo))
   = socks `foo'.\n\n

 In the last evaluation gettext was unable to find the translated string
 corresponding to msgid socks `foo'.\n\n.

What about moving ‘package-description-string’ to (guix ui) and have it
do both rendering and translation?

If an application really needs rendered-but-not-translated stuff, it can
always use (compose texi-fragment-text package-description); I think
that’d be an unusual use case anyway.

 Also I think the same replacement should be done in (guix scripts
 lint) ...

 I think more can be done in (guix scripts lint).  For example checking
 if invoking 'package-description-string' fails which would indicate that
 the markup is not correctly used.

Sure, we should do that after.

 ... and (guix scripts package).

 This script uses 'package-description' to search in it.  IIUC it was
 suggested by Ludo to search using the raw Texinfo fragment and to
 display using the plain-text version.
 https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00609.html

Right, since ‘package-recutils’ uses ‘package-description-string’, we
know that all the output is correctly rendered and translated.

Nice work, thanks!

Ludo’.

Re: Texinfo in descriptions?

[Mathieu Lirzin]

Alex Kost alez...@gmail.com writes:

 Mathieu Lirzin (2015-08-28 00:04 +0300) wrote:

 Here is a first attempt.  It doesn't feel right to me but fornow I don't
 know what to do without duplicating code or reorganizing the world.  The
 problem is that translations are handle in (guix ui) so we need to
 regenerate texi-plain-text.

 I don't understand what you mean by 'regenerate texi-plain-text'.

Maybe the correct expression should have been reiterate
texi-plain-text.  What I meant was that the process of converting from
texinfo to plain-text need to be done in (guix ui) too, because
translated package description are texinfo fragment.

 -  (define (description-recutils str)
 -(let ((str (P_ str)))
 +  (define (description-recutils str)
 +(let ((str (texi-plain-text (P_ str

 IIUC there is no need to use 'texi-plain-text' here.  Instead you can
 replace 'package-description' with 'package-description-string' in the
 body of 'package-recutils'.  Or did I miss anything?

That was my first solution before realizing that this will lead to a
problem that this unrealistic example illustrates.

  ;; with fr_FR.UTF-8 locale

  (package-description foo)
  = socks @code{foo}.

  (package-description-string foo)
  = socks `foo'.\n\n

  (N_ (package-description foo))
  = chaussettes @code{foo}.

  (N_ (package-description-string foo))
  = socks `foo'.\n\n

In the last evaluation gettext was unable to find the translated string
corresponding to msgid socks `foo'.\n\n.

 Also I think the same replacement should be done in (guix scripts
 lint) ...

I think more can be done in (guix scripts lint).  For example checking
if invoking 'package-description-string' fails which would indicate that
the markup is not correctly used.

 ... and (guix scripts package).

This script uses 'package-description' to search in it.  IIUC it was
suggested by Ludo to search using the raw Texinfo fragment and to
display using the plain-text version.
https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00609.html

Thank you very much for your reply, :)

--
Mathieu Lirzin

Re: Texinfo in descriptions?

[Mathieu Lirzin]

Mathieu Lirzin m...@openmailbox.org writes:

 From 665c92dc5e9976719ac7a6e427253b6ee65c78d8 Mon Sep 17 00:00:00 2001
 From: Mathieu Lirzin m...@openmailbox.org
 Date: Fri, 7 Aug 2015 00:10:43 +0200
 Subject: [PATCH] packages: Add package-description-string.

 * guix/packages.scm (package-description-string): New variable.
 * guix/utils.scm (texi-plain-text): Likewise.
 * guix/ui.scm (package-recutils): Use it.
 * gnu/packages/perl.scm (perl-devel-globaldestruction)
   (perl-devel-lexalias, perl-exporter-lite): Adapt to Texinfo's markup.
 * gnu/packages/python.scm (python2-empy): Likewise.
 ---
  gnu/packages/perl.scm   | 6 +++---
  gnu/packages/python.scm | 2 +-
  guix/packages.scm   | 6 ++
  guix/ui.scm | 5 +++--
  guix/utils.scm  | 8 
  5 files changed, 21 insertions(+), 6 deletions(-)

[...]
 -  (define (description-recutils str)
 -(let ((str (P_ str)))
 +  (define (description-recutils package)
^^^
 +(let ((str (texi-plain-text (P_ str
(string-recutils
 (fill-paragraph str width
 (string-length description: )

There is a mistake here, it should be 'str' instead of 'package'.

Here is the updated draft.

From e98c0ec3b609c077bf471cf838f12f54a89a0226 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin m...@openmailbox.org
Date: Fri, 7 Aug 2015 00:10:43 +0200
Subject: [PATCH] packages: Add package-description-string.

* guix/packages.scm (package-description-string): New variable.
* guix/utils.scm (texi-plain-text): Likewise.
* guix/ui.scm (package-recutils): Use it.
* gnu/packages/perl.scm (perl-devel-globaldestruction)
  (perl-devel-lexalias, perl-exporter-lite): Adapt to Texinfo's markup.
* gnu/packages/python.scm (python2-empy): Likewise.
---
 gnu/packages/perl.scm   | 6 +++---
 gnu/packages/python.scm | 2 +-
 guix/packages.scm   | 6 ++
 guix/ui.scm | 3 ++-
 guix/utils.scm  | 8 
 5 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index f784798..0236d05 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -1665,7 +1665,7 @@ particular command is available.)
 (home-page http://search.cpan.org/dist/Devel-GlobalDestruction;)
 (synopsis Provides equivalent of ${^GLOBAL_PHASE} eq 'DESTRUCT' for older perls)
 (description Devel::GlobalDestruction provides a function returning the
-equivalent of \${^GLOBAL_PHASE} eq 'DESTRUCT'\ for older perls.)
+equivalent of \$@{^GLOBAL_PHASE@} eq 'DESTRUCT'\ for older perls.)
 (license (package-license perl
 
 (define-public perl-devel-lexalias
@@ -1909,7 +1909,7 @@ constructors, which speeds code up at runtime by a significant amount.  String
 eval is not without its issues however - it's difficult to control the scope
 it's used in (which determines which variables are in scope inside the eval),
 and it's easy to miss compilation errors, since eval catches them and sticks
-them in $@ instead.  This module attempts to solve these problems.  It
+them in $@@ instead.  This module attempts to solve these problems.  It
 provides an eval_closure function, which evals a string in a clean
 environment, other than a fixed list of specified variables.  Compilation
 errors are rethrown automatically.)
@@ -1953,7 +1953,7 @@ in your modules in a \Java-esque\ manner.)
 (description
  Exporter::Lite is an alternative to Exporter, intended to provide a
 lightweight subset of the most commonly-used functionality.  It supports
-import(), @EXPORT and @EXPORT_OK and not a whole lot else.)
+import(), @@EXPORT and @@EXPORT_OK and not a whole lot else.)
 (home-page (string-append http://search.cpan.org/~neilb/;
   Exporter-Lite- version))
 (license (package-license perl
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 940efec..07275d7 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -1171,7 +1171,7 @@ other Python program.)
  EmPy is a system for embedding Python expressions and statements in
 template text; it takes an EmPy source file, processes it, and produces
 output.  This is accomplished via expansions, which are special signals to the
-EmPy system and are set off by a special prefix (by default the at sign, @).
+EmPy system and are set off by a special prefix (by default the at sign, @@).
 EmPy can expand arbitrary Python expressions and statements in this way, as
 well as a variety of special forms.  Textual data not explicitly delimited in
 this way is sent unaffected to the output, allowing Python to be used in
diff --git a/guix/packages.scm b/guix/packages.scm
index 3983d14..56d0f56 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014, 2015 Ludovic Courtès l...@gnu.org
+;;; Copyright © 2015 Mathieu Lirzin m...@openmailbox.org
 ;;; 

Re: Texinfo in descriptions?

[Mathieu Lirzin]

Andy Wingo wi...@igalia.com writes:

 Will all docstrings be parsed as texinfo?  To me this is the proper
 solution, since plain text is mostly a subset of texinfo.

Yes, that's the idea.

  It could be
 that all descriptions are already texinfo.  You just have to be careful
 about @ { and } when used literally -- they need replacing with @@ @{
 and @}.

 In Guile I've had a hack that tries to render docstrings as texinfo,
 falling back to a @verbatim block otherwise, but I don't recommend it:

   (use-modules (texinfo) (texinfo plain-text) (ice-9 regexp))

   (define many-space? (make-regexp [[:space:]][[:space:]][[:space:]]))
   (define initial-space? (make-regexp ^[[:space:]]))
   (define (string-stexi str)
 (or (and (or (not str) (string-null? str))
  '(*fragment*))
 (and (or (string-index str #\@)
  (and (not (regexp-exec many-space? str))
   (not (regexp-exec initial-space? str
  (false-if-exception
   (texi-fragment-stexi str)))
 `(*fragment* (verbatim ,str
   (define (string-format str)
 (stexi-plain-text (string-stexi str)))

 Better to just adopt texinfo and fix up any descriptions that need it.
 Probably you could use guix package -s and recutils to grep for
 descriptions that need patching.

Thank you very much for the tips and experience sharing!

--
Mathieu Lirzin

Re: Texinfo in descriptions?

[Mathieu Lirzin]

l...@gnu.org (Ludovic Courtès) writes:

 With Benno being OK, we should start looking at implementing the change.
 The various parts that I can think of are:

   • Having a ‘package-description-string’ procedure that would return
 the description rendered as a string, using the (stexi) modules.

   • ‘--search’ could use the raw description (including markup).
 However, ‘package-recutils’ must use ‘package-description-string’
 or similar.

Here is a first attempt.  It doesn't feel right to me but fornow I don't
know what to do without duplicating code or reorganizing the world.  The
problem is that translations are handle in (guix ui) so we need to
regenerate texi-plain-text.

From 665c92dc5e9976719ac7a6e427253b6ee65c78d8 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin m...@openmailbox.org
Date: Fri, 7 Aug 2015 00:10:43 +0200
Subject: [PATCH] packages: Add package-description-string.

* guix/packages.scm (package-description-string): New variable.
* guix/utils.scm (texi-plain-text): Likewise.
* guix/ui.scm (package-recutils): Use it.
* gnu/packages/perl.scm (perl-devel-globaldestruction)
  (perl-devel-lexalias, perl-exporter-lite): Adapt to Texinfo's markup.
* gnu/packages/python.scm (python2-empy): Likewise.
---
 gnu/packages/perl.scm   | 6 +++---
 gnu/packages/python.scm | 2 +-
 guix/packages.scm   | 6 ++
 guix/ui.scm | 5 +++--
 guix/utils.scm  | 8 
 5 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index f784798..0236d05 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -1665,7 +1665,7 @@ particular command is available.)
 (home-page http://search.cpan.org/dist/Devel-GlobalDestruction;)
 (synopsis Provides equivalent of ${^GLOBAL_PHASE} eq 'DESTRUCT' for older perls)
 (description Devel::GlobalDestruction provides a function returning the
-equivalent of \${^GLOBAL_PHASE} eq 'DESTRUCT'\ for older perls.)
+equivalent of \$@{^GLOBAL_PHASE@} eq 'DESTRUCT'\ for older perls.)
 (license (package-license perl
 
 (define-public perl-devel-lexalias
@@ -1909,7 +1909,7 @@ constructors, which speeds code up at runtime by a significant amount.  String
 eval is not without its issues however - it's difficult to control the scope
 it's used in (which determines which variables are in scope inside the eval),
 and it's easy to miss compilation errors, since eval catches them and sticks
-them in $@ instead.  This module attempts to solve these problems.  It
+them in $@@ instead.  This module attempts to solve these problems.  It
 provides an eval_closure function, which evals a string in a clean
 environment, other than a fixed list of specified variables.  Compilation
 errors are rethrown automatically.)
@@ -1953,7 +1953,7 @@ in your modules in a \Java-esque\ manner.)
 (description
  Exporter::Lite is an alternative to Exporter, intended to provide a
 lightweight subset of the most commonly-used functionality.  It supports
-import(), @EXPORT and @EXPORT_OK and not a whole lot else.)
+import(), @@EXPORT and @@EXPORT_OK and not a whole lot else.)
 (home-page (string-append http://search.cpan.org/~neilb/;
   Exporter-Lite- version))
 (license (package-license perl
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 940efec..07275d7 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -1171,7 +1171,7 @@ other Python program.)
  EmPy is a system for embedding Python expressions and statements in
 template text; it takes an EmPy source file, processes it, and produces
 output.  This is accomplished via expansions, which are special signals to the
-EmPy system and are set off by a special prefix (by default the at sign, @).
+EmPy system and are set off by a special prefix (by default the at sign, @@).
 EmPy can expand arbitrary Python expressions and statements in this way, as
 well as a variety of special forms.  Textual data not explicitly delimited in
 this way is sent unaffected to the output, allowing Python to be used in
diff --git a/guix/packages.scm b/guix/packages.scm
index 3983d14..56d0f56 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014, 2015 Ludovic Courtès l...@gnu.org
+;;; Copyright © 2015 Mathieu Lirzin m...@openmailbox.org
 ;;; Copyright © 2014, 2015 Mark H Weaver m...@netris.org
 ;;;
 ;;; This file is part of GNU Guix.
@@ -71,6 +72,7 @@
 package-replacement
 package-synopsis
 package-description
+package-description-string
 package-license
 package-home-page
 package-supported-systems
@@ -315,6 +317,10 @@ representation.
   Return the full name of PACKAGE--i.e., `NAME-VERSION'.
   (string-append (package-name package) - (package-version package)))
 
+(define (package-description-string package)

Re: Texinfo in descriptions?

[Andy Wingo]

On Wed 26 Aug 2015 00:09, Mathieu Lirzin m...@openmailbox.org writes:

 l...@gnu.org (Ludovic Courtès) writes:

 Mathieu Lirzin m...@openmailbox.org skribis:

 Andreas Enge andr...@enge.fr writes:

 On Wed, Jul 22, 2015 at 11:24:10PM +0200, Ludovic Courtès wrote:
 With Benno being OK, we should start looking at implementing the change.

 Good news! I'm interested in implementing this change.  I can't dedicate
 my time to do this right now, but I can do it within a period of one
 month.  If someone is willing to do the work sooner, I have no problem
 with that.

 FWIW I won’t be working (at all ;-)) in the coming weeks, so I’m happy
 if you (or someone else) works on this sometime while I’m away.  :-)

 I'm sending this email to notify that even if the estimated period of
 work has ended.  I am still working on it.

Will all docstrings be parsed as texinfo?  To me this is the proper
solution, since plain text is mostly a subset of texinfo.  It could be
that all descriptions are already texinfo.  You just have to be careful
about @ { and } when used literally -- they need replacing with @@ @{
and @}.

In Guile I've had a hack that tries to render docstrings as texinfo,
falling back to a @verbatim block otherwise, but I don't recommend it:

  (use-modules (texinfo) (texinfo plain-text) (ice-9 regexp))

  (define many-space? (make-regexp [[:space:]][[:space:]][[:space:]]))
  (define initial-space? (make-regexp ^[[:space:]]))
  (define (string-stexi str)
(or (and (or (not str) (string-null? str))
 '(*fragment*))
(and (or (string-index str #\@)
 (and (not (regexp-exec many-space? str))
  (not (regexp-exec initial-space? str
 (false-if-exception
  (texi-fragment-stexi str)))
`(*fragment* (verbatim ,str
  (define (string-format str)
(stexi-plain-text (string-stexi str)))

Better to just adopt texinfo and fix up any descriptions that need it.
Probably you could use guix package -s and recutils to grep for
descriptions that need patching.

Andy

Re: Texinfo in descriptions?

[Mathieu Lirzin]

l...@gnu.org (Ludovic Courtès) writes:

 Mathieu Lirzin m...@openmailbox.org skribis:

 Andreas Enge andr...@enge.fr writes:

 On Wed, Jul 22, 2015 at 11:24:10PM +0200, Ludovic Courtès wrote:
 With Benno being OK, we should start looking at implementing the change.

 Good news! I'm interested in implementing this change.  I can't dedicate
 my time to do this right now, but I can do it within a period of one
 month.  If someone is willing to do the work sooner, I have no problem
 with that.

 FWIW I won’t be working (at all ;-)) in the coming weeks, so I’m happy
 if you (or someone else) works on this sometime while I’m away.  :-)

I'm sending this email to notify that even if the estimated period of
work has ended.  I am still working on it.

--
Mathieu Lirzin

Re: Texinfo in descriptions?

[Ludovic Courtès]

Andreas Enge andr...@enge.fr skribis:

 On Wed, Jul 22, 2015 at 11:24:10PM +0200, Ludovic Courtès wrote:
 With Benno being OK, we should start looking at implementing the change.

 Is there a consensus on the usefulness of the change? So far (but this may
 be a classical case of confirmation bias) I noticed mainly voices against
 the use of markup or at least with moderated enthusiasm.

With my own bias ;-), I didn’t notice opposition to markup, but I’m
happy to (re)read arguments that I overlooked.

But really, I expect that maybe 80% of the descriptions won’t contain
any markup.  I do not expect markup to become pervasive, though of
course there’ll be a temptation to use @code instead of quotes in some
places, for instance (but I would reject a patch that replaces all
quotes with @code, for example.)

Ludo’.

Re: Texinfo in descriptions?

[Ludovic Courtès]

Mathieu Lirzin m...@openmailbox.org skribis:

 Andreas Enge andr...@enge.fr writes:

 On Wed, Jul 22, 2015 at 11:24:10PM +0200, Ludovic Courtès wrote:
 With Benno being OK, we should start looking at implementing the change.

 Good news! I'm interested in implementing this change.  I can't dedicate
 my time to do this right now, but I can do it within a period of one
 month.  If someone is willing to do the work sooner, I have no problem
 with that.

FWIW I won’t be working (at all ;-)) in the coming weeks, so I’m happy
if you (or someone else) works on this sometime while I’m away.  :-)

Ludo’.

Re: Texinfo in descriptions?

[Daniel Pimentel]

On 2015-07-23 10:57, l...@gnu.org wrote:

Mathieu Lirzin m...@openmailbox.org skribis:


Andreas Enge andr...@enge.fr writes:


On Wed, Jul 22, 2015 at 11:24:10PM +0200, Ludovic Courtès wrote:
With Benno being OK, we should start looking at implementing the 
change.


Good news! I'm interested in implementing this change.  I can't 
dedicate

my time to do this right now, but I can do it within a period of one
month.  If someone is willing to do the work sooner, I have no problem
with that.


FWIW I won’t be working (at all ;-)) in the coming weeks, so I’m happy
if you (or someone else) works on this sometime while I’m away.  :-)

Ludo’.

I'd like help. What do I do?
--
Daniel Pimentel (d4n1 3:)

Re: Texinfo in descriptions?

[Andreas Enge]

So there actually seems to be quite a bit of enthusiasm for this feature,
which proves me wrong! :-)

Andreas

Re: Texinfo in descriptions?

[Mathieu Lirzin]

Andreas Enge andr...@enge.fr writes:

 On Wed, Jul 22, 2015 at 11:24:10PM +0200, Ludovic Courtès wrote:
 With Benno being OK, we should start looking at implementing the change.

Good news! I'm interested in implementing this change.  I can't dedicate
my time to do this right now, but I can do it within a period of one
month.  If someone is willing to do the work sooner, I have no problem
with that.

 Is there a consensus on the usefulness of the change? So far (but this may
 be a classical case of confirmation bias) I noticed mainly voices against
 the use of markup or at least with moderated enthusiasm.

I agree with you that there is room for discussion.

IMO Texinfo markup is a good compromise between using HTML or ASCII.  It
is lightweight enough to not be intrusive, and It is not specific to
Guix.  I think the last point is important because choosing texinfo
means we have a full documentation to which we can refer, plus an already
implemented Guile module for text manipulation.  Eventually using
texinfo participate in the unity of the GNU project.

At least my enthusiasm cannot be described as moderated now ;).  My
concerns were about translation issues but since we got the green light
from Benno, I am totally OK with the choice of texinfo.

--
Mathieu Lirzin

Re: Texinfo in descriptions?

[Ludovic Courtès]

Mathieu Lirzin m...@openmailbox.org skribis:

 l...@gnu.org (Ludovic Courtès) writes:

[...]

 As much as I would appreciate texinfo markup in that context, I think it
 will still confuse our translator friends.  In 
 (info (gettext)Preparing Strings) we can found this:

[...]

 Sure HTML markup will not be pretty, but at least it will not encourage
 people to put lists everywhere (for example for listing features instead
 of describing what the package is doing).

Well, we can email the coordinator asking what they think of this.
Although not my favorite choice, HTML/XML would be fine too, as long as
we restrict ourselves to a clear subset.

(gnu.org actually uses the descriptions from the Womb (like we do), but
adds HTML markup in it:
https://lists.gnu.org/archive/html/guix-devel/2014-01/msg00074.html.)

 My secret dream is that descriptions (and their translation) would be
 managed directly in the FSD (Free Software Directory) so that we can
 import those directly and care only about the building and deployment
 process ;).

This has been discussed in the past (‘TODO’ has an item about it.)
Unfortunately, there is currently no way to do it automatically.  I’m
also not sure whether our criteria match theirs.

Thanks,
Ludo’.

Re: Texinfo in descriptions?

[Andreas Enge]

On Wed, Jul 22, 2015 at 11:24:10PM +0200, Ludovic Courtès wrote:
 With Benno being OK, we should start looking at implementing the change.

Is there a consensus on the usefulness of the change? So far (but this may
be a classical case of confirmation bias) I noticed mainly voices against
the use of markup or at least with moderated enthusiasm.

Andreas