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 &optional block-regexp)) (declare-function org-show-context "org" (&optional key)) (declare-function org-src-coderef-format "org-src" (&optional element)) -(declare-function org-src-coderef-regexp "org-src" (fmt &optional label)) +(declare-function org-src-coderef-regexp "org-src" (fmt &optional 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 &optional 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 l
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&title=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&url=file%3A%2F%2F%2Fetc%2Fmailcap&title=Triple%20Slash&body=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=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,~ "competing
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