Re: [PATCH] ol-man.el (org-man-open): Set window point not buffer point
Hi Ihor, Here is an updated patch. We can't use accept-process-output because it doesn't seem to block in the way we need, or it blocks exactly long enough for the process to finish but then continues immediately to search instead of allowing the function that fills the buffer to complete. Instead I use sleep-for a shorter time and process-live-p which gives better results. I think I got the commit message formats right this time. Best! Tom From 2db2ce6d83b27fcf6366183cbd8b5fa79fcbc4a7 Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Thu, 28 Jul 2022 23:33:22 -0700 Subject: [PATCH] ol-man: Set window point not buffer point and wait before search * lisp/ol-man.el (org-man-open): Set window point not buffer point When passed man:path::SEARCH org-man-open tries to use search-forward to jump to the location of e.g. a heading. Prior to this fix it only used search-forward, which will not change the point of the cursor in the window, meaning that even if there is a match it will not appear. Uses process-live-p and sleep-for to wait until the manpage finishes rendering before searching the buffer so that there will be something to find. --- lisp/ol-man.el | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/lisp/ol-man.el b/lisp/ol-man.el index aa22964c5..8633fe5cb 100644 --- a/lisp/ol-man.el +++ b/lisp/ol-man.el @@ -43,12 +43,22 @@ If PATH contains extra ::STRING which will use `occur' to search matched strings in man buffer." (string-match "\\(.*?\\)\\(?:::\\(.*\\)\\)?$" path) (let* ((command (match-string 1 path)) - (search (match-string 2 path))) -(funcall org-man-command command) + (search (match-string 2 path)) + (buffer (funcall org-man-command command))) (when search - (with-current-buffer (concat "*Man " command "*") - (goto-char (point-min)) - (search-forward search) + (with-current-buffer buffer +(goto-char (point-min)) +(unless (search-forward search nil t) + (let ((process (get-buffer-process buffer))) +(while (process-live-p process) + (sleep-for 0.01))) + (goto-char (point-min)) + (search-forward search)) +(previous-line) +(let ((point (point))) + (let ((window (get-buffer-window buffer))) +(set-window-point window point) +(set-window-start window point))) (defun org-man-store-link () "Store a link to a README file." -- 2.35.1
Re: [PATCH] Delete some Emacs 24 compat code
Hi Tim, thanks for reminding me the context. Tim Cross writes: > Therefore, I think the position should be that once an emacs version is > no longer one of the supported versions (current stable Emacs release > plus two previous major versions), there is no guarantee we will inform > the list when compatibility is lost. Yes, fully agreed. If my previous message was unclear: it is *good* to inform the list of any compatibility issue (with any Emacsen), but we cannot promise we will warn the list for every breakage as we don't test Org with Emacs <=25. > If you are running an unsupported > versions, either you should avoid updates or be prepared for breakage > without warning. When we do know a commit has broken compatibility, that > information will be relayed to the list, but we cannot guarantee we can > provide such information at the time the change is committed. Running an > unsupported versions is at your own risk. Yes, thanks for articulating this very clearly. -- Bastien
Re: [PATCH] Delete some Emacs 24 compat code
Hi Bastien, all you wrote is fine IMO. However, I think Ihor's point was mainly in response to the request that we notify the list when compatibility is going to be lost and that when it comes to versions less than the currently maintained versions, this isn't really possible. To put it in more concrete terms, based on your example below, we don't know exactly when org loses compatibility with Emacs 25.x because we are no longer testing against that version (we are only testing against 28, 27 and 26). We don't know the precise commit which breaks compatibility with 25 as we are no longer testing against that version, so cannot notify the list when compatibility is lost. Obviously, when we do know, we can notify the list. Sometimes, it is clear that a patch or commit will break compatibility with an old version. However, we cannot provide any guarantee we will always notify the list when that compatibility is lost. Often, this only becomes known when someone posts to the list to say it no longer works. Therefore, I think the position should be that once an emacs version is no longer one of the supported versions (current stable Emacs release plus two previous major versions), there is no guarantee we will inform the list when compatibility is lost. If you are running an unsupported versions, either you should avoid updates or be prepared for breakage without warning. When we do know a commit has broken compatibility, that information will be relayed to the list, but we cannot guarantee we can provide such information at the time the change is committed. Running an unsupported versions is at your own risk. Bastien writes: > Hi Ihor, > > Ihor Radchenko writes: > >> Could you please elaborate on how exactly we can determine if a >> commit changes the compatibility status? > > Today, we are interested in knowing whether Org is compatible with > Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1. > > Ideally, this means maintainers run the test suite against these > versions in order to check that bugfixes and/or new features don't > introduce incompatible code. > > We don't need to run tests against Emacs <=25: if Org runs okay on > Emacs <=25, it's good. If not, users can report it: maintainers are > not bound to fix such incompatibilities and we don't need to know or > to announce them beforehand since we don't make a promise that Org > will run with Emacs <=25. > > On https://orgmode.org/worg/org-maintenance.html I added this: > > It does not mean that Org will not be usable, at least partially, > with older Emacsen: but maintainers are not bound to fix bugs > reported on them. > > WDYT?
Re: :session for Julia in org babel?
> OK, now I get this: > ess-eval-buffer: Wrong type argument: symbolp, [...] > (ess-error-regexp-alist . ess-julia-error-regexp-alist) ...) Yeah, pretty much what I get as well. Thanks for confirming that it's not my configuration that causes this! -- : Eric S Fraga, with org release_9.5.4-720-g4db67d in Emacs 29.0.50
Re: [RFC PATCH] oc-csl: Add support for title, locators and bibentry styles
Dear All,
On Sun, 7 Aug 2022 at 11:45, Ihor Radchenko wrote:
> LGTM in general, but please add a proper commit message.
[...]
> Also, it would be useful to explain a bit what bibentry stands for.
thanks, I've attached a new patch implementing these recommendations.
best wishes,
András
From 361e78eca47d2a6472064ae37d43e9c1e131faa3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?=
Date: Tue, 2 Aug 2022 11:32:17 +0200
Subject: [PATCH] oc-csl: Add support for title, locators and bibentry citation
styles
* lisp/oc-csl.el: Register the newly added citation styles "title",
"locators and "bibentry" as supported by the "csl" export processor.
(org-cite-csl--create-structure-params): Add support for the creation
of citation structures with the new citation styles.
---
lisp/oc-csl.el | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 0b2fe5c41..7fcc1f1f2 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -61,11 +61,16 @@
;; - noauthor (na), including bare (b), caps (c) and bare-caps (bc) variants,
;; - nocite (n),
;; - year (y), including a bare (b) variant,
-;; - text (t). including caps (c), full (f), and caps-full (cf) variants,
+;; - text (t), including caps (c), full (f), and caps-full (cf) variants,
+;; - title (ti), including a bare (b) variant,
+;; - locators (l), including a bare (b) variant,
+;; - bibentry (b), including a bare (b) variant,
;; - default style, including bare (b), caps (c) and bare-caps (bc) variants.
;;
-;; Using "*" as a key in a nocite citation includes all available items in
-;; the printed bibliography.
+;; Using "*" as a key in a nocite citation includes all available
+;; items in the printed bibliography. The "bibentry" citation style,
+;; similarly to biblatex's \fullcite, creates a citation which is
+;; similar to the bibliography entry.
;; CSL styles recognize "locator" in citation references' suffix. For example,
;; in the citation
@@ -349,6 +354,21 @@ a property list."
(pcase variant
((or "bare" "b") '(:mode year-only :suppress-affixes t))
(_ '(:mode year-only
+ ;; "bibentry" style
+ (`(,(or "bibentry" "b") . ,variant)
+ (pcase variant
+ ((or "bare" "b") '(:mode bib-entry :suppress-affixes t))
+ (_ '(:mode bib-entry
+ ;; "locators" style
+ (`(,(or "locators" "l") . ,variant)
+ (pcase variant
+ ((or "bare" "b") '(:mode locator-only :suppress-affixes t))
+ (_ '(:mode locator-only
+ ;; "title" style
+ (`(,(or "title" "ti") . ,variant)
+ (pcase variant
+ ((or "bare" "b") '(:mode title-only :suppress-affixes t))
+ (_ '(:mode title-only
;; "text" style.
(`(,(or "text" "t") . ,variant)
(pcase variant
@@ -730,7 +750,10 @@ property list."
(("year" "y") ("bare" "b"))
(("text" "t") ("caps" "c") ("full" "f") ("caps-full" "cf"))
(("nil") ("bare" "b") ("caps" "c") ("bare-caps" "bc"))
-(("nocite" "n"
+(("nocite" "n"))
+(("title" "ti") ("bare" "b"))
+(("bibentry" "b") ("bare" "b"))
+(("locators" "l") ("bare" "b"
(provide 'oc-csl)
;;; oc-csl.el ends here
--
2.25.1
Re: :session for Julia in org babel?
OK, now I get this: ess-eval-buffer: Wrong type argument: symbolp, ((inferior-ess-primary-prompt . "\\w*> ") (inferior-ess-secondary-prompt) (inferior-ess-prompt . "\\w*> ") (ess-local-customize-alist . ess-julia-customize-alist) (inferior-ess-program . inferior-julia-program) (ess-load-command . "include(expanduser(\"%s\")) ") (ess-funargs-command . "ESS.fun_args(\"%s\") ") (ess-dump-error-re . "in \\w* at \\(.*\\):[0-9]+") (ess-error-regexp . "\\(^\\s-*at\\s-*\\(?3:.*\\):\\(?2:[0-9]+\\)\\)") (ess-error-regexp-alist . ess-julia-error-regexp-alist) ...) -- Bill On Mon, Aug 8, 2022 at 12:28 PM Fraga, Eric wrote: > Hi Bill, > > thank you for the quick response. > > On Monday, 8 Aug 2022 at 11:49, Bill Burdick wrote: > > Julia works in org without sessions for me but with sessions I get this > error: > > > > org-babel-execute:julia: Cannot open load file: No such file or > directory, ess > > Yeah, it does require the ess package to be installed. I do have that > so I get further than you do, I guess. But then get errors related to > ess settings. I'll see whether anybody else has some experience before > I start digging into the code! > > Thanks again, > eric > > -- > : Eric S Fraga, with org release_9.5.4-720-g4db67d in Emacs 29.0.50
Re: :session for Julia in org babel?
Hi Bill, thank you for the quick response. On Monday, 8 Aug 2022 at 11:49, Bill Burdick wrote: > Julia works in org without sessions for me but with sessions I get this error: > > org-babel-execute:julia: Cannot open load file: No such file or directory, ess Yeah, it does require the ess package to be installed. I do have that so I get further than you do, I guess. But then get errors related to ess settings. I'll see whether anybody else has some experience before I start digging into the code! Thanks again, eric -- : Eric S Fraga, with org release_9.5.4-720-g4db67d in Emacs 29.0.50
Integrating org-roam with logseq (works on phones)
Hi folks, In case you care about this sort of thing and you didn't see my reddit post, I read an article at https://coredumped.dev/ about integrating org-roam with logseq and wrote some code to help with that (which I shared) so now I'm able to access my org-roam files on my phone (using syncthing to keep the files straight). More details here: https://www.reddit.com/r/orgmode/comments/wgemu9/converter_for_logseq_files_stored_in_orgroam -- Bill
Re: :session for Julia in org babel?
Julia works in org without sessions for me but with sessions I get this error: org-babel-execute:julia: Cannot open load file: No such file or directory, ess -- Bill On Mon, Aug 8, 2022 at 11:22 AM Fraga, Eric wrote: > Hello all, > > has anybody tried using sessions for Julia in org? > > I'm asking because I've never used sessions (for any language) before > and it's failing with obscure ess- related errors so I just want to > confirm that Julia should (or should not) work with sessions before I > spend some time debugging. > > Thank you, > eric > > -- > : Eric S Fraga, with org release_9.5.4-719-g00adad in Emacs 29.0.50 >
Re: [PATCH] Delete some Emacs 24 compat code
Hi Ihor, Ihor Radchenko writes: > Could you please elaborate on how exactly we can determine if a > commit changes the compatibility status? Today, we are interested in knowing whether Org is compatible with Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1. Ideally, this means maintainers run the test suite against these versions in order to check that bugfixes and/or new features don't introduce incompatible code. We don't need to run tests against Emacs <=25: if Org runs okay on Emacs <=25, it's good. If not, users can report it: maintainers are not bound to fix such incompatibilities and we don't need to know or to announce them beforehand since we don't make a promise that Org will run with Emacs <=25. On https://orgmode.org/worg/org-maintenance.html I added this: It does not mean that Org will not be usable, at least partially, with older Emacsen: but maintainers are not bound to fix bugs reported on them. WDYT? -- Bastien
:session for Julia in org babel?
Hello all, has anybody tried using sessions for Julia in org? I'm asking because I've never used sessions (for any language) before and it's failing with obscure ess- related errors so I just want to confirm that Julia should (or should not) work with sessions before I spend some time debugging. Thank you, eric -- : Eric S Fraga, with org release_9.5.4-719-g00adad in Emacs 29.0.50
[PATCH] Documentation and NEWS for ` org-latex-language-alist'
Hi,
I am attaching a patch with the documentation of the new variable in the
Manual and the updated NEWS.
Best regards,
Juan Manuel
--
--
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
>From 2ec740e4b2f691f619878a7b86e4874fa05d3a82 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Mon, 8 Aug 2022 16:30:01 +0200
Subject: [PATCH] doc/org-manual.org: documentation for
`org-latex-language-alist'
* etc/ORG-NEWS: update the news with the new variable.
---
doc/org-manual.org | 57 --
etc/ORG-NEWS | 13 +++
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 466718e6e..5d0283bf2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13370,19 +13370,72 @@ general options (see [[*Export Settings]]).
- =LANGUAGE= ::
#+cindex: @samp{LANGUAGE}, keyword
#+vindex: org-latex-packages-alist
+ #+vindex: org-latex-language-alist
+ #+vindex: org-export-default-language
+
+ The list of languages supported by Org is stored in the variable
+ ~org-latex-language-alist~.
+
In order to be effective, the =babel= or =polyglossia=
packages---according to the LaTeX compiler used---must be loaded
with the appropriate language as argument. This can be accomplished
by modifying the ~org-latex-packages-alist~ variable, e.g., with the
- following snippet:
+ following snippet (note that =polyglossia= does not work with
+ pdfLaTeX):
#+begin_src emacs-lisp
(add-to-list 'org-latex-packages-alist
- '("AUTO" "babel" t ("pdflatex")))
+ '("AUTO" "babel" t ("pdflatex" "xelatex" "lualatex")))
(add-to-list 'org-latex-packages-alist
'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
#+end_src
+ LaTeX packages =babel= or =polyglossia= can also be loaded in a
+ document. The "AUTO" string will be replaced in both cases by the
+ appropiate value for the =LANGUAGE= keyword, if present in the
+ document, or by the value of ~org-export-default-language~. Let's
+ see some examples in one or another case.
+
+ =Babel= accepts the classic syntax and (in addition) the new syntax
+ with the =\babelprovide= command to load the languages using the new
+ =INI= files procedure. Keep in mind that there are a number of
+ languages that are only served in babel using =INI= files, so they
+ cannot be declared using the classic syntax, but only using the
+ =\babelprovide= command (see
+ http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf).
+ Valid usage examples could be:
+
+ #+begin_example
+ ,#+LATEX_HEADER: \usepackage[french,italian,AUTO]{babel}
+ #+end_example
+
+ where "AUTO" is the main language. But it can also be loaded using
+ the =\babelprovide= command:
+
+ #+begin_example
+ ,#+LATEX_HEADER: \usepackage[french,italian]{babel}
+ ,#+LATEX_HEADER: \babelprovide[import, main]{AUTO}
+ #+end_example
+
+ =Polyglossia=, for this procedure to be effective, must be loaded
+ using the same =babel= classic syntax (but note that /this is not/
+ the actual polyglossia syntax). For example, suppose a document
+ declares Polytonic Greek as the primary language, and French as the
+ secondary language. In this case, it would be expressed as:
+
+ #+begin_example
+ ,#+LANGUAGE: el-polyton
+ ,#+LATEX_HEADER: \usepackage[french,AUTO]{polyglossia}
+ #+end_example
+
+ This would produce in LaTeX (with the actual =polyglossia= syntax):
+
+ #+begin_example
+ \usepackage{polyglossia}
+ \setmainlanguage[variant=polytonic]{greek}
+ \setotherlanguage{french}
+ #+end_example
+
- =LATEX_CLASS= ::
#+cindex: @samp{LATEX_CLASS}, keyword
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 00fe101dc..fc9ac688a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -431,6 +431,19 @@ prompting for a link description. It can be a string (used as-is) or
a function (called with the same arguments as
~org-make-link-description-function~ to return a string to use).
+*** New list of languages for LaTeX export: ~org-latex-language-alist~
+
+~org-latex-language-alist~ unifies into a single list the old language
+lists for the =babel= and =polyglossia= LaTeX packages:
+~org-latex-babel-language-alist~ and
+~org-latex-polyglossia-language-alist~, respectively, which are
+declared obsolete.
+
+This new list captures the current state of art regarding language
+support in LaTeX. The new =babel= syntax for loading languages via
+=ini= files and the new command =\babelprovide= (see:
+http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf)
+are also supported.
* Version 9.5
** Important announcements and breaking changes
--
2.37.1
[PATCH] org-fast-tag-selection: Make group tags separator not break alignment
"Christopher M. Miles" writes: > I agree to improve the tag selection UI. The hard-to-type characters is > not necessary. It's hard to type, and not match the purpose of "fast tag > selection", and will break tags alignment. > > Also need minor improvement on alignment of tags "group tag". > > Please see my screenshot attachment. This should be easy. See the attached patch. Note that the patch does not consider a case of narrow screen, but it is not like the menu is designed with such considerations, so I do not see much point trying hard to cover the edge cases. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92 >From 1cd18001f982092534664bc257b470fd9855b839 Mon Sep 17 00:00:00 2001 Message-Id: <1cd18001f982092534664bc257b470fd9855b839.1659965569.git.yanta...@gmail.com> From: Ihor Radchenko Date: Mon, 8 Aug 2022 21:30:04 +0800 Subject: [PATCH] org-fast-tag-selection: Make group tags separator not break alignment * lisp/org.el (org-fast-tag-selection): Start " : " group tags separator before tag column in the menu. Reported in https://orgmode.org/list/62f04f7c.d40a0220.9da67.0a2csmtpin_added_bro...@mx.google.com --- lisp/org.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 3b1caecf1..f7625dac7 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -11749,7 +11749,9 @@ (defun org-fast-tag-selection (current inherited table todo-table) (while (equal (car tbl) '(:newline)) (insert "\n") (setq tbl (cdr tbl) - ((equal e '(:grouptags)) (insert " : ")) + ((equal e '(:grouptags)) +(delete-backward-char 3) +(insert " : ")) (t (setq tg (copy-sequence (car e)) c2 nil) (if (cdr e) -- 2.35.1
Re: [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface)
Hanno Perrey writes: > Good point. I attach a patch that does just that. After the '~' > character, only "space" is assigned -- which feels like a hack, but > means that the selection key field is empty and that the fields are > still aligned nicely. Actually selection any of these items is not > possible as space is assigned to clearing the tags. Should this break > anything that I have missed in my (brief) tests, please let me know! > > Additionally, the range A-Z is used once 'z' is reached before assigning > non-alphabetic (but reasonably-reachable) characters. In case that > description is difficult to follow, I attach a screenshot of the > modified code in action. Thanks! Applied onto main via 4db67da68 with minor amendments like adding double space between sentences and capitalizing first word in sentences. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4db67da68db820184bd9d4208c4f8bd7370ee9de > Please note that I have not (yet) assigned copyright to the FSF. > However, I believe that these changes are still trivial enough to > qualify as TINYCHANGE. You are good to go until 15LOC total contribution combined. >> Finally, we may simply not list tags with keys beyond "z" at all only >> indicating that there are more by showing some text at the end of the >> menu. > > That might be an alternative, as I think not even all tags are shown > now. Let me know should you rather go down that route instead. We may, but then we need support from other users. Hiding staff will be a breaking change, unlike the patch you propose, which barely improves visuals. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] org-export: Make results of named code blocks a valid link
reza writes: > Sorry for my ignorance, I thought org-mode is part of Emacs but it seems > development happens in a separate repo. How is org-mode "added" to Emacs > because I was a little bit stuck in applying the patch? Org mode is distributed with Emacs. However, we only put the latest stable Org version when Emacs releases. Because Emacs development is quite slow, Org chose to do the main development in a separate repo and release on ELPA between Emacs major releases. See more details in https://orgmode.org/, https://orgmode.org/worg/org-contribute.html, and https://orgmode.org/worg/org-maintenance.html -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] org-export: Make results of named code blocks a valid link
On 8/5/22 12:15, Ihor Radchenko wrote: > I like this idea better. See the attached patch. > After the patch, links to :exports both blocks will be ambiguous, unless > the results are explicitly named. So, I documented this detail in the > manual. Looks good for me! Sorry for my ignorance, I thought org-mode is part of Emacs but it seems development happens in a separate repo. How is org-mode "added" to Emacs because I was a little bit stuck in applying the patch? Cheers Reza OpenPGP_0xC375C6AF05125C52.asc Description: application/pgp-keys OpenPGP_signature Description: PGP signature
