Re: [PATCH] ob-shell-test, test-ob-shell and introduction
> Thank you, I was not aware of ":cmdline" argument and of ":shebang" as a > means to avoid stray prompts (I have seen mentions of similar problem > for other languages in this list). You're welcome! I was surprised to find those in the source. Glad to have documented them and even happier to hear that it's news to others. > - https://www.mirbsd.org/pics/logo-grey.png works only with http: > protocol for me. I updated (downgraded?) it to http. I'm also seeing that the kornshell logo is intermittently broken. Not quite sure the best way to go about fixing that. Maybe commit copies? Use something like archive.org? Sounds like a problem for someone else (e.g. future me). I'm out of time for tonight. > - I am unsure concerning example after "…or as a standlone script.", > maybe it should be wrapped into #+begin_example. Good call. That example was wonky. I've given a different one. Not sure it's better, though. I find the shebang behavior tricky to demo in a simple way. > - In some cases "sh" is used despite bashisms in the code like "declare" > or "echo -ne". Actually "printf" may be more convenient instead of "echo -n" > - "export" in session example is unnecessary. It is matter of taste > though. Bash and dash is not the case, but some shells require that > assignment and export should be separate commands. Good catch! Since arrays are only defined in ob-shell using bash, I've updated that example to use bash. Otherwise, I've removed the exports. > - In your examples variable values are simple. Often it is safer to add > double quotes around variable or command expansion. I would consider > adding quotes just to encourage people to do the same by default with > hope that less scripts will give strange results in response to a file > name containing a space. Actually my first impression was that > backslashes before quotes in some cases were added by mistake. Another > unescaped pair of quotes may make your intention more clear. However it > is related to code style where everybody has opinion, so I do not insist. I appreciate these clarifications. Admittedly, I'm not great with shell scripting. Your recommendations appear sound to me and I've tried to incorporate them. The updates have been made and are pushed. Thanks for your feedback!
Re: Feedback on Emacs-Jupyter
Dear Nathaniel, Let me echo others’ comments by saying how much I appreciate your work on emacs-jupyter. I use the package daily in my work and it’s been really fantastic. Thank you very, very much for your huge efforts and time investment in creating and maintaining this package. emacs-jupyter has proved so useful that I’ve been collecting a list of suggested improvements - I was actually intending on trying to contribute some of these myself, but I think it would be good to discuss first with you and other users of emacs-jupyter (is there an emacs-jupyter mailing list or preferred venue?). For now I’ll just share what I think would be the biggest improvement for my use case. I use emacs-jupyter to connect from my laptop to remote jupyter kernels and notebook servers running on powerful machines provided by my employer. I work in a notebook locally on my laptop, but execute code blocks remotely. I specify a single remote jupyter notebook server+kernel to connect to in a #+PROPERTY line at the top of my org file which globally sets header-args for jupyter-python to include the correct :session argument. For me, the biggest improvements would be addressing some pain points with disconnecting/reconnecting to the jupyter notebook server or kernel. I don’t have technical suggestions yet on how these could be addressed, so I’ll just describe the user experience side of things. 1) Reconnecting to the notebook server after disconnecting. Commonly I’ll work in my notebook, then take a break and close my laptop or disconnect from my work VPN. When I re-open my laptop/reconnect to VPN it seems like the connections to the remote notebook server are in a bad state (this may be a tramp thing, also). Currently my work around is to kill the associated emacs jupyter REPL buffer, then navigate to one of the source blocks in the notebook and run org-babel-pop-to-session which has the side-effect of re-connecting to the jupyter notebook server and recreating the jupyter REPL buffer. The main downside to this workaround is that the scroll back history of the REPL buffer is lost, since the buffer was killed. It would be great to be able to re-establish the connection to the REPL without discarding the buffer. 2) Getting results from a running block after disconnecting/reconnecting. Currently it’s difficult to manage long-running code blocks using emacs-jupyter if I disconnect from the remote server while the code block is running. The work around in #1 above to re-connect to a remote kernel doesn’t work if the kernel is still executing a block. If the kernel has completed executing the block, then the results are not populated back into the notebook (the execution UUID populated when the code block began executing remains). I don’t know much about jupyter, but I saw some jupyter logs about buffered messages. Perhaps jupyter buffers output when a remote client disconnects? If so, maybe this buffered output could be replayed in a notebook when the emacs jupyter REPL connection is re-established? 3) Similarly, improving feedback from a long-running block would be very helpful. Currently you can use print statements in a long running block to report progress, but these are lost after disconnecting (maybe they are buffered on the jupyter server side and could be replayed on reconnect?). Further, I don’t know if this is feasible, but it would be amazing to have support for progress bars for long-running tasks (e.g., have a tqdm progress bar render in the org notebook). Thanks again for the wonderful package - I hope we can talk a bit more about some of these friction points. I’d be happy to give a crack at contributing a PR, if that would be welcome. Thank you, David > On Jan 4, 2022, at 15:24, Nathaniel Nicandro > wrote: > > > Hello all, > > I'm the maintainer of the emacs-jupyter project > (https://github.com/nnicandro/emacs-jupyter) which essentially > integrates Jupyter kernels (https://jupyter.org) with Org mode source > blocks. > > I wanted to make an introduction to the Org community. So...hello! And > thanks for promoting the project on https://orgmode.org/features.html. > > I believe a lot of users of the project use it mainly for the Org > integration. I thought it would be a good idea to get some feedback > from the community on how their experience using emacs-jupyter has been. > I'm getting back into active maintenance of the project and am looking > for feedback to get a better idea of what the future of the project > could look like. What features of standard Org source blocks do you > find Jupyter source blocks are lacking? What potential features do you > think would be useful for Jupyter source blocks to support, given the > capabilities of Jupyter? What would it mean to see Emacs-Jupyter and > Org more integrated? Of course, any other thoughts are welcome. > > -- > Nathaniel >
Re: [PATCH] ob-shell-test, test-ob-shell and introduction
On 01/01/2022 02:18, Matt wrote: > Wow. Nice work! Thanks. I pushed things to Worg, if you haven't seen already (https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-shell.html). If you read it and find anything missing or unclear, please let me know. Thank you, I was not aware of ":cmdline" argument and of ":shebang" as a means to avoid stray prompts (I have seen mentions of similar problem for other languages in this list). I have noticed some glitches. - https://www.mirbsd.org/pics/logo-grey.png works only with http: protocol for me. - I am unsure concerning example after "…or as a standlone script.", maybe it should be wrapped into #+begin_example. - In some cases "sh" is used despite bashisms in the code like "declare" or "echo -ne". Actually "printf" may be more convenient instead of "echo -n" - "export" in session example is unnecessary. It is matter of taste though. Bash and dash is not the case, but some shells require that assignment and export should be separate commands. - In your examples variable values are simple. Often it is safer to add double quotes around variable or command expansion. I would consider adding quotes just to encourage people to do the same by default with hope that less scripts will give strange results in response to a file name containing a space. Actually my first impression was that backslashes before quotes in some cases were added by mistake. Another unescaped pair of quotes may make your intention more clear. However it is related to code style where everybody has opinion, so I do not insist.
Re: A simple Lua filter for Pandoc
Max Nikulin writes: > It seems, lightweight markup is more annoyance than advantage for you. > Tom posted some thoughts on more rigorous syntax in the following message: It's generally the opposite: working in Org is a pleasant journey for me... except when there are dozens of "/" and "*" in a document, and they placed in 'unhappy' positions. For example, in phonetics the "/ ... /" notation is used a lot, and there may be cases like: #+begin_example /foo/ /bar/ /baz/ #+end_example In grammar the asterisk is also used a lot, to designate that a term is not attested or to indicate that it is ungrammatical: #+begin_example *foo *bar *baz #+end_example And we can even have the combination of both: #+begin_example /*foo/ /*bar/ /*baz/ #+end_example And in certain cases, they are usually expressed in italics. With these landscapes, it's worth having a few entities rather than working from pure LaTeX, which is more accurate, but horribly more verbose. This is a page from a book I typesetted a couple of years ago (when the pandemic started), entirely from Org: https://i.imgur.com/f6X7qLs.png Best regards, Juan Manuel
Re: A simple Lua filter for Pandoc
On 04/01/2022 22:06, Juan Manuel Macías wrote: Max Nikulin writes: Ideally it should be done pandoc and only if it causes incorrect parsing of org markup. NBSP, probably, should be replaced by some exporters, I do not think, it is a problem e.g. in HTML files. The reason for this filter is my own comfort. Linguistics texts contains a lot of certain characters such as "/" or "*", and they are often italicized or bold. So, in order not to be more confused than necessary, I prefer that they pass as entities. It seems, lightweight markup is more annoyance than advantage for you. Tom posted some thoughts on more rigorous syntax in the following message: Tom Gillespie. Re: Org-syntax: Intra-word markup. Sat, 4 Dec 2021 09:53:11 -0800. https://list.orgmode.org/ca+g3_pnca3hy6tudpmfhgt35amj9a-y8dbnqo+zvbov6y3n...@mail.gmail.com For C and C++ it is possible to tune some aspects of compiler behavior using #pragma something directives. In some cases it might be convenient to e.g. temporary disable emphasis markers (or switch to more verbose alternative) through #+some: keyword In general, there are certain characters that I am more comfortable working with as entities than as literal characters (for example, a lot of zero-width combining diacritics that are used a lot in linguistics or epigraphy (and there are no fonts that include the NFC normalized version of all possible combinations: in fact, they are not in Unicode, and would have to go to the private use area). Summarizing, I prefer that these characters have their actual typographic representation only with LuaTeX. A very typical example is the character U+0323 (COMBINING DOT BELOW). It is very uncomfortable to work /in situ/, although there are fonts that usually render it well (with the 'mark' otf tag). I have seen warnings concerning complications due to variants of character representation, but I have no experience such nuances (either typing and editing or processing text programmatically). Dagger and non-breaking space in your code snippet were much more simpler cases.
Re: Tool to compare and choose fonts
It was that, Ihor! Thanks Ihor and Juan Manuel Jan 5, 2022 15:03:27 Ihor Radchenko : > Ypo writes: > >> Was a tool to compare fonts presented in this list some time ago? >> >> I lost it, I thought I discovered it on Reddit, but now I am thinking I >> found it here. >> >> It was a script that presented on emacs every font in the computer, in >> pairs; so the user chose one font each time, like if it were a >> "championship" between fonts. > > See https://ruzkuku.com/texts/emacs-font-game.html > > Best, > Ihor
Re: Tool to compare and choose fonts
Ypo writes: > Was a tool to compare fonts presented in this list some time ago? > > I lost it, I thought I discovered it on Reddit, but now I am thinking I found > it here. > > It was a script that presented on emacs every font in the computer, in pairs; > so the user chose one font each time, like if it were a "championship" > between fonts. See https://ruzkuku.com/texts/emacs-font-game.html Best, Ihor
[PATCH v2 1/3] ox-texinfo: Add function for use by kbd macro
* doc/doc-setup.org: Use org-texinfo-kbd-macro for kbd macro.
* doc/org-manual.org: Add new node "Key bindings in Texinfo export".
* lisp/ox-texinfo.el (org-texinfo-kbd-macro): New function.
---
doc/doc-setup.org | 2 +-
doc/org-manual.org | 27 +++
lisp/ox-texinfo.el | 23 ++-
3 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/doc/doc-setup.org b/doc/doc-setup.org
index f59660e8e..59ad0eb60 100644
--- a/doc/doc-setup.org
+++ b/doc/doc-setup.org
@@ -49,5 +49,5 @@
# The "kbd" macro turns KBD into @kbd{KBD}. Additionally, it
# encloses case-sensitive special keys (SPC, RET...) within @key{...}.
-#+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
+#+macro: kbd (eval (org-texinfo-kbd-macro $1))
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b65e2f173..a5aac7d61 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -15353,6 +15353,33 @@ your king.
,#+END_QUOTE
#+end_example
+*** Key bindings in Texinfo export
+:PROPERTIES:
+:DESCRIPTION: @@kbd Texinfo command.
+:END:
+
+Org does not provide any markup for key bindings that corresponds to
+Texinfo's ~@kbd~ and ~@key~ commands. One way to deal with this is to
+fall back to code syntax. =~C-x SPC~=, for example, is transcoded to
+~@code{C-x SPC}~.
+
+A better approach is to define and use an Org macro named ~kbd~. To
+make that easier the function ~org-texinfo-kbd-macro~ is provided,
+which is intended to be used like this:
+
+#+begin_example
+#+macro: kbd (eval (org-texinfo-kbd-macro $1))
+
+Type {{{kbd(C-c SPC)}}}.
+#+end_example
+
+#+texinfo: @noindent
+which becomes
+
+#+begin_example
+Type @kbd{C-c @key{SPC}}.
+#+end_example
+
*** Special blocks in Texinfo export
:PROPERTIES:
:DESCRIPTION: Special block attributes.
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index b0125894a..57cbcf6ad 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -1611,7 +1611,28 @@ (defun org-texinfo-verse-block (_verse-block contents
_info)
(format "@display\n%s@end display" contents))
-;;; Interactive functions
+;;; Public Functions
+
+(defun org-texinfo-kbd-macro (key noquote)
+ "Quote KEY using @kbd{...} and if necessary $key{...}.
+
+This is intended to be used as an Org macro like so:
+
+ #+macro: kbd (eval (org-texinfo-kbd-macro $1))
+ Type {{{kbd(C-c SPC)}}}.
+
+Also see info node `(org)Key bindings in Texinfo export'.
+
+If optional NOQOUTE is non-nil, then do not add the quoting
+that is necessary when using this in an Org macro."
+ (format (if noquote "@kbd{%s}" "@@texinfo:@kbd{@@%s@@texinfo:}@@")
+ (let ((case-fold-search nil))
+ (replace-regexp-in-string
+org-texinfo--quoted-keys-regexp
+(if noquote "@key{\\&}" "@@texinfo:@key{@@\\&@@texinfo:}@@")
+key t
+
+;;; Interactive Functions
;;;###autoload
(defun org-texinfo-export-to-texinfo
--
2.34.1
[PATCH v2 3/3] ox-texinfo: Define definition commands using description lists
* doc/org-manual.org (Plain lists in Texinfo export): Document use
of definition command prefixes in description lists.
* lisp/ox-texinfo.el: Add org-texinfo--separate-definitions to the
list of :filter-parse-tree functions of the texinfo backend.
* lisp/ox-texinfo.el (org-texinfo--quoted-keys-regexp)
(org-texinfo--definition-command-alist)
(org-texinfo--definition-command-regexp): New variables.
* lisp/ox-texinfo.el (org-texinfo--filter-parse-tree): Call
org-texinfo--separate-definitions.
* lisp/ox-texinfo.el (org-texinfo--separate-definitions)
(org-texinfo--match-definition, org-texinfo--split-definition)
(org-texinfo--split-plain-list, org-texinfo--massage-key-item):
New functions.
---
doc/org-manual.org | 70 +++
lisp/ox-texinfo.el | 139 +
2 files changed, 209 insertions(+)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b3c4a9bef..daa207a5d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -15307,6 +15307,72 @@ example is transcoded to the same output as above.
This is the common text for variables foo and bar.
#+end_example
+Likewise, the Texinfo export back-end supports two approaches to
+writing Texinfo definition commands (see [[info:texinfo::Definition
+Commands]]). One of them uses description lists and is describe below,
+the other is described in [[*Special blocks in Texinfo export]].
+
+Items in a description list in a Org file that begin with =Function:=
+or certain other prefixes are converted using Texinfo definition
+commands. This works even if other items in the same list do not have
+such a prefix; if necessary a single description list is converted
+using multiple tables (such as =@vtable=) and definition commands
+(such as =@defun=).
+
+#+begin_example
+- Function: org-texinfo-drawer drawer contents info ::
+ Transcode a DRAWER element from Org to Texinfo.
+#+end_example
+
+#+texinfo: @noindent
+becomes
+
+#+begin_example
+@defun org-texinfo-drawer drawer contents info ::
+ Transcode a DRAWER element from Org to Texinfo.
+@end defun
+#+end_example
+
+The recognized prefixes are =Command:=, =Function:=, =Macro:=,
+=Special Form:=, =Variable:= and =User Option:=. These are the same
+prefixes that appear in the Info file for the respective definition
+commands. For example a =Function:= item in the Org file is converted
+to a =@defun= command in the Texinfo file, which in turn is converted
+to a definition prefixed with =-- Function:= in the Info file.
+
+As a special case the prefix =Key:= is also recognized. No Texinfo
+definition command exists for key bindings and the output in Info
+files also lacks the =Key:= prefix. Even so this special case is
+supported because it provides a convenient shorthand, as illustrated
+here:
+
+#+begin_example
+- Key: C-c C-c (do-something) ::
+ This command does something.
+
+- User Option: do-something-somehow ::
+ This option controls how exactly ~do-something~ does its thing.
+#+end_example
+
+#+texinfo: @noindent
+becomes
+
+#+begin_example
+@table @asis
+@item @kbd{C-c C-c} (@code{do-something})
+@kindex C-c C-c
+@findex do-something
+This command does something.
+@end table
+
+@defopt do-something-somehow
+This option controls how exactly @code{do-something} does its thing.
+@end defopt
+#+end_example
+
+#+texinfo: @noindent
+Command in parenthesis, as done above, is optional.
+
*** Tables in Texinfo export
:PROPERTIES:
:DESCRIPTION: Table attributes.
@@ -15401,6 +15467,10 @@ Type @kbd{C-c @key{SPC}}.
:DESCRIPTION: Special block attributes.
:END:
+The Texinfo export back-end supports two approaches to writing Texinfo
+definition commands. One of them is describe here, the other in
+[[*Plain lists in Texinfo export]].
+
#+cindex: @samp{ATTR_TEXINFO}, keyword
The Texinfo export back-end converts special blocks to commands with
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index 8f671ea13..a79f620c6 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -84,6 +84,7 @@ (org-export-define-backend 'texinfo
:filters-alist
'((:filter-headline . org-texinfo--filter-section-blank-lines)
(:filter-parse-tree . (org-texinfo--normalize-headlines
+ org-texinfo--separate-definitions
org-texinfo--combine-items))
(:filter-section . org-texinfo--filter-section-blank-lines)
(:filter-final-output . org-texinfo--untabify))
@@ -408,6 +409,30 @@ (defconst org-texinfo-inline-image-rules
(regexp-opt '("eps" "pdf" "png" "jpg" "jpeg" "gif" "svg"
"Rules characterizing image files that can be inlined.")
+(defvar org-texinfo--quoted-keys-regexp
+ (regexp-opt '("BS" "TAB" "RET" "ESC" "SPC" "DEL"
+ "LFD" "DELETE" "SHIFT" "Ctrl" "Meta" "Alt"
+ "Cmd" "Super" "UP" "LEFT" "RIGHT" "DOWN")
+ 'words)
+ "Regexp matching keys that have to be quoted using @key{KEY}.")
+
+(defconst org-texinfo--definition-command-alist
+
[PATCH v2 2/3] ox-texinfo: Optionally use @itemx for certain description list items
* doc/org-manual.org (Plain lists in Texinfo export): Reorder and
document new functionality.
* lisp/ox-texinfo.el: Add org-texinfo--combine-items to the list of
:filter-parse-tree functions of the texinfo backend.
* lisp/ox-texinfo.el (org-texinfo--combine-items) New function.
* lisp/ox-texinfo.el (org-texinfo-item) Transcode combined items to
one @item and one or more @itemx.
---
doc/org-manual.org | 38 +++---
lisp/ox-texinfo.el | 45 +
2 files changed, 68 insertions(+), 15 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index a5aac7d61..b3c4a9bef 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -15236,6 +15236,23 @@ This paragraph is preceded by...
:DESCRIPTION: List attributes.
:END:
+#+cindex: lettered lists, in Texinfo export
+#+cindex: enum, Texinfo attribute
+The Texinfo export back-end converts unordered and ordered lists in
+the Org file using the default command =@itemize=.
+
+Ordered lists are numbered when exported to Texinfo format. Such
+numbering obeys any counter (see [[*Plain Lists]]) in the first item of
+the list. The =:enum= attribute also let you start the list at a
+specific number, or switch to a lettered list, as illustrated here:
+
+#+begin_example
+#+ATTR_TEXINFO: :enum A
+1. Alpha
+2. Bravo
+3. Charlie
+#+end_example
+
#+cindex: @samp{ATTR_TEXINFO}, keyword
#+cindex: two-column tables, in Texinfo export
#+cindex: table-type, Texinfo attribute
@@ -15262,7 +15279,7 @@ entry in the first column of the table.
The following example illustrates all the attributes above:
#+begin_example
-,#+ATTR_TEXINFO: :table-type vtable :sep , :indic asis
+,#+attr_texinfo: :table-type vtable :indic asis :sep ,
- foo, bar :: This is the common text for variables foo and bar.
#+end_example
@@ -15277,18 +15294,17 @@ This is the common text for variables foo and bar.
@end table
#+end_example
-#+cindex: lettered lists, in Texinfo export
-#+cindex: enum, Texinfo attribute
-Ordered lists are numbered when exported to Texinfo format. Such
-numbering obeys any counter (see [[*Plain Lists]]) in the first item of
-the list. The =:enum= attribute also let you start the list at
-a specific number, or switch to a lettered list, as illustrated here
+The =:combine= attribute is an alternative to the =:sep= attribute,
+which allows writing each entry on its own line. If this attribute is
+non-nil and an item in a description list has no body but is followed
+by another item, then the second item is transcoded to =@itemx=. This
+example is transcoded to the same output as above.
#+begin_example
-#+ATTR_TEXINFO: :enum A
-1. Alpha
-2. Bravo
-3. Charlie
+,#+attr_texinfo: :table-type vtable :indic asis :combine t
+- foo ::
+- bar ::
+ This is the common text for variables foo and bar.
#+end_example
*** Tables in Texinfo export
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index 57cbcf6ad..8f671ea13 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -83,7 +83,8 @@ (org-export-define-backend 'texinfo
(verse-block . org-texinfo-verse-block))
:filters-alist
'((:filter-headline . org-texinfo--filter-section-blank-lines)
-(:filter-parse-tree . org-texinfo--normalize-headlines)
+(:filter-parse-tree . (org-texinfo--normalize-headlines
+ org-texinfo--combine-items))
(:filter-section . org-texinfo--filter-section-blank-lines)
(:filter-final-output . org-texinfo--untabify))
:menu-entry
@@ -421,7 +422,7 @@ (defun org-texinfo--filter-section-blank-lines (headline
_backend _info)
(defun org-texinfo--normalize-headlines (tree _backend info)
"Normalize headlines in TREE.
-BACK-END is the symbol specifying back-end used for export.
+_BACKEND is the symbol `texinfo'; the back-end used for export.
INFO is a plist used as a communication channel.
Make sure every headline in TREE contains a section, since those
@@ -443,6 +444,37 @@ (defun org-texinfo--normalize-headlines (tree _backend
info)
info)
tree)
+(defun org-texinfo--combine-items (tree _backend info)
+ "Normalize items in TREE.
+
+_BACKEND is the symbol `texinfo'; the back-end used for export.
+INFO is a plist used as a communication channel.
+
+Items in description lists that use the \"+\" bullet are
+converted to `@itemx'. If another item is followed by such an
+item, then the first item should not be followed by a space,
+which this function takes care of.
+
+Return new tree."
+ (org-element-map tree 'item
+(lambda (item)
+ (let ((plain-list (org-element-property :parent item)))
+ (when (and (org-not-nil (org-export-read-attribute
+:attr_texinfo plain-list :compact))
+ (eq (org-element-property :type plain-list) 'descriptive))
+ (let ((next-item
+(cadr (memq item (org-element-contents plain-list)
+ (when (and next-item
+
[PATCH v2 0/3] ox-texinfo: Define definition commands using description lists
I think I have addressed all you feedback.
The only difference when exporting org-manual.org is:
-When typing text into a field, Org treats @kbd{DEL},
+When typing text into a field, Org treats @kbd{@key{DEL}},
Jonas Bernoulli (3):
ox-texinfo: Add function for use by kbd macro
ox-texinfo: Optionally use @itemx for certain description list items
ox-texinfo: Define definition commands using description lists
doc/doc-setup.org | 2 +-
doc/org-manual.org | 135 ++---
lisp/ox-texinfo.el | 207 +++--
3 files changed, 327 insertions(+), 17 deletions(-)
--
2.34.1
Re: [PATCH 2/2] ox-texinfo: Define definition commands using description lists
Nicolas Goaziou writes:
> Hello,
>
> Jonas Bernoulli writes:
>
>> Would it be okay to represent e.g. "C-c SPC" as:
>>
>>(export-snippet
>> (:back-end "texinfo" :value "@kbd{C-c @key{SPC}}" :post-blank 0 :parent
>> #2))
>
> Just use (org-export-raw-string "@kbd{C-c @key{SPC}}") instead.
That works. I must of done something wrong when first trying that.
>> 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.
>
> `org-export-raw-string' is a recent addition in Org.
>
>> Above I suggested using an `export-snippet' element (instead of `raw');
>> to me that seems appropriate too.
>
> I think that's abusing export snippets. They are more user-oriented,
> e.g. filters can apply to them.
>
> Note you can write (org-export-raw-string (some-public-function "C-c
> SPC")) where (some-public-function "C-c SPC") => "@kbd{C-c @key{SPC}}",
> as done currently by the "kbd" macro.
I named it org-texinfo-kbd-macro and wrote it so that it can be used by
the kbd macro. I have changed doc/doc-setup.org to use it.
DEL was missing from the list of special keys.
Cheers,
Jonas
Re: [PATCH 1/2] ox-texinfo: Turn a description list item with "+" bullet into @itemx
Nicolas Goaziou writes: >> 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 :: I went with that approach. > 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. Ordered lists are transcoded to @itemize, while description lists are transcoded to @table or some other table command. So they cannot be combined into one list-like thing in Texinfo. The first two lists could be combined, but IMO it is better to only require the :compact t once and avoid splitting the list and then recombining the lists back into one. Jonas Ps: Slightly sad about loosing the +. It looks very much like the x at the end of @itemx.
Re: Tool to compare and choose fonts
Ypo writes: > Was a tool to compare fonts presented in this list some time ago? > > I lost it, I thought I discovered it on Reddit, but now I am thinking > I found it here. > > It was a script that presented on emacs every font in the computer, in > pairs; so the user chose one font each time, like if it were a > "championship" between fonts. https://github.com/alphapapa/unpackaged.el#font-compare Outside of Emacs there are many tools for auditing fonts. In TeX live you have the otfinfo script, for example, very useful. And recently the Unicode Font Table package has been uploaded to CTAN, to represent character tables in (Lua/Xe)LaTeX: https://www.ctan.org/pkg/unicodefonttable (an example that I have done inside Org, using LaTeX blocks: https://i.imgur.com/eiiAUlB.png) Best regards, Juan Manuel
