Re: [PATCH 1/2] ox-texinfo: Turn a description list item with "+" bullet into @itemx

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Hello,

Jonas Bernoulli <jonas@bernoul.li> writes:

> I vaguely remember having run into this feature before when using Org to
> record a pros and cons list.  As a maintainer I don't like this question
> but; could this feature be made optional?  (Of course one could use tags
> to indicate whether an item is a pro or cons, but for such a simple use-
> case that seems more work than necessary and less immediately
> obvious.)

You can also make two lists. I don't think we should provide "pros ans
cons list", because it has implications outside export.

> This bothered me a bit too when writing it but at the same time
> it seemed like overkill to replicate the docstrings of the called
> functions.  How do you feel about using a hook instead?
>
> (defvar org-texinfo--filter-parse-tree-functions
>   '(org-texinfo--normalize-headlines
>     org-texinfo--normalize-items)
>   "List of functions the `texinfo' back-end applies to the parsed tree.
> Each filter is called with three arguments: the parse tree, as
> returned by `org-element-parse-buffer', the back-end, as
> a symbol, and the communication channel, as a plist.  It must
> return the modified parse tree to transcode.")

Sure.

> Do you prefer to add the hook functions as done above or should each one
> be added individually using add-hook?

`add-hook' is more for users, I think.

> Done.  Is this okay?:
>
>               (when (and next-item
>                          (string-prefix-p
>                           "+"
>                           (org-element-property :bullet next-item)))
>
> Or should the line-breaks go elsewhere?

The line breaks do not matter much but it may fail if
(org-element-property :bullet next-item) returns nil.

>> Anyhow, relying on mixed bullets is not great…
>
> The alternative isn't great either.
>
> For example:
>
> - Key: C-c C-w (forge-browse-TYPE) ::
> + Key: C-c C-w (forge-browse-dwim) ::
> + Key: N b I (forge-browse-issues) ::
> + Key: N b P (forge-browse-pullreqs) ::
> + Key: N b t (forge-browse-topic) ::
> + Key: N b i (forge-browse-issue) ::
> + Key: N b p (forge-browse-pullreq) ::
>
>   These commands visit the topic, issue(s), pull-request(s), post,
>   branch, commit, or remote at point in a browser. ...
>
> vs.
>
> - Key: C-c C-w (forge-browse-TYPE), C-c C-w (forge-browse-dwim), N b I (forge-browse-issues), N b P (forge-browse-pullreqs), N b t (forge-browse-topic), N b i (forge-browse-issue), N b p (forge-browse-pullreq) ::
>
>   These commands visit the topic, issue(s), pull-request(s), post,
>   branch, commit, or remote at point in a browser. ...
>
> I am sure I am gonna make mistakes when using the latter approach.

True, but OTOH, the first option is not really possible. However, there
are still alternatives. For example, you could check blank lines between
items:

  - key: a ::
  - key: b ::

  - key: c ::
  - key: d ::

I suggest to require a special attribute before doing so, e.g.,

  #+attr_texinfo: :compact t
  - key: a ::
  - key: b ::

  - key: c ::
  - key: d ::

Another option would be to merge consecutive lists with such an
attribute, for the same result:

  #+attr_texinfo: :compact t
  - key: a ::
  - key: b ::

  #+attr_texinfo: :compact t
  - key: c ::
  - key: d ::


  - This is a regular list since it does not have :compact attribute.

IIRC, I did an experiment like this one when introducing matrices in
LaTeX export.

Regards,
-- 
Nicolas Goaziou