Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Max Nikulin writes:
> Better docs and some restriction on defcustom values were discussed earlier:
> https://list.orgmode.org/87k0oyd3pw@nicolasgoaziou.fr/
> Nicolas Goaziou. Re: Using backticks for the inline code delimeter? Mon,
> 19 Apr 2021 11:27:07 +0200
>
> Sorry, I have not prepared a patch. I am not confident with defcustom
> fine tuning and have not experimented with it since that time.
Maybe something like the attached?
Best,
Ihor
>From 8057cdb57f6600443b3605c1e7f00a30bea2a9ea Mon Sep 17 00:00:00 2001
Message-Id: <8057cdb57f6600443b3605c1e7f00a30bea2a9ea.1637048505.git.yanta...@gmail.com>
From: Ihor Radchenko
Date: Tue, 16 Nov 2021 15:40:35 +0800
Subject: [PATCH] org-emphasis-alist: Update defcustom making emphasis
characters constant
* lisp/org.el (org-emphasis-alist): Mention that emphasis characters
should not be changed by user. Update the defcustom type accordingly.
---
lisp/org.el | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 603b57279..7af5e26c6 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3833,18 +3833,47 @@ (defcustom org-emphasis-alist
marker characters and the face to be used by font-lock for highlighting
in Org buffers.
+The characters in the alist must not be changed. They do not affect
+the actual Org syntax, just fontification.
+
You need to reload Org or to restart Emacs after customizing this."
:group 'org-appearance
:set 'org-set-emph-re
:version "24.4"
:package-version '(Org . "8.0")
- :type '(repeat
+ :type '(list
(list
- (string :tag "Marker character")
+ (const "*")
+ (choice
+ (face :tag "Bold emphasis face")
+ (plist :tag "Bold emphasis face property list")))
+ (list
+ (const "/")
+ (choice
+ (face :tag "Italic emphasis face")
+ (plist :tag "Italic emphasis face property list")))
+ (list
+ (const "_")
+ (choice
+ (face :tag "Underline emphasis face")
+ (plist :tag "Underline emphasis face property list")))
+ (list
+ (const "=")
+ (choice
+ (face :tag "Verbatim emphasis face")
+ (plist :tag "Verbatim emphasis face property list"))
+ (const verbatim))
+ (list
+ (const "~")
+ (choice
+ (face :tag "Code emphasis face")
+ (plist :tag "Code emphasis face property list"))
+ (const verbatim))
+ (list
+ (const "+")
(choice
- (face :tag "Font-lock-face")
- (plist :tag "Face property list"))
- (option (const verbatim)
+ (face :tag "Strike-through emphasis face")
+ (plist :tag "Strike-through emphasis face property list")
(defvar org-protecting-blocks '("src" "example" "export")
"Blocks that contain text that is quoted, i.e. not processed as Org syntax.
--
2.32.0
Re: Weird gap in agenda mode-line
Carlos Pita writes: > ... That said, what is the point of the list? What is the > reason not to concatenate the parts into one single string? It > looks and feels weird as if each section had its own menu while it's > all the same thing. It is a list because mode-name is using format-mode-line :eval constructs (see the docstring). Also, there is no need to concatenate individual strings explicitly in mode-name list. One could do it, but there will still be multiple string and :eval sections with their own menus (AFAIU). Best, Ihor
Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]
Eric S Fraga writes: > On Monday, 15 Nov 2021 at 00:03, dal-bla...@onenetbeyond.org wrote: >> So if we want to make org cooperate with window.el we must ban theses >> functions and instead delegate the window management with calls to >> proper display functions. > > I agree completely. One of my bug-bears is org-capture which I often > use during meetings to take notes or create TODO items. Typically, the > org capture window covers my Teams buffer (I use exwm as my window > manager...) which is rather annoying. > > I did play with display-buffer-alist but it seemed to not be able to > take control of some of org's windows. Everything else I do in Emacs is > nicely managed through that alist. Just want to mention that I would also really appreciate this. I asked for it ~4 years ago on this list https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00241.html and it also comes up from time to time in other places like this Reddit thread https://www.reddit.com/r/emacs/comments/ic4u1m/stop_emacs_from_hiding_other_windows_when/ Thanks, Daniel
Re: org-capture windows
On Monday, 15 Nov 2021 at 23:54, Max Nikulin wrote: > It seems, your workflow is inconsistent with original org-capture idea. > It was created at the time when screens were smaller and video meetings > were not usual activity. Indeed. The beauty & power of Emacs is how it evolves to cater for changing computing environments. From tty to ulta-wide monitors! But, yes, I had no problems with how org-capture etc. worked until a) I started using multiple large monitors and b) Emacs became my window manager. org needs to be less controlling basically (although reasonable defaults are good, of course). -- : Eric S Fraga, with org release_9.5-223-g876e81 in Emacs 29.0.50 : Latest paper written in org: https://arxiv.org/abs/2106.05096
org-capture windows
On 15/11/2021 16:57, Eric S Fraga wrote: I agree completely. One of my bug-bears is org-capture which I often use during meetings to take notes or create TODO items. Typically, the org capture window covers my Teams buffer (I use exwm as my window manager...) which is rather annoying. It seems, your workflow is inconsistent with original org-capture idea. It was created at the time when screens were smaller and video meetings were not usual activity. It is only my guess however. Some event requiring capture interrupts current activity. It should be postponed till capture completion, so all other windows are removed to not distract you. As soon as capture finished you can resume the earlier activity, so previous window layout and positions in buffers are restored. It is not bad approach per se but it is designed for frames with one or two buffers and incompatible with Emacs as window manager approach. I do not mind that such behavior should not be mandatory. I have another example when current behavior is confusing. Browser and an Emacs frame are placed side by side. A group of related pages should be captured. Initial buffer and position is arbitrary. During capture of first page I jump to particular heading to cross-reference new note with some older topic. It is necessary to add a bit more to the same topic for a next web page but on capture completion buffer position is reset to previous value despite I was going to continue capture process. Another problem is capture started through org-protocol without explicit template when template selection for previous capture was already active. Such kind of multi-tasking should not be a problem but it is since template key should be typed into minibuffer. I do not know what can be a proper solution. Maybe it can be a special mode with custom keymap for *Org Select* windows, so several such buffers may co-exist with no conflict due to minibuffer. I did play with display-buffer-alist but it seemed to not be able to take control of some of org's windows. Everything else I do in Emacs is nicely managed through that alist. A couple of months ago `display-buffer-alist' was overridden by `org-no-popups'. Currently you can put "\\*Org Select\\*\\|CAPTURE-.*\.org" buffers to e.g. side window. Unfortunately other windows are still wiped till capture completion.
Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
On 15/11/2021 22:20, Ihor Radchenko wrote: Nicolas Goaziou writes: Ihor Radchenko writes: This commit may cause random failures when org-emphasis-regexp-components is changed by user. This is not supported anyway. Yeah. Though I have seen people changing this variable. Maybe we should change defvar to defconst? Better docs and some restriction on defcustom values were discussed earlier: https://list.orgmode.org/87k0oyd3pw@nicolasgoaziou.fr/ Nicolas Goaziou. Re: Using backticks for the inline code delimeter? Mon, 19 Apr 2021 11:27:07 +0200 Sorry, I have not prepared a patch. I am not confident with defcustom fine tuning and have not experimented with it since that time.
Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend
Max Nikulin writes: > The following source block must not execute echo and touch > > #+begin_src clojure >(str "`echo $HOME`" "`touch /tmp/pwned`") > #+end_src Thanks, now I got it :) Attached is the patch changed the logic to use a temp file with org-babel-eval. Somehow it doesn't feel too great to create unnecessary temp files but I looked how other babel backends do it and e.g. ob-js and ob-haskell use the same logic. Thanks, Daniel >From cc9a24fcc42756cc76d59697bddc94a4ee2c475d Mon Sep 17 00:00:00 2001 From: Daniel Kraus Date: Sat, 13 Nov 2021 22:51:56 +0100 Subject: [PATCH] ob-clojure.el: Add support for babashka and nbb backend * lisp/ob-clojure.el: Add support for babashka and nbb backend. --- lisp/ob-clojure.el | 27 +++ 1 file changed, 27 insertions(+) diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el index 3b995d94c..8548dc86d 100644 --- a/lisp/ob-clojure.el +++ b/lisp/ob-clojure.el @@ -36,6 +36,8 @@ ;; For clojure-mode, see https://github.com/clojure-emacs/clojure-mode ;; For cider, see https://github.com/clojure-emacs/cider ;; For inf-clojure, see https://github.com/clojure-emacs/cider +;; For babashka, see https://github.com/babashka/babashka +;; For nbb, see https://github.com/babashka/nbb ;; For SLIME, the best way to install these components is by following ;; the directions as set out by Phil Hagelberg (Technomancy) on the @@ -73,6 +75,8 @@ (const :tag "inf-clojure" inf-clojure) (const :tag "cider" cider) (const :tag "slime" slime) + (const :tag "babashka" babashka) + (const :tag "nbb" nbb) (const :tag "Not configured yet" nil))) (defcustom org-babel-clojure-default-ns "user" @@ -80,6 +84,16 @@ :type 'string :group 'org-babel) +(defcustom ob-clojure-babashka-command (executable-find "bb") + "Path to the babashka executable." + :type 'file + :group 'org-babel) + +(defcustom ob-clojure-nbb-command (executable-find "nbb") + "Path to the nbb executable." + :type 'file + :group 'org-babel) + (defun org-babel-expand-body:clojure (body params) "Expand BODY according to PARAMS, return the expanded body." (let* ((vars (org-babel--get-vars params)) @@ -225,6 +239,15 @@ ,(buffer-substring-no-properties (point-min) (point-max))) (cdr (assq :package params) +(defun ob-clojure-eval-with-babashka (bb expanded) + "Evaluate EXPANDED code block using BB (babashka or nbb)." + (let ((script-file (org-babel-temp-file "clojure-bb-script-" ".clj"))) +(with-temp-file script-file + (insert expanded)) +(org-babel-eval + (format "%s %s" bb (org-babel-process-file-name script-file)) + ""))) + (defun org-babel-execute:clojure (body params) "Execute a block of Clojure code with Babel." (unless org-babel-clojure-backend @@ -236,6 +259,10 @@ (cond ((eq org-babel-clojure-backend 'inf-clojure) (ob-clojure-eval-with-inf-clojure expanded params)) + ((eq org-babel-clojure-backend 'babashka) + (ob-clojure-eval-with-babashka ob-clojure-babashka-command expanded)) + ((eq org-babel-clojure-backend 'nbb) + (ob-clojure-eval-with-babashka ob-clojure-nbb-command expanded)) ((eq org-babel-clojure-backend 'cider) (ob-clojure-eval-with-cider expanded params)) ((eq org-babel-clojure-backend 'slime) -- 2.33.1
Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Nicolas Goaziou writes: > Ihor Radchenko writes: > >> This commit may cause random failures when >> org-emphasis-regexp-components is changed by user. > > This is not supported anyway. Yeah. Though I have seen people changing this variable. Maybe we should change defvar to defconst? >> org-emph-re is calculated according to org-emphasis-regexp-components. >> Changing org-emphasis-regexp-components can make "(when (looking-at >> org-emph-re)" in parsers return nil. The emphasised text will still be >> fontified, but not available in the parsed buffer. > > That’s exactly my point. The syntax is not meant to be configurable. > I wrote a patch also removing ‘org-emph-re’ depedency from > "org-element.el", but I was delayed. I just applied it. Thanks! >> Maybe we need to move the logic for org-emph-re from org.el to >> org-element.el? > > ‘org-emph-re’ has some limitations which do not belong to syntax > definition. There’s no point in adding it in "org-element.el". > > The grand scheme is to remove most "org.el" dependencies from > "org-element.el", and move the others. That would be great. I was thinking about unifying the grammar better. Things like org-set-regexps-and-options define part of the grammar non-transparently outside org-element. As a result, the new org-persist library can be potentially broken if the user changes grammar between Emacs session (e.g. org-off-levels-only, org-todo-keywords, etc). Keeping all the variables that change the grammar in one place would be helpful. Maybe we could save the complete grammar state right inside output of org-element-parse-buffer. In the updated element cache code, I introduced properties into org-data element. Maybe we can keep all the important variables for the buffer grammar in org-data? That way, the job of org-set-regexps-and-options will be done by org-element-org-data-parser. Moreover, users exporting using ox-org will be able to create self-sufficient Org files that can be shared without relying on the same configuration in init.el. >> Also, there is org-emphasis-alist. It is even defcustom, but ignored by >> org-element.el. > > This variable is a defcustom for the faces, not the markers. I.e., it is > not meant to add, remove, or change emphasis markup, but rather alter > how they appear. IMO, this should be removed altogether: it’s up to > a theme to set such a thing. Unless I miss something, org-emphasis-alist is used in org-emphasise. Though it just another reason to remove it. Best, Ihor
Re: [SOLVED] (was: [downgrading to matlab 2019a and using 3.5 NOW does not work neither])
On 15/11/2021 20:31, Uwe Brauer wrote: Advice: don't try to upgrade python on a given Ubuntu distribution Anover advice: 1. Avoid unsupported versions of software (Ubuntu-16.04 has only payed support for more than a year) and localize its usage if there is no other way. * reinstall jupyter #+begin_src sudo dpkg --purge python3-ptyprocess sudo -H pip3 install --upgrade --force-reinstall --no-cache-dir jupyter 2. Use venv (virtualenv for Python-2.7) to keep packages installed by pip isolated from system .deb's. > I need still 2.7 to compile mercurial, since I rely on some extensions > for mercurial that do not work under 3.X Ubuntu-20.04 has (already unsupported) Python-2.7 in addition to 3.8 and 3.9. It is better to keep primary system up to date and to use containers (LXC, docker, etc.) or fully virtualized systems for special needs.
Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend
On 14/11/2021 23:30, Daniel Kraus wrote: Max Nikulin writes: On 14/11/2021 22:28, Daniel Kraus wrote: +(defun ob-clojure-escape-quotes (str-val) + "Escape quotes for STR-VAL." + (replace-regexp-in-string "\"" "\\\"" str-val 'FIXEDCASE 'LITERAL)) + +(defun ob-clojure-eval-with-babashka (bb expanded) + "Evaluate EXPANDED code block using BB (babashka or nbb)." + (let ((escaped (ob-clojure-escape-quotes expanded))) +(shell-command-to-string + (concat bb " -e \"" escaped "\"" Does not it an open door for security vulnerabilities? Consider a string somewhere in the code: "`echo arbitrary code execution`". Only outer quotes are escaped. The escaping is not done for security reasons. When I have a babel block like #+BEGIN_SRC clojure (str "foo" "bar") #+END_SRC babashka has to be called with bb -e "(str \"foo\" \"bar\")" Enough shell constructs may be interpreted by shell inside double quotes before result is passed to bb. I mentioned execution of code inside backticks, variable substitutions are mostly undesired as well. I do not think, users should escape "$" inside source blocks just because you chose incomplete escaping of shell specials. The following source block must not execute echo and touch #+begin_src clojure (str "`echo $HOME`" "`touch /tmp/pwned`") #+end_src Shell should not be used to launch any command unless it is really necessary. Arguments should be passed directly to execve(2) system call as an array. Combining them into string to pass through shell interpreter to parse into argument array again is error prone. Unfortunately Emacs API related to execution of external processes is awkward. In this particular case it encourages usage of the unsafe function since there is no convenient helper that accepts binary and *list* of arguments and returns output as a string. So more verbose code is required to invoke bb without intermediate interpretation of content of argument string. In my opinion it is better than using of more reliable and tested function to escape shell specials.
[SOLVED] (was: [downgrading to matlab 2019a and using 3.5 NOW does not work neither])
It was quite an ordeal, just in case someone runs into a similar problem. Advice: don't try to upgrade python on a given Ubuntu distribution * reinstall jupyter #+begin_src sudo dpkg --purge python3-ptyprocess sudo -H pip3 install --upgrade --force-reinstall --no-cache-dir jupyter sudo -H pip3 install --upgrade --force-reinstall --no-cache-dir numpy sudo -H pip3 install --upgrade --force-reinstall --no-cache-dir pymatbridge sudo -H pip3 install --upgrade --force-reinstall --no-cache-dir matlab_kernel #+end_src * check https://github.com/Calysto/matlab_kernel#kernel-times-out-while-starting #+begin_src python3 -m matlab_kernel.check #+end_src That told me to look for a matlab solution * matlab solution for Ubuntu 16.04 https://de.mathworks.com/matlabcentral/answers/403561-import-error-matlab-engine-in-python ** solve the gcc library problem #+begin_src LD_LIBRARY_PATH=/usr/local/lib64/:$LD_LIBRARY_PATH $ export LD_LIBRARY_PATH $ sudo apt-add-repository ppa:ubuntu-toolchain-r/test $ sudo apt-get update $ sudo apt-get install gcc-6 g++-6 #+end_src ** install the engine again #+begin_src cd /usr/local/MATLAB/R2019a/extern/engines/python/ sudo /usr/bin/python3 setup.py install #+end_src ** Start the engine DONE!
[PATCH] org-attach-attach: fix symlinks
I'm having trouble with org-attach-attach if my current buffer is visiting a filepath starting with "~/". This trivial patch fixes the problem for me by running (expand-file-name) on the file before attaching. I always use the 'lns method, so I don't know whether it might be better to expand-file-name before running any of the methods. Alternatively, it might actually be better to use a *relative* file path where possible (e.g. to ensure that project directories are fully portable), but I'm not sure how best to do that. This should be a tinychange, but also I have signed FSF paperwork. From f618fb512e62ccb2e700242a7678dacbc2b025e2 Mon Sep 17 00:00:00 2001 From: Matt Price Date: Mon, 15 Nov 2021 08:14:37 -0500 Subject: [PATCH] org-attach-attach: expand file names before linking when using symbolic links for attachments, ensure links are fully expanded to avoid filesystem errors. --- lisp/org-attach.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-attach.el b/lisp/org-attach.el index 75db69c9c..abdce3e7a 100644 --- a/lisp/org-attach.el +++ b/lisp/org-attach.el @@ -523,7 +523,7 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from ((eq method 'mv) (rename-file file attach-file)) ((eq method 'cp) (copy-file file attach-file)) ((eq method 'ln) (add-name-to-file file attach-file)) - ((eq method 'lns) (make-symbolic-link file attach-file)) + ((eq method 'lns) (make-symbolic-link (expand-file-name file) attach-file)) ((eq method 'url) (url-copy-file file attach-file))) (run-hook-with-args 'org-attach-after-change-hook attach-dir) (org-attach-tag) -- 2.33.1
Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]
On Monday, 15 Nov 2021 at 00:03, dal-bla...@onenetbeyond.org wrote: > So if we want to make org cooperate with window.el we must ban theses > functions and instead delegate the window management with calls to > proper display functions. I agree completely. One of my bug-bears is org-capture which I often use during meetings to take notes or create TODO items. Typically, the org capture window covers my Teams buffer (I use exwm as my window manager...) which is rather annoying. I did play with display-buffer-alist but it seemed to not be able to take control of some of org's windows. Everything else I do in Emacs is nicely managed through that alist. -- : Eric S Fraga, with org release_9.5-223-g876e81 in Emacs 29.0.50 : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Hello, Ihor Radchenko writes: > This commit may cause random failures when > org-emphasis-regexp-components is changed by user. This is not supported anyway. > org-emph-re is calculated according to org-emphasis-regexp-components. > Changing org-emphasis-regexp-components can make "(when (looking-at > org-emph-re)" in parsers return nil. The emphasised text will still be > fontified, but not available in the parsed buffer. That’s exactly my point. The syntax is not meant to be configurable. I wrote a patch also removing ‘org-emph-re’ depedency from "org-element.el", but I was delayed. I just applied it. > Maybe we need to move the logic for org-emph-re from org.el to > org-element.el? ‘org-emph-re’ has some limitations which do not belong to syntax definition. There’s no point in adding it in "org-element.el". The grand scheme is to remove most "org.el" dependencies from "org-element.el", and move the others. > Also, there is org-emphasis-alist. It is even defcustom, but ignored by > org-element.el. This variable is a defcustom for the faces, not the markers. I.e., it is not meant to add, remove, or change emphasis markup, but rather alter how they appear. IMO, this should be removed altogether: it’s up to a theme to set such a thing. Regards, -- Nicolas Goaziou
