Re: should a "wrapped" table result behave differently than one that is not?
Hi Chuck, On Tuesday, 18 Jan 2022 at 18:43, Berry, Charles wrote: > This is annoying, but I think you can get the product you want by > "pre-wrapping" the results. Ah, I see: do the wrapping manually instead of using the :wrap header argument. Yes, this works. A little annoying but it's a solution and easy enough to do. It's not as if I have that many results that need this processing. Thank you. eric -- : Eric S Fraga, with org release_9.5.2-306-g9623da in Emacs 29.0.50
Re: [BUG] Bug Report Requested [9.5.2 (9.5.2-ga98ae4 @ /Users/apc/.emacs.d/straight/build/org/)]
Alejandro Pérez Carballo writes: > I was simply calling `org-agenda` when I was prompted to submit this report. > I'm submitting this as requested. Thanks for reporting! If you keep seeing the warning, please followup this thread showing the warning text. It will give us clues what went wrong. Best, Ihor
Re: Yet another browser extension for capturing notes - LinkRemark
Max Nikulin writes: > Scientific papers require more work, it is necessary to make them > available to org-cite somehow. Some nerds use quite peculiar blog > engines and strange setting of metadata. So shopping on some sites might > work better than other cases. I have plans to implement something called oc-org.el The plan is using ol-bibtex-compatible Org headings as a source of citations. Best, Ihor
Re: Problem when tangling source blocks with custom coderefs
Hi Luis, I don't think you are doing anything wrong. IIRC the portion of the patch that allowed the customization to propagate to the tangled code was not included. Given that I am no longer the only one who is looking for/expecting this behavior, maybe it is worth revisiting the decision. The simplest fix right now would be to prepend your coderef with the python comment symbols # |hello| so that at the very least it won't break your tangled files. I would like to see this implemented, so let's see what Nicolas has to say. Best! Tom
Re: Org Syntax Specification
Hi Ihor, Thank you very much for the detailed responses. Let me start with some context. 1. A number of the comments that I made fall into the brainstorming category, so they don't need to make their way into the document at this time. I agree that it is critical for this document to capture how org is parsed right now and that we should not put the pie-in-the-sky changes in until the behavior of org-element matches (if such a change is made at all). 2. Though I haven't been hacking on it, I fully intend to contribute test cases and exploratory work on org-element in the future, so please don't interpret some of what I am writing as requests for other people to write code (unless they want to :) 3. When I say grammar in this context I mean specifically an eBNF that generates a LALR(1) or LR(1) parser. This is narrower than the definition used in the document, which includes things that have to be implemented in the tokenizer, or in a pass after the grammar has been applied, or are related to some other aspect beyond the pure surface syntax. 4. A number of my comments are about the structure of the document more than the structure of the syntax or the implementation. I think that most of them are trying to ask whether we want to clearly delineate pure surface syntax from semantics to make the document easier to understand. More replies in line. Best! Tom > As for your other comments, you seem to be suggesting a number of > changes to the existing Org syntax. Some of them looks fine, some are > not. However, please keep in mind that we have to deal with back > compatibility, third party compatibility, and not breaking existing Org > documents unless we have a very strong justification. I suggest to > branch a number of new threads from here for each concrete suggestion > where you want to make changes to Org syntax, as opposed to just > document wording. Otherwise, this discussion will become a total mess. Agreed. I put many of these in here as notes from my experiences, I will branch those off into separate discussions so that we don't pollute this thread. > Nope. Sections are actually elements. See =org-element-all-elements=. I realized this at a slightly later date but missed cleaning up this comment. See my response on section vs segment below. > I disagree. Nesting rules are the important part of syntax. We have > restrictions on what elements can be inside other element. The same > patterns are not recognised in Org depending on their nesting. For > example, links that you put into property drawers are not considered > link objects. When I wrote this comment I was still confused about sections.I think discussion of nesting in most contexts is ok, but there are some case where nesting cannot be determined from the grammar, and there I think we need to make a distinction. In my thinking I separate the context sensitive nature of parsing from the nesting structure of the resulting sexpressions, org elements, etc.The most obvious example of this is that the sexpression representation for headings nests based on the level of the heading, but heading level cannot be determined by the grammar so it must be reconstructed from a flat sequence of headings that have varying level. > Again I disagree. While your idea about table cells is reasonable > (similar for citation-references inside citations), I am against > decoupling Org syntax from org-element implementation. In > org-element.el, table-cells are just yet another object. If we make > things in org-element and syntax document out of sync, confusion and > errors will follow during future maintenance. Org element treats all elements and objects as a single homogenous type. This is fine. However, to help people understand the syntax it seems easier to define things in a positive way so that we don't say "all except these two." Therefore, despite the fact that the implementation of org-element treats table rows and cells no different from any other node in the parse tree, we don't need to burden the reader with that information at this point in time, and could provide that information as an implementation note for cells. I think the other issue I was having here is that the spec for tables is spread allover the place, and it would be much easier to understand and implement ifit were all in one place. > This actually reads slightly confusing. "Blank lines separate paragraphs > and other elements" sounds like blank lines are only relevant > before/after paragraphs. However, there are also footnote references and > lists. Maybe we can try something like: > > Blank lines can be used to indicate end of some elements. > > "can" because a single blank line usually does not separate anything. I think your version is quite a bit more readable. Can we list the set of all the elements that can be ended by a new lineas well as those that cannot (iirc they are elements such as footnotes that can only
[BUG] Bug Report Requested [9.5.2 (9.5.2-ga98ae4 @ /Users/apc/.emacs.d/straight/build/org/)]
Hello,
I was simply calling `org-agenda` when I was prompted to submit this report.
I'm submitting this as requested.
Thanks for all your good work on this,
APC
Emacs : GNU Emacs 28.0.90 (build 1, x86_64-apple-darwin19.6.0, NS
appkit-1894.60 Version 10.15.7 (Build 19H1419))
of 2021-12-14
Package: Org mode version 9.5.2 (9.5.2-ga98ae4 @
/Users/apc/.emacs.d/straight/build/org/)
current state:
==
(setq
org-archive-location "~/org/agenda/archives/%s_archive.org::datetree/"
org-roam-db-location "/Users/apc/.emacs.d/var/org/org-roam.db"
org-link-elisp-confirm-function 'yes-or-no-p
org-agenda-skip-deadline-prewarning-if-scheduled 2
org-cite-insert-processor 'citar
org-after-refile-insert-hook '(org-gcal--refile-post)
org-indirect-buffer-display 'current-window
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-log-done 'time
org-agenda-custom-commands '(("d" "Default (ignore @sched and @hold)"
((agenda ""
((org-agenda-span 'day)
(org-super-agenda-groups
'((:name none :time-grid t)
(:name "To do" :and (:not (:tag ("@hold"))
:not (:tag ("@sched")))
:discard (:anything t))
)
)
)
)
)
)
("z" "Work: focused"
((agenda ""
((org-agenda-span 'day)
(org-agenda-files `(,(concat my/agenda-dir
"/work.org")))
(org-super-agenda-groups
'((:name "First and foremost" :and (:tag
("@today") :priority "A"))
(:name "The rest" :tag ("@today") :discard
(:anything t)))
)
)
)
)
)
("p" "Planning view"
((agenda ""
((org-agenda-span 'day)
(org-super-agenda-groups
'((:name "Up next" :and (:todo "NEXT" :not
(:scheduled past)))
(:name "New today" :and
(:not (:todo ("WAIT" "KILL")) :not (:tag
("@sched")) :scheduled today)
:deadline today)
(:name "In progress" :todo "STRT")
(:name "Overdue" :and
(:not (:todo ("DONE" "KILL" "WAIT")) :not
(:tag ("@sched")) :deadline
past)
)
(:name "Backlog" :and
(:not (:todo ("STRT" "DONE" "KILL"
"WAIT")) :not (:tag ("@sched"))
:scheduled past)
:discard (:anything t))
)
)
)
)
(alltodo ""
((org-agenda-overriding-header "")
(org-super-agenda-groups
`((:name "Refile" :and
(:not (:todo ("DONE" "KILL" "WAIT")) :tag
("refile") :not
(:tag ("read" "gkry")))
)
(:name "Next available actions" :and
(:todo "NEXT" :scheduled future)
:and (:todo "NEXT" :deadline future))
(:name "Coming up" :and
(:todo "TODO" :scheduled (before
,(org-read-date nil nil "+7d"))
:scheduled future)
)
(:name "Important and unscheduled" :and
(:priority>= "B" :scheduled nil :not
(:tag ("read"
(:name "On hold" :todo "WAIT")
(:name "Etc" :and (:scheduled nil :not
(:tag ("read"))) :discard
(:anything t))
)
)
)
)
)
Problem when tangling source blocks with custom coderefs
Dear all,
I would like to tangle source code blocks that contain coderefs. I have
found that the coderefs are correctly filtered out from the tangled files
if they follow the default format, i.e. "(ref:%s)", but not if I try to
customize the format using the documented "-l" switch [1] to change them to
something else, e.g. "|%s|".
Here is an example:
#+begin_src python -r -l "|%s|" :tangle example.py
try:
sys.exit(app.run())
except:|\label{line:except}\ding{182}|
sys.exit(1)
#+end_src
In line \ref{line:except}, marked \ding{182}, we are catching all
exceptions ...
After using `org-babel-tangle`, I would expect `example.py` to not have any
of the text between the `||` characters, but it is there and it makes the
file invalid to run.
I have found a thread in this mail list [2] where the coderef format used
during tangle is streamlined to use the function `org-src-coderef-regexp`.
That seems to be correct, but the behavior I am seeing does not recognize
the custom format correctly. Can someone please tell me if I am doing
something wrong? Or is that function not doing what it is intended to do?
I am running Org mode version 9.6 on top of GNU Emacs 27.2.
Thank you,
Luis
References:
[1] https://orgmode.org/manual/Literal-Examples.html
[2]
https://list.orgmode.org/ca+g3_ponzfmfb-upuce3jzpw5fvsbjztecco4uktoa9neuu...@mail.gmail.com/#R
Re: Preview fonts from Dired with org-latex-preview (and test opentype features)
Please excuse brevity. Sent from tiny pocket computer with non-haptic feedback keyboard. On Mon, Jan 10, 2022, 08:53 Juan Manuel Macías wrote: > Hi, > > I have written for my personal use this code (still quite crude) that > allows me to preview with org-latex-preview small text strings in a font > marked in dired, and test open type features too. The preview is > compiled with LuaLaTeX, since LuaTeX allows to load fonts that are not > installed in the system. > > When a font is selected, the list of opentype features included in the > font are extracted (using the otfinfo command), and they are arranged in > the preview buffer as buttons. By clicking on each button we can > activate in the preview the corresponding opentype feature. For example, > if the font includes the 'smcp' feature, clicking on the button 'smcp' > the text will be displayed in small caps. > > We can enter the text strings literally or through Unicode code: each > character separated by a space; the separation between words is marked > with a vertical bar. For example, this code: > > 0063 006f 0064 0065 | 0068 0065 0072 0065 > > returns the string "code here". > > As a third option, a complete specimen can be displayed from a file. > > Here is a demo video: https://cloud.disroot.org/s/aHXKiof36fTSZGB > > As I said, my function is still pretty crude, and while it works well, > it's now more of a proof of concept than a finished thing. But if anyone > wants to try it, I attach the code here in an org document. > > Best regards, > > Juan Manuel > >
Re: should a "wrapped" table result behave differently than one that is not?
Eric,
> On Jan 18, 2022, at 9:05 AM, Eric S Fraga wrote:
>
> been wrapped in a RESULTS special block be different than one that is
> not wrapped (beyond the wrapping, of course)? Specifically, wrapping
> the results seems to cause org to ignore that ATTR_LATEX :center toggle
> [1]. A minimal example, both org and resulting LaTeX, attached.
>
> I guess it makes sense in that the attr line will probably be applied to
> the results special block. I am not sure how to get around this.
> Suggestions very welcome indeed! I do need to wrap the results in a
> block of some type so I can control the formatting in the resulting PDF
> export but I do not want the table centred necessarily [2].
>
This is annoying, but I think you can get the product you want by
"pre-wrapping" the results.
Here is an example:
#+begin_src org
Show default:
,#+begin_src emacs-lisp :exports both
org-latex-tables-centered
,#+end_src
,#+name: awrappedtable
,#+header: :exports results
,#+header: :results value
,#+begin_src emacs-lisp
'((1 2) (3 4))
,#+end_src
,#+begin_results
,#+attr_latex: :center nil
,#+RESULTS: awrappedtable
: initial filler
,#+end_results
#+end_src
On export I get
Show default:
\begin{verbatim}
org-latex-tables-centered
\end{verbatim}
\begin{verbatim}
t
\end{verbatim}
\begin{results}
\begin{tabular}{rr}
1 & 2\\
3 & 4\\
\end{tabular}
\end{results}
HTH,
Chuck
should a "wrapped" table result behave differently than one that is not?
Dear all,
Should the export of a table that is the result of a code block and has
been wrapped in a RESULTS special block be different than one that is
not wrapped (beyond the wrapping, of course)? Specifically, wrapping
the results seems to cause org to ignore that ATTR_LATEX :center toggle
[1]. A minimal example, both org and resulting LaTeX, attached.
I guess it makes sense in that the attr line will probably be applied to
the results special block. I am not sure how to get around this.
Suggestions very welcome indeed! I do need to wrap the results in a
block of some type so I can control the formatting in the resulting PDF
export but I do not want the table centred necessarily [2].
Thank you,
eric
Footnotes:
[1] describing this as a toggle (in the info manual) does not really
make much sense to me as it implies a known initial state which is
not specified in the manual. I would prefer to have to say
":center no" (or nil) which then allows for ":center t"...?
[2] centring should happen by request, not by default, in my opinion, as
it is trivial to enclose a table in a centring environment
explicitly but difficult to remove otherwise.
--
: Eric S Fraga, with org release_9.5.2-306-g9623da in Emacs 29.0.50
t.org
Description: Lotus Organizer
% Created 2022-01-18 Tue 16:52
% Intended LaTeX compiler: pdflatex
\documentclass{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage{xcolor}
\usepackage{tikz}
\usepackage{soul}
\usepackage{listings}
\usepackage[version=3]{mhchem}
\usepackage{doi}
\usepackage{amsmath}
\usepackage[british, english]{babel}
\author{Eric S Fraga}
\date{\today}
\title{}
\hypersetup{
pdfauthor={Eric S Fraga},
pdftitle={},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 29.0.50 (Org mode 9.5.2)},
pdflang={English}}
\begin{document}
\tableofcontents
A bare table gets exported properly:
\begin{tabular}{rr}
1 & 2\\
3 & 4\\
\end{tabular}
Now a table that is the result of some code:
\begin{tabular}{rr}
1 & 2\\
3 & 4\\
\end{tabular}
and finally a table from some code but wrapped:
\begin{results}
\begin{center}
\begin{tabular}{rr}
1 & 2\\
3 & 4\\
\end{tabular}
\end{center}
\end{results}
The last table is centred unfortunately.
\end{document}
ignore previous email please: found org-latex-tables-centered (blush)
As the subject line says. Missed it due to the plural tables... (my bad). Although I must add that I have spent some time playing with org babel options and I am unclear about why ":results value verbatim" (or raw or scalar or drawer) don't behave as I would have thought. But that's a discussion for another day maybe. Apologies for the noise and thank you. -- : Eric S Fraga, with org release_9.5.2-306-g9623da in Emacs 29.0.50
[PATCH v3 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 v3 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 36e1436d7..751ad1126 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 v3 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 | 48 ++
2 files changed, 71 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..36e1436d7 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,40 @@ (defun org-texinfo--normalize-headlines (tree _backend
info)
info)
tree)
+(defun org-texinfo--combine-items (tree _backend info)
+ "Combine certain description list items.
+
+_BACKEND is the symbol `texinfo'; the back-end used for export.
+INFO is a plist used as a communication channel.
+
+If the `:combine' attribute of a description list is non-nil and
+an item in that list has no body and is followed by another item,
+then remove the first item and prepend its `:tag' to that of the
+second item.
+
+Such an item that absorbed the tags of other items is later
+transcoded to one `@item', followed by one or more `@itemx'.
+
+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
[PATCH v3 0/3] ox-texinfo: Define definition commands using description lists
The code is the same as in v3, but I noticed that I had forgotten to update one of the doc-strings, so that's fixed here. Cheers, Jonas 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 | 210 +++-- 3 files changed, 330 insertions(+), 17 deletions(-) -- 2.34.1
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
Dejan Josifović writes: > But, since ob-plantuml already had variable for arguments for executable > it fells natural to me to have customizable variables for when using > jar. These headers are of course easier, but the user would have to > write them on each source block to achieve something that should be > globally customizable (like charset). FYI, you can customise any header arg globally. See manual page 16.3 Using Header Arguments. > I second the concern that Max stated: >> Is there a case when some arguments are suitable for dedicated binary but >> should be avoided for jar (when a user has both executable from system >> package and manually downloaded jar having newer version)? It may be a >> reason to have separate variables (or header arguments). > I believe it is better design decision to separate arguments for > executable and jar. I am not sure about this specific case. The PlantUML executable is literally a wrapper around java call to jar. Below is the contents of plantuml file in my system: #!/bin/bash gjl_package=plantuml gjl_jar="plantuml.jar" source /usr/share/java-config-2/launcher/launcher.bash Unless it is any different on your side, the arguments for jar and executable should be literally the same. > Since we are making jar arguments customizable, we should think about > adding java arguments customizable (also mentioned by Max!). This line > in patch: > + "-Djava.awt.headless=true" > can be also added to a separate variable. I feel that running headless mode in the ob-plantuml is deliberate. We may not want users to change it. Otherwise, you are free to customize java arguments in org-babel-default-header-args:plantuml > Lastly, there is a typo in the patch: > +** Removed or renamed functions and variables > +*** =org-plantump-executable-args= is renamed and applies to jar as well > + > +The new variable name is =org-plantump-args=. It now applies to both > +jar PlantUML file and executable. > Word plantump should be plantuml I guess. :-) Thanks! Will fix. Best, Ihor
Re: Org Syntax Specification
Tom Gillespie writes: > Extremely in favor of removing switches. There are so many better ways > to do this now that aren't like some eldritch unix horror crawling up > out of the abyss and into the eBNF :) I also agree that switches and $$-style equations may be deprecated. We can 1. Do not mention them in the document 2. Add org-lint warnings about obsoletion As for your other comments, you seem to be suggesting a number of changes to the existing Org syntax. Some of them looks fine, some are not. However, please keep in mind that we have to deal with back compatibility, third party compatibility, and not breaking existing Org documents unless we have a very strong justification. I suggest to branch a number of new threads from here for each concrete suggestion where you want to make changes to Org syntax, as opposed to just document wording. Otherwise, this discussion will become a total mess. More details below. > +Elements are further divided into "[[#Headings][headings]]", > "[[#Sections][sections]]"[fn::sections are not elements], > "[[#Greater_Elements][greater Nope. Sections are actually elements. See =org-element-all-elements=. > +other headings. [fn:tom2:I would not discuss strata here because it is > +not related to the syntax of the document. It is related to how that > +syntax is interpreted by org mode. The strata are nesting rules that > +are independent of the syntax, and discussing that here in the syntax > +document is confusing, because the nesting is not something that can be > +parsed directly because it depends on the number of asterisks.] I disagree. Nesting rules are the important part of syntax. We have restrictions on what elements can be inside other element. The same patterns are not recognised in Org depending on their nesting. For example, links that you put into property drawers are not considered link objects. > +citation references and [[#Table_Cells][table cells]].[fn:tom3:Table cells > should > +be treated in a way that is entirely separate from objects. This document > has included > +them as such as has org-element (iirc) however since they can never appear > in a paragraph > +and because tables are completely separate syntactically, we should probably > drop the > +idea that table cells are objects. I realize that this might mean the > creation of a > +distinction between paragraph-objects, title-objects, table-objects etc.] Again I disagree. While your idea about table cells is reasonable (similar for citation-references inside citations), I am against decoupling Org syntax from org-element implementation. In org-element.el, table-cells are just yet another object. If we make things in org-element and syntax document out of sync, confusion and errors will follow during future maintenance. > A line containing only spaces, tabs, newlines, and line feeds (=\t\n\r=) > -is considered a /blank line/. Blank lines can be used to separate > +is considered a /blank line/. Blank lines separate > paragraphs and other elements. This actually reads slightly confusing. "Blank lines separate paragraphs and other elements" sounds like blank lines are only relevant before/after paragraphs. However, there are also footnote references and lists. Maybe we can try something like: Blank lines can be used to indicate end of some elements. "can" because a single blank line usually does not separate anything. > +considered part of the paragraph.[fn:tom4:I don't think we need to discuss > +nesting scope here, it is confusing, it is always the immediately prior > +(lesser?) element.] Then where can we put it? This is one of the tricky conventions we use in the parser. > ++ STARS :: A string consisting of one or more asterisks[fn::removed > + note about inline tasks because it is still a heading, any mention > + of a concrete number should not appear in the specification of > syntax.] I am not sure here. Inline tasks are special because a one-line inline task must not contain any text below, cannot have planning or properties. > + contains =TODO= and =DONE=, however org-todo-keywords-1 is a buffer local > + variable and can be set by users in an org file using =#+todo:=.]. If we mention this, we also need to elaborate kind of element is #+todo:, where it can be located, and how to parse multiple instances of #+todo in the document. > -A heading contains directly one section (optionally), followed by > -any number of deeper level headings. > +The level of a heading can be used to construct a nested structure. > +All content following a heading that appears before the next heading > +(regardless of the level of that next heading) is a section. In addition, > +text before the first heading in an org document is also a section. Note that it is not true for one-line inline tasks. > +considered a section), sections only occur within headings.[fn:: The > +choice to call this syntactic component a section is confusing because > +it is at odds with the usual
add-to-list problem with ox-context
Hi all,
I guess that I am not able to configure ox-context like this:
#+begin_src emacs-lisp
(use-package ox-context
:straight (ox-context :type git :host github :repo
"Jason-S-Ross/ox-context")
:config
(setq org-context-pdf-process '("context --mode=trimsize %f"))
(add-to-list 'org-context-presets-alist
'("book1" .
(:literal "\n\\environment juh.env-garamond
\n\\environment juh.env-garamond-trimsize5.5-8.5
\n\\environment juh.env-umbruch
\n\\environment juh.env-layout
\n\\environment juh.env-ligaturen
\n\\environment juh.env-heading
\n\\environment juh.env-deutsch"
:template "report"
:snippets ("title-report"
(add-to-list 'org-context-presets-alist
'("book2" .
(:literal "\n\\environment juh.env-gentium
\n\\environment juh.env-gentium-trimsize5.5-8.5
\n\\environment juh.env-umbruch
\n\\environment juh.env-layout
\n\\environment juh.env-ligaturen
\n\\environment juh.env-heading
\n\\environment juh.env-deutsch"
:template "report"
:snippets ("title-report"
)
#+end_src
While book1 works book2 give the default style of ox-context. So I guess
that either I made a mistake (most likely) or somehow
org-context-presets-alist don't get more than one additional entry.
TIA
juh
Re: Yet another browser extension for capturing notes - LinkRemark
On 18/01/2022 12:43, Samuel Banya wrote: Not sure if it helps, but you could also use the w3m browser's mentality of just keeping an HTML file that contains all of your bookmarks. I'm sure there's probably even a way to use 'eww' in the same fashion too. Maybe even making your own personal wiki of a webring of sorts would help too. I don't personally bookmark anything anymore but just store links on a webring on my site. Actually Samuel Wales added more details to his message posted a year ago. I started that thread to announce LinkRemark browser extension https://github.com/maxnikulin/linkremark It was me who tried to revive the thread a month ago. The idea is to store bookmarks in Org file and it should be more than just URL and page title. Rich "bookmark" should have more metadata and may have user comments. In eww you likely can use org-store-link or org-capture directly. Example of projects that extracts metadata: https://github.com/yantar92/org-capture-ref Doesn't Org mode is better than any wiki? At least in some aspects.
Re: Yet another browser extension for capturing notes - LinkRemark
Samuel, since significant part of your message is dedicated to capturing of tab groups I should ask if you have tried version of LinkRemark add-on currently available from browser extension catalogues: - https://addons.mozilla.org/firefox/addon/linkremark/ - https://chrome.google.com/webstore/detail/mgmcoaemjnaehlliifkgljdnbpedihoe Groups of tabs or selected (highlighted) tabs are supported for Chromium, Firefox has no built-in tab groups, but it is still possible to capture selected tabs. Your feature requests: - Clean-up URLs. I have such idea, but I have not approached to implementation of it. Maybe URLs should be sent to another extension that excels in such task. If you have come comments which add-ons are great and which work rather poor, the suggestions my be helpful. - Deduplicate URLs from tab groups. It requires some work to merge selected text, links, or nested frames from each tab. The complication is that some sites use internal navigation not reflected in location, so the same URL may have completely different content. Some sites have their top pages as canonical URLs, so some measures against false positives is required. Currently the extension may check if URL already present in org files. It requires https://github.com/maxnikulin/burl helper application that is in proof-of concept stage. - Restore set of tabs. It requires some elisp code to iterate over subtree and to pick first "Link URL" or "URL" from description lists. Currently I am thinking on some changes of interface since sometimes I just want to check if some URL is in my notes already. I would prefer to avoid adding more context menu items. Additional details are inline. On 17/01/2022 09:29, Samuel Wales wrote: On 12/26/20, Maxim Nikulin wrote: On 26/12/2020, Samuel Wales wrote: [... i can imagine great things possible with such extensions. for example, you could have sets of tabs, selected by right click in firefox, to save to a bunch of org entries. then you could load that particular set of entries into firefox whenever you want. interesting. i do note tab selection features in recent firefox-esr and i was just assuming something like that. There is no a ready to use recipe for loading saved tabs, but saving should work to some extent. You can do this with the "Copy all URLs" extension (ID: djdmadneanknadilpjiknlnanaolmbfk). Use this as the custom format (note the linebreak): I am almost sure that similar extension should exist for Firefox as well. i think this is for copying all tabs, not selected ones. ... also i think this extension does not exist any more in firefox. I have not tried them: - https://github.com/piroor/copy-selected-tabs-to-clipboard/ - https://github.com/yorkxin/copy-as-markdown - Are you going to capture reviews of "rice cookers" that could be considered as ordinary pages or you are going to save items from online stores? ... Could you inspect head element of pages in your favorite stores contains desired metadata using page source or inspect element tools? my web knowledge is too limited to understand your question, but i am just hoping it would capture ordinary amazon links, review sites, and so on. It seems that quality of metadata in marketplaces like amazon severely depends on particular seller. The extension attempts to treat some data specially if there are microdata or JSON-LD with Product schema.org type. If I remember correctly, Amazon does not expose canonical link explicitly. [now if i can only debug the extra-blank-lines-in-capture problem.] Fully agree that it is really annoying. It is among high priority items in my TODO list. we might be talking about different thinks. i am referring to something in org that adds blank lines when my particular org capture templates are used. See info "(org) Template elements" https://orgmode.org/manual/Template-elements.html :empty-lines, :empty-lines-after, :empty-lines-before however I can not say that I really understand their meaning. Actually I do not mind to have empty line before next heading when refile is completed. My impression that it depends on number of empty lines at the end of capture buffer. I usually add some comments to captured pages. On 18/01/2022 08:03, Samuel Wales wrote: > my amazon example was silly and confusing. the point isn't shopping > for something; it's anything. science papers, news outlets, nerd > blogs. Scientific papers require more work, it is necessary to make them available to org-cite somehow. Some nerds use quite peculiar blog engines and strange setting of metadata. So shopping on some sites might work better than other cases.
