Re: First steps exporting to tex
> Hi Tim
> I have been exporting from orgmode to PDF time ago, but very basic PDFs,
> playing with some basic options of orgmode. When I tried to produce a
> meeting minute with a logo in the heading, I decided that I should learn
> better a way of exporting, because the minute meeting was a first
> challenge, but many more would come. For example, for that task I started
> with this code, which I think it goes far beyond what the "LaTeX
> Defaults" can offer (I must yet "play around" a lot with it):
> #+BEGIN_SRC
> #+options: toc:nil
> #+options: num:1
> #+options: d:nil
> #+export_file_name: BORRAR
> #+options: broken-links:mark
> #+LaTeX_header_extra: \usepackage{fancyhdr}
> #+begin_export LaTeX
> \thispagestyle{fancy}
> \lhead{\includegraphics[width=4cm]{//192.168.1.2/f/LOGO-IMAGEN
> CORPORATIVA/IMAGEN CORPORATIVA 2018/DEFINITIVO
> ANAGRAMAS/SELLO1_grueso.png}}
> \rhead{Student Name: John Doe\\
> Student ID: 1234\\
> Course: IDB 601 (Fall 2020)}
> #+end_export
> #+END_SRC
> The buffer I exported my meeting notes from has much more information which
> is not related with meetings nor with the logo. So I foresaw 3 things:
> 1 A fast cluttering of the buffers with LaTeX headings would happen, as I
> will learn more about LaTeX and I will want to add more and more
> packages.
> 2 A need for flexibility to be able to export different kinds of documents
> from the same buffer, ideally achieved just by changing a line (or few lines)
> in the buffer. Although, from my example, it seems that ~#+begin_export...~
> contents can't be added in that way.
> 3 A great potential if it were possible to use already existing, and well
> curated, LaTeX templates frictionless through orgmode.
> I find quite useful to analyse the default generated TeX file though.
> Best regards
OK, now I understand your objectives a bit more there are a couple of
things I would recommend.
Org is already fully setup to provide a clean and consistent way to do
much of what you are currently achieving with export latex blocks and
which can avoid much of the clutter in your org files. The way you are
customizing the latex etc is OK for 'one off' type hacks, but isn't the
best solution for crating a standard format.
Have a look at the documentation for org-latex-classes. In this
variable, you can define your own 'pseudo' classes, which you can then
use in your org file with a simple #+LATEX_CLASS: line. This will take
care of all the preamble stuff, plus more (it uses other org variables,
such as ones for listing default 'usepackage' lines and other preamble
lines, so read the documentation carefully).
So, you could add a 'meeting' class to that variable and when you need
to do an org file for meetings, just add #+LATEX_CLASS; meeting at the
top of your org file and your ready to go.
This is what I did for my 'work' class, which produces documents
that included my employers logo, branding colours, fonts, font sizes,
heading formats etc. Now when I need to produce a work document, I just
add the #+LATEX_CLASS: header and then just write a normal org file. I
actually had a number of these custom 'class' definitions.
Really nice thing is that if I find something needs to be tweaked or
changed, I just have to fix the org-latex-classes and related
definitions and know that if I re-export any of my org files that use
them, they will all get the fix (no need to edit each individual org
file to apply the fix).
--
Tim Cross
Re: Bug: inconsistent escaping of coderef regexp
Hi Nicolas,
I've attached a patch with a first pass implementation that I think
resolves most of the issues. It probably needs a few tests to go along
with it, but I think it is the simplest way forward. I tried to make the
changes without disrupting the org-babel info structure, but it comes
with the cost of having to pull out :coderef-prefix in a number of separate
contexts. Best,
Tom
> If possible, I'd like not to conflate current issue with switches
> deprecation, which needs to be discussed separately.
We can decouple them, so not an issue. The attached patch implements
the header arg equivalents of -r and -l without making any changes to the
existing switch behavior.
> What do you mean by "it is impossible for the user to specify their own
> coderef regexp that can be used in both cases"? In particular, what is
> a coderef regexp in this context? I know about coderef format, but
> I don't think users are supposed to provide a regexp here.
I did a first pass implementation and realized that allowing users to
specify coderef-regexp is a bad idea. The attached patch fixes the
divergent behavior of org-bable-tangle-single-block and provides a
standard way to specify a :coderef-prefix regexp so that empty
comments can be stripped.
From e017fe3f4fb36da2c8560ae526b8bdfd42dc Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Sun, 4 Apr 2021 21:40:32 -0700
Subject: [PATCH] improve org-src-coderef-regexp and regularize usage
* lisp/ob-core.el
org-babel-common-header-args-w-values: new :coderef- header args
org-babel-safe-header-args: include the new :coderef- header args
(org-babel-get-src-block-info): calulate params before info in let* so
that they can be used to set the coderef-format field (nth 6 info)
(org-babel--expand-body): use coderef-prefix to correctly strip
coderefs when expanding
* lisp/ob-tangle.el (orb-babel-tangle-single-block): Regularize
behavior when removing coderefs during tangling. This fixes an issue
where trailing whitespace would be retained when coderefs were removed
for tangling. Make the header argument :coderef-tangle no work the
same way that the -r switch currently works
* lisp/ol.el (org-link-search): use org babel info to match the
coderef format for each block
* lisp/org-src.el (org-src-coderef-regexp): now takes an additional
argument rx-prefix that can be used to customize the text preceeding
the coderef that should be removed during tangling, this is most
useful for removing comments and trailing whitespace.
* lisp/ox.el (org-export-resolve-coderef)
and (org-export-unravel-code): use org babel info to
correctly match the coderef format for each block.
This commit adds support for three new src block header arguments,
:coderef-format :coderef-prefix and :coderef-tangle. :coderef-format
has the same behavior has the org src switch -l and :coderef-tangle
has the same behavior as org src switch -r. :coderef-prefix provides
new functionality and makes it possible to set the regexp for text
leading up to the coderef. In particular this can be used to strip
comments, which are required if authoring an org file that works with
older versions of org.
---
lisp/ob-core.el | 43 +--
lisp/ob-tangle.el | 18 +++---
lisp/ol.el| 17 +++--
lisp/org-src.el | 5 +++--
lisp/ox.el| 15 +++
5 files changed, 61 insertions(+), 37 deletions(-)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 2e78ac3e6..feb6f2235 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -76,7 +76,7 @@
(declare-function org-previous-block "org" (arg block-regexp))
(declare-function org-show-context "org" ( key))
(declare-function org-src-coderef-format "org-src" ( element))
-(declare-function org-src-coderef-regexp "org-src" (fmt label))
+(declare-function org-src-coderef-regexp "org-src" (fmt label rx-prefix))
(declare-function org-src-get-lang-mode "org-src" (lang))
(declare-function org-table-align "org-table" ())
(declare-function org-table-convert-region "org-table" (beg0 end0 separator))
@@ -392,6 +392,9 @@ then run `org-babel-switch-to-session'."
(defconst org-babel-common-header-args-w-values
'((cache . ((no yes)))
(cmdline . :any)
+(coderef-format . :any)
+(coderef-prefix . :any)
+(coderef-tangle . ((nil yes no)))
(colnames . ((nil no yes)))
(comments . ((no link yes org both noweb)))
(dir . :any)
@@ -434,7 +437,8 @@ Note that individual languages may define their own language
specific header arguments as well.")
(defconst org-babel-safe-header-args
- '(:cache :colnames :comments :exports :epilogue :hlines :noeval
+ '(:cache :coderef-format :coderef-prefix :coderef-tangle
+ :colnames :comments :exports :epilogue :hlines :noeval
:noweb :noweb-ref :noweb-sep :padline :prologue :rownames
:sep :session :tangle :wrap
(:eval . ("never" "query"))
@@ -607,29 +611,31 @@ a list with the following pattern:
(lang-headers
Re: [feature request] The :pre header argument
Hi, Rodrigo Morales writes: > I've provided more relevant information on this feature request [[ > https://codeberg.org/rdrg109/gists/src/branch/main/feature-request-pre-header-argument.org][here]]. > Please consider reading that instead of the first message on this thread. I think the origin intention of the :post header argument is slightly different from your use-case. It is intended to be used for post-processing the results: > The ‘post’ header argument is for post-processing results from block > evaluation. When ‘post’ has any value, Org binds the results to > ‘*this*’ variable for easy passing to ‘var’ header argument > specifications (see *note Environment of a Code Block::). That makes > results available to other code blocks, or even for direct Emacs Lisp > code execution. If you want to execute some arbitrary code before/after your code block, it is probably more canonical to use noweb references. Using your example: #+begin_src emacs-lisp # Cleanup first using experiments/clean-dir(): "<>" # Create dir structure using # minimal-reproducible-example/create-dir-structure: # "<>" # Finally, execute `tree' using experiments/execute-tree: (message "<>") #+end_src It will not produce spurious variable definitions. Best, Ihor
Re: Bug: inconsistent escaping of coderef regexp
Hello, Tom Gillespie writes: > After a bit of investigation I understand the issue better now. > There are two problems here. One is an easy single line change, > the other is a deeper issue, which is that it is impossible for the > user to specify their own coderef regexp that can be used in both > cases. No matter what change we make we are likely to break > existing org files if users relied on one behavior and not the other. [...] > If we want a temporary fix, a patch is attached, but I would suggest > against changing the behavior right now and instead work toward > a new, more consistent system using header args. If possible, I'd like not to conflate current issue with switches deprecation, which needs to be discussed separately. What do you mean by "it is impossible for the user to specify their own coderef regexp that can be used in both cases"? In particular, what is a coderef regexp in this context? I know about coderef format, but I don't think users are supposed to provide a regexp here. Regards, -- Nicolas Goaziou
Re: Using backticks for the inline code delimeter?
Hello, Joost Kremers writes: > So if I were so inclined, I could write a parser for Markdown that produces > this > internal format and get all the export targets that Org has? (Not that I'm so > inclined... Just wondering. ;-) ) You can turn this internal format back to Org syntax with `org-element-interpret-data' and you can do anything with it, including exporting it. >> Anyway, one of the goals of Org is to provide a universal document >> format. It is not there yet, but allowing local modifications of the >> syntax certainly goes against that goal. > > I tend to agree that allowing local modifications of Org's syntax is pretty > much > pointless, but then why is `org-emphasis-alist` a user option? In practice, the faces, i.e., the values, are meant to be customizable, not the keys. Regards, -- Nicolas Goaziou
Re: Bug: inconsistent escaping of coderef regexp
Hi Nicolas, After a bit of investigation I understand the issue better now. There are two problems here. One is an easy single line change, the other is a deeper issue, which is that it is impossible for the user to specify their own coderef regexp that can be used in both cases. No matter what change we make we are likely to break existing org files if users relied on one behavior and not the other. Given this, I would say that it is worse to break tangling behavior than it is to break coderef search because it is obvious to the user when coderef search breaks, whereas a change in tanging behavior is a silent change that users will not be aware of. If we want a temporary fix, a patch is attached, but I would suggest against changing the behavior right now and instead work toward a new, more consistent system using header args. I think that moving to use header args to control these is an opportunity to resolve both issues, and to make a start toward eventually deprecating the switches. The only question that I have right now regarding that implementation is whether we provide header args for just the coderef regexp or also for the coderef format, with the coderef regexp taking precedence. The deeper issue is that the format string that appears in the org-src snippit below is hard coded, and if we allow users to set the coderef format, then it may make sense to let them set that format string. However, this would duplicate the simpler functionality of simply allowing the user to provide their own coderef regexp. At the moment I have two proposed header args which are :coderef-regexp with default matching the current output of the org-src snippit below, and :coderef-tangle which defaults to yes matching the behavior of the existing =-r= switch. There is an option for a 3rd header arg that would directly replaced the =-l= switch :coderef-format, however as mentioned above it adds significant complexity and requires a fourth argument :coderef-surround or something like that which is the hard coded format string in the org-src snippit. I'm working on a basic implementation and will respond in this thread again when I have something worth looking at. Best! Tom For the record there are at least 3 different inconsistent regex that are used to detect coderefs. org-element: (string-match "-l +\"\\([^\"\n]+\\)\"" switches) is duplicated between org-element-src-block-parser and org-element-example-block-parser org-src: (format "\\([ \t]*\\(%s\\)[ \t]*\\)$" (replace-regexp-in-string "%s" (if label (regexp-quote label) "\\([-a-zA-Z0-9_][-a-zA-Z0-9_ ]*\\)") (regexp-quote fmt) nil t)) ob-tangle: (re-search-forward (replace-regexp-in-string "%s" ".+" cref-fmt) nil t) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index aa0373ab8..677d9d8ba 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -446,7 +446,7 @@ non-nil, return the full association list to be used by (when (string-match "-r" extra) (goto-char (point-min)) (while (re-search-forward - (replace-regexp-in-string "%s" ".+" cref-fmt) nil t) + (replace-regexp-in-string "%s" ".+" (org-src-coderef-regexp cref-fmt)) nil t) (replace-match ""))) (run-hooks 'org-babel-tangle-body-hook) (buffer-string
Re: Using backticks for the inline code delimeter?
On Sun, Apr 04 2021, Nicolas Goaziou wrote: > Joost Kremers writes: > >> On Sat, Apr 03 2021, Tom Gillespie wrote: >>> Is there any reason why folks couldn't just customize >>> org-emphasis-alist using a file local variable? > > [...] > >> If all exporters worked off an internal representation such as what is >> returned by `org-element-parse-buffer`, it should be easier to modify the >> front-end syntax. > > I think they do. So if I were so inclined, I could write a parser for Markdown that produces this internal format and get all the export targets that Org has? (Not that I'm so inclined... Just wondering. ;-) ) > Anyway, one of the goals of Org is to provide a universal document > format. It is not there yet, but allowing local modifications of the > syntax certainly goes against that goal. I tend to agree that allowing local modifications of Org's syntax is pretty much pointless, but then why is `org-emphasis-alist` a user option? I originally thought its purpose was to customise Org's syntax, until I found that the exporters didn't play ball. ;-) -- Joost Kremers Life has its moments
[PATCH] LaTeX export: arbitrary float environments
Aloha all,
LaTeX users are able to define arbitrary float types, e.g. with
the float package. The attached patch makes them accessible from
Org mode.
This is a follow on to my efforts several years ago to support the
Tufte-LaTeX package in Org mode, and a suggestion at the time (by
Rasmus iirc) to implement an :environment attribute for LaTeX
export. This patch achieves a similar goal, but is a bit lighter
imo.
Let me know if you have questions.
All the best,
Tom
>From 5154901b781f93d08851f96431c976f010fc420c Mon Sep 17 00:00:00 2001
From: "Thomas S. Dye"
Date: Sun, 4 Apr 2021 08:11:40 -1000
Subject: [PATCH] LaTeX export: arbitrary float environments
* lisp/ox-latex.el (`org-latex--inline-image', `org-latex--decorate
table'): recognize arbitrary :float value.
LaTeX users are able to define arbitrary float types. This patch
makes them accessible from Org mode.
* etc/ORG-NEWS: Announce new :float capability.
---
etc/ORG-NEWS | 6 +-
lisp/ox-latex.el | 16 +++-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9fc126b2f..cdfb1c727 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -12,6 +12,10 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
* Version 9.5 (not yet released)
** New options and settings
+*** LaTeX attribute ~:float~ now passes through arbitrary values
+
+LaTeX users are able to define arbitrary float types, e.g. with the float package. The Org mode LaTeX exporter is now able to process and export arbitrary float types. The user is responsible for ensuring that Org mode configures LaTeX to process any new float type.
+
*** Option ~org-hidden-keywords~ now also applies to #+SUBTITLE:
The option ~org-hidden-keywords~ previously applied
@@ -106,7 +110,7 @@ behavior.
By default ox-html now inlines webp images.
** New features
-*** =ob-python= improvements to =:return= header argument
+*** =ob-python= improvements to =:return= header argument
The =:return= header argument in =ob-python= now works for session
blocks as well as non-session blocks. Also, it now works with the
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 376d27a07..514801d7c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2377,6 +2377,7 @@ used as a communication channel."
((string= float "sideways") 'sideways)
((string= float "multicolumn") 'multicolumn)
((and (plist-member attr :float) (not float)) 'nonfloat)
+(float float)
((or float
(org-element-property :caption parent)
(org-string-nw-p (plist-get attr :caption)))
@@ -2470,6 +2471,18 @@ used as a communication channel."
nil t
;; Return proper string, depending on FLOAT.
(pcase float
+ ((and (pred stringp) env-string)
+ (format "\\begin{%s}%s
+%s%s
+%s%s
+%s\\end{%s}"
+ env-string
+ placement
+ (if caption-above-p caption "")
+ (if center "\\centering" "")
+ comment-include image-code
+ (if caption-above-p "" caption)
+ env-string))
(`wrap (format "\\begin{wrapfigure}%s
%s%s
%s%s
@@ -3200,7 +3213,7 @@ centered."
(defun org-latex--decorate-table (table attributes caption above? info)
"Decorate TABLE string with caption and float environment.
-ATTRIBUTES is the plist containing is LaTeX attributes. CAPTION
+ATTRIBUTES is the plist containing LaTeX attributes. CAPTION
is its caption, as a string or nil. It is located above the
table if ABOVE? is non-nil. INFO is the plist containing current
export parameters.
@@ -3211,6 +3224,7 @@ Return new environment, as a string."
(cond ((and (not float) (plist-member attributes :float)) nil)
((member float '("sidewaystable" "sideways")) "sidewaystable")
((equal float "multicolumn") "table*")
+ (float float)
((or float (org-string-nw-p caption)) "table")
(t nil
(placement
--
2.25.1
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: Using backticks for the inline code delimeter?
Hello, Bill Burdick writes: > Allowing local modifications lets people experiment and share > their impressions. Local modifications are allowed, this is Elisp after all. I don't see a good reason to make it easier, tho. > Unless the org-mode format is perfect for universal needs now and into the > future? I think you misunderstood me. I'm not against Org syntax evolving somehow if necessary, but I see no good in users cooking their own pet Org syntax. IMO, Markdown syntax is an example not to follow. Therefore, I would not recommend digging in that direction. Regards, -- Nicolas Goaziou
Re: Using backticks for the inline code delimeter?
On 02/04/2021 18:23, Andreas Eder wrote: On Do 01 Apr 2021 at 09:32, autofrettage wrote: Please evaluate the design of Org Mode (and other things) without putting a value on how similar it is to other things. A bicycle would appear more familiar to a car driver if we replaced the handlebar with a steering wheel, but it wouldn't make the bike any better. If someones fingers cannot adjust, let him/her customise a bit. +1 I think, for a part of people in this thread another comparison is more appropriate. Bike handlebars are quite specialized and each type of bike has its own shape to be more convenient. And steering wheel is more suitable when wider range of angles is required. Choices of characters to denote code snippets are quite arbitrary. Imagine that you have to drive at the right lane while you are around the office. But as soon as you cross the river on your everyday trip to home, you have to stick to the left side of the road... There is no apparent advantage or defect of any of these rules. The mix is rather dangerous. "Emacs everywhere" suggested in another message could be a rescue in some cases. Unless original formatting is already broken by another external tool. Customization becames a pain when communication is involved. OK, what might be a reason why org does not use backticks is that backticks around lisp expressions could be confusing.
Re: Using backticks for the inline code delimeter?
On Sun, Apr 4, 2021 at 7:21 AM Nicolas Goaziou wrote: > Anyway, one of the goals of Org is to provide a universal document > format. It is not there yet, but allowing local modifications of the > syntax certainly goes against that goal. > Allowing local modifications lets people experiment and share their impressions. So rather than going against the goal of a universal document format, it is crucial for progress towards it. Unless the org-mode format is perfect for universal needs now and into the future? -- Bill
Re: Idea for handling timezones
The notes below are quite general and unrelated to particular message. On 04/04/2021 07:51, Tom Gillespie wrote: followed by a space and then the repeat or delay for example [+1-01-01 10:11:00,992315771-04:00 Sat] or [-480-08-20 05:00+01:00] or more temporally local [2021-03-03 17:43-07:00 Sat] Just an idea, I do not know if it is feasible and convenient. Have anyone considered a kind of src blocks to describe timestamps? Current inline syntax is suitable for simple cases, sometimes more details are required, some information could be redundant to allow consistency check: - Date-time in the original form as it appeared in external source (with a hint related to particular format e.g. rfc822 date. - Either it is local time or it is bound to some event as Solar eclipse. - List if time zones to have notion of local time of all participants of an online meeting. - Location for planned event since there is a chance that existing time zone will be split into smaller ones. A couple of bookmarks to get impression of complexity: - https://stackoverflow.com/tags/timezone/info timezone Tag Info - https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time Falsehoods programmers believe about time and follow-ups. Emacs API is hardly suitable for working with multiple time zones. Something could be borrowed from other projects, e.g. https://howardhinnant.github.io/date_algorithms.html Low-Level Date Algorithms (C++) A special attribute has been added in python to deal with local time ambiguity around time transitions https://docs.python.org/3/library/datetime.html#datetime.datetime.fold https://www.python.org/dev/peps/pep-0495/ PEP 495 -- Local Time Disambiguation I think, it is a challenge to provide a convenient way to generate agenda for a trip across several time zones. P.S. Raw UNIX timestamp as 1234567890 is convenient for some computations but hardly human friendly. UTC date-time 2009-02-13T23:31:30Z is better. With particular offset 2009-02-13T22:31:30-01:00 it is equally precise and even more convenient. Still neither of such forms are applicable if it is scheduled event with fixed local time and offset of particular timezone might be changed.
[PATCH 3/3] test-org-protocol.el: Add expected failures for file:/// URLs
* testing/lisp/test-org-protocol.el
(test-org-protocol/org-protocol-store-link-file,
test-org-protocol/org-protocol-capture-file): Add tests to document
that existing calls to `org-protocol-sanitize-uri' could make passed
URLs invalid by changing number of slashes after scheme.
Till a fix of the problem the new tests are marked as expected failures.
Unless a relatively recent commit 5748615c48, I would believe that
`org-protocol-sanitize-uri' was added by mistake to the initial
implementation. Capture URLs are anyway escaped with percent encoding.
---
testing/lisp/test-org-protocol.el | 24
1 file changed, 24 insertions(+)
diff --git a/testing/lisp/test-org-protocol.el
b/testing/lisp/test-org-protocol.el
index 5ab96fdc2..d33052b30 100644
--- a/testing/lisp/test-org-protocol.el
+++ b/testing/lisp/test-org-protocol.el
@@ -78,6 +78,16 @@
(should (null (org-protocol-check-filename-for-protocol uri (list uri)
nil)))
(should (equal (car org-stored-links) '("URL3" "TITLE3")
+(ert-deftest test-org-protocol/org-protocol-store-link-file ()
+ "store-link: `org-protocol-sanitize-uri' could distort URL."
+ :expected-result :failed
+ (let ((uri
"/org-protocol:/store-link:/file%3A%2F%2F%2Fetc%2Fmailcap/Triple%20Slash"))
+(should (null (org-protocol-check-filename-for-protocol uri (list uri)
nil)))
+(should (equal (car org-stored-links) '("file:///etc/mailcap" "Triple
Slash"
+ (let ((uri
"/org-protocol:/store-link?url=file%3A%2F%2F%2Fetc%2Fmailcap=Triple%20Slash"))
+(should (null (org-protocol-check-filename-for-protocol uri (list uri)
nil)))
+(should (equal (car org-stored-links) '("file:///etc/mailcap" "Triple
Slash")
+
(ert-deftest test-org-protocol/org-protocol-capture ()
"Test `org-protocol-capture' specifications."
(let* ((org-protocol-default-template-key "t")
@@ -134,6 +144,20 @@
test-urls)
(delete-file temp-file-name)))
+(ert-deftest test-org-protocol/org-protocol-capture-file ()
+ "capture: `org-protocol-sanitize-uri' could distort URL."
+ :expected-result :failed
+ (let* ((org-protocol-default-template-key "t")
+(temp-file-name (make-temp-file "org-protocol-test"))
+(org-capture-templates
+ `(("t" "Test" plain (file ,temp-file-name) "%a\n%i\n" :kill-buffer
t
+(let ((uri
"/org-protocol:/capture:/t/file%3A%2F%2F%2Fetc%2Fmailcap/Triple%20Slash/Body"))
+ (should (null (org-protocol-check-filename-for-protocol uri (list uri)
nil)))
+ (should (string= (buffer-string) "[[file:///etc/mailcap][Triple
Slash]]\nBody")))
+(let ((uri
"/org-protocol:/capture?template=t=file%3A%2F%2F%2Fetc%2Fmailcap=Triple%20Slash=Body"))
+ (should (null (org-protocol-check-filename-for-protocol uri (list uri)
nil)))
+ (should (string= (buffer-string) "[[file:///etc/mailcap][Triple
Slash]]\nBody")
+
(ert-deftest test-org-protocol/org-protocol-open-source ()
"Test org-protocol://open-source links."
(let* ((temp-file-name1 (make-temp-file "org-protocol-test1"))
--
2.25.1
[PATCH 2/3] org-protocol.el: Fix detection of old-style URIs
* lisp/org-protocol.el (org-protocol-check-filename-for-protocol): Avoid incorrect regexp in check whether command line argument uses new syntax. Fix failures of org-protocol tests. Question mark was not escaped in the previous version 928e67df7e, so any string was matched by lazy "*". Match in never used, thus `string-match-p` would be better, but actually regexp is redundant here. It is not documented what browser or desktop environment adds extra slash before "?". Accordingly to mid:a2b0655f-bf28-4943-bc05-99021bfda...@robewald.de, Windows may be involved. Likely it happens with double slash after schema as in org-protocol://capture?url=URL=TITLE due to subprotocol is considered as host name and URI is normalized by adding a slash as mandatory path part before "?" query. So just reverting the original commit will likely cause a regression. Another guess is that with single or triple slash (org-protocol:/capture?url=URL) subprotocol is a part of path thus no "smart" actions are necessary. --- lisp/org-protocol.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el index 731f51e19..86a8dc3bc 100644 --- a/lisp/org-protocol.el +++ b/lisp/org-protocol.el @@ -631,7 +631,7 @@ CLIENT is ignored." (greedy (plist-get (cdr prolist) :greedy)) (split (split-string fname proto)) (result (if greedy restoffiles (cadr split))) - (new-style (string-match "/*?" (match-string 1 fname + (new-style (not (= ?: (aref (match-string 1 fname) 0) (when (plist-get (cdr prolist) :kill-client) (message "Greedy org-protocol handler. Killing client.") (server-edit)) -- 2.25.1
[PATCH 1/3] test-org-protocol.el: Fix the case for parse parameters with complex argument
* testing/lisp/test-org-protocol.el (test-org-protocol/org-protocol-parse-parameters): Specify that the case simulating real life capture uses new style parameters string to prevent test failure. It looks like a typo survived since addition of this case in 2216f4d2c7. --- testing/lisp/test-org-protocol.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testing/lisp/test-org-protocol.el b/testing/lisp/test-org-protocol.el index b5df7c132..5ab96fdc2 100644 --- a/testing/lisp/test-org-protocol.el +++ b/testing/lisp/test-org-protocol.el @@ -40,7 +40,7 @@ "url=https%3A%2F%2Forgmode.org%2Forg.html%23capture-protocol&" "title=The%20Org%20Manual&" "body=9.4.2%20capture%20protocol")) -(data (org-protocol-parse-parameters url))) +(data (org-protocol-parse-parameters url t))) (should (string= (plist-get data :template) "p")) (should (string= (plist-get data :url) "https://orgmode.org/org.html#capture-protocol;)) (should (string= (plist-get data :title) "The Org Manual")) -- 2.25.1
Broken org-protocol tests
Hi, Is there any reason why org-protocol tests are not run by default? Is dependency on server.el considered as too heavy for routine testing? I know, the tests are broken, but I suspect, it is a consequence that additional efforts are required to run them. Almost unrelated note: either I missed something or org tests depend on a couple of things unavailable in emacs-25, e.g. temporary-file-directory function.
Re: Using backticks for the inline code delimeter?
Hello, Joost Kremers writes: > On Sat, Apr 03 2021, Tom Gillespie wrote: >> Is there any reason why folks couldn't just customize >> org-emphasis-alist using a file local variable? [...] > If all exporters worked off an internal representation such as what is > returned by `org-element-parse-buffer`, it should be easier to modify the > front-end syntax. I think they do. Anyway, one of the goals of Org is to provide a universal document format. It is not there yet, but allowing local modifications of the syntax certainly goes against that goal. Regards, -- Nicolas Goaziou
Re: First steps exporting to tex
Ypo writes: > I've already tried that. But it doesn't seem to understand the HOME > directory ~~/~. At least at Windows. I haven't touched Windows for a thousand years :-), but maybe this thread can help you: https://stackoverflow.com/questions/13584118/how-to-write-a-path-with-latex best regards, Juan Manuel
Re: how to export (latex) a image without using figure
>>> "JMM" == Juan Manuel Macías writes:
Hi Juan,
> Hi Uwe,
> Try:
> #+ATTR_LaTeX: :float nil
> #+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$,
> $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
> [[./images/dfp_03.png]]
Muchas gracias, I mean thank you very much.
Uwe
smime.p7s
Description: S/MIME cryptographic signature
Re: how to export (latex) a image without using figure
Hi Uwe,
Try:
#+ATTR_LaTeX: :float nil
#+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$,
$\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
[[./images/dfp_03.png]]
Best regards,
Juan Manuel
Uwe Brauer writes:
> Hi
>
> Currently
>
> #+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$,
> $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
> #+NAME: fig:plotcalor23
>
> [[./images/dfp_03.png]]
>
> Gets translated to
>
> \begin{figure}[htbp]
> \centering
> \includegraphics[width=.9\linewidth]{./images/dfp_03.png}
> \caption{\label{fig:plotcalor23}La función La función \(x^2 e^{-\alpha x}
> = \frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con \(p=0.3\)}
> \end{figure}
>
> For reasons that needs a longer explanation I would need.
>
>
>
> \includegraphics[width=.9\linewidth]{./images/dfp_03.png}
> \captionof{figure}{\label{fig:plotcalor23}La función La función \(x^2
> e^{-\alpha x} = \frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con
> \(p=0.3\)}
>
>
> How can this be achieved?
>
> Thanks
>
> Uwe Brauer
>
>
>
>
Re: First steps exporting to tex
>>> El 03/04/2021 a las 18:00, emacs-orgmode-requ...@gnu.org escribió:
Message: 34
Date: Sun, 04 Apr 2021 00:31:24 +1100
To:emacs-orgmode@gnu.org
Subject: Re: First steps exporting to tex
Message-ID:<871rbr7ag1@gmail.com>
Content-Type: text/plain; charset=utf-8
Why do you think you need any of this for your 'first steps'. Start by
just writing your org file and exporting it to LaTeX or pdf. Then, once
you have your first document, see what you think needs changing and come
back and ask advice on what you need to do to make the changes you want.
In your first document, don't use any LaTeX commands, header options or
anything else - just write your document using standard org mode.
Org already sets up a reasonable starting default. Once you know what
the default is, then we can discuss what you may need to change. For
many documents, you may not need to change much at all and you may not
need any templates - for example, you will likely want to change the
margin sizes (this is a common request) or you may want to see what some
of the other 'standard' LaTeX document classes are like. All of this can
be achieved with just minor configuration of org mode.
The org export to LaTeX only needs to be as complicated as you need it
to be. Org has variables which can be used to add/remove things from the
preamble and once you have those configured, you don't have to put
anything in the org file itself. Start simple and add as you find a need
rather than try to start with something complex which might not be
necessary.
-- Tim Cross
Hi Tim
I have been exporting from orgmode to PDF time ago, but very basic PDFs,
playing with some basic options of orgmode. When I tried to produce a
meeting minute with a logo in the heading, I decided that I should learn
better a way of exporting, because the minute meeting was a first
challenge, but many more would come. For example, for that task I
started with this code, which I think it goes far beyond what the "LaTeX
Defaults" can offer (I must yet "play around" a lot with it):
#+BEGIN_SRC
#+options: toc:nil
#+options: num:1
#+options: d:nil
#+export_file_name: BORRAR
#+options: broken-links:mark
#+LaTeX_header_extra: \usepackage{fancyhdr}
#+begin_export LaTeX
\thispagestyle{fancy}
\lhead{\includegraphics[width=4cm]{//192.168.1.2/f/LOGO-IMAGEN
CORPORATIVA/IMAGEN CORPORATIVA 2018/DEFINITIVO ANAGRAMAS/SELLO1_grueso.png}}
\rhead{Student Name: John Doe\\
Student ID: 1234\\
Course: IDB 601 (Fall 2020)}
#+end_export
#+END_SRC
The buffer I exported my meeting notes from has much more information
which is not related with meetings nor with the logo. So I foresaw 3
things:
1. A fast cluttering of the buffers with LaTeX headings would happen,
as I will learn more about LaTeX and I will want to add more and
more packages.
2. A need for flexibility to be able to export different kinds of
documents from the same buffer, ideally achieved just by changing a
line (or few lines) in the buffer. Although, from my example, it
seems that ~#+begin_export...~ contents can't be added in that way.
3. A great potential if it were possible to use already existing, and
well curated, LaTeX templates frictionless through orgmode.
I find quite useful to analyse the default generated TeX file though.
Best regards
>>> El 03/04/2021 a las 12:15, Martin Steffen escribió:
Good morning, Martin
For the "preamble" of a latex document, the general setup that comes
_before_ \begin{document} and before any output is generated, I use
native latex using instructions like
#+BEGIN_SRC
#+latex_header: \input{switches}
#+latex_header: \input{preamble}
#+latex_header: \input{style/style-common}
#+latex_header: \input{macros}
#+END_SRC
Thanks for your input. I'll keep with that.
As far controlling input is concerned, I also rely on latex-specific
setting (outside org, also outside emacs), things like environment
settings like $TEXINPUT, a path-specification, where one can control
where LaTeX finds (additional) stylefiles, outside of the standard
``load-path''.
Thus, I often try to avoid to use hardcoded things, like
>>> \input{~//export//template.tex}
I would use \input{template} (".tex" is not needed) and I make sure, the
templatex.tex file is included in the $TEXINPUTS-path. Typically, the
current directory "./" should be included by default (and stuff from
the latex-installation is also routinely found)
Thanks. But I can read in this post:
https://tex.stackexchange.com/questions/93712/definition-of-the-texinputs-variable
that ~$TEXINPUT~ could give some problems with LuaLaTeX, could it be? It
seems important, since LuaLaTeX is the safe recommendation of our
mailing list pal Juan Manuel Macías [maciaschain@...].
>>> El 03/04/2021 a las 12:43, Dr. Arne Babenhauserheide escribió:
A pleasure, Arne.
Alternatively you can use #+INCLUDE: template.org
to grab more than just the org-setup.
And there you show me a different way: ~#+INCLUDE,~
how to export (latex) a image without using figure
Hi
Currently
#+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$,
$\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
#+NAME: fig:plotcalor23
[[./images/dfp_03.png]]
Gets translated to
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{./images/dfp_03.png}
\caption{\label{fig:plotcalor23}La función La función \(x^2 e^{-\alpha x} =
\frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con \(p=0.3\)}
\end{figure}
For reasons that needs a longer explanation I would need.
\includegraphics[width=.9\linewidth]{./images/dfp_03.png}
\captionof{figure}{\label{fig:plotcalor23}La función La función \(x^2
e^{-\alpha x} = \frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con
\(p=0.3\)}
How can this be achieved?
Thanks
Uwe Brauer
Re: Using backticks for the inline code delimeter?
On Sat, Apr 03 2021, Tom Gillespie wrote:
> Is there any reason why folks couldn't just customize
> org-emphasis-alist using a file local variable? Just add ("`" org-code
> verbatim) and see what happens. Knowing a bit about the codebase this
> will probably lead to trouble during export because the backends are
> likely unaware,
Yes, I tried this at one time because /.../ is used in linguistics to denote
phonological representations. So I removed the entry for `/` in
`org-emphasis-alist` and replaced it with something else. It worked up until the
point where you start exporting.
If all exporters worked off an internal representation such as what is
returned by `org-element-parse-buffer`, it should be easier to modify the
front-end syntax.
--
Joost Kremers
Life has its moments
A formal grammar for Org
Dear all, Here is a draft of a formal grammar for Org mode [1]. It is still in a rough state, despite quite a bit of work. However, following some changes to improve performance for parsing real (big) Org files, I think it is time to share it with the community so that we can start to gather feedback. There are a number of opportunities that I have found for simplifying the org grammar (sometimes by extending it to make it more regular, and in the process adding useful features) that are much easier to understand with this grammar in hand as a reference. The grammar itself is implemented using Racket's #lang brag (see [2] for an overview of brag's syntax). I had considered trying to break it up into literate sections in an Org file, but for now decided to leave it as a single file to simplify the development workflow. As a result the full implementation is fairly long [3]. Comments and feedback would be greatly appreciated. Best! Tom 1. https://github.com/tgbugs/laundry 2. https://docs.racket-lang.org/brag/#%28part._.The_language%29 3. https://github.com/tgbugs/laundry/blob/master/org-mode/parser.rkt
Re: Generating documentation about Org from random org file
Michael, > Now I want to use this file to showcase the use case a bit, but also > to produce documentation about Org, about how to solve a problem with > Org. Therefore I want to show the code blocks, but this time with the > begin/end tags, with header parameters etc. Is there a nice way to do > that without too much code duplication and convolution? Or should I > just copy the file and separate the use case and the showcase one? well. sigh. i had a desire to do something like that recently for a presentation on using Org Mode with ESS for R code development. (part of a larger, "intro to R with ESS" series. with initial help/pointers of others on this list, i developed some code that takes a file and "orgifies" it (after, in my case, "resultifying"). the code, if you want to look at it, is in the file ess-org.org in this repository: https://github.com/ess-intro/presentation-org-mode (to cover my shame, somewhat -- that *file* is not really intended for public consumption, it's messy, etc. *do* feel free to complain about my code itself.) the first code block is =org-filter-by-argument-value=. as an example, *this* .org file https://ess-intro.github.io/presentation-org-mode/artefacts/ess-org-demo-expanded.org run through my stuff produced this .html file https://ess-intro.github.io/presentation-org-mode/artefacts/ess-org-demo-results.html well, either this is serendipitously *exactly* what you were looking for. or, not. if the former, but you have problems, please ask. cheers, Greg
