Re: [BUG] org-element-at-point warning with org-timer in agenda [9.7-pre, release_N/A-N/A-b45b39 @ /home/bhavin/.emacs.d/elpa/org-9.7pre0.20240405.140341/, ]
Here is a patch which fixes the problem. From d34e2cd1a1e830acc6d1575a32522f8e9e5b4d99 Mon Sep 17 00:00:00 2001 From: Bhavin Gandhi Date: Mon, 8 Apr 2024 23:33:29 +0530 Subject: [PATCH] org-timer-set-timer: Don't run `org-entry-get' in non Org buffers * lisp/org-timer.el (org-timer-set-timer): Avoid calling org-entry-get when we are not in an Org buffer. In case of Agenda buffer, we jump to the entry first. It was triggering an org-element warning when used in Agenda buffer, and was failing to find the value of Effort property. This patch is based on a fix by Ihor https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a1fa52197 Reported-by: Bhavin Gandhi Link: https://list.orgmode.org/CAOn=hbez7-4wfg2m1-mshqawvv0mysvlauyp9_gk6mrsbtz...@mail.gmail.com/ --- lisp/org-timer.el | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/lisp/org-timer.el b/lisp/org-timer.el index 8bb8be7be..23bb1c31c 100644 --- a/lisp/org-timer.el +++ b/lisp/org-timer.el @@ -424,9 +424,14 @@ using three \\[universal-argument] prefix arguments." (if (numberp org-timer-default-timer) (number-to-string org-timer-default-timer) org-timer-default-timer)) - (effort-minutes (let ((effort (org-entry-get nil org-effort-property))) - (when (org-string-nw-p effort) - (floor (org-duration-to-minutes effort) + (effort-minutes + ;; When called from Org buffer, remain in position. + ;; When called from Agenda buffer, jump to headline position first. + (org-with-point-at (org-get-at-bol 'org-marker) +(if (derived-mode-p 'org-mode) +(let ((effort (org-entry-get nil org-effort-property))) + (when (org-string-nw-p effort) + (floor (org-duration-to-minutes effort))) (minutes (or (and (numberp opt) (number-to-string opt)) (and (not (equal opt '(64))) effort-minutes -- 2.44.0
[BUG] org-element-at-point warning with org-timer in agenda [9.7-pre, release_N/A-N/A-b45b39 @ /home/bhavin/.emacs.d/elpa/org-9.7pre0.20240405.140341/, ]
When running org-timer-set-timer (bound to `;') in an Org agenda buffer, I get following warning: ⛔ Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org buffer # (org-agenda-mode) I tried to understand the code of org-timer-set-timer. It runs (org-entry-get nil org-effort-property) initially to find the Efforts property. This in-turn calls org-element-at-point. I think the solution could be similar to https://orgmode.org/list/m2leawo9zo@hazy.com where we go to that heading first, and then call org-entry-get? Also, I guess it should check if the buffer is org-agenda-mode or org-mode before running the org-entry-get. Is this a good approach? If yes, I would like to come up with a patch for this. Emacs : GNU Emacs 29.3 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-03-25 Package: Org mode version 9.7-pre (release_N/A-N/A-b45b39 @ /home/bhavin/.emacs.d/elpa/org-9.7pre0.20240405.140341/) -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [BUG] Warning (org-element-cache): Org parser error (error "Invalid search bound (wrong side of point)")
On Wed, 5 Jul 2023 at 23:45, Ihor Radchenko wrote: > Thanks for the report! > May you increase your org-element--cache-diagnostics-ring-size 10x and > try to record the backtrace again? > I can see that org-data boundaries are incorrect (not at point-max), but > cannot track down when exactly the boundaries are not updated properly. So, I got the error again today. First I got following warning followed by the original warning: Received this when I added a new list item under one heading, the heading mentioned in the warning is not the one where I added a new list item. ⛔ Warning (org-element-cache): org-element--cache: Warning(file2.org): Added org-data parent to non-headline element: (section (:begin 15073 :end 16104 :contents-begin 15073 :contents-end 16104 :robust-begin 15073 :robust-end 16102 :post-blank 0 :post-affiliated 15073 :mode section :granularity element :cached t :parent (headline (:raw-value "Project questions" :begin 15030 :end 16104 :pre-blank 0 :contents-begin 15073 :contents-end 16104 :robust-begin 15131 :robust-end 16102 :true-level 1 :level 1 :priority nil :tags nil :todo-keyword "WAITING" :todo-type todo :post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 15030 :CREATED "[2023-04-26 Wed 16:49]" :title "Project questions" :mode nil :granularity element :cached nil :parent (org-data (:begin 1 :contents-begin 1 :contents-end 1407670 :end 1407670 :robust-begin 3 :robust-end 1407668 :post-blank 0 :post-affiliated 1 :path "/home/bhavin/work/orgfiles/file2.org" :mode org-data :CATEGORY "file2" :cached t)) :org-element--cache-sync-key (11 . 15010))) :org-element--cache-sync-key (11 . 15052))) Will see if I can share the whole backtrace. And then while doing something in Agenda (I think that was clock out or save), I got: ⛔ Warning (org-element-cache): org-element--cache: Warning(file2.org): Org parser error in file2.org::#. Resetting. The error was: (error "Invalid search bound (wrong side of point)") I think this has something to do with headings which have many list items, the warnings I have received are from a different file than the previous one. -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [ox-gfm] (was: org mode to github markdown)
On Mon, 8 May 2023 at 18:35, Uwe Brauer wrote: > > >>> "GdaO" == General discussions about Org-mode writes: > > > Uwe Brauer writes: > > >> There seems no export backend for (github) markdown > > > I think you are looking for "ox-gfm". > > Thanks, I realized this is an important pkg for my purpose (although I > have to see how it can be included in my email export) > > But also I can run the function org-gfm-export-as-markdown directly, I > would like to include this exporter directly in the usual > org-export-dispatch but I don't now how, there is now repository or > webapge for this package, and also no email address of the author I think this is the package we are referring to? https://github.com/larstvei/ox-gfm https://list.orgmode.org/m2eh1adtye@ifi.uio.no/ > Anybody has an idea how to incldue ox-gfm into the org-export-dispatch? The README says loading ox-gfm adds it to the org-export-dispatch, I tried doing (require 'ox-gfm) and it started showing up. But I don't know if there is any other/better way to do that. -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: bug#59882: Multiple versions of Org in load-path problem
On Wed, 22 Feb 2023 at 16:17, Ihor Radchenko wrote: > > Bhavin Gandhi writes: > > > I'm able to reproduce this on Fedora 37, Emacs 28.2. > > > > In Fedora we have: > > - /usr/share/emacs/site-lisp/site-start.el (has code to load .el and .elc > > from /usr/share/emacs/site-lisp/site-start.d). > > - /usr/share/emacs/site-lisp/default.el (sets smime-CA-directory). > > May I know what is the contents of > /usr/share/emacs/site-lisp/site-start.d ? These are init files specific to other packages installed via OS package manager. But those are not loaded, it seems in the above steps. I tried to run (featurep 'clang-format) and it returned nil, while this returns t in my normal Emacs instance. $ ls -1 /usr/share/emacs/site-lisp/site-start.d/ autoconf-init.el https://src.fedoraproject.org/rpms/autoconf/blob/rawhide/f/autoconf-init.el clang-format.el clang-include-fixer.el clang-rename.el cmake-init.el https://src.fedoraproject.org/rpms/cmake/blob/rawhide/f/cmake-init.el desktop-entry-mode-init.el https://src.fedoraproject.org/rpms/desktop-file-utils/blob/rawhide/f/desktop-entry-mode-init.el gtypist-init.el https://src.fedoraproject.org/rpms/gtypist/blob/rawhide/f/gtypist.spec#_43-46 mercurial-site-start.el https://src.fedoraproject.org/rpms/mercurial/blob/rawhide/f/mercurial-site-start.el None of these load org-mode. -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: bug#59882: Multiple versions of Org in load-path problem
On Fri, 3 Feb 2023 at 16:35, Ihor Radchenko wrote: > > Max Nikulin writes: > > > On 27/12/2022 16:47, Ihor Radchenko wrote: > >> Can you then try to test using Emacs 28? > >> The main question if whether this has been fixed in newer Emacs releases > >> or it is also something to do with OS environment. > > > > I see quite the same issue with Emacs-28.2 in Debian testing. Compile > > buffer displays a bit more warnings and usual `org-assert-version' > > warnings and errors are present as well. It might have another level of > > complexity due to .eln files. I am unsure what happens with calls to > > undefined macros. > > I asked people around to test using Debian, and we do have a > confirmation that Debian + Emacs 27 and Debian + Emacs 28 do trigger the > error. > > I also installed Debian 11.6.0 on virtual machine, and I was also able to > trigger the error, following the provided steps, using the Emacs 27 > installed via apt-get. > > The problem seems to be real and appears to be some combination of > Debian/Ubuntu + Emacs. I'm able to reproduce this on Fedora 37, Emacs 28.2. In Fedora we have: - /usr/share/emacs/site-lisp/site-start.el (has code to load .el and .elc from /usr/share/emacs/site-lisp/site-start.d). - /usr/share/emacs/site-lisp/default.el (sets smime-CA-directory). There are other patches but most of them are backports and seem to be unrelated to package.el: https://src.fedoraproject.org/rpms/emacs/tree/rawhide Steps using with-emacs.sh (https://github.com/alphapapa/with-emacs.sh): 1. mkdir /tmp/emacs-59882 2. with-emacs.sh -d /tmp/emacs-59882 -- -l org 3. M-x package-list-packages 4. Install Org 9.6.1 from ELPA 5. When the package is compiled you get this error at the end (it is there multiple times) ox.el:82:1: Error: Symbol’s function definition is void: org-assert-version 6. Close Emacs and start it again with with-emacs.sh -d /tmp/emacs-59882 -- -l org 7. I get byte-code: Invalid function: org-assert-version -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
On Wed, 17 Aug 2022 at 15:14, Ihor Radchenko wrote: > >> Yikes! Then, can also check for window-minibuffer-p, but I feel that it > >> will be a fight against all kinds of edge cases. > > > > I haven't been able to make much progress on this bug in the last two > > weeks. Will try to send a patch in a few days, as the steps I gave above > > feels like an edge case which we won't see happening hopefully. > > Your patch will be already an improvement. I'm attaching the patch for the current approach we discussed in this thread. I have tried basic operations like taking note on state change, and have tried with recurring entries which need more than 10 cycles to be marked as done (original bug report). As I was changing the indentation of code from org-add-log-note, I converted some tabs to spaces, is it okay to do so? -- Bhavin Gandhi (bhavin192) | https://geeksocket.in From afb1158d9a360020f093436228cdf4e689474db8 Mon Sep 17 00:00:00 2001 From: Bhavin Gandhi Date: Sun, 25 Sep 2022 22:06:53 +0530 Subject: [PATCH] org.el: Make sure `org-add-log-note' runs at the end of Org command MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org.el (org-add-log-setup): Save `this-command' and `recursion-depth' before adding the `org-add-log-note'to post-command-hook. (org-add-log-note): Execute only if the current `(recursion-depth)' and `this-command' are same as the ones we saved during the log-setup. This change tries to make sure that we run the `org-add-log-note' only after the current Org command has finished executing. Previously, the post-command-hook was getting triggered if the Org command in turn runs some other command. Fixes the bug originally reported by Michael Powe. Bhavin Gandhi. [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note. Sat, 18 Jun 2022 23:30:50 +0530. https://list.orgmode.org/CAOn=hbcsoco++we0xgrhfoxxcexrocpygd1ncjzkyy-9lck...@mail.gmail.com/ Relevant discussion on bug-gnu-emacs: https://debbugs.gnu.org/56425 --- lisp/org.el | 64 - 1 file changed, 34 insertions(+), 30 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index b63aaed4f..ba20df59f 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10355,6 +10355,8 @@ EXTRA is additional text that will be inserted into the notes buffer." org-log-note-how how org-log-note-extra extra org-log-note-effective-time (org-current-effective-time) +org-log-note-this-command this-command +org-log-note-recursion-depth (recursion-depth) org-log-setup t) (add-hook 'post-command-hook 'org-add-log-note 'append)) @@ -10383,37 +10385,39 @@ EXTRA is additional text that will be inserted into the notes buffer." (defun org-add-log-note ( _purpose) "Pop up a window for taking a note, and add this note later." - (remove-hook 'post-command-hook 'org-add-log-note) - (setq org-log-setup nil) - (setq org-log-note-window-configuration (current-window-configuration)) - (delete-other-windows) - (move-marker org-log-note-return-to (point)) - (pop-to-buffer-same-window (marker-buffer org-log-note-marker)) - (goto-char org-log-note-marker) - (org-switch-to-buffer-other-window "*Org Note*") - (erase-buffer) - (if (memq org-log-note-how '(time state)) - (org-store-log-note) -(let ((org-inhibit-startup t)) (org-mode)) -(insert (format "# Insert note for %s. + (when (and (equal org-log-note-this-command this-command) + (= org-log-note-recursion-depth (recursion-depth))) +(remove-hook 'post-command-hook 'org-add-log-note) +(setq org-log-setup nil) +(setq org-log-note-window-configuration (current-window-configuration)) +(delete-other-windows) +(move-marker org-log-note-return-to (point)) +(pop-to-buffer-same-window (marker-buffer org-log-note-marker)) +(goto-char org-log-note-marker) +(org-switch-to-buffer-other-window "*Org Note*") +(erase-buffer) +(if (memq org-log-note-how '(time state)) +(org-store-log-note) + (let ((org-inhibit-startup t)) (org-mode)) + (insert (format "# Insert note for %s. # Finish with C-c C-c, or cancel with C-c C-k.\n\n" - (cl-case org-log-note-purpose - (clock-out "stopped clock") - (done "closed todo item") - (reschedule "rescheduling") - (delschedule "no longer scheduled") - (redeadline "changing deadline") - (deldeadline "removing deadline") - (refile "refiling") - (note "this entry") - (state - (format "state change from \"%s\" to \"%s\"" - (or org-log-note-previous-state "") - (or org-log-note-state ""))) - (t (error &q
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
On Thu, 21 Jul 2022 at 23:33, Bhavin Gandhi wrote: > > On Sat, 16 Jul 2022 at 14:50, Ihor Radchenko wrote: > > > Seems like soon I will cross the TINYCHANGE limit, so I will get the > > > FSF copyright assignment done. > > > > Note that FSF should reply within 5 working days. If not, we can help > > you to push them. > > Thanks! I received the PDF to sign the next day after my email, this > will probably take a couple of days more from my side as I'm talking > with my employer. I finally got this done. I now have a fully executed copy of the copyright assignment (signed by FSF and me). Do I need to send it to someone so that they can check and update the page at https://orgmode.org/worg/contributors.html ? On Tue, 26 Jul 2022 at 17:18, Ihor Radchenko wrote: > > > > So, I saved this-command and (recursion-depth) value, and I'm checking > > for it in the org-add-log-note (attaching diff of my changes). But this > > doesn't guarantee that we are not in the minibuffer when the > > post-command-hook runs. > > > > This is what I did, and it failed after answering the question about 10 > > repeated intervals: > > 1. M-: (y-or-n-p "Some question") > > 2. Now I switched to Org mode buffer. > > 3. Did C-c C-t on the entry. > > > > When org-log-add-setup runs, (recursion-depth) is 1, and > > (minibuffer-depth) is also 1. > > Now, the question about 10 repeated intervals is asked, once I answer > > it, post-command-hook runs. And it runs while we are in the minibuffer > > waiting for 'Some question'. > > Yikes! Then, can also check for window-minibuffer-p, but I feel that it > will be a fight against all kinds of edge cases. I haven't been able to make much progress on this bug in the last two weeks. Will try to send a patch in a few days, as the steps I gave above feels like an edge case which we won't see happening hopefully. -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
[BUG] Incorrect fontification of src blocks for indentation sensitive language modes
In the following Org mode file, the Ledger mode source block is not highlighted correctly. How to reproduce: 1. Clone Ledger mode: git clone https://github.com/ledger/ledger-mode.git /tmp/ledger-mode 2. emacs -Q -L ~/src/org-mode/lisp 3. Evaluate the following in the *scratch* buffer. (add-to-list 'load-path "/tmp/ledger-mode") (require 'ledger-mode) 4. Create an Org mode file test.org with following content --8<---cut here---start->8--- * Some heading - Option one #+begin_src ledger 2022/08/16 Buy books Expenses:Books ₹299 Assets:Cash #+end_src --8<---cut here---end--->8--- 5. The block is not fontified. 6. Now go to the src block and do C-c ', you will see the block correctly fontified, and after doing C-c ' again, we are back to incorrect fontification. I tried to debug this and found the function org-src-font-lock-fontify-block. Turns out that the code block is actually being fontified, but Ledger mode seems to get the block with indentation. I found this by adding a (message string) in this function. --8<---cut here---start->8--- 2022/08/16 Buy books Expenses:Books ₹299 Assets:Cash --8<---cut here---end--->8--- Notice the extra indentation at the beginning of year 2022. This block is not valid Ledger mode content, so it just keeps it grayed out, instead of having colors. If we remove the indentation from the src block in the Org mode file, it gets fontified correctly. Setting org-adapt-indentation to t didn't make any difference. Value of org-src-fontify-natively is t by default. I even tried https://github.com/yantar92/org/tree/feature/org-font-lock-element, it had the same issue. I think the language mode should get the block without the extra indentation. Or am I missing something here? PS: I haven't looked at the code of org-src-font-lock-fontify-block in detail, so I could be wrong with this analysis. -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
On Sat, 16 Jul 2022 at 14:50, Ihor Radchenko wrote: > > Seems like soon I will cross the TINYCHANGE limit, so I will get the > > FSF copyright assignment done. > > Note that FSF should reply within 5 working days. If not, we can help > you to push them. Thanks! I received the PDF to sign the next day after my email, this will probably take a couple of days more from my side as I'm talking with my employer. > Thanks for the idea, I'm exploring (recursion-depth), > (minibuffer-depth). I will come up with a patch to fix this bug. So, I saved this-command and (recursion-depth) value, and I'm checking for it in the org-add-log-note (attaching diff of my changes). But this doesn't guarantee that we are not in the minibuffer when the post-command-hook runs. This is what I did, and it failed after answering the question about 10 repeated intervals: 1. M-: (y-or-n-p "Some question") 2. Now I switched to Org mode buffer. 3. Did C-c C-t on the entry. When org-log-add-setup runs, (recursion-depth) is 1, and (minibuffer-depth) is also 1. Now, the question about 10 repeated intervals is asked, once I answer it, post-command-hook runs. And it runs while we are in the minibuffer waiting for 'Some question'. So, I changed the second condition to (= (minibuffer-depth) 0). This has a different effect when org-todo finishes the execution and we are still in minibuffer: this-command won't be org-todo again unless it is invoked again by the user. org-add-log-note post-command-hook is never removed, and it keeps executing as the condition is not fulfilled. I'm going through the code of org-add-log-note to see if we can avoid calling (delete-other-windows) in the minibuffer. Or move out of minibuffer and then proceed. diff --git a/lisp/org.el b/lisp/org.el index 3d4de5b4f..978850199 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10146,6 +10146,8 @@ EXTRA is additional text that will be inserted into the notes buffer." org-log-note-how how org-log-note-extra extra org-log-note-effective-time (org-current-effective-time) +org-log-note-this-command this-command +org-log-note-recursion-depth (recursion-depth) org-log-setup t) (add-hook 'post-command-hook 'org-add-log-note 'append)) @@ -10174,6 +10176,8 @@ EXTRA is additional text that will be inserted into the notes buffer." (defun org-add-log-note ( _purpose) "Pop up a window for taking a note, and add this note later." + (when (and (equal org-log-note-this-command this-command) + (= org-log-note-recursion-depth (recursion-depth))) (remove-hook 'post-command-hook 'org-add-log-note) (setq org-log-setup nil) (setq org-log-note-window-configuration (current-window-configuration)) @@ -10204,7 +10208,7 @@ EXTRA is additional text that will be inserted into the notes buffer." (t (error "This should not happen") (when org-log-note-extra (insert org-log-note-extra)) (setq-local org-finish-function 'org-store-log-note) -(run-hooks 'org-log-buffer-setup-hook))) +(run-hooks 'org-log-buffer-setup-hook (defvar org-note-abort nil) ; dynamically scoped (defun org-store-log-note ()
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
On Mon, 11 Jul 2022 at 07:26, Ihor Radchenko wrote: > > Bhavin Gandhi writes: > > >> A better fix may relate to the fact that org-add-log-setup is usually > >> used to run org-add-log-note at the end of current command. y-or-n-p or > >> any other kind of command (e.g. added via advice) will break this > >> assumption we use. So, org-add-log-setup could also store > >> `this-command', say, in `org-log-note-this-command' and > >> `org-add-log-note' can then execute only when `this-command' is the same > >> with `org-log-note-this-command'. WDYT? > > > > I had something similar in my mind, something like we check if > > this-command is org-* (not very robust). Your idea makes sense to > > me. But this won't work when read-from-minibuffer is called as it > > doesn't seem to change this-command when it runs. > > Then, we will also need to save (recursion-depth) value and check for it > in addition to this-command. Thanks for the idea, I'm exploring (recursion-depth), (minibuffer-depth). I will come up with a patch to fix this bug. Seems like soon I will cross the TINYCHANGE limit, so I will get the FSF copyright assignment done. -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
On Mon, 4 Jul 2022 at 17:32, Ihor Radchenko wrote: > > While looking at the *Messages* buffer, I came across the command > > y-or-n-p-insert-y. There are commands for n, and other keys. When we > > press y, M-p etc, these commands get executed. So, even if we manage to > > fix the initial example in Emacs, the hook will still run while one is > > in the minibuffer. > > This explains the observed behavior. Apart from these commands triggering the post-command-hook, there is one additional time it gets executed. This is the place when y-or-n-p calls read-from-minibuffer. When read-from-minibuffer executes, this-command remains my-test-command. > A possible fix could be let-binding post-command-hook to > (delq #'org-add-log-note post-command-hook), though we may get a similar > issue in other context in future. > > A better fix may relate to the fact that org-add-log-setup is usually > used to run org-add-log-note at the end of current command. y-or-n-p or > any other kind of command (e.g. added via advice) will break this > assumption we use. So, org-add-log-setup could also store > `this-command', say, in `org-log-note-this-command' and > `org-add-log-note' can then execute only when `this-command' is the same > with `org-log-note-this-command'. WDYT? I had something similar in my mind, something like we check if this-command is org-* (not very robust). Your idea makes sense to me. But this won't work when read-from-minibuffer is called as it doesn't seem to change this-command when it runs. I had created an Emacs bug report: https://debbugs.gnu.org/56425 -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
On Fri, 1 Jul 2022 at 07:43, Ihor Radchenko wrote: > > Currently, when we call `org-auto-repeat-maybe', it adds > > `org-add-log-note' to post-command-hook using `org-add-log-setup'. As > > soon as we reach the question about 10 repeater intervals (the call to > > `y-or-n-p' from `org-auto-repeat-maybe'), the post-command-hook gets > > executed.[1] > > Bhavin, did you have a chance to send a bug report on this to Emacs > devs? Haven't done that yet. But it seems like we will have to find a fix to make sure `delete-other-windows' is not called for the minibuffer. My modified example: (defvar my-hook-counter) (defun my-test-command () (interactive) (message "my-test-command: setting post-command-hook") (setq my-hook-counter 3) (add-hook 'post-command-hook 'my-own-hook) (y-or-n-p "Some question: ") (message "my-test-command: message after setting the hook") ) (defun my-own-hook () (print (format "hook: this: %s, real: %s, last: %s" this-command real-this-command last-command)) (message "my-own-hook: hopefully executing at the end") (setq my-hook-counter (- my-hook-counter 1)) (if (eq my-hook-counter 0) (remove-hook 'post-command-hook 'my-own-hook)) ) While looking at the *Messages* buffer, I came across the command y-or-n-p-insert-y. There are commands for n, and other keys. When we press y, M-p etc, these commands get executed. So, even if we manage to fix the initial example in Emacs, the hook will still run while one is in the minibuffer. -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
[BUG] Could not resolve host: updates.orgmode.org
updates.orgmode.org doesn't seem to have any DNS record (A or CNAME)? dig @9.9.9.9 updates.orgmode.org is not returning any record, and I'm not able to open https://updates.orgmode.org/ -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
[BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
On Mon, 13 Jun 2022 at 23:01, Bhavin Gandhi wrote: > > 1. emacs -Q > > 2. Create test.org with following content > > > > * TODO Repeating entry > > SCHEDULED: <2022-05-01 Mon ++2d> > > > > 3. C-c C-t on the entry, shows the above error. And shifts the scheduled > >date correctly. > > When this error appears, the log note entry about state change is not > added. I found this issue for the first time when I saw the state > change log notes were missing. > > If I do C-c C-t again on the same entry, we get the note. > - State "DONE" from "TODO" [2022-06-13 Mon 22:48] > > This is missing when we hit the error mentioned in the first mail. Confirmed. Trying to change the subject for Woof! for the first time, I hope I get it right. I remember reading this code around a year back, where we were fixing two bugs. 1. Bug: Duplicate logbook entry for repeated tasks: https://list.orgmode.org/orgmode/CAOn=hbcaW1R6vtun-E2r4LS=j3dp=vjqmjgtzy8uc1sypar...@mail.gmail.com/ 2. Bug: org-agenda-undo does not work with repeated tasks [9.4]: https://list.orgmode.org/87v98a8mes@gnu.org/ Currently, when we call `org-auto-repeat-maybe', it adds `org-add-log-note' to post-command-hook using `org-add-log-setup'. As soon as we reach the question about 10 repeater intervals (the call to `y-or-n-p' from `org-auto-repeat-maybe'), the post-command-hook gets executed.[1] So, we end up calling `delete-other-windows' while we are waiting for the user to respond with y/n. And this causes error "Can’t expand minibuffer to full frame". I don't know how to fix this issue yet, but I'm planning to add a test case for completing repeating tasks which need 10+ repeating intervals to shift the date. Maybe this is off-topic: I'm not sure why [1] happens, my assumption was Emacs will wait till all the functions finish executing, and then run the post-command-hooks. this-command remains org-todo (C-c C-t) throughout all the other calls done by org-todo as long as they are not commands i.e. org-auto-repeat-maybe etc. So, I tried following snippet: (defun my-test-command () (interactive) (message "my-test-command: setting post-command-hook") (add-hook 'post-command-hook 'my-own-hook) (y-or-n-p "Some question: ") (message "my-test-command: message after setting the hook") ) (defun my-own-hook () (remove-hook 'post-command-hook 'my-own-hook) (message "my-own-hook: hopefully executing at the end") ) In this case as well, as soon as it calls y-or-n-p, I can see "my-own-hook: hopefully executing at the end" in the minibuffer (while it is still waiting for user input). Is it expected? I read (info "(elisp)Command Overview") but couldn't understand this behavior. -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: Org Agenda Error
On Sun, 12 Jun 2022 at 23:16, Bhavin Gandhi wrote: > 1. emacs -Q > 2. Create test.org with following content > > * TODO Repeating entry > SCHEDULED: <2022-05-01 Mon ++2d> > > 3. C-c C-t on the entry, shows the above error. And shifts the scheduled >date correctly. When this error appears, the log note entry about state change is not added. I found this issue for the first time when I saw the state change log notes were missing. If I do C-c C-t again on the same entry, we get the note. - State "DONE" from "TODO" [2022-06-13 Mon 22:48] This is missing when we hit the error mentioned in the first mail.
Re: Org Agenda Error
Hello Michael On Sun, 12 Jun 2022 at 21:20, Michael Powe wrote: > [MP] Error in post-command-hook (org-add-log-note): (error "Can’t expand > minibuffer to full frame") > [MP] 10 repeater intervals were not enough to shift date past today. > Continue? (y or n) y I have been seeing these with my repeating tasks recently, and took this bug report as an opportunity to see if I can reproduce it with emacs -Q. 1. emacs -Q 2. Create test.org with following content * TODO Repeating entry SCHEDULED: <2022-05-01 Mon ++2d> 3. C-c C-t on the entry, shows the above error. And shifts the scheduled date correctly. This happens on the Org mode version bundled with Emacs 28.1 i.e. release_9.5.2-25-gaf6f12. And with latest main: release_9.5.4-544-gae168d -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: org-capture firefox extension broken [silently]
On Thu, 9 Jun 2022 at 02:45, Samuel Wales wrote: > > i really like and rely on the org-capture extension for firefox. it > has worked for years. i was never able to get manual installation of > org-protocol and bookmarklets to work, so this extension has been > extremely useful.[*] > > however, upon an upgrade and a reboot in a security-supported debian, > text no longer appears in org. > > the extension does flash its large "captured" notification, suggesting > to the user [me] that something did work. i used to rely on that to > know it was captured, but now i do not know what it is a reliable > indicator of. I use it too, and it seems to be working fine on my machines. I have everything setup as given here https://github.com/sprig/org-capture-extension Here are the versions on my system: Firefox 100.0.2 Emacs 28.1 Org mode 9.5.2 Org Capture 0.2.1 In the Preferences of the extension, I have "Use New-Style links?" turned on. > there is a debug option but idk where hte console is in firefox. I was able to see the logs: 1. I turned on Debug, hit the save button. 2. Then I visited https://orgmode.org 3. Hit F12, and then select the "Console" tab. 4. Gear icon > Persist Logs 5. While the webpage was active, I did Ctrl+Shift+L (the shortcut I use for Org Capture). 6. I was able to see a log line in the console: Capturing the following URI with new org-protocol: org-protocol://capture?template=L=https%3A%2F%2Forgmode.org%2F=Org%20mode%20for%20Emacs= Can you try to open the above org-protocol:// link as suggested by Max. -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [DISCUSSION, default settings] Using mailcap as default handler for opening file links
Hello Max, On Mon, 6 Jun 2022 at 19:09, Max Nikulin wrote: > P.P.S. I had a hope that recent Fedora-36 release has Emacs-28 packaged, > so it would be possible to test live image in qemu to quickly check > behavior in full-fledged desktop environment, but version 27 is really > packaged there. I think we will have Emacs 28 in Fedora 37 (that's because major changes are not introduced in beta/released versions)[1]. I can test the Emacs 28 + Fedora 36 combination, if you give me steps to perform. Sorry, I don't have full context on how MIME type stuff applies to Org mode etc., so I can try the steps and report back the behavior. If you want to try it, run these commands when you boot into Fedora 36. This Copr is maintained by me, and is built from the official RPM spec file + modifications for Emacs 28[2]. sudo dnf copr enable bhavin192/emacs-pretest sudo dnf install emacs [1] https://gitlab.com/bhavin192/emacs-pretest-rpm/-/issues/3 [2] https://src.fedoraproject.org/rpms/emacs/pull-request/12#comment-105727 -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: Cannot link to files with no extension
Hello Colin, On Wed, 9 Mar 2022 at 02:24, Colin Baxter wrote: > Org-mode cannot link to files without an extension. I therefore cannot > use org-store-link for org-journal files, etc. I'm not able to reproduce this on the latest main branch. I tried this with Emacs 28.0.91: Opened the COPYING file from org-mode repository. Executed M-x org-store-link Created test.org and did C-c C-l. I was able to create a link and open it with C-c C-o. Can you add more details like version, and steps to reproduce with emacs -Q? -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [BUG] Inline images cannot be displayed [9.5 (release_9.5-108-g93132c @ /tmp/org-mode/lisp/)]
Hello Liu, On Fri, 15 Oct 2021 at 19:49, Liu Hui wrote: > > Org mode cannot display inline images because of an error caused by > org-display-inline-image--width. It seems display-line-numbers-width > is regarded as a number unconditionally. > > Recipe: > > 1. emacs -Q > > 2. Make the following settings: > >(setq org-image-actual-width nil) >(setq org-startup-with-inline-images t) > > 3. Open some org-mode file containing image links, e.g. > >#+attr_org: :width 50% >[[file:~/test.jpg]] Confirmed I was able to reproduce this with the latest main branch. It works fine with attributes like this: #+attr_org: :width 500px And the 9.5 tag does not have this bug, so I think this might be related to recent changes to image width. Adding Timothy to CC who worked on those changes. -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: Someone to help merging orgmode.org/contribute.html and orgmode.org/worg/org-contribute.html ?
Hi Ihor and Bastien, On Thu, 7 Oct 2021 at 21:08, Bastien wrote: > Ihor Radchenko writes: > > > We may want to put reference to Woof docs. Not all users are even able > > to add headers to emails. Or we can simply recommend using word > > "^Confirmed" in emails. I second the mention of something like "Confirmed" instead of email headers. I recently started reading Org mode list, reproducing bug reports, and using email headers is something I haven't managed to do yet (pending as I'm yet to set up some email client). Reading Woof! documentation made it clear about other ways than email headers though. > Yes - this needs to be better documented. I'm currently working on > the next version of Woof!, it will comes with many enhancements, I'll > reference to the new documentation when I make the switch. > Awesome! Thanks. -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]
Hello Marcel, On Tue, 5 Oct 2021 at 19:14, Marcel van der Boom wrote: > […] > - emacs -Q test.org > - make sure the outline is unfolded > - make a change so test.org is 'dirty' > - M-x org-save-all-org-buffers > > Observed behaviour: > The outline in test.org will collapse and only show 'Header one' > > Expected behaviour: > Outline state does not change on calling `org-save-all-buffers` > I tried to follow the above steps with Emacs 27.1, and Org mode latest main branch as well as the release_9.5 tag. The only different step I took was this: emacs -Q -L ~/src/org-mode/lisp/ ~/test.org When I modify the test.org and call org-save-all-org-buffers, all the headings remain unfolded. I tried to switch to a different buffer and called the function, but still it remained in overview state. Maybe someone with the latest Emacs build from master can try to reproduce? -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: master-->main?
Hi Uwe, On Mon, 4 Oct 2021 at 17:50, Uwe Brauer wrote: > > Was master «renamed» main, I mean is the default branch now main instead of > master? > As far as I have understood, yes. master branch was renamed to main. Reference: https://list.orgmode.org/87ee9bbpc9@gnu.org/ -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
[PATCH] org-tools/index.org: Add go-org to list of Org-mode parsers (Worg)
This adds the Org mode parser written in Go to the list of Org-mode parsers. I'm sending a patch for Worg for the first time, I hope this is the correct way to do so. -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in From 12b0f792ff75c7ea2e4dfe24dc54921e4caa24b0 Mon Sep 17 00:00:00 2001 From: Bhavin Gandhi Date: Wed, 11 Aug 2021 23:53:25 +0530 Subject: [PATCH] org-tools/index.org: Add go-org to list of Org-mode parsers --- org-tools/index.org | 1 + 1 file changed, 1 insertion(+) diff --git a/org-tools/index.org b/org-tools/index.org index fbbdd8c8..87e7e665 100644 --- a/org-tools/index.org +++ b/org-tools/index.org @@ -40,6 +40,7 @@ This page lists external tools useful for handling Org files. | [[https://github.com/ixmatus/orgmode-parse][orgmode-parse]] | ? | | | | [[https://hackage.haskell.org/package/org-mode][org-mode]]| Haskell | | | | [[https://github.com/PoiScript/orgize][orgize]] | Rust| | | +| [[https://github.com/niklasfasching/go-org][go-org]] | Go | Niklas Fasching | | * Org-mode exporters -- 2.31.1
Re: Subject: Bug: Org-Clock-Out in indirect buffer error after refile [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
Hello Eddie On Mon, 19 Jul 2021 at 16:15, Eddie Drury wrote: > > When I am working in an indirect buffer and am currently clocked into a > subheading. If I refile this subheading and then run org-clock-out, I get the > error "Clock start time is gone". I'm not sure if this is intended behaviour or a bug, but I was able to reproduce this with the following steps on the latest master. Can you confirm if you are doing something similar as well? Content of test.org #+begin_src org * Read Org mode list ** Triage bugs * Read Emacs bugs list #+end_src 1. Now go to the "Read Org mode list" entry and run, org-tree-to-indirect-buffer (C-c C-x b). 2. Switch to the indirect buffer. 3. Go to the "Triage bugs" entry, and run org-clock-in (C-c C-x C-i). 4. Refile the "Triage bugs" entry to "Read Emacs bugs list" with org-refile (C-c C-w) 5. Switch to test.org buffer, and go to the "Triage bugs" entry, and run org-clock-out (C-c C-x C-o) 6. This will show "Clock start time is gone" > When not working in an indirect buffer, Org Mode is able to track this > subtree and clock out of it, which is the expected behaviour. Yes, I found that it is able to track the refile. -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [PATCH] Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
On Tue, 13 Jul 2021 at 21:06, Alan Ristow wrote: > > Also, thanks to Ihor and Bhavin for your work on this. Prior to applying > the patch, I was noticing new bizarre behavior relating to recurring > tasks. I haven't been running the patched org very long yet, but so far, > so good. Thank you for confirming that it is working correctly for you. > Finally, as a newbie here myself, I have a naïve question of my own: > Provided the patch proves successful, how/when is it applied to the > official org repo? Is it up to Ihor (or somebody else) to make a pull > request, for example? >From my very little experience here, the patch will get reviewed by someone, and one of the maintainers (one with committer access) will merge/apply it in a few days. It might take more time as well. https://orgmode.org/worg/org-contribute.html#what-can-I-expect -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
On Sun, 11 Jul 2021 at 06:59, Ihor Radchenko wrote: > You are right. I believe that I fixed the breakage in the attached > patch. Also, I noticed that c67037 did not fix the original bug when > state change requests interactive note. Thanks! I tested your latest patch, and it is fixing both the original issues which `c67037' solved as well as this one. I was trying to understand your change. So, when we call `org-agenda-todo', it calls `org-todo' which adds the post-command-hook. This hook is supposed to run when `org-agenda-todo' finishes, but instead of that we call it directly. This makes sure that the change is recorded in `buffer-undo-list'. Sorry if that's too much to ask, but why don't we need something similar when org-log-note-how is 'note? Can you please help me understand that? I tried reading org-add-log-note and org-store-log-note, but I think I'm missing something basic here. Also, should this line from org.el (org-store-log-note) be removed? ;; Don't add undo information when called from `org-agenda-todo'.
Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
Hello Ihor, On Sat, 10 Jul 2021 at 19:18, Ihor Radchenko wrote: > The breakage was introduced in commit c67037: > > [c670379adfbdc4883d3cfa230289fd2829993265] Fix `org-agenda-todo' undo > behavior when logging (not adding note) > > The fix is attached. Thank you! I tried the patch, but the original bug[1] which the commit `c67037' tried to fix, gets introduced again. Basically, `org-agenda-undo' just removes the logbook entry and the scheduled date remains new. [1] https://orgmode.org/list/87v98a8mes@gnu.org/
Re: Bug: Unexpected behavior marking recurring tasks as DONE
Hello Alan, Thank you for sharing a detailed description. On Wed, 7 Jul 2021 at 23:52, Alan Ristow wrote: > […] > > > > First, if I do exactly the same as above, the time of completion is > > logged twice: > > > > ** TODO Daily review > >SCHEDULED: <2021-07-08 Thu .+1d> > >:PROPERTIES: > >:LAST_REPEAT: [2021-07-07 Wed 11:18] > >:END: > >:LOGBOOK: > >- State "DONE" from "TODO" [2021-07-07 Wed 11:18] > >- State "DONE" from "TODO" [2021-07-07 Wed 11:18] > >- State "DONE" from "TODO" [2021-07-06 Tue 10:03] > >:END: > > I think this is same issue as reported in this bug report: https://orgmode.org/list/87o8c8xp9b@gmail.com/ > > Second, if I bulk-process a habit via org-agenda-bulk-action, the task > > is simply marked DONE. Bot the recurrence and the LAST_REPEAT field > > are ignored, but the time stamp is only entered into the LOGBOOK once: > > > > ** DONE Walk > >CLOSED: [2021-07-07 Wed 11:26] SCHEDULED: <2021-07-07 Wed .+1d> > >:PROPERTIES: > >:STYLE: habit > >:LAST_REPEAT: [2021-07-06 Tue 15:33] > >:END: > >:LOGBOOK: > >- State "DONE" from "TODO" [2021-07-07 Wed 11:26] > >- State "DONE" from "TODO" [2021-07-06 Tue 15:33] > >:END: I was not able to reproduce this correctly, I will try to reproduce it again later.
Re: getting "before first headline at position xxx in buffer *Org Note*" when clocking out
Hello Timothy On Thu, 1 Jul 2021 at 21:12, Timothy wrote: > > Thanks for going to the effort of working out a series of steps to > reproduce the issue, it's most helpful. If you wouldn't mind, do you > think you could try testing the current HEAD/master and seeing if you > still encounter the issue? I tried the steps on the current master, and I was not able to reproduce this. I think this has been already fixed https://orgmode.org/list/CAP=AKM_MLob51bZx85CtpjDtLNfc+HOe4Ki8xsdmw=ezvhd...@mail.gmail.com/ -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
On Sun, 27 Jun 2021 at 12:01, Bhavin Gandhi wrote: > > Till now I found that the function `org-add-log-setup' is getting > called twice. Why that's happening, I'm not sure yet. I think running > edebug will help here, I'm going to try that. > I found the reason for this behavior with the help of edebug. `org-todo' calls `org-add-log-setup' to log the state change, and then it calls `org-auto-repeat-maybe'. The `org-auto-repeat-maybe' then calls the `org-add-log-setup' again, I think this is for logging something related to repeated entries. Before the change `c670379ad', `org-add-log-setup' used to add `org-add-log-note' to post-command-hook instead of calling it directly. If I have understood the post-command-hooks correctly, it used to keep only one entry of `org-add-log-note'. This is because `add-hook' function makes sure that there are no duplicate entries in the hooks. I'm not sure how this can be fixed, I'm going to read the `org-auto-repeat-maybe' to understand what all it is doing.
Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
On Sat, 26 Jun 2021 at 00:13, Jeff Kowalski wrote: > While I don't have a fix for the root issue, I did have a chance to > create > a lint for LOGBOOK duplicates, as you suggested. Thank you Jeff, I had no clue how to write something like that :) On Sun, 27 Jun 2021 at 07:58, Gustavo Barros wrote: > > I did some digging and, as far as I can tell, the commit which > introduces the bug is "c670379ad Fix `org-agenda-todo' undo behavior > when logging (not adding note)". > > I tested the ECM initially reported, and I don't find the behavior in > commit `b2be3dd0e', but I do find it in `59edcc27c', and what happened > in `master' between the two is `c670379ad'. You are right, I actually did a bisect last week and found that change has introduced this behavior. I should have posted that immediately, it would have saved some of your time. I'm trying to wrap my head around the `org-todo' code as well as the change from `c670379ad'. Till now I found that the function `org-add-log-setup' is getting called twice. Why that's happening, I'm not sure yet. I think running edebug will help here, I'm going to try that. -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
On Mon, 14 Jun 2021 at 19:10, Gustavo Barros wrote: > The marking of repeated tasks as "done" is currently resulting in > duplicate entries in the "LOGBOOK" drawer, which is not expected. I > don't know exactly when this came to be, but it does not happen in the > current built-in version (9.4.4), while it does in the latest release > (9.4.6). I was able to reproduce this, and here are my findings as well as a reproducible configuration with only a few settings. =test.org= file: #+begin_src org * TODO First * TODO Read book SCHEDULED: <2021-06-15 Tue +1d> #+end_src Start emacs -Q and open the test.org file. Go to the 'First' entry, and do C-c C-t. This adds an a timestamp record (this does not happen with 9.4.4, not sure if the default behavior has been changed). Changed test.org file: #+begin_src org * DONE First - State "DONE" from "TODO" [2021-06-14 Mon 23:23] * TODO Read book SCHEDULED: <2021-06-15 Tue +1d> #+end_src Now, load this configuration: #+begin_src elisp (add-to-list 'load-path "~/src/org-mode/lisp/") (setq org-todo-keywords '((sequence "TODO(t)" "|" "DONE(d!)"))) #+end_src Open the test.org again, and go to the "Read book" entry, mark it done with C-c C-t. Now, there are two timestamp changes getting recorded. #+begin_src org […] * TODO Read book SCHEDULED: <2021-06-16 Wed +1d> :PROPERTIES: :LAST_REPEAT: [2021-06-14 Mon 23:26] :END: - State "DONE" from "TODO" [2021-06-14 Mon 23:26] - State "DONE" from "TODO" [2021-06-14 Mon 23:26] #+end_src -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
Re: BUG: Logging habits to LOGBOOK results in double entered time stamp.
Hello Carlo On Wed, 9 Jun 2021 at 10:42, Carlo Tambuatco wrote: > When I mark the task as DONE for the day, it logs the task as: > > :LOGBOOK: > - State "DONE" from "TODO" [2021-06-08 Tue 22:20] <-- Repeated > entry > - State "DONE" from "TODO" [2021-06-08 Tue 22:20] > […] > I'm not able to reproduce this issue with emacs -q and the latest master. But I think that this issue is similar to https://orgmode.org/list/877diwbm6a@gmail.com/T/#u Can you share the value of org-todo-keywords variable? (C-h v org-todo-keywords). -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
[PATCH] org-refile: Fix double slashes in the refile targets
Adding [PATCH] to the subject so that it appears on updates.orgmode.org.
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
On Sun, 23 May 2021 at 23:53, Timothy wrote:
>
> Hi Bhavin! Great to see you on the mailing list :)
>
> Thank you so much for looking at the bugs, investigating one, /and/
> working out a fix. That's absolutely fantastic of you!
Thank you for a welcoming message! :)
On Mon, 24 May 2021 at 00:28, Gustavo Barros wrote:
>
> The patch looks good to me, and corresponds to my analysis of the
> problem and suggested fix. I have only one minor nitpick: you could go
> with a simple `let' there, instead of a `let*', since we only have one
> let-bound variable there anyway.
Yes, I have attached an updated patch.
> > [...] it has other details as well.
>
> As far as I could see, we are very much aligned on the problem and fix.
> But perhaps I'm missing something, could you elaborate on that?
We are indeed aligned. The only additional thing I discovered was
the reason `org-refile--get-location' works despite having double
slashes. That was new for me.
Just experimenting with Woof!
X-Woof-Patch: confirmed
From e069c35ff6011a7f9efe372e675a0bc43ba1fa80 Mon Sep 17 00:00:00 2001
From: Bhavin Gandhi
Date: Sun, 23 May 2021 23:07:13 +0530
Subject: [PATCH] org-refile: Fix double slashes in the refile targets
* org-refile.el (org-refile-get-location): When we generate the `tbl'
variable, we add extra slash depending on the value of
`org-refile-use-outline-path'. This patch updates some locations which
add another extra slash assuming the target did not have it.
`org-refile--get-location' does lookup for entries with and without
slash, so it was not causing any issues before. It works as it is now
as well.
Thanks to Gustavo Barros for a very detailed bug report.
TINYCHANGE
---
lisp/org-refile.el | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index bffad0a81..678759e10 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -649,20 +649,18 @@ this function appends the default value from
(setq old-hist org-refile-history)
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
- (or cdef (concat (car org-refile-history) extra
+ (or cdef (car org-refile-history
(if (setq pa (org-refile--get-location answ tbl))
- (let* ((last-refile-loc (car org-refile-history))
- (last-refile-loc-path (concat last-refile-loc extra)))
+ (let ((last-refile-loc (car org-refile-history)))
(org-refile-check-position pa)
(when (or (not org-refile-history)
(not (eq old-hist org-refile-history))
- (not (equal (car pa) last-refile-loc-path)))
+ (not (equal (car pa) last-refile-loc)))
(setq org-refile-history
(cons (car pa) (if (assoc last-refile-loc tbl)
org-refile-history
(cdr org-refile-history
- (when (or (equal last-refile-loc-path (nth 1 org-refile-history))
- (equal last-refile-loc (nth 1 org-refile-history)))
+ (when (equal last-refile-loc (nth 1 org-refile-history))
(pop org-refile-history)))
pa)
(if (string-match "\\`\\(.*\\)/\\([^/]+\\)\\'" answ)
--
2.31.1
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Finally after spending a couple of hours, I was able to understand the code
of org-refile-get-location \o/. The detailed bug report helped me to
understand the issue. I'm attaching a patch here which should fix the
problem, it has other details as well. I have tested a few basic scenarios
as mentioned in the report.
OTOH, I haven't signed the FSF Copyright assignment yet, should I do it
before this gets merged or it can be done later?
From 234316ed49023362d116d884ba7f2859e5f04c1b Mon Sep 17 00:00:00 2001
From: Bhavin Gandhi
Date: Sun, 23 May 2021 23:07:13 +0530
Subject: [PATCH] org-refile: Fix double slashes in the refile targets
* org-refile.el (org-refile-get-location): When we generate the `tbl'
variable, we add extra slash depending on the value of
`org-refile-use-outline-path'. This patch updates some locations which
add another extra slash assuming the target did not have it.
`org-refile--get-location' does lookup for entries with and without
slash, so it was not causing any issues before. It works as it is now
as well.
Thanks to Gustavo Barros for a very detailed bug report.
TINYCHANGE
---
lisp/org-refile.el | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index bffad0a81..c4ac1c108 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -649,20 +649,18 @@ this function appends the default value from
(setq old-hist org-refile-history)
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
- (or cdef (concat (car org-refile-history) extra
+ (or cdef (car org-refile-history
(if (setq pa (org-refile--get-location answ tbl))
- (let* ((last-refile-loc (car org-refile-history))
- (last-refile-loc-path (concat last-refile-loc extra)))
+ (let* ((last-refile-loc (car org-refile-history)))
(org-refile-check-position pa)
(when (or (not org-refile-history)
(not (eq old-hist org-refile-history))
- (not (equal (car pa) last-refile-loc-path)))
+ (not (equal (car pa) last-refile-loc)))
(setq org-refile-history
(cons (car pa) (if (assoc last-refile-loc tbl)
org-refile-history
(cdr org-refile-history
- (when (or (equal last-refile-loc-path (nth 1 org-refile-history))
- (equal last-refile-loc (nth 1 org-refile-history)))
+ (when (equal last-refile-loc (nth 1 org-refile-history))
(pop org-refile-history)))
pa)
(if (string-match "\\`\\(.*\\)/\\([^/]+\\)\\'" answ)
--
2.31.1
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hello Bastien I'm new to Org mode codebase as well as Elisp. Is this something I can pick up, I was not sure that's why I thought of asking here on the list. -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
bug#44824: 27.1; Org export as pdf and open file does not open it
On Sat, 30 Jan 2021 at 19:04, Maxim Nikulin wrote: > […] > > Geraldo, "M-x shell" case is rather strange. Could you, please, confirm > ones more that okular window with the file content does not appear if > you call xdg-open from an *interactive* emacs shell buffer? The link to > an emacs-orgmode list message, that I have posted earlier, explains why > async-shell-command *may* fail while shell-command should work reliably. > I am really surprised by failure when command is executed in a [e]shell > buffer. > I was expecting something similar, surprisingly here is what I observed on my system (with emacs -Q, GNOME and Evince — Document Viewer). M-x eshell $ xdg-open ~/Documents/test.pdf [Nothing happens] M-x shell $ xdg-open ~/Documents/test.pdf [Evince pops up with the PDF] M-! xdg-open ~/Documents/test.pdf [Evince pops up with the PDF] M-& xdg-open ~/Documents/test.pdf [Nothing happens] Emacs: 27.1.91 GNOME: 3.38.3 xdg-open 1.1.3+ -- Warm Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
