Re: Website revamp?
Colin Baxter writes: >> TEC writes: >> - The site is now more mobile friendly, the navbar now has a > > Why? How many users are installing org-mode on their 'phones - smart or > otherwise? Zero, I expect :P However, I don't think that's the question we should be asking. Consider someone tweeting about org-mode, the question then is: how many people use twitter on their phones? Likewise, if someone wants to share a org-mode with a friend, and sends them a link - whether it be by email, sms, whatsapp, messenger, or telegram: what's the chance that they'll take a peek oh their phones? Of course we don't exactly have any hard answers to these questions, but I'd wager the answer is enough to warrant a little bit of effort to make the mobile experience not-garbage. To see how orgmode.org currently appears, see https://i.imgur.com/XPFfBaB.png IMO that's downright off-putting --- and I say that intending no criticism to Carsten or Bastien, in 2012 mobile design simple wasn't a priority. Moreover, we can improve the mobile experience with no compromise to the desktop --- so why wouldn't we? :D I hope this fleshes out my motivation for improving the mobile experience :) Timothy.
Re: Website revamp?
> TEC writes: > Another update :) > - For inspection, the WIP-code can now be found on github: > https://github.com/tecosaur/orgwebsite. > - The site is now more mobile friendly, the navbar now has a Why? How many users are installing org-mode on their 'phones - smart or otherwise? Colin Baxter. -- Colin Baxter URL: http://www.Colin-Baxter.com - GnuPG fingerprint: 68A8 799C 0230 16E7 BF68 2A27 BBFA 2492 91F5 41C8
Re: file-mode source code block header argument
John Herrlin writes: > Thank you for the comments Kyle! I updated the patch accordingly. Took > your test straight of as I think it's really clean and easy to reason > about. Thanks for the updates. Applied (ea946353a), tweaking the markup in the NEWS entry and rewording the test docstring.
Re: Bug: org-toggle-item removes tags from next heading [9.3.7 (release_9.3.7-696-g82b496 @ mixed installation! /home/n/.emacs.d/straight/build/org/ and /home/n/.emacs.d/straight/build/org/eln-x86_64-
No Wayman writes: > Added the test in the attached patch. Thanks. Applied (093b474e6), appending a period to the comment in the test for consistency.
Re: Bug: [patch] Fix org-babel-result-to-file never expanding links when babel is evaluated in indirect buffer [9.3.7 (release_9.3.7-728-g1efc4e @ /home/yantar92/.emacs.d/straight/build/org/)]
> I don't have a real world scenario, just the one I made up below. I used
> that to play around with the function.
I see. FYI: I do change default-directory during src block execution in
my config. The following code makes src blocks execute inside attachment
folder by default:
(define-advice org-babel-execute-src-block (:filter-args ( args)
set-detault-dir-to-org-attach-path)
"Set working directory to the current entry's attach directory."
(if (eq major-mode 'org-mode)
(let* ((directory (file-name-as-directory (org-attach-dir
'create-if-none)))
(arg (car args))
(info (cadr args))
(params (org-babel-merge-params (nth 2 info) (caddr args)))
(dir-param (alist-get :dir params)))
(unless (and dir-param (or (equal (f-full default-directory) (f-full
dir-param))
(f-absolute-p dir-param)))
(setf (alist-get :dir params)
(if dir-param
(f-join directory (alist-get :dir params))
directory)))
(list arg info params))
(list arg info params)))
That's actually how I found the reported bug.
Best,
Ihor
John Herrlin writes:
> Ihor Radchenko writes:
>
>>> It's intended to change directory and dont clone base buffer values. I
>>> tried to accomplish "If the `default-directory' is different from the
>>> containing file's directory then expand relative links."
>>
>> Not sure if I understand your use-case. Can you explain why you need to
>> achieve such behaviour? There might be an easier way to get what you
>> want.
>
> I don't have a real world scenario, just the one I made up below. I used
> that to play around with the function.
>
> Best regards
> John
>
>>
>> Best,
>> Ihor
>>
>>
>> John Herrlin writes:
>>
>>> It's intended to change directory and dont clone base buffer values. I
>>> tried to accomplish "If the `default-directory' is different from the
>>> containing file's directory then expand relative links." As I
>>> understands it that's when it inserts a relative link, otherwise it just
>>> `result'. I was looking from the indirect buffers point of view and from
>>> there the relative link is off in this case. But from the base buffers
>>> point of view everything works fine. I guess that it was my use case
>>> that is strange.
>>>
>>> Looks good!
>>>
>>> Best regards
>>> John
>>>
> In my case the result is a relative link, but if I follow the link I end
> up in the wrong place.
Do you mean that the generated script.sh ends up in your home dir?
It is expected since default-directory in your buffer is "~/":
> (dired "~/")
> (make-indirect-buffer "tmp.org" "tmp-indirect")
Note that you called make-indirect-buffer without third argument.
According to manual:
> (make-indirect-buffer BASE-BUFFER NAME CLONE)
> CLONE nil means the indirect buffer's state is reset to default values.
> Org first tries to generate the filename from the value of the
> ‘file’ header argument and the directory specified using the
> ‘output-dir’ header arguments. If ‘output-dir’ is not specified,
> Org assumes it is the current directory.
No surprise you got your file in the default-directory (~/).
If you use (make-indirect-buffer "tmp.org" "tmp-indirect" t) instead,
the script.sh link will be relative, as expected.
Let me know if I miss something.
Best,
Ihor
> Hey Ihor,
>
> Could not get the patch to work.
>
> I used this use case.
>
> (with-current-buffer
> (find-file "/tmp/tmp.org")
> (insert "* A\n** b\n** c\n\n some text")
> (dired "~/")
> (make-indirect-buffer "tmp.org" "tmp-indirect")
> (switch-to-buffer "tmp-indirect")
> (goto-char (point-max))
> (funcall 'org-mode)
> (insert (concat "\n\n| default-directory | " default-directory " |\n"
> "| org-link-file-path-type | " (symbol-name
> org-link-file-path-type) " |\n"
> "| (expand-file-name default-directory) | "
> (expand-file-name default-directory) " |\n"
> "| (buffer-file-name (buffer-base-buffer)) | "
> (buffer-file-name (buffer-base-buffer)) " |\n"))
> (org-table-align)
> (insert "\n\n#+BEGIN_SRC shell :results file :file script.sh
>echo \"#!/bin/bash\"
>echo \"echo Hey\"\n#+END_SRC")
> (org-babel-execute-src-block))
>
> In my case the result is a relative link, but if I follow the link I end
> up in the wrong place.
>
> src_emacs-lisp{emacs-version} {{{results(=26.3=)}}}
> src_emacs-lisp{org-version} {{{results(=9.3.7=)}}}
>
> Best regards
> John
>
>
> Ihor Radchenko writes:
>
>> Remember to cover the basics, that is, what you expected to happen and
>> what in fact did
Re: Bug#42184: org-fontify-whole-*-line in emacs 27
Since 27.1-rc1 is out, I'd like to bump this; it'd be a shame if 27.1 shipped with this bug, which seems to be getting some attention (I just spotted a Reddit thread[1] about it, in addition to the original report on Debbugs). [1]: https://old.reddit.com/r/emacs/comments/i26n46/why_does_my_orgmode_look_different_to_leuven/ Kévin Le Gouguec writes: > Could Org maintainers weigh in on bug#42184? > > To recap my understanding of the issue: > > - org-fontify-whole-heading-line controls whether > org-set-font-lock-defaults includes the final newline in the headline > regexp (resp. org-fontify-whole-block-delimiter-line with begin/end > block regexps). > > - This assumes that fontifying the final newline is enough to fontify > everything beyond this newline. > > - This assumption is no longer valid with Emacs 27, where this extension > is opt-in, using the :extend face attribute. > > With Eli's help, I proposed a patch for org-mode against the emacs-27 > branch that does something similar to what is done for the org-hide > face: when setting up the major mode, depending on those user options, > the :extend attribute is (re)set for the relevant faces (using a > compatibility function defined in org-compat). > > I've reattached the patch for convenience. Does it look sound? > > From 07d123c548051eb7f6bbac5c7f5a4e4b8411f976 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= > Date: Thu, 9 Jul 2020 16:02:49 +0200 > Subject: [PATCH] Fix org-fontify-whole-*-line by setting face extension > (bug#42184) > > * lisp/org/org-compat.el (org--set-faces-extend): New function to set > face extension, for Emacs versions where this attribute exists. > * lisp/org/org.el (org-mode): Call it to set the extend attribute of > relevant faces to the correct value. > --- > lisp/org/org-compat.el | 4 > lisp/org/org.el| 6 +- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el > index c1aaf17ca2..fcc325e475 100644 > --- a/lisp/org/org-compat.el > +++ b/lisp/org/org-compat.el > @@ -101,6 +101,10 @@ org-table1-hline-regexp >(defun org-time-convert-to-list (time) > (seconds-to-time (float-time time > > +(defun org--set-faces-extend (faces extend-p) > + (when (fboundp 'set-face-extend) > +(mapc (lambda (f) (set-face-extend f extend-p)) faces))) > + > > ;;; Emacs < 26.1 compatibility > > diff --git a/lisp/org/org.el b/lisp/org/org.el > index 568f5b9b87..fb31336ea4 100644 > --- a/lisp/org/org.el > +++ b/lisp/org/org.el > @@ -4944,7 +4944,11 @@ org-mode >;; Try to set `org-hide' face correctly. >(let ((foreground (org-find-invisible-foreground))) > (when foreground > - (set-face-foreground 'org-hide foreground > + (set-face-foreground 'org-hide foreground))) > + ;; Set face extension as requested. > + (org--set-faces-extend '(org-block-begin-line org-block-end-line) > + org-fontify-whole-block-delimiter-line) > + (org--set-faces-extend org-level-faces org-fontify-whole-heading-line)) > > ;; Update `customize-package-emacs-version-alist' > (add-to-list 'customize-package-emacs-version-alist
Re: Setting language on result of code block
You can use =:wrap= for that.
Here is the docs: https://orgmode.org/manual/Results-of-Evaluation.html
And here is an example.
#+BEGIN_SRC shell :results output :wrap example json
curl http://ip.jsontest.com/
#+END_SRC
#+RESULTS:
#+begin_example json
{"ip": "8.8.8.8"}
#+end_example
Best regards
John
Magnus Therning writes:
> Is there some way to specify the language on the result of a code block.
> For instance, if the block
>
> #+begin_src bash
> aws --endpoint-url=http://localhost:4566 sns create-topic --name the-topic
> #+end_src
>
> gives the result
>
> #+RESULTS:
> #+begin_example
> {
> "TopicArn": "arn:aws:sns:eu-central-1::the-topic"
> }
> #+end_example
>
> Is there some way I can specify that the result is JSON? That is get the
> result
>
> #+RESULTS:
> #+begin_example json
> {
> "TopicArn": "arn:aws:sns:eu-central-1::the-topic"
> }
> #+end_example
>
> /M
Setting language on result of code block
Is there some way to specify the language on the result of a code block.
For instance, if the block
#+begin_src bash
aws --endpoint-url=http://localhost:4566 sns create-topic --name the-topic
#+end_src
gives the result
#+RESULTS:
#+begin_example
{
"TopicArn": "arn:aws:sns:eu-central-1::the-topic"
}
#+end_example
Is there some way I can specify that the result is JSON? That is get the
result
#+RESULTS:
#+begin_example json
{
"TopicArn": "arn:aws:sns:eu-central-1::the-topic"
}
#+end_example
/M
--
Magnus Therning OpenPGP: 0x927912051716CE39
email: mag...@therning.org
twitter: magthe http://magnus.therning.org/
Every act of creation is first an act of destruction.
— Pablo Picasso
signature.asc
Description: PGP signature
Re: make org-refile auto-recache when needed?
i recall wanting this at some point also, and also did not figure out why one would not want it. perhaps it thinks you will use an alternate to refiling if you know it will be too slow. but it's worth keeping in mind that caching has, or had, bugs. in particular, if refile targets are filtered [and you might have more than one set], a single cache could seemingly get confused. of course a solution would be to filter late. if there is anything else that can be done to speed up refile and refile goto /without/ caching, that's definitely best. you have probably profiled, but make sure your completer [ivy, ido, helm] is not the bottleneck. i wish we could get rid of this cache. On 7/15/20, Adam Spiers wrote: > Hi all, > > I note that when org-refile-use-cache is enabled and the cache becomes > stale, attempting to refile results in this error message (originating > from `org-refile-check-position'): > > Invalid refile position, please clear the cache with `C-0 C-c C-w' > before refiling > > Is there any reason why it couldn't just automatically rebuild the > cache when needed? If it did that then I struggle to imagine why > anyone would ever *not* want the cache enabled, because in the worst > case org-refile would just behave the same as when the cache is > disabled, and in the best case it would perform a lot faster. > > Cheers, > Adam > > -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Bug: [patch] Fix org-babel-result-to-file never expanding links when babel is evaluated in indirect buffer [9.3.7 (release_9.3.7-728-g1efc4e @ /home/yantar92/.emacs.d/straight/build/org/)]
Ihor Radchenko writes:
>> It's intended to change directory and dont clone base buffer values. I
>> tried to accomplish "If the `default-directory' is different from the
>> containing file's directory then expand relative links."
>
> Not sure if I understand your use-case. Can you explain why you need to
> achieve such behaviour? There might be an easier way to get what you
> want.
I don't have a real world scenario, just the one I made up below. I used
that to play around with the function.
Best regards
John
>
> Best,
> Ihor
>
>
> John Herrlin writes:
>
>> It's intended to change directory and dont clone base buffer values. I
>> tried to accomplish "If the `default-directory' is different from the
>> containing file's directory then expand relative links." As I
>> understands it that's when it inserts a relative link, otherwise it just
>> `result'. I was looking from the indirect buffers point of view and from
>> there the relative link is off in this case. But from the base buffers
>> point of view everything works fine. I guess that it was my use case
>> that is strange.
>>
>> Looks good!
>>
>> Best regards
>> John
>>
In my case the result is a relative link, but if I follow the link I end
up in the wrong place.
>>>
>>> Do you mean that the generated script.sh ends up in your home dir?
>>> It is expected since default-directory in your buffer is "~/":
>>>
(dired "~/")
(make-indirect-buffer "tmp.org" "tmp-indirect")
>>>
>>> Note that you called make-indirect-buffer without third argument.
>>>
>>> According to manual:
>>>
(make-indirect-buffer BASE-BUFFER NAME CLONE)
CLONE nil means the indirect buffer's state is reset to default values.
>>>
Org first tries to generate the filename from the value of the
‘file’ header argument and the directory specified using the
‘output-dir’ header arguments. If ‘output-dir’ is not specified,
Org assumes it is the current directory.
>>>
>>> No surprise you got your file in the default-directory (~/).
>>>
>>> If you use (make-indirect-buffer "tmp.org" "tmp-indirect" t) instead,
>>> the script.sh link will be relative, as expected.
>>>
>>> Let me know if I miss something.
>>>
>>> Best,
>>> Ihor
>>>
>>>
Hey Ihor,
Could not get the patch to work.
I used this use case.
(with-current-buffer
(find-file "/tmp/tmp.org")
(insert "* A\n** b\n** c\n\n some text")
(dired "~/")
(make-indirect-buffer "tmp.org" "tmp-indirect")
(switch-to-buffer "tmp-indirect")
(goto-char (point-max))
(funcall 'org-mode)
(insert (concat "\n\n| default-directory | " default-directory " |\n"
"| org-link-file-path-type | " (symbol-name
org-link-file-path-type) " |\n"
"| (expand-file-name default-directory) | "
(expand-file-name default-directory) " |\n"
"| (buffer-file-name (buffer-base-buffer)) | "
(buffer-file-name (buffer-base-buffer)) " |\n"))
(org-table-align)
(insert "\n\n#+BEGIN_SRC shell :results file :file script.sh
echo \"#!/bin/bash\"
echo \"echo Hey\"\n#+END_SRC")
(org-babel-execute-src-block))
In my case the result is a relative link, but if I follow the link I end
up in the wrong place.
src_emacs-lisp{emacs-version} {{{results(=26.3=)}}}
src_emacs-lisp{org-version} {{{results(=9.3.7=)}}}
Best regards
John
Ihor Radchenko writes:
> 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.
>
>
> I noticed that org-babel-result-to-file never expands file: links in
> src block results when ran from indirect buffer and default-directory
> is not same with base buffer file's directory. This is against the
> docstring stating that
>
>> If the `default-directory' is different from the containing
>> file's directory then expand relative links.
>
> The misbehavior happens because buffer-file-name variable is always
> nil in indirect buffers. We need to call (file-name-directory
> (buffer-file-name (buffer-base-buffer))) instead.
>
> The patch is attached.
>
> Best,
> Ihor
>
> diff --git a/lisp/ob-core.el b/lisp/ob-core.el
> index f86282f0f..d37eef5f9 100644
> --- a/lisp/ob-core.el
> +++ b/lisp/ob-core.el
> @@ -2561,16 +2561,16 @@ If the `default-directory' is different from the
> containing
> file's directory then expand relative links."
>(when (stringp result)
> (let ((same-directory?
> -(and buffer-file-name
[PATCH] org-get-cursor-date regexp patch
The regular expression in `org-get-cursor-date' assumes the time grid string will have two digits in the hour portion of the time strng. However, the grid time string does not always have two digits. For example: " 8:00.." The attached patch accounts for this and uses the rx macro to communicate the intent of the regular expression more clearly. >From 4724b4cc5e9600da60b465c4c2f1968b75c7c31d Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Sun, 2 Aug 2020 14:42:34 -0400 Subject: [PATCH] org.el: (org-get-cursor-date): Fix regular expression * lisp/org.el Fix regular expression. --- lisp/org.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index ee8be256d..37136cc48 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18728,10 +18728,11 @@ If WITH-TIME is non-nil, returns the time of the event at point (in the agenda) or the current time of the day; otherwise returns the earliest time on the cursor date that Org treats as that date (bearing in mind `org-extend-today-until')." - (let (date day defd tp hod mod) + (let ((hhmm-regexp (rx (seq (group (** 1 2 digit)) ":" (group (= 2 digit) + date day defd tp hod mod) (when with-time (setq tp (get-text-property (point) 'time)) - (when (and tp (string-match "\\([0-9][0-9]\\):\\([0-9][0-9]\\)" tp)) + (when (and tp (string-match hhmm-regexp tp)) (setq hod (string-to-number (match-string 1 tp)) mod (string-to-number (match-string 2 tp (or tp (let ((now (decode-time))) -- 2.27.0
Re: Website revamp?
Another update :) - For inspection, the WIP-code can now be found on github: https://github.com/tecosaur/orgwebsite. - The site is now more mobile friendly, the navbar now has a burger state - The features page has seen a revamp in style and content Please check it out and give me feedback on the current state of affairs! Timothy.
Re: Bug: org-toggle-item removes tags from next heading [9.3.7 (release_9.3.7-696-g82b496 @ mixed installation! /home/n/.emacs.d/straight/build/org/ and /home/n/.emacs.d/straight/build/org/eln-x86_64-
Kyle Meyer writes: Would you mind updating the patch to add a test case along the lines of your ECM to test-org-list/toggle-item? Thanks. Added the test in the attached patch. Thanks, Kyle. ~ Nicholas Vollmer >From 838a6a548396eecfa958161abb66f0a1719a9aef Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Fri, 31 Jul 2020 18:38:11 -0400 Subject: [PATCH] org-list: Operate on single line if no active region * lisp/org-list.el (org-toggle-item): Operate on single line if no active region. --- lisp/org-list.el | 2 +- testing/lisp/test-org-list.el | 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/lisp/org-list.el b/lisp/org-list.el index fb061b054..c43630d05 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -3032,7 +3032,7 @@ With a prefix argument ARG, change the region in a single item." (if (org-region-active-p) (setq beg (funcall skip-blanks (region-beginning)) end (copy-marker (region-end))) - (setq beg (funcall skip-blanks (point-at-bol)) + (setq beg (point-at-bol) end (copy-marker (point-at-eol ;; Depending on the starting line, choose an action on the text ;; between BEG and END. diff --git a/testing/lisp/test-org-list.el b/testing/lisp/test-org-list.el index abd1a3c83..24a55464d 100644 --- a/testing/lisp/test-org-list.el +++ b/testing/lisp/test-org-list.el @@ -1109,6 +1109,13 @@ b. Item 2" (org-test-with-temp-text "* H\n:PROPERTIES:\n:A: 1\n:END:\n\n\nText" (org-toggle-item nil) (buffer-string + ;; When no region is marked and point is on a blank line + ;; only operate on current line + (should + (equal " \n* H :tag:" + (org-test-with-temp-text " \n* H :tag:" + (org-toggle-item nil) + (buffer-string ;; When a region is marked and first line is a headline, all ;; headlines are turned into items. (should -- 2.27.0
Bug: Org sentence commands and emphasis markers [9.3 (release_9.3 @ /usr/local/share/emacs/27.1/lisp/org/)]
Hi All, There is some adverse interaction between Emacs sentence related commands and Org emphasis markers, when whole sentences are emphasized. This report describe some cases of this interaction, for your consideration. But, as a general rule, if a whole sentence is emphasized, sentence movement and killing, and paragraph filling won't work as expected. Let's take the case of a small paragraph, with sentences ended with double spaces, and with `sentence-end-double-space' having its default value of t. And let's have the whole second sentence emphasized with bold markers. "!" represents point position. #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src 1 - Sentence movement If we call on this paragraph the regular Org sentence movement commands `org-backward-sentence' and `org-forward-sentence', the second sentence will no longer be recognized as such. Starting from the beginning of the paragraph and calling `org-forward-sentence' will result in: #+begin_src org !Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.! *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.! Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src That is, the end of the second (emphasized) sentence was missed. A similar problem occurs when going backwards with `org-backward-sentence'. 2 - Sentence killing With point at the end of the first sentence, as in; #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.! *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src If we call `kill-sentence' we will get: #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.! Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src That is, the second and third sentences were killed. A similar problem occurs with point somewhere on the third sentence and
[feature request] org-at-timestamp-p should accept multiple parameters
Hi, recently I was doing some customization and I needed to check if timestamp at a point is active or inactive. That timestamp also contains an agenda like information about reoccurring. So I tried to use org-at-timestamp-p function for this purpose. The problem is I needed to check if the timestamp is agenda like and inactive or ignore the context at the same time. But org-at-timestamp-p takes only one parameter, and I needed to give it multiple parameters, which is not possible in the current version. Can you amend the implementation of org-at-timestamp-p to make it accept a list of parameters or named parameters instead of just one parameter? Thanks, Adam
Re: file-mode source code block header argument
Thank you for the comments Kyle! I updated the patch accordingly. Took
your test straight of as I think it's really clean and easy to reason
about.
Best regards
Kyle Meyer writes:
> John Herrlin writes:
>
>> I am looking for a way to set permission on a file created from source
>> code block result when :file header argument is used. I was looking for
>> something like :tangle-mode but could not find anything. I wrote a patch
>> that does just that and it works for my small use case.
>
> Thanks for the patch.
>
>> It's a header argument called :file-mode and can be used in the same
>> way as :tangle-mode.
>>
>> Example usage:
>>
>> #+BEGIN_SRC shell :results file :file script.sh :file-mode (identity #o755)
>> echo "#!/bin/bash"
>> echo "echo Hello World"
>> #+END_SRC
>>
>> Is this a suitable way of doing it?
>
> Looks sensible to me. Hopefully others with more knowledge and interest
> in Babel will chime in if they disagree. In the meantime, I mostly just
> have convention nit-picks...
>
>> Subject: [PATCH] ob-core: file-mode option in source code block arguments
>>
>> * ob-core.el (org-babel-execute-src-block): Source code block header
>> argument :file-mode can set file permission if :file argument is provided
>
> Please end this sentence with a period.
>
> Also, assuming the listing at
> https://orgmode.org/worg/org-contribute.html is up to date, this should
> come with a TINYCHANGE cookie.
>
>> ---
>> doc/org-manual.org | 12
>> lisp/ob-core.el | 5 -
>> testing/lisp/test-ob.el | 17 +
>> 3 files changed, 33 insertions(+), 1 deletion(-)
>
> Please also add an ORG-NEWS entry.
>
>> diff --git a/doc/org-manual.org b/doc/org-manual.org
>> index b616446..2919139 100644
>> --- a/doc/org-manual.org
>> +++ b/doc/org-manual.org
>> @@ -17440,6 +17440,18 @@ default behavior is to automatically determine the
>> result type.
>>uses the generated file name for both the "link" and
>>"description" parts of the link.
>>
>> + #+cindex: @samp{file-mode}, header argument
>> + The =file-mode= header argument defines the file permission. For
>
> s/permission/permissions/
>
> Also, the convention for this project is two spaces following a
> sentence.
>
>> + example, to make a read-only file, use ‘:file-mode (identity
>> + #o444)’. To make it executable, use ‘:file-mode (identity #o755)’
>
> These ‘...’ should be =...=, I think.
>
> I know this text is just following the text for :tangle-mode, but from
> my point of view, "For example ..." through to the example block could
> be dropped. If the reader knows about file permissions, then it's
> unnecessary; if they don't, I don't see how it'd be enough to help them
> figure out what's going on.
>
>> + #+begin_example
>> + ,#+BEGIN_SRC shell :results file :file script.sh :file-mode (identity
>> #o755)
>> +echo "#!/bin/bash"
>> +echo "echo Hello World"
>> + ,#+END_SRC
>> + #+end_example
>
>> diff --git a/lisp/ob-core.el b/lisp/ob-core.el
>> index e798595..cc3e002 100644
>> --- a/lisp/ob-core.el
>> +++ b/lisp/ob-core.el
>> @@ -731,7 +731,10 @@ block."
>> (with-temp-file file
>>(insert (org-babel-format-result
>> result
>> - (cdr (assq :sep params))
>> + (cdr (assq :sep params)
>> +;; Set permissions if header argument `:file-mode' is
>> provided
>
> To continue my nit-picking: Please follow the style of the surrounding
> comments, ending with a period and filling the paragraph.
>
>> +(when (assq :file-mode params)
>> + (set-file-modes file (cdr (assq :file-mode params)
>
> Looks good.
>
>>(setq result file))
>> ;; Possibly perform post process provided its
>> ;; appropriate. Dynamically bind "*this*" to the
>> diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
>> index 7c44622..c4aaad1 100644
>> --- a/testing/lisp/test-ob.el
>> +++ b/testing/lisp/test-ob.el
>> @@ -1746,6 +1746,23 @@ line 1
>> (cdr (assq :file (nth 2 (org-babel-get-src-block-info t))
>> ))
>>
>> +(ert-deftest test-ob/file-mode ()
>> + "Ensure that file have correct permissions."
>> + (let* ((file (org-babel-temp-file "file-mode-" ".sh"))
>> + (filename (file-name-nondirectory file))
>> + (path (file-name-directory file)))
>> +(org-test-with-temp-text
>> +(concat
>> + "#+BEGIN_SRC emacs-lisp :results file "
>> + ":file " filename " "
>> + ":output-dir " path " "
>> + ":file-mode (identity #o755)
>> + nil
>> + #+END_SRC")
>
> Rather than using org-babel-temp-file to generate a temporary file, I
> think the preferred way to do this would be to use
> org-test-with-temp-text-in-file.
>
>> + (org-babel-execute-src-block))
>> +(should (equal (file-modes file)
>> + 493
>
> To my eyes, spelling this as
Re: make org-refile auto-recache when needed?
Seconding this. Ideally, refile should also try to perform refiling after rebuilding the cache. Best, Ihor Adam Spiers writes: > Hi all, > > I note that when org-refile-use-cache is enabled and the cache becomes > stale, attempting to refile results in this error message (originating > from `org-refile-check-position'): > > Invalid refile position, please clear the cache with `C-0 C-c C-w' > before refiling > > Is there any reason why it couldn't just automatically rebuild the > cache when needed? If it did that then I struggle to imagine why > anyone would ever *not* want the cache enabled, because in the worst > case org-refile would just behave the same as when the cache is > disabled, and in the best case it would perform a lot faster. > > Cheers, > Adam > -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate
Hi Kyle, Sorry for the slow turnaround time on this one. Having now tested it, I think that your solution is a much better one for the time being, so please go ahead and apply it. From this discussion there are a number of good options for improvements in the future, but my priority would be to get the expanded version of the body passed to org-confirm-babel-evaluate asap with as few disturbances to the rest of the code base as possible. Best! Tom On Tue, Jul 21, 2020 at 9:20 PM Kyle Meyer wrote: > > Tom Gillespie writes: > > > On Sun, Jul 19, 2020 at 2:13 PM Kyle Meyer wrote: > > >> An option not mentioned above is to replace (nth 1 info) with the > >> expanded body upstream of (when (org-babel-check-evaluate info) ...). > >> Modifying the body in INFO is admittedly not pretty, but it's in line > >> with what is done elsewhere (e.g., -expand-src-block, > >> -exp-process-buffer, -load-in-session), as well as with how other INFO > >> elements in -execute-src-block are handled. > > > > I considered this as well, and in fact I assumed that this is how it worked > > before I looked to see the code was actually doing. I didn't know what the > > consequences of making it work that way would be and tend to err on the > > side of not kobbering data that some other function might expect to be in > > an unmodified state. This would certainly be the most expedient solution. > > > > There would need to be a way to indicate that info should not expand noweb > > references so that :noweb no-export can get the unexpanded form. Maybe > > and optional argument =expand= that defaults to t? > > (defun org-babel-get-src-block-info ( light datum expand) > > ... ) > > Hmm, it looks like you're thinking of a different spot than I was > referring to. I was talking about modifying (nth 1 info) in > -execute-src-block, before the (when (org-babel-check-evaluate ...). > > Prior to commit 3b3fc520a, (nth 1 info) was modified in > -execute-src-block but after org-babel-check-evaluate and > org-babel-confirm-evaluate. That makes me think it'd probably be safe > to do again, just a bit upstream in the same function. And I don't see > a spot where modifying that element would be problematic. On the > incoming end, INFO is passed to copy-tree if it is provided as an > argument, and I don't think any of the functions that -execute-src-block > feeds INFO to would be affected. But I of course could be overlooking > something. > > On the other hand, if org-babel-get-src-block-info did the expansion, > I'd be a bit more worried about downstream effects (though I haven't > tried to trace things too closely). Also, -execute-src-block takes a > PARAMS argument, and I think that needs to be merged with (nth 2 info) > before considering whether to expand, so it seems like expanding in > -get-src-block-info would be too soon. > > Regardless of whether modifying (nth 1 info) would work, I also think > it'd be fine to instead go ahead with something along the lines of your > initial patch. In that case, the main question is whether coderefs > should be removed (as they currently are in your patch). If not, > perhaps something like below (untested) would suffice. > > diff --git a/lisp/ob-core.el b/lisp/ob-core.el > index e798595bd..230706b7f 100644 > --- a/lisp/ob-core.el > +++ b/lisp/ob-core.el > @@ -238,7 +238,10 @@ (defun org-babel-check-confirm-evaluate (info) > (if (functionp org-confirm-babel-evaluate) > (funcall org-confirm-babel-evaluate > ;; Language, code block body. > -(nth 0 info) (nth 1 info)) > +(nth 0 info) > +(if (org-babel-noweb-p headers :eval) > +(org-babel-expand-noweb-references info) > + (nth 1 info))) > org-confirm-babel-evaluate > (cond > (noeval nil)
