Re: [PATCH] org.el (org-do-latex-and-related): Fix duplicate 'latex-and-related faces
Sébastien Miquel writes: > With the current org-do-latex-and-related function, fontification of > a region before a LaTeX fragment repeatedly adds the > 'org-latex-and-related face to the fragment. > > You can reproduce with an org buffer with the following content. [...] > The attached patch fixes this. Thanks for the clear reproduction steps and for the patch. > Subject: [PATCH] org.el (org-do-latex-and-related): Fix duplicate 'latex faces > > * lisp/org.el (org-do-latex-and-related): Do not add a > 'org-latex-and-related face beyond the fontification limit Please add a period after the changelog entry. https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html > --- > lisp/org.el | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lisp/org.el b/lisp/org.el > index 4db2dbe04..a0c703630 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -5502,6 +5502,8 @@ highlighting was done, nil otherwise." > (while (and (< (point) limit) > (re-search-forward org-latex-and-related-regexp nil t)) > (cond > + ((>= (match-beginning 0) limit) > + (throw 'found nil)) Any reason not to pass limit as re-search-forward's BOUND instead?
Re: emacs27 and let: Symbol’s value as variable is void: org-table-header-line-p
Santiago Mejia writes: > Hi All, > > I just did a clean install of Xubuntu 20.04. I also installed emacs27 > (from this repository:ppa:kelleyk/emacs) > > When I try to export any snippet from org-mode by calling > org-export-dispatch, my freshly installed emacs complains: > > "let: Symbol’s value as variable is void: org-table-header-line-p" Nothing looks off in Org's sources: org-table.el defines org-table-header-line-p, and that is used in one spot in org.el, which loads org-table.el. org-table-header-line-p was added recently (v9.4). So, it looks like in your setup there's a mismatch with a newer org.el loading an older org-table.el. https://orgmode.org/worg/org-faq.html#mixed-install
Re: Bug: Hole in `org-html-format-drawer-function' variable documentation [9.4.4 (9.4.4-21-g61336f-elpaplus @ /home/jmazon/.emacs.d/elpa/org-plus-contrib-20210208/)]
Jean-Baptiste Mazon writes: > The documentation for customizable variable > `org-html-format-drawer-function' currently reads as such: [...] > For example, the variable could be set to the following function > in order to mimic default behavior: > > The default value simply returns the value of CONTENTS. > > > There is obviously something missing between the two last paragraphs. Thanks for noticing. The example was dropped in adcebf38f (2013-11-14) but the leading "For example ..." was left behind. I've dropped that now too (478929ae6).
Re: [PATCH] Update example :publishing-function names in manual
Greg Minshall writes: > --- > doc/org-manual.org | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Thanks. Pushed (d15639944), adding a changelog entry.
Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command
Diego Zamboni writes: > I have seen differences in this behavior depending on the Emacs build. The > emacs-mac port (https://github.com/railwaycat/homebrew-emacsmacport) > seems to intercept certain Mac-specific keybindings such as C-space and > C-M-space and gives them their "Mac meaning", e.g. to bring up Spotlight or > the > symbol chooser. I could never figure out how to disable this behavior. > > Now I use emacs-plus (https://github.com/d12frosted/homebrew-emacs-plus) and > this no longer happens. > Normally, you need to disable those 'shortcuts' at the OS level i.e. under the keyboard shortucts item in macOS preferences panel. Problem is any macOS shortcut will grab the keys before Emacs sees them. Not sure how the emacs-plus version gets around this.
Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command
I have seen differences in this behavior depending on the Emacs build. The emacs-mac port (https://github.com/railwaycat/homebrew-emacsmacport) seems to intercept certain Mac-specific keybindings such as C-space and C-M-space and gives them their "Mac meaning", e.g. to bring up Spotlight or the symbol chooser. I could never figure out how to disable this behavior. Now I use emacs-plus (https://github.com/d12frosted/homebrew-emacs-plus) and this no longer happens. --Diego On Wed, Mar 24, 2021 at 10:34 PM Tim Cross wrote: > > Uwe Brauer writes: > > > Hi > > > > Does anybody know how to achieve the traditional binding of > > C-space to set-mark-command on MacOS (for emacsformacos)? > > > > Shift arrow down works, but will not work for a lot of features in org > > mode. > > > > Have you verified c-space is not being used by the macOS UI as a > shortcut for something like spotlight search? > > I now use spacemacs, but when I used my own setup, I don't recall having > to do anything special to get this behaviour apart from disabling macOS > shortcuts. > > -- > Tim Cross > >
Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command
Uwe Brauer writes: > Hi > > Does anybody know how to achieve the traditional binding of > C-space to set-mark-command on MacOS (for emacsformacos)? > > Shift arrow down works, but will not work for a lot of features in org > mode. > Have you verified c-space is not being used by the macOS UI as a shortcut for something like spotlight search? I now use spacemacs, but when I used my own setup, I don't recall having to do anything special to get this behaviour apart from disabling macOS shortcuts. -- Tim Cross
MacOS (emacsformacosx) c-spc, does not run set-mark-command
Hi Does anybody know how to achieve the traditional binding of C-space to set-mark-command on MacOS (for emacsformacos)? Shift arrow down works, but will not work for a lot of features in org mode. Thanks Uwe Brauer
Bug: 9.4.4 - ob-sql inserts page break (^L) in first cell of results table and truncates some column names
Using ob-sql for the first time. It works great and I no longer need to deal with the ugly output from the SQL command line. However, I noted that after submitting a query the first cell (first column name) of the results table includes a page break (^L). I use the purcell/page-break-lines package [1] and this resulted in the table layout being distorted. Once I disabled that mode the table was no longer distorted but I could see the ^L in the first cell. I also noted that some column names are truncated. Oddily, it doesn not appear to be based on length as some that are truncated are very short only three characters yet others which are much longer are not. Thanks for your time. [1]: https://github.com/purcell/page-break-lines
Re: wip-cite status question and feedback
Am 24. März 2021 um 09:22 Uhr -0400 schrieb Bruce D'Arcus: > Anyone know anything else? Not really. I would just like to say that I am eagerly watching this thread and am earnestly curious about what will happen to wip-cite. A proper cite system for org would be such a useful feature. -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu |For security: Passau, Germany | kont...@guelker.eu| () Avoid HTML e-mail European Union | PGP: see homepage | /\ http://asciiribbon.org
Re: Bug: Org manual, 16.15.2 The ‘capture’ protocol, possible error [9.4.4 (release_9.4.4 @ /home/admin/Programming/Software/emacs/lisp/org/)]
On 21/03/2021 14:04, Jean Louis wrote:
> emacsclient
org-protocol://capture?template=X?url=URL?title=TITLE?body=BODY
Certainly extra question marks should be replaced by "&".
emacsclient 'org-protocol://capture?template=X=URL=TITLE=BODY'
However I am in doubts if such form with double slash should be
recommended if org-protocol scheme is registered in desktop settings.
Subprotocol "capture" could be parsed as host name before passing to
handler. With old syntax and colon after subprotocol the problem was
more severe:
https://github.com/sprig/org-capture-extension/issues/16
Colon in some desktop environments may be dropped since port number
after it is not specified. It seems with new syntax a similar problem
could happen as well:
https://code.orgmode.org/bzg/org-mode/commit/928e67df
These complications are irrelevant if org-protocol URI is passed
directly to emacsclient bypassing desktop handlers.
Is any problem expected with single slash after the scheme?
org-protocol:/capture?template=X=URL=TITLE=BODY
Alternatively 3 slashes could be used in examples:
org-protocol:///capture?template=X=URL=TITLE=BODY
I hope, "capture" in both variants is parsed as part of path, so it is
safer. On the other hand I could not test on Mac and Windows. Even some
linux distribution could be some specific.
Such change could be committed in optimistic way if nobody will object,
not requiring to confirm that it works on every OS.
A have a couple more questions.
Is it intended decision that no leading slash is not allowed?
org-protocol:capture?template=T&...
In my opinion it is similar to mailto: scheme, so subprotocol should not
be considered as hostname.
Is there any reason that space can not be encoded as "+"? It is allowed
in query URL part and it prevents direct usage of modern API available
in JavaScript:
String(new URLSearchParams({template: "X", url: "https://orgmode.org/;,
title: "Org mode"}))
"template=X=https%3A%2F%2Forgmode.org%2F=Org+mode"
I guess that decoding of "+" just was not necessary in old syntax since
all parameters were encoded as path components. Could anything bad
happen due to update of decode function to allow "+"?
Re: org-adapt-indentation not honored prior to Org 9.4?
On 24/03/2021 21:08, TRS-80 wrote: On 2021-03-22 15:37, Mike Kupfer wrote: In 27.1, if I visit foo.org and type "* header RET", point is put in the first column. In 27.2, point is put in column 3. You are not alone, mate. We discussed this not too long ago in the following thread: There were at least one similar thread before and a discussion prior to the change. The following setting was never mentioned however: org-indent-mode-turns-off-org-adapt-indentation
Re: emacs27 and let: Symbol’s value as variable is void: org-table-header-line-p
On 2021-03-23 19:57, Santiago Mejia wrote: Hi All, I just did a clean install of Xubuntu 20.04. I also installed emacs27 (from this repository:ppa:kelleyk/emacs) When I try to export any snippet from org-mode by calling org-export-dispatch, my freshly installed emacs complains: "let: Symbol’s value as variable is void: org-table-header-line-p" Any help would be much appreciated Santiago Mejia I guess you should take it up with whoever this kelleyk person is? If you can reproduce the error from "normal" distro sources (or Emacs repo from source, etc.) then I suppose it is an issue for this list. Otherwise I don't think it is? I guess there must be some reason you installed it from that particular location? Cheers, TRS-80
Re: org-adapt-indentation not honored prior to Org 9.4?
On 2021-03-22 15:37, Mike Kupfer wrote: Over the weekend I upgraded my Emacs from 27.1 (Org 9.3) to 27.2-rc2 (Org 9.4). I noticed that Org mode behaves differently, even with "emacs -Q". In 27.1, if I visit foo.org and type "* header RET", point is put in the first column. In 27.2, point is put in column 3. AFAIK, I'm not using electric-indent-mode; at least it's not shown in the minor mode list in the modeline. org-adapt-indentation is t in both Emacs 27.1 and Emacs 27.2. Was there a bug fix that went into Org 9.4 such that org-adapt-indentation is now honored? Could the change in behavior be documented in the ORG-NEWS file in Emacs? I already asked about this on emacs-devel; Eli Z. sent me over here. thanks, mike You are not alone, mate. We discussed this not too long ago in the following thread: Turning off all indentation in 9.4.4 https://lists.gnu.org/archive/html/emacs-orgmode/2021-02/msg00045.html In particular, the answer you seek may be in this post: https://lists.gnu.org/archive/html/emacs-orgmode/2021-02/msg00285.html The TL; DR of which is to turn off ~electric-indent-local-mode~ in org-mode: #+begin_src emacs-lisp (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1))) #+end_src Of course, you could test live first in an Org buffer by pressing M-: and eval: #+begin_src emacs-lisp (electric-indent-local-mode -1) #+end_src If that does what you expect, then set up the above mode hook in your init file. If your expectations are slightly different to mine, hopefully there is something in that thread that might be helpful for you. Cheers, TRS-80
Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]
Updated version of the patch.
Ihor Radchenko writes:
> Nicolas Goaziou writes:
>> Actually, this is (was?) intentional. By forbidding parenthesis in
>> a plain URL, you allow one to type, e.g., (https://orgmode.org), which
>> is, IMO, a more frequent need than having to deal with parenthesis in
>> the URL.
>
> The patch correctly recognises situations like this.
> https://orgmode.org is recognised correctly without parenthesis.
>
> I guess this example may be another addition to the tests.
>
> Best,
> Ihor
>From 08efc990a578c925d42315c45e0b9b76536b92af Mon Sep 17 00:00:00 2001
From: Ihor Radchenko
Date: Wed, 24 Mar 2021 21:27:24 +0800
Subject: [PATCH] Improve org-link-plain-re
(org-link-plain-re): Update docstring. Now, the docstring explicitly
mentions that the regexp must contain groups for the link type and the
path.
* lisp/ol.el (org-link-make-regexps): Allow URLs with up to two levels
of nested brackets. Now, URLs like [1] can be matched. The new
regexp is based on [2].
* testing/lisp/test-ol.el: Add tests for the plain link regexp
[1] https://doi.org/10.1016/0160-791x(79)90023-x
[2] https://daringfireball.net/2010/07/improved_regex_for_matching_urls
---
lisp/ol.el | 41 +++
testing/lisp/test-ol.el | 110
2 files changed, 141 insertions(+), 10 deletions(-)
diff --git a/lisp/ol.el b/lisp/ol.el
index b8bd7d234..550c0cff6 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -519,7 +519,10 @@ links more efficient."
"Matches link with angular brackets, spaces are allowed.")
(defvar org-link-plain-re nil
- "Matches plain link, without spaces.")
+ "Matches plain link, without spaces.
+Group 1 must contain the link type (i.e. https).
+Group 2 must contain the link path (i.e. //example.com).
+Used by `org-element-link-parser'.")
(defvar org-link-bracket-re nil
"Matches a link in double brackets.")
@@ -807,15 +810,33 @@ This should be called after the variable `org-link-parameters' has changed."
(format "<%s:\\([^>\n]*\\(?:\n[ \t]*[^> \t\n][^>\n]*\\)*\\)>"
types-re)
org-link-plain-re
- (concat
- "\\<" types-re ":"
- "\\([^][ \t\n()<>]+\\(?:([[:word:]0-9_]+)\\|\\([^[:punct:] \t\n]\\|/\\)\\)\\)")
- ;; "\\([^]\t\n\r<>() ]+[^]\t\n\r<>,.;() ]\\)")
- org-link-bracket-re
- (rx (seq "[["
- ;; URI part: match group 1.
- (group
- (one-or-more
+ (let* ((non-space-bracket "[^][ \t\n()<>]")
+ (parenthesis
+ `(seq "("
+ (0+ (or (regex ,non-space-bracket)
+ (seq "("
+ (0+ (regex ,non-space-bracket))
+ ")")))
+ ")")))
+ ;; Heuristics for an URL link inspired by
+ ;; https://daringfireball.net/2010/07/improved_regex_for_matching_urls
+ (rx-to-string
+ `(seq word-start
+ ;; Link type: match group 1.
+ (regexp ,types-re)
+ ":"
+ ;; Link path: match group 2.
+ (group
+ (1+ (or (regex ,non-space-bracket)
+ ,parenthesis))
+ (or (regexp "[^[:punct:] \t\n]")
+ ?/
+ ,parenthesis)
+ org-link-bracket-re
+ (rx (seq "[["
+ ;; URI part: match group 1.
+ (group
+ (one-or-more
(or (not (any "[]\\"))
(and "\\" (zero-or-more "") (any "[]"))
(and (one-or-more "\\") (not (any "[]"))
diff --git a/testing/lisp/test-ol.el b/testing/lisp/test-ol.el
index 5b7dc513b..ddcc570b3 100644
--- a/testing/lisp/test-ol.el
+++ b/testing/lisp/test-ol.el
@@ -491,5 +491,115 @@
(org-previous-link))
(buffer-substring (point) (line-end-position))
+
+;;; Link regexps
+
+
+(defmacro test-ol-parse-link-in-text (text)
+ "Return list of :type and :path of link parsed in TEXT.
+\"\" string must be at the beginning of the link to be parsed."
+ (declare (indent 1))
+ `(org-test-with-temp-text ,text
+ (list (org-element-property :type (org-element-link-parser))
+ (org-element-property :path (org-element-link-parser)
+
+(ert-deftest test-ol/plain-link-re ()
+ "Test `org-link-plain-re'."
+ (should
+ (equal
+'("https" "//example.com")
+(test-ol-parse-link-in-text
+"(https://example.com)")))
+ (should
+ (equal
+'("https" "//example.com/qwe()")
+(test-ol-parse-link-in-text
+"(Some text https://example.com/qwe())")))
+ (should
+ (equal
+'("https" "//doi.org/10.1016/0160-791x(79)90023-x")
+(test-ol-parse-link-in-text
+"https://doi.org/10.1016/0160-791x(79)90023-x")))
+ (should
+ (equal
+'("file" "aa")
+(test-ol-parse-link-in-text
+"The file:aa link")))
+ (should
+ (equal
+'("file" "a(b)c")
+(test-ol-parse-link-in-text
+"The file:a(b)c link")))
+ (should
+ (equal
+'("file" "a()")
+(test-ol-parse-link-in-text
+"The file:a() link")))
+ (should
+ (equal
+'("file" "aa((a))")
+(test-ol-parse-link-in-text
+"The file:aa((a))
Re: [PATCH] Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]
Maxim Nikulin writes: > Example for #+STARTUP: overview: > > org-activate-links 560 0.028971085 5.173...e-05 > > For content number of calls is 410, without special settings (all) 120, > let me remind that it is for 10 find-file invocations. Another example > > org-activate-links 410 0.1384633219 0.0003377154 I repeated your benchmark on my largest working file (~14k links): ;; with patch ;; org-activate-links 400 0.0259791009 6.494...e-05 ;; org-activate-links 400 0.0114822140 2.870...e-05 ;; org-activate-links 400 0.0255080609 6.377...e-05 ;; without patch ;; org-activate-links 400 0.0297167870 7.429...e-05 ;; org-activate-links 400 0.0149334709 3.733...e-05 ;; org-activate-links 400 0.0105385180 2.634...e-05 There is not much difference indeed. I guess, there was something about my config and external packages. > I see such variations in both cases with and without the patch, but > these numbers are negligible in my opinion. Your benchmark is measuring is jit-lock - there will be no reliable result as jit-lock is timer-based. I did more reliable version as well: (progn (require 'elp) (require 'org-element) (setq elp-function-list (list #'org-activate-links)) (elp-instrument-list nil) (dolist (i (number-sequence 1 10)) (message "iter %d" i) (find-file "~/Org/notes.org") (font-lock-ensure) ;; Force fontification in all the buffer (sit-for 1) (kill-buffer "notes.org") (sit-for 1)) (elp-results)) Results are not different though (time-per-single-call): ;; with patch + font-lock-ensure ;; org-activate-links 163290 9.720667509 5.953...e-05 ;; org-activate-links 163290 9.8090518640 6.007...e-05 ;; without patch + font-lock-ensure ;; org-activate-links 163290 9.9175657860 6.073...e-05 ;; org-activate-links 163290 10.073281878 6.168...e-05 This latter case was what was happening with my config. Some package was causing full buffer fontification. > In my opinion, combining changes related to white spaces and meaningful > modifications makes commits less clear, especially when reading email. > However the following recommendation has certainly more weight: > > https://orgmode.org/list/87zh2hosex@bzg.fr/ From: Bastien >> Also, the convention in Emacs is to avoid whitespaces-only commits, >> you need to fix whitespaces within other non-whitespaces changes in >> a commit. Actually, I feel confused now. I remember that message from Bastien, but now I cannot recall what is considered "fix whitespaces". Do we use tab-convention or space-convention? I think I will better clear the whitespace staff in the patch before I understand the whitespace policy more clearly. At least, the patch will be more readable. Best, Ihor
Re: wip-cite status question and feedback
I know Bastien and Nicolas are less active on the list these days, but does anyone know what the plan is with the wip-cite branch? My understanding is the syntax work that Nicolas did was done enough that it was ready for testing, and that the remaining questions were really what more needed to be done before merging. So lingering questions included possibility of incorporating citeproc-org directly, so rich formatting was available out of box, and if not that, what was minimum functionality needed for release. At least that's what I recall; it's been awhile. Anyone know anything else? On Wed, Jun 3, 2020 at 10:53 AM Bruce D'Arcus wrote: > On Wed, Jun 3, 2020 at 10:40 AM Bastien wrote: > > > Hi all, > > > > just a quick word in this thread to say that we are in feature freeze > > for Org core features (ie. everything in org*.el files, + ob.el/ol.el). > > > > So let's take the time to discuss this in details for 9.5 (or later, > > when it's ready.) > > What about the question of including citeproc.el and citeproc.org in org > proper? > > That seems the most immediate practical question, as it would impact what > code > would be (further) developed, and therefore what would need to be tested, > etc. > > Andras has expressed openness to that, but also questions. > > Bruce >
Re: Exam LaTeX class
Hi Xianwen,
I think the easiest way to conditionally include text in the preamble of
the document would be by including a file which can be empty sometimes, and
contain the appropriate text when needed. For example, you could have
something like this in your Org file:
#+include: ./printanswers.org
#+TITLE: Test
...
Then the following function will automatically export the file twice, one
with the \printanswers command inserted then rename the resulting file, and
export again without:
(defun org-latex-export-exams ()
(interactive)
(write-region "#+latex_header: \\printanswers" nil "printanswers.org")
(org-latex-export-to-pdf)
(rename-file (org-export-output-file-name ".pdf")
(org-export-output-file-name "-with_answers.pdf"))
(write-region "" nil "printanswers.org")
(org-latex-export-to-pdf))
You can then run M-x org-latex-export-exams to generate both files.
Hope this helps,
--Diego
On Wed, Mar 24, 2021 at 11:21 AM Xianwen Chen (陈贤文)
wrote:
> Dear Christine (and CC list),
>
> Thank you!
>
>
>
> On 2021-03-19 10:13, Christine Köhn wrote:
>
> Here is one way to do the latex part. You could pass a jobname to latex.
>
> I have this
>
> \IfEndWith*{\jobname}{withsolution}{%
> \usepackage{todonotes}
> \printanswers
> }{\usepackage[disable]{todonotes}}
>
> in a myexam.sty file to switch between modes (with or without solutions
> and todo notes) and use it in the latex file with
>
> \usepackage{myexam}
>
> You could add your own latex class to org-latex-classes and add this
> line there.
>
> The jobname has to be passed to latex with something like -jobname
> withsolution if you want it to be with solutions. I use a Makefile for
> this purpose which calls latexmk
>
> latexmk -pdf -pdflatex="pdflatex --interaction=errorstopmode" -use-make
>
> and adds -jobname=$(basename $@) if asked to create a pdf ending with
> withsolution.pdf. I can send you the Makefile if you're interested.
>
>
> That's very interesting way to solve the problem using LaTeX. Thank you
> for sharing this. At the moment I'm leaning more towards solving it using
> emacs lisp.
>
>
> To use the jobname from within orgmode, you'll have to change
> org-latex-pdf-process to use the jobname if needed. I think one way to
> achieve this is to add a new export backend which is derived from latex
> (see org-export-define-derived-backend) and which sets
> org-latex-pdf-process accordingly (and resets it afterwards).
>
>
> Thank you again. I'm thinking of a function like following. I'm using
> comments to express the programming detail that I don't know how to do yet.
>
> (deffun org-latex-export-to-pdf-exam ()
> (interactive)
> # do some emacs lisp to add \printanswers to the end of org document
> header, i.e., adding a line of #+LATEX_HEADER: \printanswers
> (org-latex-export-to-pdf)
> # do some emacs lips to move the foo.pdf to foo-with_solutions.pdf
> # do some emacs lisp to add \noprintanswers to the end of org document
> header, i.e., removing the line of #+LATEX_HEADER: \printanswers and adding
> a line of #+LATEX_HEADER: \noprintanswers
> (org-latex-export-to-pdf)
> # remove the line of #+LATEX_HEADER: \noprintanswers
> )
>
> I don't know enough emacs lisp to fill in the details here for now.
> However, I think this would be a way to do it within emacs. So each time I
> call org-latex-export-to-pdf-exam, it would export two PDF files, one with
> solutions and one without.
>
> What do you think?
>
> Yours sincerely,
> Xianwen
>
Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]
Nicolas Goaziou writes: > Actually, this is (was?) intentional. By forbidding parenthesis in > a plain URL, you allow one to type, e.g., (https://orgmode.org), which > is, IMO, a more frequent need than having to deal with parenthesis in > the URL. The patch correctly recognises situations like this. https://orgmode.org is recognised correctly without parenthesis. I guess this example may be another addition to the tests. Best, Ihor
Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]
Hello, Ihor Radchenko writes: > I have a https link like "https://doi.org/10.1016/0160-791x(79)90023-x". > If I put this link into an org file (using emacs -Q or Org mode master), > only "https://doi.org/10.1016/0160-791x(79)" part of the link is treated > as a link. I guess, it should not happen. Actually, this is (was?) intentional. By forbidding parenthesis in a plain URL, you allow one to type, e.g., (https://orgmode.org), which is, IMO, a more frequent need than having to deal with parenthesis in the URL. Regards, -- Nicolas Goaziou
Re: [PATCH] Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]
On 19/03/2021 22:07, Ihor Radchenko wrote: Maxim Nikulin writes: I could not guess how to benchmark font-lock. I have tried to open file (to get everything loaded), kill the buffer, I usually just use profiler-start/open buffer/profiler-report. However, there is also https://github.com/Lindydancer/font-lock-profiler for more fine-grained benchmark. Also, you may instrument org-activate-links with elp.el (built-in). I suspect I may not notice performance penalty due to some specific usage pattern (e.g. I rarely use links in heading titles) or due to absence of some customization. I have converted bracketed links to plain ones, so I have more than 4000 links in the test file. I expect that regexp affects loading of a file. As earlier, org-activate-links entry in profiler-report have less than 1%. I have tried elp. My measurements are not accurate due to I did not fix CPU regime to performance. I have seen times varied quite widely (several times) but often the numbers are the same with and without your patch. I am puzzled a bit by number of calls. (progn (require 'elp) (setq elp-function-list (list #'org-activate-links)) (elp-instrument-list nil) (dolist (i (number-sequence 1 10)) (message "iter %d" i) (find-file "plain.org") (sit-for 3) (kill-buffer "plain.org") (sit-for 1)) (elp-results)) Example for #+STARTUP: overview: org-activate-links 560 0.028971085 5.173...e-05 For content number of calls is 410, without special settings (all) 120, let me remind that it is for 10 find-file invocations. Another example org-activate-links 410 0.1384633219 0.0003377154 I see such variations in both cases with and without the patch, but these numbers are negligible in my opinion. I decided to stop experiments since I could not reproduce decrease in performance. Thank you for the font-lock-profiler link however. So I have no reason to be against more complicated regexp. Are changes in white spaces below actually modified lines in your patch intended? They are generated by aggressive-indent. Since org files mix indentation styles I keep getting those whitespace changes in my patches. Forgot to remove this time. Should I? In my opinion, combining changes related to white spaces and meaningful modifications makes commits less clear, especially when reading email. However the following recommendation has certainly more weight: https://orgmode.org/list/87zh2hosex@bzg.fr/ From: Bastien Also, the convention in Emacs is to avoid whitespaces-only commits, you need to fix whitespaces within other non-whitespaces changes in a commit.
Re: Exam LaTeX class
Dear Christine (and CC list),
Thank you!
On 2021-03-19 10:13, Christine Köhn wrote:
Here is one way to do the latex part. You could pass a jobname to
latex.
I have this
\IfEndWith*{\jobname}{withsolution}{%
\usepackage{todonotes}
\printanswers
}{\usepackage[disable]{todonotes}}
in a myexam.sty file to switch between modes (with or without solutions
and todo notes) and use it in the latex file with
\usepackage{myexam}
You could add your own latex class to org-latex-classes and add this
line there.
The jobname has to be passed to latex with something like -jobname
withsolution if you want it to be with solutions. I use a Makefile for
this purpose which calls latexmk
latexmk -pdf -pdflatex="pdflatex --interaction=errorstopmode" -use-make
and adds -jobname=$(basename $@) if asked to create a pdf ending with
withsolution.pdf. I can send you the Makefile if you're interested.
That's very interesting way to solve the problem using LaTeX. Thank you
for sharing this. At the moment I'm leaning more towards solving it
using emacs lisp.
To use the jobname from within orgmode, you'll have to change
org-latex-pdf-process to use the jobname if needed. I think one way to
achieve this is to add a new export backend which is derived from latex
(see org-export-define-derived-backend) and which sets
org-latex-pdf-process accordingly (and resets it afterwards).
Thank you again. I'm thinking of a function like following. I'm using
comments to express the programming detail that I don't know how to do
yet.
(deffun org-latex-export-to-pdf-exam ()
(interactive)
# do some emacs lisp to add \printanswers to the end of org document
header, i.e., adding a line of #+LATEX_HEADER: \printanswers
(org-latex-export-to-pdf)
# do some emacs lips to move the foo.pdf to foo-with_solutions.pdf
# do some emacs lisp to add \noprintanswers to the end of org document
header, i.e., removing the line of #+LATEX_HEADER: \printanswers and
adding a line of #+LATEX_HEADER: \noprintanswers
(org-latex-export-to-pdf)
# remove the line of #+LATEX_HEADER: \noprintanswers
)
I don't know enough emacs lisp to fill in the details here for now.
However, I think this would be a way to do it within emacs. So each time
I call org-latex-export-to-pdf-exam, it would export two PDF files, one
with solutions and one without.
What do you think?
Yours sincerely,
Xianwen
org-adapt-indentation not honored prior to Org 9.4?
Over the weekend I upgraded my Emacs from 27.1 (Org 9.3) to 27.2-rc2 (Org 9.4). I noticed that Org mode behaves differently, even with "emacs -Q". In 27.1, if I visit foo.org and type "* header RET", point is put in the first column. In 27.2, point is put in column 3. AFAIK, I'm not using electric-indent-mode; at least it's not shown in the minor mode list in the modeline. org-adapt-indentation is t in both Emacs 27.1 and Emacs 27.2. Was there a bug fix that went into Org 9.4 such that org-adapt-indentation is now honored? Could the change in behavior be documented in the ORG-NEWS file in Emacs? I already asked about this on emacs-devel; Eli Z. sent me over here. thanks, mike
emacs27 and let: Symbol’s value as variable is void: org-table-header-line-p
Hi All, I just did a clean install of Xubuntu 20.04. I also installed emacs27 (from this repository:ppa:kelleyk/emacs) When I try to export any snippet from org-mode by calling org-export-dispatch, my freshly installed emacs complains: "let: Symbol’s value as variable is void: org-table-header-line-p" Any help would be much appreciated Santiago Mejia
Bug: Hole in `org-html-format-drawer-function' variable documentation [9.4.4 (9.4.4-21-g61336f-elpaplus @ /home/jmazon/.emacs.d/elpa/org-plus-contrib-20210208/)]
Hello, The documentation for customizable variable `org-html-format-drawer-function' currently reads as such: Function called to format a drawer in HTML code. The function must accept two parameters: NAME the drawer name, like "LOGBOOK" CONTENTS the contents of the drawer. The function should return the string to be exported. For example, the variable could be set to the following function in order to mimic default behavior: The default value simply returns the value of CONTENTS. There is obviously something missing between the two last paragraphs. Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2020-10-08 Package: Org mode version 9.4.4 (9.4.4-21-g61336f-elpaplus @ /home/jmazon/.emacs.d/elpa/org-plus-contrib-20210208/)
Re: [PATCH] Apply emacs manual css to org pages
Hi, Kyle Meyer writes: >> # How to create the HTML file >> -TEXI2HTML = makeinfo --html --number-sections >> +TEXI2HTML = makeinfo --html --number-sections --css-ref >> "https://www.gnu.org/software/emacs/manual.css; I made this change and tested it online, the HTML Org manual now looks like the Emacs manual: https://orgmode.org/manual/ Thanks for the suggestion! > Hmm, while I barely ever look at the online manual, I thought I recalled > it having custom styling, and indeed it looks like that was the case: > > https://web.archive.org/web/20171222052224/https://orgmode.org/org.html > > At least based on the Wayback Machine rendering, it seems like the > custom CSS was lost shortly after the snapshot above. > > If you look in the repo for org-manual.css, you can see there is still > handling for it. Yes, I remember I tried to enhance the css for the manual, and I don't remember why this change was reverted. > So, if we're going to go in the direction of this patch, there should be > some mention of the previous approach, why it was dropped, and the > handling for org-manual.css should probably be removed. Perhaps Bastien > can help fill in some details here. In any cas, the Emacs manual css is better than my attempt and using it for Org makes sense IMO. Best, -- Bastien
Re: Invalid function: org-preserve-local-variables
"Loris Bennett" writes: > Kyle Meyer writes: > >> Loris Bennett writes: >> >>> Hi, >>> >>> I'm running >>> >>> Org mode version 9.4.4 (9.4.4-25-g3a522a-elpaplus @ >>> /home/loris/.emacs.d/elpa/org-plus-contrib-20210222/) >>> >>> and today I encountered the following error when refiling >>> >>> org-refile: Invalid function: org-preserve-local-variables >>> >>> Despite the error, the refiling itself did however work. >>> >>> I am fairly sure that I have refiled without seeing this error message >>> since I last updated Org, thus I am somewhat surprised by it. >> >> org-preserve-local-variables is a macro defined in org-macs.el. That >> file is loaded by org.el, which is loaded by org-refile.el. So, I think >> everything looks fine there. >> >> My guess---especially if you're running Emacs 26 or lower, which ships >> with an Org that didn't yet have org-preserve-local-variables---is that >> you have a mixed installation. list-load-path-shadows might reveal the >> problem. >> >> https://orgmode.org/worg/org-faq.html#mixed-install > > Thanks for the information and the suggestions. > > I am running 26.1. The Org version is > > Org mode version 9.4.4 (9.4.4-25-g3a522a-elpaplus @ > /home/loris/.emacs.d/elpa/org-plus-contrib-20210222/) > > list-load-path-shadows lots of lines like > > /home/loris/.emacs.d/elpa/org-plus-contrib-20210222/ox-md hides > /home/loris/.emacs.d/elpa/org-20210222/ox-md > > where elpa/org-plus-contrib hides elpa/org, and lots of lines like > > /home/loris/.emacs.d/elpa/org-plus-contrib-20210222/ox-md hides > /usr/share/emacs/26.1/lisp/org/ox-md > > where elpa/org-plus-contrib hides Org from the OS. > > Having both org and org-plus-contrib installed from ELPA has always > bothered me a bit, but I seem to remember that certainly at some point > several years ago, there was an issue (to do with dependencies? or > use-package?) which meant I had some problems with org-plus-contrib on > its own. Maybe that was wrong back then and maybe is still wrong now. > > However, duckduckgoing a bit I find the following issue > > https://github.com/jwiegley/use-package/issues/597 > > from a few years back. Maybe that's what I was hitting. I'll change > make my set-up to just use org-plus-contrib and see whether I can > reproduce the org-preserve-local-variables error. I have removed 'org' and now list-load-path-shadows just shows the Elpa Org hiding the version installed with Emacs in the OS (Debian 10) plus the following /usr/share/emacs/site-lisp/rst hides /usr/share/emacs/26.1/lisp/textmodes/rst but that doesn't look like anything to worry about. However, I am still getting org-refile: Invalid function: org-preserve-local-variables when I refile, although the refiling works. Any ideas where else I could look? Cheers, Loris -- This signature is currently under construction.
Re: straight.el and org info pages?
Gustav, thanks. installing org went very well. and, i'm pleased with straight.el. (package.el didn't seem to install the info pages, either.) cheers, Greg
Re: straight.el and org info pages?
Richard, thanks. for ess, i see your results. for org, or org-plus-contrib, i see info pages from /usr/share/info. a mystery. (which shall be, for the moment, let be.) cheers, Greg
