[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] ox-texinfo: Define definition commands using description

From: Jonas Bernoulli
Subject: Re: [PATCH 2/2] ox-texinfo: Define definition commands using description lists
Date: Mon, 27 Dec 2021 19:05:07 +0100

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> There's a mismatch between the keys.


> Simply put:
> Command in parenthesis, as done above, is optional.


>> +Regardless of which approach you use, you must define the =kbd= macro
>> +(see [[*Macro Replacement]]), which you can then use anywhere in the Org
>> +file:
>> +
>> +#+begin_example
>> +,#+macro: kbd (eval (let ((case-fold-search nil) (regexp (regexp-opt 
>> '("SPC" "RET" "LFD" "TAB" "BS" "ESC" "DELETE" "SHIFT" "Ctrl" "Meta" "Alt" 
>> "Cmd" "Super" "UP" "LEFT" "RIGHT" "DOWN") 'words))) (format 
>> "@@texinfo:@kbd{@@%s@@texinfo:}@@" (replace-regexp-in-string regexp 
>> "@@texinfo:@key{@@\\&@@texinfo:}@@" $1 t))))
>>  #+end_example
> Ouch. I don't think we should expect users to define this in order to
> use the feature being implemented. IOW, it should work out of the box.

Luckily that's already how it works; I just chose to not document the
fallback (done that now).  If the macro is not available, then @code{}
is used instead.

> I think the functions responsible for generating the Texinfo code should
> handle this without relying on the macro.

I tried but could not get it to work that way.  Whatever I tried
ox-texinfo insisted on breaking it by adding quotes.

I didn't go as far as to try injecting export-snippet elements into the
tree because without using org-macro-replace-all it seemed painful to do
that.  But on second thought...

Would it be okay to represent e.g. "C-c SPC" as:

    (:back-end "texinfo" :value "@kbd{C-c @key{SPC}}" :post-blank 0 :parent #2))

instead of the more painful to construct:

    (:back-end "texinfo" :value "@kbd{" :begin 317 :end 334 :post-blank 0 
:parent #2))
   #("C-c " 0 4
     (:parent #2))
    (:back-end "texinfo" :value "@key{" :begin 338 :end 355 :post-blank 0 
:parent #2))
   #("SPC" 0 3
     (:parent #2))
    (:back-end "texinfo" :value "}" :begin 358 :end 371 :post-blank 0 :parent 
    (:back-end "texinfo" :value "}" :begin 371 :end 384 :post-blank 0 :parent 

> Of course, if that part is
> factored out, the macro might, in turn, make use of it.

>> +(defconst org-texinfo--definition-command-regexp
>> +  (format "\\`%s: \\(.+\\)"
>> +          (regexp-opt
>> +           (delq nil (mapcar #'cdr org-texinfo--definition-command-alist))
>> +           1))
> What is 1 meaning here? Do you mean t?

Yes. Done.

>> +(defun org-texinfo--separate-definitions (tree _backend info)
>> +  "Split up descriptive lists that contain Texinfo definition
>> commands."
> You need to document the arguments.
>> +  (org-element-map tree 'plain-list
>> +    (lambda (plain-list)
>> +      (when (eq (org-element-property :type plain-list) 'descriptive)
>> +        (let ((contents (org-element-contents plain-list))
>> +              item items)
> Nitpick: (items nil)


>> +          (while (setq item (pop contents))
> nitpick: Use dolist.

Err, that's what I would usually do.  Not sure why not here.


>> +    (if (string-match " +(\\([^()]+\\)) *\\'" args)
> Could you use `rx' here?


(Not a fan personally.  IMO rx is less readable than a plain old
regexp, though that's probably just because I never took the time
to retrain myself.)

>> +        (setq key (substring args 0 (match-beginning 0))
>> +              cmd (match-string 1 args))
>> +      (setq key args))
>> +    (org-element-put-property
>> +     item :tag
>> +     (nconc (if (assoc "kbd" org-macro-templates)
>> +                (let ((templates org-macro-templates))
>> +                  (with-temp-buffer
>> +                    (insert (format "{{{kbd(%s)}}}" key))
> Here, there could be a function building the key chord, and you could
> wrap the result into a raw string (see `org-export-raw-string').

I think that is one of the things I tried that ox-texinfo insisted on
quoting anyway.  I might misremember, so I will have another look.
Above I suggested using an `export-snippet' element (instead of `raw');
to me that seems appropriate too.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]