Re: [PATCH] Bug: fragile org refile cache
thanks for reporting that you use it. would it be more useful if it automaticaly generated the cache instead of telling you to runt he command to do so? if a solid, perhaps unified, cache existed, would org-id use it too? On 4/28/21, Ihor Radchenko wrote: > Samuel Wales writes: > >> long ago i used to use the refile cache. i think it is probably not >> widely used, or maybe even not at all. > > At least, I do use it. A lot. I rely on it. > > I do not observe the breakage as described in the first message, mostly > because I use refile cache exclusively for org-refile. Yet, I often see > "Please regenerate the refile cache with C-0 C-c C-w" when I do a lot of > batch refiling. A faster, more reliable, caching would be certainly > welcome. > > In general, various parts of Org mode code base implement different > types of caches in parallel. I am aware at least about org-element, > org-scan-tags, org-agenda, org-refile, and org-goto. Probably Org mode > could benefit from unified caching mechanism? A good implementation > coming to my mind is org-ql [1]. It implements tag caches, outline path > caches, and can even be used to cache results of an arbitrary function > with point at heading. Basically, all (except org-element) types of > caches Org mode uses now are already implemented in org-ql in unified > way. > > WDYT? > > [1] https://github.com/alphapapa/org-ql > > Best, > Ihor > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] Bug: fragile org refile cache
Samuel Wales writes: > long ago i used to use the refile cache. i think it is probably not > widely used, or maybe even not at all. At least, I do use it. A lot. I rely on it. I do not observe the breakage as described in the first message, mostly because I use refile cache exclusively for org-refile. Yet, I often see "Please regenerate the refile cache with C-0 C-c C-w" when I do a lot of batch refiling. A faster, more reliable, caching would be certainly welcome. In general, various parts of Org mode code base implement different types of caches in parallel. I am aware at least about org-element, org-scan-tags, org-agenda, org-refile, and org-goto. Probably Org mode could benefit from unified caching mechanism? A good implementation coming to my mind is org-ql [1]. It implements tag caches, outline path caches, and can even be used to cache results of an arbitrary function with point at heading. Basically, all (except org-element) types of caches Org mode uses now are already implemented in org-ql in unified way. WDYT? [1] https://github.com/alphapapa/org-ql Best, Ihor
Re: [PATCH] Bug: fragile org refile cache
long ago i used to use the refile cache. i think it is probably not widely used, or maybe even not at all. the reason i stopped was behavior that sounds similar to your description. such as, it would produce a set of results that did not match the calling conditions. i cannot reach the thread you point to, however. what i did was use ido-hacks to speed up ido and restrict to :goto: and :refile: tagged entries for common targets. this worked for me; it is fast despite my huge set of olpaths. it would be great if the cache were unnecessary. that might nt work for you, but perhaps this provides confirmation or ideas for you. On 4/28/21, Maxim Nikulin wrote: > Reviewing my attempt to speedup collecting of refile targets > https://orgmode.org/list/s209r8$16en$1...@ciao.gmane.io/ > I have realized that refile cache is unreliable. > > With specific customization, cache content and thus refile targets > depend on the function called first: `org-refile' ([C-u] C-c C-w) or > `org-goto' (C-u C-c C-w). > > I decided to try to provide minimal example and steps to reproduce in > the form of a test marked as expected failure. > > Certainly cache should be enabled > (org-refile-use-cache t) > `org-refile-targets' should have (nil . (:maxlevel . 5)) for the > affected buffer. The value of the following setting is intentionally set > to alternative value in comparison to `org-goto' code > (org-refile-use-outline-path nil) > To see the issue interactively, you likely should set > (org-outline-path-complete-in-steps nil) > > Clean cache (C-u C-u C-u C-c C-w) and try jumping using C-u C-c C-w and > C-u C-c C-j in various order. Use TAB completion to see targets. > > To make difference more apparent, define > `org-refile-target-verify-function' to filter-out some headings. > > My expectation that each command has list of targets formatted > accordingly to user setting or `org-goto' internal overrides. Actually > lists of target are the same since they share cache entry. > > I suppose, cache keys should include values of all parameters affecting > filtering and formatting, not only regexp for heading selection. > > However I have no idea how to derive some value suitable for cache key > from `org-refile-target-verify-function'. > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Timothy writes: > Ihor Radchenko writes: > > Maybe this is a good time to start a discussion about moving Org's > minimum supported Emacs to 25...? I checked Red Hat, Centos, Debian, SuSE, and Ubuntu. They are all 25.1 or later in their current distributions. So that will probably not cause too much breakage. -- Robert Horn rjh...@alum.mit.edu
Re: [PATCH] Fixed-pitch tables and code blocks that do not break variable-pitch-mode
On 2021-04-27, 21:28 +0200, Bastien wrote: >> Please see the attached diff. An explanation is offered below. I have >> already assigned copyright to the FSF. > > Sorry it took so long to commit this, it is done in commit 667cb6f1a > in master, adding fixed-pitch for org-hide, org-verbatim and org-code > too. > > Thanks! Thank you Bastien for this and for every other contribution! -- Protesilaos Stavrou https://protesilaos.com
Re: [PATCH] Have C-c C-c recognise #+plot lines
Hi Eric, Have you had a chance to test this out? -- Timothy
Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
On 28/04/2021 15:37, Utkarsh Singh wrote: +List of preferred separator (in order of preference): +comma, TAB, semicolon, colon or SPACE. I will hardly be using this feature heavily, so I do not insist that the following must be taken into account. Just some considerations... There are locales where comma is used as decimal separator 23,5 (e.g. ru_RU.UTF-8). Office software and applications oriented to office users often use semicolon as field separator. There are still may be plenty of numbers with fractional part, so with commas. Likely ";" should be tried at first for such locales. However the same user may have enough CSV files that are really "comma separated", e.g. results of numerical simulation where localization is intentionally ignored, data obtained from some equipment, etc. Some files (e.g. downloaded bank statements) may be in legacy 8-bit encoding instead of UTF-8. As a result, sometimes the only convenient way is to try various options with interactive preview.
Re: splot and #+PLOT keyword
Looking at the code, 3d plotting does not support plotting individual selected columns, it would appear. :-( I think I'll stick to using src blocks instead, which is what I've been doing for years, for 3d plots. Sorry for the noise and thanks again. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b
Re: splot and #+PLOT keyword
Hi Nick, On Wednesday, 28 Apr 2021 at 11:28, Nick Dokos wrote: > Have you tried looking at the produced gnuplot script? It goes in a > temp file so it's a bit of a pain, but that's my fallback method when > I'm really confused :-) The issue appears to be the data that are also placed in a temp file. These are data extracted from the table, i.e. the relevant columns. The file disappears... so I guess I will go diving into the code and make sure the file sticks around so I can debug. Thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b
[PATCH] Bug: fragile org refile cache
Reviewing my attempt to speedup collecting of refile targets https://orgmode.org/list/s209r8$16en$1...@ciao.gmane.io/ I have realized that refile cache is unreliable. With specific customization, cache content and thus refile targets depend on the function called first: `org-refile' ([C-u] C-c C-w) or `org-goto' (C-u C-c C-w). I decided to try to provide minimal example and steps to reproduce in the form of a test marked as expected failure. Certainly cache should be enabled (org-refile-use-cache t) `org-refile-targets' should have (nil . (:maxlevel . 5)) for the affected buffer. The value of the following setting is intentionally set to alternative value in comparison to `org-goto' code (org-refile-use-outline-path nil) To see the issue interactively, you likely should set (org-outline-path-complete-in-steps nil) Clean cache (C-u C-u C-u C-c C-w) and try jumping using C-u C-c C-w and C-u C-c C-j in various order. Use TAB completion to see targets. To make difference more apparent, define `org-refile-target-verify-function' to filter-out some headings. My expectation that each command has list of targets formatted accordingly to user setting or `org-goto' internal overrides. Actually lists of target are the same since they share cache entry. I suppose, cache keys should include values of all parameters affecting filtering and formatting, not only regexp for heading selection. However I have no idea how to derive some value suitable for cache key from `org-refile-target-verify-function'. >From d23b10d658539a4646ef015ac2660e1f8c8e7e1b Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Wed, 28 Apr 2021 22:30:04 +0700 Subject: [PATCH] testing/lisp/test-org.el: Refile cache failure testing/lisp/test-org.el (test-org/org-refile-cache): Add expected failure for cache content discrepancy when it is populated by `org-refile' or by `org-goto' (C-u C-c C-j). Usage of just regexp for heading filtering as cache key is unreliable since other settings affects selected entries (`org-refile-target-verify-function') or content of entries (`org-refile-use-outline-path'). However most of users have no chance to notice collision since they do not call both functions interchangeably or have `org-refile-targets' different from the value in `org-goto' code. --- testing/lisp/test-org.el | 24 1 file changed, 24 insertions(+) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 9f0ede1b9..f44cd76a6 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -6394,6 +6394,30 @@ Paragraph" (org-refile-targets `((nil :level . 1 (member (buffer-name) (mapcar #'car (org-refile-get-targets))) +(ert-deftest test-org/org-refile-cache () + "Demostrate a cache conflict of `org-goto' and `org-refile'. + +Notice that `org-refile-target-verify-function' can cause more severe +divergence of cache content generated by these functions." + :expected-result :failed + (org-test-with-temp-text "* H1\n** H2\n" +(let ((org-refile-use-cache t) + ;; Regexp serves as cache key, so targets should be the same + ;; as in `org-goto' code. + (org-refile-targets '((nil . (:maxlevel . 5 + ;; This value is opposite to the one in `org-goto' code. + (org-refile-use-outline-path nil) + (targets-refile)) + ;; If jumping using `org-refile' (C-u C-c C-w)... + (setq targets-refile (mapcar #'car (org-refile-get-targets))) + (org-refile-cache-clear) + ;; Tune settings to simulate `org-goto' (C-u C-c C-j). + (let ((org-refile-use-outline-path t)) +;; Value is discarded, call just to populate the cache. +(org-refile-get-targets)) + ;; Targets got by `org-refile'. + (let ((targets-goto (mapcar #'car (org-refile-get-targets +(should (equal targets-refile targets-goto)) ;;; Sparse trees -- 2.25.1
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Ihor Radchenko writes: > In any case, not all the warnings go away even using Emacs 25.3: Just going to chime in here with the relevant info: > ob-gnuplot.el:299:1:Warning: the function ‘file-local-name’ is not known to be > defined. :added:26.1 It looks like the definition could just be used here: (or (file-remote-p file 'localname) file) > In end of data: > org-plot.el:727:1:Warning: the function ‘ignore-error’ is not known to be > defined. :added:27.1 Once again, the definition isn't too bad. (condition-case nil (progn ,@body) (,condition nil)) This one is actually within my purview (oops), so I'll take care of this shortly. -- Timothy
Re: splot and #+PLOT keyword
Eric S Fraga writes: > Hello, > > a question/problem regarding the #+plot: keyword. > > I am trying to plot out some data where the table looks like this: > > #+begin_src org > ,#+plot: ind:(6 7) deps:(1) with:"linespoints pt 7" set:"logscale xy" > type:3d > | 1 | 81 | 5 | 0 | 2.27 | 0.9729848950975623 | > 0.019370016994566613 | 0.0 | > | 2 | 179 | 12 | 2 | 3.68 |0.42919355355596267 | > 0.098179980500945 | 0.0 | > | 3 | 192 | 6 | 4 | 3.73 | 0.022272788298562045 | > 107.57399021086516 | 0.0 | > | 4 | 207 | 7 | 8 | 3.78 | 5.793210638997738 | > 0.0012069891001225872 | 0.0 | > | 5 | 194 | 10 | 12 | 3.83 |0.06356594000544429 | > 0.04724965431965522 | 0.0 | > | 6 | 216 | 8 | 14 | 3.89 |0.06342050747033937 | > 0.0030380306687021346 | 0.0 | > | 7 | 193 | 7 | 18 | 3.94 | 0.0021538841210584 | > 0.05771587421360767 | 0.0 | > | 8 | 193 | 7 | 19 | 3.99 | 0.0010739216097561438 | > 0.10625133051680691 | 0.0 | > | 9 | 182 | 6 | 19 | 4.04 | 0.0014893478573963876 | > 0.03593357278451856 | 0.0 | > |10 | 192 | 6 | 21 | 4.10 | 0.013251328328567616 | > 0.0006605631984014402 | 0.0 | > #+end_src > > > I have tried a variety of directives for the #+PLOT: keyword but none > give me what I want. I would like to plot column 1 (dependent variable) > versus columns 6 and 7 (independent variables) in 3d. (don't ask ;-)) > > I have also tried: > >#+plot: ind:6 deps:(7 1) ... > > but in all cases I seem to be getting somewhat random data plotted, > possibly columns 2 versus 3 and 4, which makes no sense except that > maybe the "|" table column separator is being retained in the data file > created. Is there any way to stop the data file from being deleted > after plotting? I can inspect the *gnuplot* buffer but cannot see the > actual data. > > 2d plots work just fine, by the way. > > thank you, > eric Have you tried looking at the produced gnuplot script? It goes in a temp file so it's a bit of a pain, but that's my fallback method when I'm really confused :-) -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: org-goto and org-store-link/org-id-get-create
Hi Ihor, applied in master as commit 232d9a060, thanks a lot! -- Bastien
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Timothy writes: > Maybe this is a good time to start a discussion about moving Org's > minimum supported Emacs to 25...? I have no objections here, since I am on Emacs master anyway. In any case, not all the warnings go away even using Emacs 25.3: Compiling /home/yantar92/Git/org-mode/lisp/ob-gnuplot.el... In end of data: ob-gnuplot.el:299:1:Warning: the function ‘file-local-name’ is not known to be defined. Compiling /home/yantar92/Git/org-mode/lisp/org-plot.el... In end of data: org-plot.el:727:1:Warning: the function ‘ignore-error’ is not known to be defined. Compiling /home/yantar92/Git/org-mode/lisp/org.el... In org-display-inline-images: org.el:16554:57:Warning: reference to free variable ‘image-map’ Best, Ihor
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Ihor Radchenko writes: Maybe this is a good time to start a discussion about moving Org's minimum supported Emacs to 25...? -- Timothy
Re: org-goto and org-store-link/org-id-get-create
Bastien writes:
> Can you provide a patch for this?
Sure. Attached.
>From d914acea52d251e2099681ac9541e4cb42e0953f Mon Sep 17 00:00:00 2001
Message-Id:
From: Ihor Radchenko
Date: Wed, 28 Apr 2021 22:51:53 +0800
Subject: [PATCH] Bypass read-only state in org-entry-put
* lisp/org.el (org-entry-put): Ignore read-only state of the buffer.
Fixes bug when ID property is not insered when creating ID in an
indirect read-only org-goto buffer. [1]
[1] https://orgmode.org/list/8ffe2da5-e2cb-f44c-0a46-b19873c0b...@gmx.de/
---
lisp/org.el | 113 ++--
1 file changed, 57 insertions(+), 56 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index eb4b2db88..dbc245534 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12340,62 +12340,63 @@ (defun org-entry-put (pom property value)
((not (stringp value)) (error "Properties values should be strings"))
((not (org--valid-property-p property))
(user-error "Invalid property name: \"%s\"" property)))
- (org-with-point-at pom
-(if (or (not (featurep 'org-inlinetask)) (org-inlinetask-in-task-p))
- (org-back-to-heading-or-point-min t)
- (org-with-limited-levels (org-back-to-heading-or-point-min t)))
-(let ((beg (point)))
- (cond
- ((equal property "TODO")
- (cond ((not (org-string-nw-p value)) (setq value 'none))
- ((not (member value org-todo-keywords-1))
- (user-error "\"%s\" is not a valid TODO state" value)))
- (org-todo value)
- (org-align-tags))
- ((equal property "PRIORITY")
- (org-priority (if (org-string-nw-p value) (string-to-char value) ?\s))
- (org-align-tags))
- ((equal property "SCHEDULED")
- (forward-line)
- (if (and (looking-at-p org-planning-line-re)
- (re-search-forward
- org-scheduled-time-regexp (line-end-position) t))
- (cond ((string= value "earlier") (org-timestamp-change -1 'day))
- ((string= value "later") (org-timestamp-change 1 'day))
- ((string= value "") (org-schedule '(4)))
- (t (org-schedule nil value)))
- (if (member value '("earlier" "later" ""))
- (call-interactively #'org-schedule)
- (org-schedule nil value
- ((equal property "DEADLINE")
- (forward-line)
- (if (and (looking-at-p org-planning-line-re)
- (re-search-forward
- org-deadline-time-regexp (line-end-position) t))
- (cond ((string= value "earlier") (org-timestamp-change -1 'day))
- ((string= value "later") (org-timestamp-change 1 'day))
- ((string= value "") (org-deadline '(4)))
- (t (org-deadline nil value)))
- (if (member value '("earlier" "later" ""))
- (call-interactively #'org-deadline)
- (org-deadline nil value
- ((member property org-special-properties)
- (error "The %s property cannot be set with `org-entry-put'" property))
- (t
- (let* ((range (org-get-property-block beg 'force))
- (end (cdr range))
- (case-fold-search t))
- (goto-char (car range))
- (if (re-search-forward (org-re-property property nil t) end t)
- (progn (delete-region (match-beginning 0) (match-end 0))
- (goto-char (match-beginning 0)))
- (goto-char end)
- (insert "\n")
- (backward-char))
- (insert ":" property ":")
- (when value (insert " " value))
- (org-indent-line)
-(run-hook-with-args 'org-property-changed-functions property value)))
+ (org-no-read-only
+ (org-with-point-at pom
+ (if (or (not (featurep 'org-inlinetask)) (org-inlinetask-in-task-p))
+ (org-back-to-heading-or-point-min t)
+ (org-with-limited-levels (org-back-to-heading-or-point-min t)))
+ (let ((beg (point)))
+ (cond
+((equal property "TODO")
+ (cond ((not (org-string-nw-p value)) (setq value 'none))
+ ((not (member value org-todo-keywords-1))
+ (user-error "\"%s\" is not a valid TODO state" value)))
+ (org-todo value)
+ (org-align-tags))
+((equal property "PRIORITY")
+ (org-priority (if (org-string-nw-p value) (string-to-char value) ?\s))
+ (org-align-tags))
+((equal property "SCHEDULED")
+ (forward-line)
+ (if (and (looking-at-p org-planning-line-re)
+ (re-search-forward
+ org-scheduled-time-regexp (line-end-position) t))
+ (cond ((string= value "earlier") (org-timestamp-change -1 'day))
+ ((string= value "later") (org-timestamp-change 1 'day))
+ ((string= value "") (org-schedule '(4)))
+ (t (org-schedule nil value)))
+ (if (member value '("earlier" "later" ""))
+ (call-interactively #'org-schedule)
+ (org-schedule nil value
+((equal property "DEADLINE")
+ (forward-line)
+ (if (and (looking-at-p org-planning-line-re)
+ (re-search-forward
+ org-deadline-time-regexp (line-end-position) t))
+ (cond ((string= value "earlier") (org-timestamp-change -1 'day))
+ ((string= value "later") (org-timestamp-change 1 'day))
+ ((string= value "") (org-deadline '(4)))
+ (t (org-deadline nil value)))
+ (if (member value '("earlier" "later" ""))
+
Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
I was recently testing Org mode using old Emacs versions. Running make on master fails with the following errors and warnings: Compiling /home/yantar92/Git/org-mode/lisp/ob-C.el... Eager macro-expansion failure: (error "Vector QPatterns not implemented yet") Compiling /home/yantar92/Git/org-mode/lisp/ob-clojure.el... In end of data: ob-clojure.el:255:1:Warning: the function `funcall-interactively' is not known to be defined. Compiling /home/yantar92/Git/org-mode/lisp/ob-core.el... In toplevel form: ob-core.el:649:1:Error: Vector QPatterns not implemented yet Compiling /home/yantar92/Git/org-mode/lisp/ob-gnuplot.el... In end of data: ob-gnuplot.el:299:1:Warning: the function `file-local-name' is not known to be defined. Compiling /home/yantar92/Git/org-mode/lisp/ob-python.el... Compiler-macro error for python-syntax-context: (void-function python-syntax--context-compiler-macro) Compiling /home/yantar92/Git/org-mode/lisp/ol-eww.el... In org-eww-store-link: ol-eww.el:76:36:Warning: reference to free variable `eww-data' In end of data: ol-eww.el:182:1:Warning: the function `eww-current-url' is not known to be defined. Compiling /home/yantar92/Git/org-mode/lisp/org-agenda.el... In toplevel form: org-agenda.el:5400:1:Warning: Unused lexical argument `e' In end of data: org-agenda.el:10851:1:Warning: the following functions are not known to be defined: funcall-interactively, window-font-width Compiling /home/yantar92/Git/org-mode/lisp/org-plot.el... In org-plot/gnuplot: org-plot.el:633:4:Warning: `(dump-func (plist-get type :data-dump))' is a malformed function org-plot.el:682:17:Warning: reference to free variable `dump-func' In end of data: org-plot.el:727:1:Warning: the following functions are not known to be defined: seq-group-by, if-let, ignore-error Compiling /home/yantar92/Git/org-mode/lisp/org.el... In org-display-inline-images: org.el:16554:57:Warning: reference to free variable `image-map' In end of data: org.el:21292:1:Warning: the function `make-process' is not known to be defined. Best, Ihor
Re: [WDYT, mini] key h in agenda for quick help
Timothy, thanks! > Greg Minshall writes: > > > having glanced briefly at transient, would it be something with which > > one could, e.g., implement the export menu? > > > > where else in org-mode would you see using it? > > > > (just curiosity.) > > > > cheers, Greg > > This is going to sound really generic, but I think it's a good model for > performing any action that takes options, and bundling related > functionality. The one exception would probably be capturing. > > Off-hand, the export menu is the first thing that comes to mind which > would benefit. If there's nothing else some patches would be better > than a branch, but it's now part of Emacs, so why not make use of it :) > > I feel like other things would come up, but nothing leaps to mind. > > -- > Timothy >
Re: More use of lexical-binding in ox.el
>> Yes: >> >> (push (cons var val) varvals >> varvals))) >> >> should be >> >> (push (cons var val) varvals) >> varvals)) >> >> so that the final `varvals` is outside the `dolist` (it's the thing we >> want to return to store it in the outer `varvals` variable). > > Indeed. I couldn't spot this. Yes, I tried to make it discrete. Sadly, your test suite wasn't fooled, Stefan
Re: [patch] to allow org-attach-git to handle individual repositories
Hi Bastien, Bastien writes: > It looks good but it is significative enough to require you to sign > the FSF copyright assignment. If you're willing to go through this > (which will secure future contributions too), please see: Thanks for the advice. I just signed and sent the FSF copyright assignment. Best regards, Juan Manuel
Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.17.4) of 2021-03-26 Package: Org mode version 9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/) When using org-edit-special to edit inline latex, i.e., equations between \( and \), in an org-mode buffer, a number of spaces may get inserted before \( after the latex editing minibuffer is closed. It seems like the number of extra spaces defaults to the indentation of the line in which the inline math is located. This behavior makes complete sense for code blocks and latex environments, but I can't see a use case in which it should be applied to inline math. It looks like the option to edit inline math with org-edit-special was added only recently, so this could be a bug that noone noticed yet. I looked at the code that does things and it seems the variable that controls the indentation of the parts edited in the minibuffer is a buffer-local variable org-src--preserve-indentation. Setting a default value to it has no effect because it gets overwritten internally in the function org-src--edit-element. There is a variable with a similar name org-src-preserve-indentation that is supposed to set by the user, but it has no effect specifically in the case of latex fragments because org-src--edit-element contains the code: (let* (... (preserve-ind (and (memq type '(example-block src-block)) (or (org-element-property :preserve-indent datum) org-src-preserve-indentation))) ...) ... (setq org-src--preserve-indentation preserve-ind) So the user is only allowed to turn off org-edit-special messing with the indentation if he is an an example-block or src-block. I hacked in a fix modifying org-src--edit-element by replacing (memq type '(example-block src-block)) with (memq type '(example-block src-block latex-fragment)) and setting org-src-preserve-indentation. This seems to have solved the issue, but I believe the function shouldn't even be trying to indent inline math in the first place.
Re: [WDYT, mini] key h in agenda for quick help
Greg Minshall writes: > having glanced briefly at transient, would it be something with which > one could, e.g., implement the export menu? > > where else in org-mode would you see using it? > > (just curiosity.) > > cheers, Greg This is going to sound really generic, but I think it's a good model for performing any action that takes options, and bundling related functionality. The one exception would probably be capturing. Off-hand, the export menu is the first thing that comes to mind which would benefit. If there's nothing else some patches would be better than a branch, but it's now part of Emacs, so why not make use of it :) I feel like other things would come up, but nothing leaps to mind. -- Timothy
Re: [WDYT, mini] key h in agenda for quick help
Timothy, > I actually think Org would benefit from using transient (which has > recently been merged into Emacs), and it could reduce the maintenance > burden, but I suppose that's not possible with our minimum version at > Emacs 24... having glanced briefly at transient, would it be something with which one could, e.g., implement the export menu? where else in org-mode would you see using it? (just curiosity.) cheers, Greg
Re: [PATCH] org-protocol: Fix missing '+' in js snippet
Hi Bastien. On 28/04/2021 12:40, you wrote: Hi Maxim, Would you like to volunteer as the maintainer for org-protocol.el? For now org-protocol.el indicates that Sebastian Rose, the original author, is the maintainer, but I don't think he would mind handing it to someone else. I am proud to get such offer, but I am afraid, it is too early. I do not have enough experience with elisp and emacs. Beware of putting a vimer into maintainer position... Example of my ignorance: I suspect, I did not recognize that apostrophe needs special escaping in doc strings https://orgmode.org/list/s4hsag$ogg$1...@ciao.gmane.io/ Actually, I do not think, org-protocol requires a dedicated maintainer. There are a few things that may be improved, but they should be discussed at first. It seems, all current user already managed to configure their handlers and prefer to not experiment any more. So there is a little interest in this area.
Re: Bug? C-h v in src block since org-9.4
On Wednesday, 28 Apr 2021 at 19:19, Maxim Nikulin wrote: > With org 9.4+ I have to type variable name, no default option is > provided. TAB completion still works. Moreover, after help page for a > variable has been open (even for another one, e.g. > `org-refile-targets'), next time C-h v at the same buffer position > kindly offers `org-refile-use-cache' by default. Maybe something related to autoloading of org? PS - I hope I have fixed my emails so that I no longer break threads? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b
Bug? C-h v in src block since org-9.4
Hi, I am unsure if it is a bug or expected behavior of autoload. Try the following org file in new a "emacs -Q" instance: --- >8 --- #+begin_src elisp (setq org-refile-use-cache t) ;;^- put cursor here and try C-h v #+end_src --- 8< --- With org 9.3.8 I get `org-refile-use-cache' as default option. With org 9.4+ I have to type variable name, no default option is provided. TAB completion still works. Moreover, after help page for a variable has been open (even for another one, e.g. `org-refile-targets'), next time C-h v at the same buffer position kindly offers `org-refile-use-cache' by default. I have noticed this behavior change trying to prepare minimal example for another issue related to org refile cache.
splot and #+PLOT keyword
Hello, a question/problem regarding the #+plot: keyword. I am trying to plot out some data where the table looks like this: #+begin_src org ,#+plot: ind:(6 7) deps:(1) with:"linespoints pt 7" set:"logscale xy" type:3d | 1 | 81 | 5 | 0 | 2.27 | 0.9729848950975623 | 0.019370016994566613 | 0.0 | | 2 | 179 | 12 | 2 | 3.68 |0.42919355355596267 | 0.098179980500945 | 0.0 | | 3 | 192 | 6 | 4 | 3.73 | 0.022272788298562045 | 107.57399021086516 | 0.0 | | 4 | 207 | 7 | 8 | 3.78 | 5.793210638997738 | 0.0012069891001225872 | 0.0 | | 5 | 194 | 10 | 12 | 3.83 |0.06356594000544429 | 0.04724965431965522 | 0.0 | | 6 | 216 | 8 | 14 | 3.89 |0.06342050747033937 | 0.0030380306687021346 | 0.0 | | 7 | 193 | 7 | 18 | 3.94 | 0.0021538841210584 | 0.05771587421360767 | 0.0 | | 8 | 193 | 7 | 19 | 3.99 | 0.0010739216097561438 | 0.10625133051680691 | 0.0 | | 9 | 182 | 6 | 19 | 4.04 | 0.0014893478573963876 | 0.03593357278451856 | 0.0 | |10 | 192 | 6 | 21 | 4.10 | 0.013251328328567616 | 0.0006605631984014402 | 0.0 | #+end_src I have tried a variety of directives for the #+PLOT: keyword but none give me what I want. I would like to plot column 1 (dependent variable) versus columns 6 and 7 (independent variables) in 3d. (don't ask ;-)) I have also tried: #+plot: ind:6 deps:(7 1) ... but in all cases I seem to be getting somewhat random data plotted, possibly columns 2 versus 3 and 4, which makes no sense except that maybe the "|" table column separator is being retained in the data file created. Is there any way to stop the data file from being deleted after plotting? I can inspect the *gnuplot* buffer but cannot see the actual data. 2d plots work just fine, by the way. thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b
[PATCH] fix point position shifting in some org-src instances
Hi All,
I've noticed for a while that if you have a block with
overlays/invisible characters that editing it with `org-edit-special'
moves the point around.
For example, with Org pretty entities enabled, and █ indicating the
cursor, if I call org-edit-special on a LaTeX fragment like:
\( \alpha +█\beta \)
which is displayed as \( α +█β \)
The point is moved on creation of the org-src buffer
\( \alpha + \beta █\)
Then if I move it back to after the "+", on calling `org-edit-src-exit'
the point is moved to
\(█ \alpha + \beta \)
In the original buffer.
This may seem quite minor, but if you're editing a lot of LaTeX
fragments having the point constantly jumping around can be quite a
pain.
After investigating this, I tried shifting org-src--{goto-}coordinates
to a point-based approach from a column-based approach, and it seems to
have fixed the problem.
I have tested a few other situations (e.g. LaTeX environments, example
blocks, src blocks), and it seems to work well.
--
Timothy
>From 8e8faf389d6d5c0769b5f95775ec7883820b10b3 Mon Sep 17 00:00:00 2001
From: TEC
Date: Wed, 28 Apr 2021 18:17:00 +0800
Subject: [PATCH] org-src: Use point instead of column for coords
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/org-src.el (org-src--coordinates, org-src--goto-coordinates):
Using a column-based approach fails to account for invisible regions
or display overlays that change the number of columns: for example,
showing a LaTeX \alpha as α. In src edits which involve such
structures, this causes the point to be shifted undesirably.
By using a point-based approach this issue does not occur.
---
lisp/org-src.el | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lisp/org-src.el b/lisp/org-src.el
index cabedecb6..a694e5595 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -327,8 +327,7 @@ (defun org-src--coordinates (pos beg end)
(cons (count-lines beg (line-beginning-position))
;; Column is relative to the end of line to avoid problems of
;; comma escaping or colons appended in front of the line.
- (- (current-column)
- (progn (end-of-line) (current-column)))
+ (- (point) (min end (line-end-position)))
(defun org-src--goto-coordinates (coord beg end)
"Move to coordinates COORD relatively to BEG and END.
@@ -341,9 +340,9 @@ (defun org-src--goto-coordinates (coord beg end)
(org-with-wide-buffer
(goto-char beg)
(forward-line (car coord))
- (end-of-line)
- (org-move-to-column (max (+ (current-column) (cdr coord)) 0))
- (point)
+ (max (point)
+ (+ (min end (line-end-position))
+ (cdr coord)))
(defun org-src--contents-area (datum)
"Return contents boundaries of DATUM.
--
2.31.1
Re: More use of lexical-binding in ox.el
Hello, Stefan Monnier writes: > That's because the "buffer copy" also copies the local vars, For some reason, I misread the code and thought `buffer-file-name' and `default-directory' were explicitly ignored. Go figure. > Yes: > > (push (cons var val) varvals > varvals))) > > should be > > (push (cons var val) varvals) >varvals)) > > so that the final `varvals` is outside the `dolist` (it's the thing we > want to return to store it in the outer `varvals` variable). Indeed. I couldn't spot this. I applied your patch. Thank you! Regards, -- Nicolas Goaziou
bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
Hi,
On 2021-04-27, 22:21 +0200, Nicolas Goaziou wrote:
>> + When using org-table-import interactively if we failed to guess
>> separator then we will be left with a user-error message and an
>> 'unconverted table'. We can make use of 'temp-buffer' to import our
>> file after successfully conversion.
>
> I'm not sure to understand what you mean.
Note: I will advice you to apply patch no. 2 before trying out the
following example.
1. Download the attached CSV file. We can call this example.csv
2. Go to *scratch* buffer.
3. Use 'M-x org-table-import' to import example.csv as org-table.
You will see even thought org-table-guess-separator failed in guessing
separator we are still left with unconverted region added to our buffer.
>> + Conversion part of org-table-convert-region make a distinction between
>> '(4) (comma separator) and rest of the separator we should either string
>> version of comma as AND condition or rewrite to simplify it.
>
> Ditto. But it can be the object of another patch. Let's concentrate on
> `org-table-guess-separator' first.
>
>> I am willing to do these possible changes but currently waiting for your
>> review for org-table-guess-separator as there can be more serious bugs
>> lurking around on my code which I am considering base for these
>> changes.
>
> You should definitely write tests for this function. Here's a start:
>
> (ert-deftest test-org-table/guess-separator ()
> "Test `test-org-table/guess-separator'."
> ;; Test space separator.
> (should
>(equal " "
> (org-test-with-temp-text "a b\nc d"
> (org-table-guess-separator (point-min) (point-max)
> (should
>(equal " "
> (org-test-with-temp-text "a b\nc d"
> (org-table-guess-separator (point-min) (point-max)
> ;; Test "inverted" region.
> (should
>(equal " "
> (org-test-with-temp-text "a b\nc d"
> (org-table-guess-separator (point-max) (point-min)
> ;; Do not error on empty region.
> (should-not
>(org-test-with-temp-text ""
> (org-table-guess-separator (point-max) (point-min
> (should-not
>(org-test-with-temp-text " \n"
> (org-table-guess-separator (point-max) (point-min)
>
I will surely do more testing.
I would also like to simplify the condition for guessing SPACE as
separator due to following cases:
+ field1 'this is field2' 'this is field3' :: In this case we still have
SPACE inside quote (' in this case).
+ Since SPACE is our last valid separator I think searching for a line
which doesn't contains space is more than enough.
Required patch:
>From 6b112927de73c43edfd08254217808ebff42772a Mon Sep 17 00:00:00 2001
From: Utkarsh Singh
Date: Wed, 28 Apr 2021 10:26:46 +0530
Subject: [PATCH 1/3] org-table.el (org-table-import): add yes-and-no prompt
Add a yes and no prompt for files which don't have .txt, .tsv OR .csv
as file extensions.
---
lisp/org/org-table.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lisp/org/org-table.el b/lisp/org/org-table.el
index 0e93fb271f..e0b2be6892 100644
--- a/lisp/org/org-table.el
+++ b/lisp/org/org-table.el
@@ -938,7 +938,8 @@ org-table-import
- regexp When a regular expression, use it to match the separator."
(interactive "f\nP")
(when (and (called-interactively-p 'any)
- (not (string-match-p (rx "." (or "txt" "tsv" "csv") eos) file)))
+ (not (string-match-p (rx "." (or "txt" "tsv" "csv") eos) file))
+ (not (yes-or-no-p "File does not have .txt, .tsv or .csv as extension. Do you still want to continue? ")))
(user-error "Cannot import such file"))
(unless (bolp) (insert "\n"))
(let ((beg (point))
--
2.31.1
>From 9bb017cfc8284075e04faf5496ed560ba48d5bbc Mon Sep 17 00:00:00 2001
From: Utkarsh Singh
Date: Wed, 28 Apr 2021 10:42:32 +0530
Subject: [PATCH 2/3] org-table.el (org-table-convert-region): move out
separator-guessing
1. Move separator guessing code to org-table-guess-separator (new
function).
2. Add semicolon, colon and SPACE to the list of know separator
(separator which we can guess).
---
lisp/org/org-table.el | 49 +--
1 file changed, 38 insertions(+), 11 deletions(-)
diff --git a/lisp/org/org-table.el b/lisp/org/org-table.el
index e0b2be6892..295f7a9b90 100644
--- a/lisp/org/org-table.el
+++ b/lisp/org/org-table.el
@@ -846,6 +846,39 @@ org-table-create
(goto-char pos))
(org-table-align)))
+(defun org-table-guess-separator (beg0 end0)
+ "Guess separator for region BEG0 to END0.
+
+List of preferred separator (in order of preference):
+comma, TAB, semicolon, colon or SPACE.
+
+Search for a line which doesn't contain a separator if found
+search again using next preferred separator or else return
+separator as string."
+ (let* ((beg (save-excursion
+(goto-char (min beg0 end0))
+
bug#45915: 27.2; deletechar distorts org-table
>> I confirm that there still is following problem on 27.1.91. >> Could someone take a look and show me work around? > > I cannot reproduce this with latest Org stable version 9.4.5. > > Can you try again and report? I downloaded Org 9.4.5 and reproduced the problem on 26.3, 27.2, and 28.0.50. Here is a recipe again. > On certain condition, typing distorts alignment of > a table. Then, typing moves point to previous line but far > right position (column 14 instead of column 2). > > | | rownames | | | rownames | > | / | | | / | | > |---+--| -> |---+--| > | / | a| | | a| > > Here is a recipe to reproduce the glitch started from emcas -Q. > > 1. Create a buffer with (text-mode) and yank following table. > > | | rownames | > | / | | > |---+--| > | | a| > > 2. (progn (require 'org) (call-interactively 'orgtbl-mode)) > 3. Move point to the first column and the third line with letter 'a'. > 4. Hit . > 5. Hit . > 6. Hit .
Re: [Patch] to correctly sort the items with emphasis marks in a list
Bastien writes: > Thanks for the heads-up. I reverted the commit. Please go ahead with > whatever you see fit. PS: Re-opening this work-in-progress patch for updates.orgmode.org. -- Bastien
Re: Plea for reviews/action on my Patches
Thanks for getting back to me on this Bastien :) Bastien writes: > I suggest you rather bump them individually: sending such a digest > will scatter the discussion in separate places. (I'm raising some > points below, but please follow-up in the upstream thread.) I have responded to your point in the relevant threads, where appropriate. > [Fontification] See original threads for a response. > You're the maintainer, please go ahead. > Dismissed. > Done. > Done. 4 resolved just like that, great! > [Major modes] > [$$ in markdown] Will respond in-thread. >> I also have some more patches lined up, and I'd rather my number of >> unresolved patches stayed out of the double digits. > > Let's focus on all the help requests and issues: the more free time > you liberate from the core maintainers, the more free time they will > have on dealing with new stuff (I'm stating the obvious, sorry.) Don't worry, I don't /just/ pump out new features for maintainers to review :P. My next two patches I anticipate being bugfixes actually :) I will confess that after that I do have more "new stuff", but hopefully I'll be able to reduce the workload somewhat in my new role as a contributor steward. -- Timothy
Re: [PATCH 2/3] org-protocol.el: Fix detection of old-style URIs
Applied in maint, thanks! -- Bastien
Re: [PATCH] Add font-lock rule for inline export snippets
Timothy writes: > Hello, > > The latest in my visually-oriented (mostly) short patch series, adding > basic fontification to inline export snippets --- @@comment:these things@@. > > I think fontification for stuff like this is nice because it visually > indicates to the user that they've written out an Org construct, and > haven't just mis-remembered / imagined some syntax. > > In future this could be extended to use native fontification for > recognised export formats (like src blocks do), but I think this is a > nice improvement over nothing. This addition to the font-lock regexps is quite simple, and doesn't contain anything fancy/expensive (like backtracking), so I don't expect there to be any performance concerns --- but it would be good to hear from others :) I considered limiting this to no-newlines, but https://orgmode.org/worg/dev/org-syntax.html says anything other than @@ is allowed. -- Timothy
Re: [PATCH 3/3] test-org-protocol.el: Add expected failures for file:/// URLs
Applied as 3dbeb677e in master, thanks. Maxim Nikulin writes: > * 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. -- Bastien
Re: [PATCH] Fontification for inline src blocks
Timothy writes: > Hi All, > > I've been using inline src blocks a fair bit more recently, and I've > thought it's a pity how bad they look as they are currently without > fontification. A little digging into Org internals and font-lock later > and we have this patch. I could speak about what's been done, but I > think a screenshot does a much better comparison. > > For more details, see the attached patch. Since this affects font-lock, display performance is obviously a key concern, and so I have two things to note on that front: 1. I have been using this patch for over a month at this point, frequently in a ~10k line Org file (my Emacs config), and there has been no noticeable performance degradation 2. The most expensive part of this is the native syntax highlighting, which is only used when `org-src-fontify-natively' is t, and the second most expensive part (results formatting) is only performed when `org-inline-src-prettify-results' (a new variable) is t. In brief: I don't anticipate any significant performance implications of this patch, though of course second opinions would be great :) -- Timothy
Re: [PATCH 1/3] test-org-protocol.el: Fix the case for parse parameters with complex argument
Applied in maint, thanks and sorry for the slow reply. Maxim Nikulin writes: > * 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. -- Bastien
Re: [Patch] to correctly sort the items with emphasis marks in a list
Nicolas Goaziou writes: > Unfortunately, this is not a proper fix for the problem, as discussed in > the thread. Thanks for the heads-up. I reverted the commit. Please go ahead with whatever you see fit. -- Bastien
Re: Plea for reviews/action on my Patches
Hi Timothy, Timothy writes: > This is a very me-centric email Hehe. > but I've got a collection patches that > have received little attention (1 of the past 9 patches I've submitted > has been reviewed by a core contributor, 6 have zero replies). I care > about them, and I think it would be good if they were looked at. As a newly appointed contributor steward, together with Tim and John, you are of course welcome bumping your own threads ;-} I suggest you rather bump them individually: sending such a digest will scatter the discussion in separate places. (I'm raising some points below, but please follow-up in the upstream thread.) > So, I'm going to list those patches here, organised by topic. > > * Rendering in/of Org buffers > > - [PATCH] Fontification for inline src blocks (Mar 31) > https://orgmode.org/list/87pmzf4bd0@gmail.com/ > > - [PATCH] Add font-lock rule for inline export snippets (Mar 31) > https://orgmode.org/list/87im57fh8j@gmail.com/ Let's be extra careful for anything that touches fontification: did you check the patch was not slowing the display? How efficient is it with many inline blocks? Can we turn this off if we don't use inline blocks at all? > - [PATCH] Refresh inline plotted images, org-plot (Apr 24) > https://orgmode.org/list/87r1j0mg56@gmail.com/ You're the maintainer, please go ahead. > * Documentation > > - [PATCH] Improve documentation of #+startup keyword (Mar 19) > https://orgmode.org/list/874kh72vrl@gmail.com/ Dismissed. > * Exporting > > - [PATCH] tweaks to ox-html style (Jan 20) > https://orgmode.org/list/87turbj2nu@gmail.com/ > This is commented on a fair bit, but unresolved. > If the CTAGS stuff is contentious I'd rather that's > just ignored and the rest is merged. Done. > - [PATCH] Use tags for SVGs (Apr 7) > https://orgmode.org/list/87k0pemj6d@gmail.com/ Done. > - [PATCH] avoid loading major modes when exporting to file (Mar 31) > https://orgmode.org/list/87lfa3fips@gmail.com/ Can you make sure loading major modes while exporting is *never* needed? My gut feeling is that it is, sometimes. Also I suggest Nicolas should be the one to validate such a patch. > - [PATCH] Wrap LaTeX snippets in $$ with markdown export (Apr 1) > https://orgmode.org/list/87ft0bff7q@gmail.com/ I'll let Nicolas decide about this one too. > I also have some more patches lined up, and I'd rather my number of > unresolved patches stayed out of the double digits. Let's focus on all the help requests and issues: the more free time you liberate from the core maintainers, the more free time they will have on dealing with new stuff (I'm stating the obvious, sorry.) Thanks! -- Bastien
Re: [Patch] to correctly sort the items with emphasis marks in a list
Hello, Bastien writes: > Juan Manuel Macías writes: > >> Done! I've attached the corrected patch. Sorry for the flaws in me >> previous patch: I'm a bit of a novice at submitting patches... > > applied in the maint branch as commit 5be650714. Unfortunately, this is not a proper fix for the problem, as discussed in the thread. Regards, -- Nicolas Goaziou
Re: [PATCH]
Hi Timothy, Timothy writes: > Bastien writes: > >> Feel free to install changes when they have reached consensus, >> or to ask for decisions when not. > > Thanks for the reply Bastien, would you mind elaborating on this a bit > more? I'm comfortable with the idea of what I can do with org-plot.el as > the maintainer (directly push, but field patches to the ML for > non-trivial changes), but as a non-core-contributor I didn't think I > could push my own patches for other things. Regular contributors can commit patches themselves whenever the maintainers say so. > Also, with the batch of patches I sent a plea about recently, how would > you recommend I proceed with that? There doesn't seem to be any > consensus or decision despite prompting. Perhaps that's because such plea contains too many different issues. I will reply there. Thanks, -- Bastien
Re: [PATCH]
Hi Timothy,
TEC writes:
> This is just some tweaks to the styling in ox-html that I think may
> appeal (and prevent ridiculously long lines on non-small displays, which
> are an issue for legibility).
>
> I also took the opportunity to remove the (obsolete) CDATA strings and
> make the CSS more consistently formatted. If you don't want this to
> get its own commit, please just squash it.
>
> Style changes:
> - Restrict max content width, and centre
> - tweak styling of source code blocks
>
> I took some screenshots (1440p monitor, 120% zoom, Firefox).
> Current: https://0x0.st/-iW9.png
> This patch: https://0x0.st/-iWp.png
Thanks for these patch. I've applied most of them, sometimes updating
the changelog entries -- in particular,
* lisp/ox-html.el (org-html-scripts, org-html-style-default,
^^^
This should be:
* lisp/ox-html.el (org-html-scripts, org-html-style-default)
^^^
Fill-paragraph in change-log-mode should do the right thing.
I've not applied the change about moving from
{
... : ...
}
to
{
... : ... }
As I think the former looks more consistent.
Thanks!
Re: [WDYT, mini] key h in agenda for quick help
Bastien writes: > Timothy writes: > >> Great to hear! I think this would probably be developed as a branch like >> wip-cite-new > > Yes. > >> , and it would need transient to be installed (via ELPA?) on >> Emacs <28, but I think it has the potential to both: >> - Improve the user experience, and >> - Remove Org's own home-cooked transient-ish interfaces, >>so leave us with less code to watch over > > Yes, exactly. Also there is plan to include Transient in Emacs core, > so this makes this move even more appealing: > > https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00944.html I would also suggest that if we were going to have a 'help' key, rather than describe mode, it might be better to link to the info manual (you could just link to the agenda section of the manual). I've rarely found describe mode to be terribly useful (there are exceptions). However, I have used modes which have bound a help key to a section in the info manual and I've found that much more useful. The depth of information is usually better (what people looking for help probably want) and once your in the info pages, moving to cross references and other possibly relevant sections is very easy. I also think adding transient mode would be beneficial in a number of areas of org. In addition to reducing code maintenance, it would increase consistency with other Emacs modes etc. -- Tim Cross
Re: org agenda bug — diary-sexp-entry-symbol is not respected
Hi Joe, Joe Corneli via "General discussions about Org-mode." writes: > The string "%%" is hard coded here as a date prefix: > https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-agenda.el#L5648 > > Shouldn’t this be diary-sexp-entry-symbol to allow local overrides, > etc.? Yes -- also in other places. Could you provide a patch for this?
bug#45915: 27.1.91; deletechar distorts org-table
Tak Kunihiro writes: > I confirm that there still is following problem on 27.1.91. > Could someone take a look and show me work around? I cannot reproduce this with latest Org stable version 9.4.5. Can you try again and report? See https://orgmode.org/org.html#Installation on how to install using Org’s git repository if you want to try the latest version.
