Re: A mobile clocking solution?
On 2021-11-21, at 15:25, Daniel Baker wrote: > Hi Marcin, > > There's an open pull request on github that has a working implementation > for clocking in and out. There's a few ui things to fix. I'm running that > branch at the moment and it works quite well. Thanks, but... which app are you talking about? -- Marcin Borkowski http://mbork.pl
Re: bulk archive slow
thank you! bulk archiving will be among the first things i will try once i upgrade. i have years[?] of doneified tasks now i think. i always use maint, with my own few patches rebased on top, so not sure if i can take advantage of it, except to run main to do it. still will be highly useful. i ahve kept these improvements to bulk archving in mind as i consier upgrading. this brings up a tangential question. what was the reasoning behind changing maint to bugfix and master to main? On 11/23/21, Ihor Radchenko wrote: > Samuel Wales writes: > >> in recent maint, bulk archive is slow for me. not a huge deal but >> org-element--current-element takes up 92 percent of cpu time in >> profiler. 6 entries took a few minutes. this is just a heads up in >> case anybody can confirm. > > Just a note that bulk archiving should be a lot faster on latest main. > > Best, > Ihor > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: org-sort random
if random sorting of siblings is useful, another entry in the sorting menu, dedicated to it, would eliminate any issues with completion. it is a clever idea to feed random to sort by function. maybe some won't catch the connection. just a possibility. not trying to bloat. On 11/23/21, Vikas Rawal wrote: >> >> >> I think that depends on the completion framework. With the default >> completion, yes, I think RET should do it. With ivy, it's instead >> ivy-immediate-done (C-M-j). I'm not sure offhand about other >> frameworks. >> >> > That's what it needed. Thanks. > > I wonder if there would be a better way to document this somewhere so that > people using different completion frameworks could figure out how to do it. > It seems to be something that would be useful to others. > > Thanks again > > Vikas > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] Fix regex for determining image width from attribute
Max Nikulin writes: > I may be wrong, but it seems both the old and the new regexps match > > #+attr_html : :width 50% > > that is not a keyword due to a space before ":". The dot in the regexp > is too permissive. I agree. > Despite ".*" includes ": " before ":width", I would prefer explicit > space before ":width". Currently we have a space before .*. Would you prefer it after? Anyway, I've also implemented this change. Let me know what you think. Matt >From 76a0c05cec8e449efd5cbffd8123338912815f17 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Mon, 22 Nov 2021 23:28:48 -0800 Subject: [PATCH 1/2] org.el: Prioritize attr_org when computing image width * lisp/org.el (org-display-inline-image--width): First look for attr_org: :width and then look for another attr_.* :width when that isn't specified. --- lisp/org.el | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 308bb7d51..5f9d120a2 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16853,13 +16853,20 @@ buffer boundaries with possible narrowing." ((listp org-image-actual-width) (let* ((case-fold-search t) (par (org-element-lineage link '(paragraph))) - (attr-re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)") + (attr-re (lambda (backend) + (concat "^[ \t]*#\\+attr_" + backend + ":+.*? :width +\\(\\S-+\\)"))) (par-end (org-element-property :post-affiliated par)) - ;; Try to find an attribute providing a :width. + ;; If an attr_org provides a :width, use that. Otherwise, + ;; use the first attribute that provides it, if any. (attr-width (when (and par (org-with-point-at (org-element-property :begin par) - (re-search-forward attr-re par-end t))) + (or (re-search-forward (funcall attr-re "org") +par-end t) + (re-search-forward (funcall attr-re "[a-z]*?") +par-end t (match-string 1))) (width (cond -- 2.31.1 >From 0bc320b895ffb80a2a3ca8fb494e0aabe76180a3 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Mon, 22 Nov 2021 23:30:11 -0800 Subject: [PATCH 2/2] org.el: Clarify documentation for computing image width * lisp/org.el (org-display-inline-image--width) (org-image-actual-width): Specify documentation for computing an inline image width in org-image-actual-width and remove the redundant documentation from org-display-inline-image--width. --- lisp/org.el | 38 -- 1 file changed, 24 insertions(+), 14 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 5f9d120a2..37369cdb6 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15529,10 +15529,29 @@ When set to a number in a list, try to get the width from any and fall back on that number if none is found. -When set to nil, try to get the width from an #+ATTR.* keyword -and fall back on the original width if none is found. - -When set to any other non-nil value, always use the image width. +When set to nil, first try to get the width from #+ATTR_ORG. If +that is not found, use the first #+ATTR_.*:width specification. +If that is also not found, fall back on the original image width. + +Finally, org is quite flexible in the width specifications it +supports and intelligently interprets width specifications for +other backends when rendering an image in an org buffer. This +behavior is described presently. + +1. A floating point value is interpreted as the percentage of the text + area that should be taken up by the image. +2. A number followed by a percent sign is divided by 100 and then + interpreted as a floating point value. +3. If a number is followed by other text, extract the number and + discard the remaining text. That number is then interpreted as a + floating-point value. For example, + + #+ATTR_LATEX: :width 0.7\\linewidth + + would be interpreted as 70% of the text width. +4. If t is provided the original image width is used. This is useful + when you want to specify a width for a backend, but still want to + use the original image width in the org buffer. This requires Emacs >= 24.1, built with imagemagick support." :group 'org-appearance @@ -16838,16 +16857,7 @@ buffer boundaries with possible narrowing." (defvar visual-fill-column-width) ; Silence compiler warning (defun org-display-inline-image--width (link) "Determine the display width of the image LINK, in pixels. -- When `org-image-actual-width' is t, the image's pixel width is used. -- When `org-image-actual-width' is a number, that value will is used. -- When `org-image-actual-width' is nil or a list, the first :width attribute -
Re: org-sort random
i have found or would find random line within buffer or region to be useful, and also random entry in org agenda files. i'd find this useful too, but i think i'd find it more useful to keep the ordering the same but instead go to a random entry within region. On 11/23/21, Samuel Wales wrote: > if random sorting of siblings is useful, another entry in the sorting > menu, dedicated to it, would eliminate any issues with completion. > > it is a clever idea to feed random to sort by function. maybe some > won't catch the connection. just a possibility. not trying to bloat. > > On 11/23/21, Vikas Rawal wrote: >>> >>> >>> I think that depends on the completion framework. With the default >>> completion, yes, I think RET should do it. With ivy, it's instead >>> ivy-immediate-done (C-M-j). I'm not sure offhand about other >>> frameworks. >>> >>> >> That's what it needed. Thanks. >> >> I wonder if there would be a better way to document this somewhere so >> that >> people using different completion frameworks could figure out how to do >> it. >> It seems to be something that would be useful to others. >> >> Thanks again >> >> Vikas >> > > > -- > The Kafka Pandemic > > Please learn what misopathy is. > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [BUG] org-element--cache: Cache corruption [9.5, (release_9.5-255-g54da1d @, c:/Users/micha/AppData/Roaming/.emacs.d/org-new/org-mode/lisp/)]
Hello, I pulled the latest this evening. I expect we'll be fine. I wish all packages were as well-behaved as org. Thanks. mp On 11/22/2021 06:42, Ihor Radchenko wrote: Michael Powe writes: Error message: "Warning (emacs): org-element--cache: Cache corruption detected in emacs-config-prog-modes.org. Resetting. The error was: (error "rx ‘**’ range error") Backtrace: nil Please report this to Org mode mailing list"" Done. Thanks! After 17d4b31a8, you should hopefully not see this error. I am not 100% sure though. Please, followup on this thread if you keep seeing the same rx range error after update to latest main. Best, Ihor -- "Do not neglect to do good, and to share what you have." - Hebrews 13:16a Michael Powe Naugatuck CT USA po...@ctpowe.net
[PATCH] org.el: Warning for unsupported markers in `org-set-emphasis-alist'
On 21/11/2021 17:01, Ihor Radchenko wrote:
Max Nikulin writes:
My draft version is attached. Ihor, thank you for inspiration. Feel free
to improve it. I hope, it makes problem more apparent to user who tries
to customize markers.
A patch is attached. I have dropped changes in documentation since I am
not the author of them.
For init file (entries may be in arbitrary order)
(custom-set-variables
'(org-emphasis-alist
(quote
(
("*" bold)
("_" underline)
("=" org-verbatim verbatim)
("/" italic)
("~" org-code verbatim)
("!" org-todo) ;; does not work
("+" (:strike-through t)
)
emacs --eval "(customize-variable 'org-emphasis-alist)"
looks as the following
Hide Org Emphasis Alist:
[INS] [DEL] :
Marker: [Value Menu] *Bold*
Font: [Value Menu] Face: (sample) bold
[ ] verbatim
[INS] [DEL] :
Marker: [Value Menu] _Underline_
Font: [Value Menu] Face: (sample) underline
[ ] verbatim
[INS] [DEL] :
Marker: [Value Menu] =Verbatim=
Font: [Value Menu] Face: (sample) org-verbatim
[X] verbatim
[INS] [DEL] :
Marker: [Value Menu] /Italic/
Font: [Value Menu] Face: (sample) italic
[ ] verbatim
[INS] [DEL] :
Marker: [Value Menu] ~Code~
Font: [Value Menu] Face: (sample) org-code
[X] verbatim
[INS] [DEL] :
Marker: [Value Menu] Unsupported ignored character: !
Font: [Value Menu] Face: (sample) org-todo
[ ] verbatim
[INS] [DEL] :
Marker: [Value Menu] +Strike-through+
Font: [Value Menu] Property list:
[INS] [DEL] :
Key: :strike-through
Value: t
[INS]
[ ] verbatim
[INS]
[ State ]: SAVED and set.
>From 1ee52f7ffc1039fd442775e9267403f1dca86b88 Mon Sep 17 00:00:00 2001
From: Max Nikulin
Date: Mon, 22 Nov 2021 23:56:15 +0700
Subject: [PATCH] org.el: Warning for unsupported markers in
`org-set-emphasis-alist'
* lisp/org.el (org-emphasis-alist, org-set-emphasis-alist): Change
custom variable type definition and add :set parameter to warn users
that non-standard marker characters are ignored.
Attempts to introduce new markers have been discussed enough times to
add some code that should prevent wasting of time.
Unfortunately there is no way to issue warning for e.g. `setq'.
---
lisp/org.el | 47 +--
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index df3d139c7..1a65b6db8 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3771,6 +3771,25 @@ newline The maximum number of newlines allowed in an emphasis exp.
You need to reload Org or to restart Emacs after setting this.")
+(defun org-set-emphasis-alist (var value)
+ "Set VAR (`org-emphasis-alist') to VALUE and check it for ignored characters.
+Warn user that Org syntax can not be extended with new emphasis markers
+if such attempt is detected. The function is intended for :set argument
+of `defcustom'."
+ (set var value)
+ (let ((unsupported
+ (delq nil
+ (mapcar
+(lambda (entry)
+ (let ((marker (car entry)))
+(unless (member marker '("*" "/" "_" "=" "~" "+")) marker)))
+value
+(when unsupported
+ (message "Warning! Unsupported markup characters '%s' detected in `%s'"
+ (mapconcat #'identity unsupported " ")
+ (symbol-name var
+ value)
+
(defcustom org-emphasis-alist
'(("*" bold)
("/" italic)
@@ -3784,18 +3803,34 @@ for example *bold*, _underlined_ and /italic/. This variable sets the
marker characters and the face to be used by font-lock for highlighting
in Org buffers.
+Do not change the characters and do not add new ones to use custom
+markers for existing styles or to introduce new styles. Org syntax is
+not meant to be configurable and such modifications will not work with
+export.
+
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")
+ :set #'org-set-emphasis-alist
:type '(repeat
- (list
- (string :tag "Marker character")
- (choice
- (face :tag "Font-lock-face")
- (plist :tag "Face property list"))
- (option (const verbatim)
+ (group
+ (choice
+:tag "Marker"
+(const :tag "*Bold*" "*")
+(const :tag "/Italic/" "/")
+(const :tag "_Underline_" "_")
+(const :tag "+Strike-through+" "+")
+(const :tag "=Verbatim=" "=")
+(const :tag "~Code~" "~")
+;; To warn users that it does not work.
+(string :tag "Unsupported
Dired images in an Org buffer
Hi, I don't like image-dired thumbnails, so I wrote this function to preview all images in a directory in an Org buffer. I share it here, in case it is useful to someone: #+begin_src emacs-lisp (defun my-org-img-dired-preview () (interactive) (if (not (derived-mode-p 'dired-mode)) (error "not in dired") (let* ((dir-name default-directory) (buf (concat "*" dir-name "--images *"))) (setq my-img-dired-list nil) (save-excursion (goto-char (point-min)) (while (re-search-forward "\\.png\\|\\.jpg\\|\\.tif" nil t) (let* ((img-path (dired-get-filename))) (add-to-list 'my-img-dired-list img-path t (when (get-buffer buf) (kill-buffer buf)) (get-buffer-create buf) (set-buffer buf) (org-mode) (let ((img-list (mapconcat (lambda (el) (let ((link (concat "[[file:" el "]]"))) link)) my-img-dired-list "\n\n")) (img-num (number-to-string (length my-img-dired-list (insert (concat "* Images in " dir-name "\n\n")) (insert (concat img-num " files:\n\n")) (insert img-list) (org-toggle-inline-images)) (pop-to-buffer buf) (beginning-of-buffer (with-eval-after-load 'dired (define-key dired-mode-map (kbd "P") 'my-org-img-dired-preview)) #+end_src Best regards, Juan Manuel
Re: [PATCH] Fix regex for determining image width from attribute
On 23/11/2021 14:46, Matt Huszagh wrote: Here are two patches that prioritize attr_org over other attr_ keywords. I believe this is what you had in mind Timothy. But let me know if not. diff --git a/lisp/org.el b/lisp/org.el index 308bb7d51..bf5d08e09 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16853,13 +16853,20 @@ buffer boundaries with possible narrowing." ((listp org-image-actual-width) (let* ((case-fold-search t) (par (org-element-lineage link '(paragraph))) - (attr-re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)") + (attr-re (lambda (backend) + (concat "^[ \t]*#\\+attr_" + backend + ": +.*?:width +\\(\\S-+\\)"))) (par-end (org-element-property :post-affiliated par)) - ;; Try to find an attribute providing a :width. + ;; If an attr_org provides a :width, use that. Otherwise, + ;; use the first attribute that provides it, if any. (attr-width (when (and par (org-with-point-at (org-element-property :begin par) - (re-search-forward attr-re par-end t))) + (or (re-search-forward (funcall attr-re "org") +par-end t) + (re-search-forward (funcall attr-re ".*?") +par-end t I may be wrong, but it seems both the old and the new regexps match #+attr_html : :width 50% that is not a keyword due to a space before ":". The dot in the regexp is too permissive. The second patch (intended to be applied after the first) improves the documentation. It describes behavior that wasn't previously documented and removes redundant documentation between org-image-actual-width and org-display-inline-image--width (now only in org-image-actual-width). Please double check I got everything correct, as I haven't used all this behavior myself. +that is not found, use the first #+ATTR_.*:width specification. Despite ".*" includes ": " before ":width", I would prefer explicit space before ":width".
Re: insert automatically a reference to a section header and a link
On Wed, Nov 17, 2021 at 12:18 PM Uwe Brauer wrote: > > I type "As we have seen in section [[*Intro]]" (literally, I tend to > > not use any keybindings or function to insert the link). This (the > > "*Intro" inside double square brackets) is called an internal link to > > headlines and they are a default feature of Org: > > Yes, but, what do you do, if you have a 10 header and each has 20 > subheaders. How do you remember all these names? Seems like completion could help, either at point, or with completing-read? I've been playing a bit with something using the latter, and it's not alway so straightforward how to do this given the flexibility of org, but here's what it looks like using the Emacs 28 grouping support and Emacs 27 annotation support: https://raw.githubusercontent.com/bdarcus/oxr/main/images/oxr-insert.png Bruce
Re: org-sort random
> > > I think that depends on the completion framework. With the default > completion, yes, I think RET should do it. With ivy, it's instead > ivy-immediate-done (C-M-j). I'm not sure offhand about other > frameworks. > > That's what it needed. Thanks. I wonder if there would be a better way to document this somewhere so that people using different completion frameworks could figure out how to do it. It seems to be something that would be useful to others. Thanks again Vikas
Re: [PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
>> I am not sure if "Org *10*.0" is a good general example. It is probably >> one of those cases when users want fine control over emphasis and must >> use zero width space. > > This is simply the first example that crossed my mind. My point is that > changing the regexp substantially may not be rewarding, ultimately. Agree. At least not until we find a clearly better variant. Yet, I do not like the current state of things. Especially with regards to mixing emphasis and hidden parts of links. Situations like in /A link [[https://orgmode.org/?oops=true][Org Mode]] or like reported in https://list.orgmode.org/orgmode/87pmtqp79s@web.de/ can be very hard to notice and cause "mysterious" Org failures. >> +Sometimes, when marked text also contains the marker character itself, >> +the result may be unsettling. For example, [ 8 more citation lines. Click/Enter to show. ] >> + >> +#+begin_example >> +/One may expect this whole sentence to be italicized, but the >> +following ~user/?variable~ contains =/= character, which effectively >> +stops emphasis there./ >> +#+end_example >> + >> +You can use zero width space to help Org sorting out the ambiguity. >> +See [[*Escape Character]] for more details. > > LGTM! Applied. Best, Ihor
Re: [PATCH] Fontification for inline src blocks
Hi Timothy,
Sorry for my stupid question. I have figured out the problem is not
relevant to
your work and I have fixed it. I'm really looking forward to your org-mode
asynchronous fragment compilation.
All the best,
VitalyR
On Tue, Nov 23, 2021 at 6:45 PM Vitaly Ankh wrote:
>
> Hi Timothy,
> It seems a great work! I'm not familiar with this yet, just curious
> that if this "org-inline-src-block"
> could save this problem: the preview image of inline LaTeX has a
> different color from
> the normal text, which is ugly and annoying. And setting
> 'org-format-latex-options
> doesn't help because the problem is caused by the inline LaTeX using
> the 'org-fixed-width face
> which has a different color and when the preview image is not big
> enough the color will be shown.
> The attachment shows the problem where some preview LaTeX images have
> different colors
> surrounded.
>
> Regards,
> VitalyR
>
>
> On Sun, Nov 21, 2021 at 10:16 PM Timothy wrote:
> >
> > Hi All,
> >
> > Since the contentious component of my previous patches has been the
> > `{{{results()}}}' prettification, I’ve prepared an alternate version that
> > I’m
> > hoping everybody will be fairly happy with (fingers crossed!) that tosses
> > out
> > the results prettification for now.
> >
> > I think Protesilaos’ comments on making some new faces deserve
> > consideration,
> > but could easily be done subsequently, as I’m quite keen to get this merged
> > for
> > now.
> >
> > All the best,
> > Timothy
Re: [PATCH] Fontification for inline src blocks
Timothy writes: >> I can see the purpose. However, it still looks like overcomplication. >> org-element-context takes care about this issue simply by narrowing to >> current element (inline src block is an object and hence must end within >> current element). > > Well, one simple change we could do is just replace > org-inline-src-fontify-max-length with the addition of `(save-excursion > (search-forward "\n" limit nil) (point))' to the restriction. That's an option. Though you should also consider a paragraph ending at EOB. Searching for "\n" will fail with error then. >> Sounds like an omission in org-element-context. At least, the parser >> could return :contents-begin and :contents-end. Then, you would also not >> need to re-implement the parser. > > Perhaps. However frankly I don’t think it would do that much to reduce the > complexity, and what’s in this patch seems to work fairly nicely. I am mostly thinking in terms of https://list.orgmode.org/87tug8t8ql@gmail.com/T/#t Otherwise, your variant is fine for me. Best, Ihor
[PATCH] Re: org-metashiftleft/right should honor org-support-shift-select
Carlos Pita writes: > Hi all, > > on macOS option-shift-left / right extend the selection by one word. > Emacs by default binds meta-shift-left / right in a way that is > compatible with the system shortcuts. But org-mode interferes with > these bindings even when org-support-shift-select is t. OTOH, an > effort has been done to support shift selection in > org-shiftcontrolleft / right. The problem is that macOS uses option > instead of control to achieve selection by word. Can you test the attached patch? I am not using MacOS. Best, Ihor >From 77312a266c200a65a4a8cf63040e32357304396c Mon Sep 17 00:00:00 2001 Message-Id: <77312a266c200a65a4a8cf63040e32357304396c.1637674022.git.yanta...@gmail.com> From: Ihor Radchenko Date: Tue, 23 Nov 2021 21:24:52 +0800 Subject: [PATCH] Make org-shiftmetaleft/org-shiftmetaright honour shift-select on MacOS * lisp/org.el (org-shiftmetaleft): (org-shiftmetaright): Honour shift-select bound to meta-arrow on MacOS when `org-support-shift-select' is non-nil. Fixes https://orgmode.org/list/CAEOO5Tdg6sdjNfAg=j_dvq50xx1oxafavyyynda6o_-t3hg...@mail.gmail.com --- lisp/org.el | 8 1 file changed, 8 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 048abb142..a86ad301f 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -17378,6 +17378,10 @@ (defun org-shiftmetaleft () individual commands for more information." (interactive) (cond + ((and (eq system-type 'darwin) + (or (eq org-support-shift-select 'always) + (and org-support-shift-select (org-region-active-p +(org-call-for-shift-select 'backward-char)) ((run-hook-with-args-until-success 'org-shiftmetaleft-hook)) ((org-at-table-p) (call-interactively 'org-table-delete-column)) ((org-at-heading-p) (call-interactively 'org-promote-subtree)) @@ -17394,6 +17398,10 @@ (defun org-shiftmetaright () individual commands for more information." (interactive) (cond + ((and (eq system-type 'darwin) + (or (eq org-support-shift-select 'always) + (and org-support-shift-select (org-region-active-p +(org-call-for-shift-select 'forward-char)) ((run-hook-with-args-until-success 'org-shiftmetaright-hook)) ((org-at-table-p) (call-interactively 'org-table-insert-column)) ((org-at-heading-p) (call-interactively 'org-demote-subtree)) -- 2.32.0
Re: [PATCH] Bug: Unintended column added to table [9.4.6 (9.4.6-gab9f2a @ /home/user/.emacs.d/elpa/org-9.4.6/)]
Spectira Chiando writes: > Patch is working great, have been using it heavily for the past month. Thanks > very much! Applied. I took a freedom to push the patch to main. Best, Ihor
Re: bulk archive slow
Samuel Wales writes: > in recent maint, bulk archive is slow for me. not a huge deal but > org-element--current-element takes up 92 percent of cpu time in > profiler. 6 entries took a few minutes. this is just a heads up in > case anybody can confirm. Just a note that bulk archiving should be a lot faster on latest main. Best, Ihor
Re: Bug: org-tangle writes region for every single block [9.4.4 (9.4.4-elpa @ /home/miha/.config/emacs/elpa/org-20201222/)]
jakanakaevang...@chiru.no writes: > Tangling a file with a lot of src blocks can get quite slow because > write-region is called for each individual src block. > > On my machine it takes 8 seconds to tangle a file with 160 blocks of the > same language. Tangling the file over tramp would probably take about 5 > minutes. > > Perhaps it would be more optimal to only save each file at the end > of src block extraction. I am not sure if the bulk of tangling time is spent actually writing to disk. Can you try your problematic file on latest main? There are some improvements that should improve tangling speed significantly. Best, Ihor
[PATCH] "Cache corruption detected" when editing CLOCK timestamp by hand
Ihor Radchenko writes:
> This looks like a bug in org-element-timestamp-parser
>
> Minimal reproducer:
>
> 1. Create an empty org file and open it
> 2. Yank the following string: "CLOCK: [2021-10-22 Fri 10:41]--[2021]"
> 3. M-: (org-element-at-point)
The attached is tentative fix for cases like the above.
It gets rid of the observed error, however I am not sure if the clock
line parser returns a reasonable value is such case. With the patch,
org-element-at-point returns
(clock (:status running
:value
(timestamp (
:type inactive
:raw-value "[2021-10-22 Fri 10:41]"
:year-start 2021 :month-start 10 :day-start 22
:hour-start 10 :minute-start 41 :year-end 2021
:month-end 10 :day-end 22 :hour-end 10 :minute-end 41
:begin 301 :end 323 :post-blank 0))
:duration nil :begin 294 :end 331 :post-blank 0 :post-affiliated 294))
Should we consider the above CLOCK line as a valid running clock or
maybe it should be parsed as a paragraph?
Best,
Ihor
>From 91749491eb95cf1088fbe5a479eb30816478dba7 Mon Sep 17 00:00:00 2001
Message-Id: <91749491eb95cf1088fbe5a479eb30816478dba7.1637670436.git.yanta...@gmail.com>
From: Ihor Radchenko
Date: Tue, 23 Nov 2021 20:25:41 +0800
Subject: [PATCH] org-element: Fix org-element-timestamp-parser for incomplete
ranges
* lisp/org-element.el (org-element-timestamp-parser): Use more strict
regexp to match second timestamp in timestamp--timestamp range.
Fixes https://list.orgmode.org/orgmode/87tuh88kjv.fsf@localhost/
---
lisp/org-element.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index b47fba9eb..b40ff2d33 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3900,7 +3900,9 @@ (defun org-element-timestamp-parser ()
(activep (eq (char-after) ?<))
(raw-value
(progn
- (looking-at "\\([<[]\\(%%\\)?.*?\\)[]>]\\(?:--\\([<[].*?[]>]\\)\\)?")
+ (looking-at (concat "\\([<[]\\(%%\\)?.*?\\)[]>]\\(?:--\\("
+org-ts-regexp-both
+"\\)\\)?"))
(match-string-no-properties 0)))
(date-start (match-string-no-properties 1))
(date-end (match-string 3))
--
2.32.0
Re: Why is an image width restricted to being between 0 and 200% of the text area
Hi, If org mode won't blow up, kick out the restriction. It is not up to us to decide what users will have use for or not. Besides, if someone specifies an outrageously wide picture by mistake, it's a mistake which is easy to spot and fix. I finish my argument with a small war story. Many years ago my colleagues and I tried to create a computational grid around a ship, for flow simulations. However, the grid generation program refused to follow our instructions, no matter what we tried. We reported this to the company behind the grid generation software, and it turned out they had imposed a 1000 m size limit on grids. It just so happens that many merchant ships are almost 400 m long, and when you extend the computational grid sufficiently up- and downstream, you get a grid well over 1000 m long. Given the magnitude limit for double precision floating point numbers, 1000 m was a ridiculous limit. yours Rasmus
Re: Why is an image width restricted to being between 0 and 200% of the text area
Matt Huszagh writes: > I agree that requesting an image to be >2x the buffer text width is a > strange request, and it's not one I've ever tried to give. But, I think > the salient point is that it's a very clear request, and I think org > should carry it out. I'm all in favor of org helping people not shoot > themselves in the foot, but I don't think it should prevent people from > doing so, especially when they're clear about their intentions. I also > think this qualifies as a case where someone /might/ have a valid reason > for doing this. +1M. We need to ensure org does not become too opinionated regarding what is reasonable. If there is no good reason to impose an upper limit, we should avoid doing so. Org is so powerful and open to customisation, it is unlikely any of us can foresee all possible scenarios, so we need to be careful not to artificially constrain the possibilities. , > > I guess we could make the upper limit customizable and default to > 2.0. But, this is a bit confusing because it doesn't apply to the > original image width. I also think adding too many customizable > variables adds to complexity. I don't know. Thoughts? This also isn't a > feature I've ever needed... so I'm happy to concede and revisit it in > the future if I have a valid use case for it. > +1M. Org already has an excessive number of custom settings. We need to actively avoid adding mor whenever we can. At first glance, a custom variable seems to be a good option. However, once you take testing and maintenance into consideration and think about the basic testing principal of ensuring all possible paths are tested, you soon see why adding such custom options really increases maintenance overhead. If there is a legitimate technical reason to set an upper limit, then that is fine. However, setting a limit because you cannot imagine anyone wanting to go above it is probably not.
