Re: [Problems with org-ref-helm-insert-ref-link and org-id-get-create]
>>> "UB" == Uwe Brauer writes: > So I checked out the org-ref-2 branch from the github repository. > But still there the function org-ref-helm-insert-cite-link is gone and > other related org-ref-helm functions. Is this correct? I got the behaviour back by loading (require 'org-ref-helm) (require 'org-ref-helm-cite) (require 'org-ref-helm-bibtex) Right now I am not sure, what I prefer ;) smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] org-manual.org: org-cite additions
Hi Bruce, Thanks for this patch. I've had a read through and it all looks good to me. I've just applied this with minor tweaks as 30dbfc6. > This is a minor patch to address the most obvious missing pieces that > have confused people. -- Timothy
Re: [BUG] Weird sparse tree folding [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Carlos Pita writes: > That said, my report was about the expansion of: > ... > c3 > ... > to: > * a... > ** b3 > c3 > ... > c4 > ... > > when pressing TAB at the beginning of the first ... Confirmed on current main. Though I plan a bunch of commits that will also fix this particular issue. Best, Ihor
Re: [BUG] require org-macs at compile time [9.5 (9.5-g0a86ad @ /home/phil/.emacs.d/elpa/org-9.5/)]
Hi Phil, > The macro `org-dlet' is not expanded in file org-agenda.el at compile > time when installing Org 9.5 from ELPA. How does this issue manifest? I tried byte-compiling org-agenda.el and didn't see any errors/warnings. -- Timothy
Re: [BUG] org-mode binds C-c C-TAB, which seems illegal [9.5 (9.5-g0a86ad @ /home/il/.config/emacs/elpa/org-9.5/)]
Timothy writes: > I think that the two actions we may want to take here are: > 1. Replace "C-TAB" with "C-" in the keybinding > 2. Change the keybinding to something else that doesn't use control+tab >for instance, "C-c M-TAB" seems to be available. > > Which option seems preferable? Note that 565361eb6 explicitly changed C- to C-TAB: >> Fixes: `org-mode-map` binds `` which is unnecessary and harmful, >> since it takes precendence over bindings of TAB even in keymaps with >> higher precedence. >> >> Reported-by: Daniel Mendler M-TAB may be not good for Windows users. Maybe C-c S-TAB? Though it feels not intuitive. Another possibility may be overloading C-c TAB (org-ctrl-c-tab). Best, Ihor
Re: [PATCH] Accept more :tangle-mode specification forms
Hi All, This has just been pushed as described in fa97f9a39. See some tests I performed before pushing below. #+begin_src text :tangle-mode (identity #o345) :tangle t1.txt this works #+end_src #+begin_src text :tangle-mode 433 :tangle t2.txt this works #+end_src #+begin_src text :tangle-mode u+x :tangle t3.txt this works #+end_src #+begin_src text :tangle-mode rw-r--r-- :tangle t4.txt this works #+end_src #+begin_src text :tangle-mode hey :tangle t5.txt invalid, error message given #+end_src -- Timothy
Re: [BUG] org-occur doesn't hide unmatching top-levels [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Carlos Pita writes: > I see no reason why a match inside b2 will hide b1 and b3 but not a > and c (I'm referring to the headings, not the contents). I think you misread the docstring for org-show-context-detail: >> Alist between context and visibility span when **revealing** a ;; <-- >> revealing! >> location. >> >> Some actions may move point into invisible >> locations. As a consequence, Org always exposes a neighborhood >> around point. How much is shown depends on the initial action, >> or context. This variable does not control how much text is hidden, but rather how much context is revealed around a folded text. Your misunderstanding may come from the fact that you are interested in org-occur, which first folds everything inside lowest-level headings. Consider agenda views. The relevant default value in org-show-context-detail is (agenda . local). If you press on an agenda entry which is located _inside folded subtree_, only the headline will be revealed. However, if e.g. the headline and it's siblings are already revealed, org-show-context-detail will not cause siblings to be hidden. Best, Ihor
Re: [PATCH] ob-R async evaluation
Hi Jeremie, Sorry it's taken a while to get to this. I've just gone through your patch and it looks quite reasonable. I also took the liberty of fixing the indentation in a few spots and tweaking your commit message. This has just been pushed as 58db28d. > I'm attaching a patch that clean up a bit of non conventional coding > practices (mainly because of my ignorance), in ob-R. These were > initially generating warning during the compilation of org-mode. By the way, just letting you know that your mail client declared your .patch to be a PDF file š. > [2. application/pdf; 0001-ob-R.el-Patch-4-async-evaluation.patch]... -- Timothy
Re: [BUG] org-occur doesn't hide unmatching top-levels [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Hi Ihor, On Thu, Nov 18, 2021 at 7:28 AM Ihor Radchenko wrote: > > Carlos Pita writes: > > > I see no reason why a match inside b2 will hide b1 and b3 but not a > > and c (I'm referring to the headings, not the contents). > > I think you misread the docstring for org-show-context-detail: Sorry, I don't concur here. This is in the docstring I'm interested in (org-occur): The tree will show the lines where the regexp matches, and any other context defined in āorg-show-context-detailā, which see. It might be that org-show-context-detail is used for org-reveal, but this says it's also used for org-occur, which makes sense. Besides, there is occur-tree when using the command āorg-occurā (āC-c / /ā) as a context for org-show-context-detail and it indeed makes a difference in what is shown and what is hidden. > This variable does not control how much text is hidden, but rather how > much context is revealed around a folded text. > Your misunderstanding may come from the fact that you are interested in > org-occur, which first folds everything inside lowest-level headings. It's not very relevant to my concern if things are first hidden and then revealed, because that will just change my question to why top-levels are not hidden to begin with. Again: The tree will show the lines where the regexp matches, and any other context defined in āorg-show-context-detailā, which see. The top-level headings in my example don't match the regexp and are not part of the context that org-show-context-detail should reveal with my current configuration. I cannot help concluding that this fact contradicts the documentation. Moreover, even if a escape clause were found in the documentation, the examples I've presented show a behavior that is clearly different for the top-level compared to any other level and that alone calls for some kind of explanation IMO, as it is now it seems arbitrary, perhaps there is an obvious reason for this that I'm failing to grasp. > Consider agenda views. The relevant default value in I indeed considered the agenda, but I prefer using a sparse tree. I have a file with a large number of brief notes in top level headings and it's useful to see the expanded matching notes, the behaviour of org-occur is ideal in this regard, instead the agenda only shows the headings and even in follow mode it's more cumbersome than merely pressing M-g n/p directly in the target buffer. The problem I have now is that hundreds of unmatching headings are still shown just because they happen to be at the top-level. I see I could demote them or just use the agenda, it's no big deal after all. But because of all the reasons above I judge that the current behavior is not right, that's the reason for my report. Nevertheless, thank you for your suggestions, as always. Best regards, Carlos
Re: [BUG] org-occur doesn't hide unmatching top-levels [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Carlos Pita writes:
>> I think you misread the docstring for org-show-context-detail:
>
> Sorry, I don't concur here.
>
> This is in the docstring I'm interested in (org-occur):
I agree that org-occur could have a better docstring.
> It's not very relevant to my concern if things are first hidden and
> then revealed, because that will just change my question to why
> top-levels are not hidden to begin with. Again:
>
> The tree will show the lines where the regexp matches, and any other
> context
> defined in āorg-show-context-detailā, which see.
>
> The top-level headings in my example don't match the regexp and are
> not part of the context that org-show-context-detail should reveal
> with my current configuration. I cannot help concluding that this fact
> contradicts the documentation.
Currently, Org never ever hides headlines without parent and the top
section of the Org buffers.
Note that org-occur's docstring never explicitly states that all
non-matching lines will be hidden, just that matching lines will be
revealed and that the tree will be "compact". Though I understand your
confusion and I do agree that we should either clarify the docstring or
change org-occur to hide non-matching subtrees.
Changing org-occur is actually trivial (just one LOC), but this would be
a major change and can catch old Org users by surprise. I would prefer
to hear other's opinions before pushing such patch upsteam.
>> Consider agenda views. The relevant default value in
>
> I indeed considered the agenda, but I prefer using a sparse tree. I
> have a file with a large number of brief notes in top level headings
> and it's useful to see the expanded matching notes, the behaviour of
> org-occur is ideal in this regard, instead the agenda only shows the
> headings and even in follow mode it's more cumbersome than merely
> pressing M-g n/p directly in the target buffer.
FYI, there is org-agenda-entry-text-mode ("E" in agenda buffers).
Best,
Ihor
Re: [PATCH] Treat :tangle-mode as an octal value not integer
Just removing this from updates.orgmode.org.
Re: [PATCH] org.el (org-display-inline-image--width): Small fix
Just marking this patch as applied for updates.orgmode.org. Nicolas Goaziou writes: > Hello, > > SĆ©bastien Miquel writes: > >> Subject: [PATCH] org.el (org-display-inline-image--width): Small fix > > I expounded the commit message and applied your patch. Thank you. > > Regards,
Re: c47b535bb origin/main org-element: Remove dependency on āorg-emphasis-regexp-componentsā
Max Nikulin writes: > These regexps will always fail under some conditions, since it is not > strict markup. An example is emphasis terminated inside link target > > /A link [[https://orgmode.org/?oops=true][Org Mode]] Your example actually reveals a much bigger issue with current element parser. Even though the link is fontified by Org, if you run org-element-context on the link, it will return nil. The parsed sentence will look like: /A link [[https://orgmode.org/?oops=true][Org Mode]] The reason behind is partially regexps used to detect emphasised text and partially the way our parser works - no intersected objects are allowed. My intuition says that the current parser behaviour is not correct. It would make more sense to prioritise link over italics. However, it would require a major change in the parser - instead of a single pass, the parser may parse different types of objects sequentially. The emphasis objects should come last avoiding the markers to have different parents. Nicolas, WDYT? >> Maybe something like the attached? > > Thank you, Ihor. Another reason why I have not tried to do it myself is > that it is necessary to test behavior for users who customized markers. > The change should not be fatal for them. I have not checked it with you > patch yet. > > I was considering some way to warn users if improper customization is > detected (unexpected marker is noticed). It should be noticeable to make > user aware of export issues but not too annoying. > >> +The characters in the alist must not be changed. They do not affect >> +the actual Org syntax, just fontification. > > Since this is known point of abuses, maybe stronger words are appropriate. > > Do not change makers and do not add new ones to use custom markers for > existing styles or to introduce new styles. Org syntax is not meant to > be configurable and such modifications will not work with export. If you > are interested in fontification of custom markup inside Emacs only, > there are other ways to achieve desired effect. > ... > In addition, I do not like the following phrase in the manual: > >> To narrow down the list of available markup syntax, you can customize >> org-emphasis-alist. I updated the patch dropping your last suggested sentence in the docstring. I find it not very helpful for the user. We should either say nothing (as in the patch) or give a concrete reference how to "achieve the desired effect". Best, Ihor >From c950768bc08b4cae07ba3cb451d8af0abfec7dc8 Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Tue, 16 Nov 2021 15:40:35 +0800 Subject: [PATCH] org-emphasis-alist: Update defcustom making emphasis characters constant * lisp/org.el (org-emphasis-alist): Mention that emphasis characters should not be changed by user. Update the defcustom type accordingly. * doc/org-manual.org (Emphasis and Monospace): Update the referece to `org-emphasis-alist'. --- doc/org-manual.org | 5 +++-- lisp/org.el| 41 - 2 files changed, 39 insertions(+), 7 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index c4bb7ef30..9fea2c42e 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -10814,9 +10814,10 @@ ** Emphasis and Monospace exported verbatim. #+vindex: org-fontify-emphasized-text +#+vindex: org-emphasis-alist To turn off fontification for marked up text, you can set -~org-fontify-emphasized-text~ to ~nil~. To narrow down the list of -available markup syntax, you can customize ~org-emphasis-alist~. +~org-fontify-emphasized-text~ to ~nil~. For more fine-tuned +fontification, you can customize ~org-emphasis-alist~. ** Subscripts and Superscripts :PROPERTIES: diff --git a/lisp/org.el b/lisp/org.el index 603b57279..00ac00ab3 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3833,18 +3833,49 @@ (defcustom org-emphasis-alist marker characters and the face to be used by font-lock for highlighting in Org buffers. +Do not change the characters and do not add new ones to use custom +markers for existing styles or to introduce new styles. Org syntax is +not meant to be configurable and such modifications will not work with +export. + You need to reload Org or to restart Emacs after customizing this." :group 'org-appearance :set 'org-set-emph-re :version "24.4" :package-version '(Org . "8.0") - :type '(repeat + :type '(list (list - (string :tag "Marker character") + (const "*") + (choice + (face :tag "Bold emphasis face") + (plist :tag "Bold emphasis face property list"))) + (list + (const "/") + (choice + (face :tag "Italic emphasis face") + (plist :tag "Italic emphasis face property list"))) + (list + (const "_") + (choice + (face :tag "Underline emphasis face") + (plist :tag "Underline emphasis face property list"))) + (list + (const "=") + (choice + (face :tag "Verbatim emphasis face") + (plist :tag "Verbatim
Re: c47b535bb origin/main org-element: Remove dependency on āorg-emphasis-regexp-componentsā
Hello, Ihor Radchenko writes: > My intuition says that the current parser behaviour is not correct. It > would make more sense to prioritise link over italics. However, it would > require a major change in the parser - instead of a single pass, the > parser may parse different types of objects sequentially. The emphasis > objects should come last avoiding the markers to have different parents. > > Nicolas, WDYT? I disagree. Priority should be given to the first object being started. This is, IMO, the only sane way to handle syntax. Regards, -- Nicolas Goaziou
Re: [Problems with org-ref-helm-insert-ref-link and org-id-get-create]
if you don't get a helm buffer popping up, it could mean you have not turned helm-mode on (e.g. M-x helm-mode). That redefines completing-read in a helm style, and should act and feel like helm when you insert a ref link. If you don't have that on, then you will see the older completing read behavior where you have to press tab to see the candidates etc. The old v2 definition of org-ref-helm-insert-cite-link can be found at https://github.com/jkitchin/org-ref/blob/org-ref-2/org-ref-helm-bibtex.el#L406, but for refs, it probably just calls this function: https://github.com/jkitchin/org-ref/blob/org-ref-2/org-ref-helm.el#L62. in v3, you can customize the insert functions any way you want, so if you want to use the old v2 functions and have them around, there should be no issue with that. I think if you set `org-ref-insert-ref-function` to the function you want, it should just work the way you want. John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Thu, Nov 18, 2021 at 2:46 AM Uwe Brauer wrote: > >>> "JK" == John Kitchin writes: > > > Probably M-x org-ref-insert-ref-link will do what you want. A lot of > things > > got "simplified" in version 3 to leverage completing-read more natively. > > helm-mode should work with org-ref-insert-ref-link. > > I see. I think I got it to work, but the navigation is not entirely > clear to me, if I fire up that function a buffer pops up with possible > labels but how do I do something like scroll-up and scroll-down? > > > See https://github.com/jkitchin/org-ref#configuration for some details > on > > how to configure v3 with helm. > > Honestly I miss a bit the old behaviour, when calling a ref function.[1] > > So I checked out the org-ref-2 branch from the github repository. > > But still there the function org-ref-helm-insert-cite-link is gone and > other related org-ref-helm functions. Is this correct? > > > Footnotes: > [1] I mean the helm menu that popped up > >
Re: c47b535bb origin/main org-element: Remove dependency on āorg-emphasis-regexp-componentsā
Nicolas Goaziou writes: >> My intuition says that the current parser behaviour is not correct. It >> would make more sense to prioritise link over italics. However, it would >> require a major change in the parser - instead of a single pass, the >> parser may parse different types of objects sequentially. The emphasis >> objects should come last avoiding the markers to have different parents. >> >> Nicolas, WDYT? > > I disagree. Priority should be given to the first object being started. > This is, IMO, the only sane way to handle syntax. Multi-pass may indeed over-complicate the syntax. However, it is not clear then how to handle situations like /A link [[https://orgmode.org/?oops=true][Org Mode]] or /A code ~user/?my-user-variable~ with slash/ or /A verbatim =text/.= with slash/ Should we modify the closing-re for emphasis? >> (seq (not space) >> (group ,mark) >> (or (any space ?- ?. ?, ?\; ?: ?! ?? ?' ?\" ?\) ?\} ?\\ ?\[) >> line-end)) Best, Ihor
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
On Wed, Nov 17, 2021 at 7:03 AM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> > Here's another on c47b535bb:
> >
> > https://gist.github.com/aaronjensen/348d879f79099c0d9b660bad199f25af
> >
> > I don't recall what I was doing at the time, it was during a meeting.
>
> I do not see anything meaningful in the backtrace, except that "Current
> command: nil" is probably related to some third-party package. If there
> is nothing obvious in your config that may be responsible, you can set
> org-element--cache-diagnostics-modifications to nil to suppress the
> warning.
>
> Best,
> Ihor
Ok, I've disabled it for now.
I'm seeing another issue and I don't know if it is related. When I
save an org-capture my emacs spins for a long time. I C-g w/
toggle-debug-on-quit and got this:
Debugger entered--Lisp error: (quit)
org-element--parse-generic-emphasis("/" italic)
org-element-italic-parser()
org-element--object-lex((bold citation code entity export-snippet
footnote-reference inline-babel-call inline-src-block italic
line-break latex-fragment link macro radio-target statistics-cookie
strike-through subscript superscript target timestamp underline
verbatim))
org-element--parse-objects(532 1586811 (paragraph (:begin 532 :end
1586811 :contents-begin 532 :contents-end 1586811 :post-blank 0
:post-affiliated 532 :mode nil :granularity nil :parent nil)) (bold
citation code entity export-snippet footnote-reference
inline-babel-call inline-src-block italic line-break latex-fragment
link macro radio-target statistics-cookie strike-through subscript
superscript target timestamp underline verbatim))
org-element--parse-elements(508 1586811 planning nil nil nil
(section (:begin 508 :end 1586812 :contents-begin 508 :contents-end
1586811 :robust-begin 508 :robust-end 1586809 :post-blank 1
:post-affiliated 508 :mode section :granularity nil :parent nil)))
org-element--parse-elements(508 1586811 section nil nil nil
(headline (:raw-value "Report org" :begin 490 :end 1586812 :pre-blank
0 :contents-begin 508 :contents-end 1586811 :robust-begin 510
:robust-end 1586809 :level 1 :priority nil :tags nil :todo-keyword
#("TODO" 0 4 (wrap-prefix #("* " 0 2 (face org-indent)) line-prefix ""
fontified nil)) :todo-type todo :post-blank 1 :footnote-section-p nil
:archivedp nil :commentedp nil :post-affiliated 490 :title (#("Report
org" 0 10 (:parent #7))) :mode nil :granularity nil :parent nil)))
org-element--parse-elements(1 1587283 first-section nil nil nil
(org-data (:begin 1 :contents-begin 1 :contents-end 1587283 :end
1587283 :robust-begin 67 :robust-end 1587281 :post-blank 0
:post-affiliated 1 :path "/Users/path..." :mode org-data :ID
"AB94746D-500B-49F3-9E4F-067D2B7E3976" :CATEGORY "Refile")))
org-element-parse-buffer()
org-roam-db-update-file()
org-roam-db-autosync--try-update-on-save-h()
run-hooks(after-save-hook)
basic-save-buffer(nil)
save-buffer()
org-capture-finalize(nil)
funcall-interactively(org-capture-finalize nil)
command-execute(org-capture-finalize)
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
Aaron Jensen writes:
> I'm seeing another issue and I don't know if it is related. When I
> save an org-capture my emacs spins for a long time. I C-g w/
> toggle-debug-on-quit and got this:
>
>
> Debugger entered--Lisp error: (quit)
> org-element--parse-generic-emphasis("/" italic)
> org-element-italic-parser()
> org-element--object-lex...
> org-element--parse-objects...
> org-element-parse-buffer()
org-element--parse-generic-emphasis has been introduced in very recent
commits. However, I haven't seen issues with this new function.
I tried to run org-element-parse-buffer from a capture buffer. It works
just fine for me.
It would be helpful if you provide a repro.
Also, you can try to debug-on-entry org-element-parse-buffer and check
where exactly the hang happens by stepping through the debugger.
Best,
Ihor
[BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."
On 14/11/2021 14:59, Ihor Radchenko wrote: Ihor Radchenko writes: Confirmed However, I can only trigger the warning up to Emacs 27. Emacs 28 and later has no issue. Need to investigate further. Fixed via c3f457375. This is another case when Emacs internals (replace-match) increase buffer-chars-modified-tick. Eventually, this warning should be disabled and we need to make a patch for Emacs to trigger cache updates regardless of inhibit-modification-hooks. See https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-11/msg01069.html Ihor, I am sorry, but I am still getting the error LANG=en_US.UTF-8 emacs -Q -L ~/src/emacs/org-mode/lisp/ new.org C-\ russian-computer RET A C-* Latin "A" to type Cyrillic "Š¤" Org 58db28db04 + Emacs-26.3
Re: table and Cyrillic characters: org-element--cache: Unregistered buffer modifications detected. Resetting
On 17/11/2021 19:15, Ihor Radchenko wrote: Max Nikulin writes: Unintentionally I pressed some keys and it appeared again ... C-\ russian-computer RET || By "|" I mean Shift+\ that inserts "/" with russian-computer input method. I pushed yet another workaround. That part of code is turning into one giant FIXME and I do not see anything better than patching Emacs itself. Hopefully, not many more built-in places in Emacs are doing similar silent modifications. Unfortunately the issue persists in Emacs-26.3
LinkRemark Firefox extension approved for addons.mozilla.org
A year ago I announced LinkRemark browser extension to save metadata of web pages as notes in Org Mode. New version is available in Firefox catalog (It is not published to Chrome store, the only option is still to load unpacked extension.): https://addons.mozilla.org/firefox/addon/linkremark/ Capture is not ideal and notes require edits. Some subset of schema.org microdata embedded into HTML markup is extracted now. I addressed some issues from comments to first release. Example: #+begin_src org ,* Link: Karl Voit: UOMF: Managing web bookmarks with Org Mode :PROPERTIES: :DATE_ADDED: [2021-09-28 Tue 12:15] :END: - Link URL :: [[https://karl-voit.at/2014/08/10/bookmarks-with-orgmode/]] - Link text :: Karl Voit: UOMF: Managing web bookmarks with Org Mode ,#+begin_quote author: Karl Voit published: [2014-08-10 Sun] ,#+end_quote On the page ,** Adam Porter ā org-almanac :PROPERTIES: :DATE_ADDED: [2021-09-28 Tue 12:15] :LAST_MODIFIED: [2021-09-18 Tue 01:23]ā 09/18/2021 01:23:46 :END: - URL :: [[https://alphapapa.github.io/org-almanac/]] - title :: org-almanac - author :: Adam Porter - referrer :: [[https://www.google.com/]] #+end_src On 26/12/2020 20:49, Ihor Radchenko wrote: Another idea would be providing a callback from elisp to browser (I am not sure if it is possible). org-capture-ref has a mechanism to check if the link was captured in the past. If the link is already captured, the information about the link location and todo-state can be messaged back to the browser. I looked into org-capture-ref code and stole the idea to use an external tool to search in Org files. LinkRemark now can ask native messaging application helper whether URLs are already known. Proof of concept: https://github.com/maxnikulin/burl For the scientific publications, the key point is usually getting DOI/ISBN. At least apparent DOI and links should be recognized now, however with no additional actions. Also, do you pass any of the parsed metadata to org-protocol? If you do, it would be trivial to get it into capture templates on Elisp (and org-capture-ref) side. Actually it was possible even a year ago to specify "object" format instead of "org" and to get extracted metadata in JSON format wrapped into org-protocol URI. I can not say that structure of data has been stabilized and I would not change it again. For example, I tweaked title of captured github issues to include "issue#", which helps to distinguish such pages from individual repo bookmarks. In particular case of GitHub it is better to fetch raw data curl -H 'Accept: application/vnd.github.v3+json' 'https://api.github.com/repos/yantar92/org-capture-ref/issues/2' On 26/12/2020 05:11, Samuel Wales wrote: for example, you could have sets of tabs, selected by right click in firefox, to save to a bunch of org entries. then you could load that particular set of entries into firefox whenever you want. and you could keep notes on each page and move the entries wherever you want. this would be useful for such things as "i am researching rice cookers; these are my tabs, but i don't want them cluttering firefox and i want them with my org notes and to make notes on them and will re-load them into firefox when i want to revisit" I implemented capture of highlighted tab group for Firefox. No ready to use solution is provided to restore it. It is just a tree of Org headings. now if i can only debug the extra-blank-lines-in-capture problem. I hope, a kind of hack to avoid excessive newlines in selected text would not be a source of problems. Clipboard managers might be a trouble though.
Re: [BUG] org-mode binds C-c C-TAB, which seems illegal [9.5 (9.5-g0a86ad @ /home/il/.config/emacs/elpa/org-9.5/)]
On 18/11/2021 04:19, Ingo Lohmar wrote: On Fri, Oct 01 2021 23:16 (+0200), Ingo Lohmar wrote: In 9.5, org-key-map binds org-force-cycle-archived to (kbd "C-c C-TAB"). At least on my machine, this specification is illegal: it generates an entry in org-key-map, but the key presses yield an "undefined" message. Binding the command to (kbd "C-c C-") instead works, but not on a tty. It's been my understanding that "TAB" is the ascii control character, identical to C-i, and hence "C-TAB" cannot work. "" is the GUI system's key event (in my case, X), and does not work on a terminal. it seems that the above bug report has gone unnoticed. It seems the change was introduced in 565361eb698b0b39c1d823ad1565f5bd88fa2034 and persists. Can people actually enter "C-c C-TAB" into their emacs (how?), or has everybody has just bound another key in their config? There were a discussion of GUI-only vs. terminal key events: https://list.orgmode.org/00ca1c7b-1e1d-fc91-eef3-dfc29b51b...@daniel-mendler.de/T/#u
Re: [PATCH] Accept more :tangle-mode specification forms
Hi All, I thought Iād checked for this, but Iāve just noticed that :tangle-mode 755 doesnāt actually work as expected. I assumed 755 would be passed as a string but org-babel-parse-header-arguments actually turns it into an integer, just like (identity #o755). Obviously 755 != #o755 and so this causes issues. As it stands ā755ā works, but that isnāt great (most importantly, itās easy to confuse). Since itās easier to add than remove things like this, we could just get rid of this for now, but a convenient octal notation was a large chunk of the motivation here IIRC. We could also change the implementation to handle :tangle-mode o755, which will make org-babel-parse-header-arguments parse the argument as a string. Iām be keen to hear other peopleās thoughts on this. All the best, Timothy
[BUG] Footnotes break iCalendar export [9.4.6 (9.4.6-g069bcb @ /home/msi/.emacs.d/straight/build/org/)]
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. Hello, I have some footnotes in my Org agenda files. So I want to export my org agenda with this : org-icalendar-combine-agenda-files. Without footnotes, I don't have any problem. But with, I have this in my .ics file. SUMMARY:Hello DESCRIPTION:<2012-04-20 Sat 15:00> CATEGORIES:test END:VEVENT Footnotes ā [1] which isn't very interesting [2] which still isn't very interesting END:VCALENDAR It's, I think, the same problem of this thread : https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg01478.html I try to add this : (footnote-definition . ignore) in ox-ascii.el. But, it doesn't works :/. Thank you in advance. Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2020-09-19 Package: Org mode version 9.4.6 (9.4.6-g069bcb @ /home/msi/.emacs.d/straight/build/org/)
Bug: org-fill-paragraph [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
When using `org-fill-paragraph' on a part of a paragraph, e.g. with halve the lines as active region, it still uses the unselected text around when filling. This works different than `fill-paragraph', `fill-region' and `fill-region-as-paragraph' that fill only the selected part of a paragraph WITHOUT effecting the text around. I don't know if this is a real bug but it is confusing, and annoying because org-mode overrides the default `C-q' key binding for `fill-paragraph' so I have to invoke that command via M-x. Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0) of 2021-02-09, modified by Debian Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)
[BUG] Bug: Footnotes break iCalendar export [9.4.6 (9.4.6-g069bcb @ /home/msi/.emacs.d/straight/build/org/)]
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. Hello, When I make the function "org-icalendar-combine-agenda-files", all it's ok. But, when I add a footnote, I have this in my .ics file : BEGIN:VEVENT. DTSTAMP:2026T101642Z. UID:SC-6a6cf716-f056-4116-a419-5f0e96b14fd9. DTSTART;VALUE=DATE:20220516. DTEND;VALUE=DATE:20220517. SUMMARY:S: Prehistoric Kingdom. CATEGORIES:5References(liensTextes),TODO. END:VEVENT Footnotes ā a footnote another END:VCALENDAR I think that is the same bug of this thread : https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg01478.html So I add too this line: (footnote-definition . ignore) in ox-ascii.el, but it doesn't works. Thank you in advance Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2020-09-19 Package: Org mode version 9.4.6 (9.4.6-g069bcb @ /home/msi/.emacs.d/straight/build/org/)
Re: [PATCH] Accept more :tangle-mode specification forms
Hi Timothy, The confusion with 755 and "755" could lead to security issues in cases like 600 vs "600" vs #o600. The need to protect against the 600 case is fairly important, however I don't think there is anything we can do about it, because someone might want to enter their modes as base 10 integers. If we were to prepend every integer with #o (or setting the radix to 8 when reading this particular field) before passing it to org-babel-parse-header-arguments then it would be impossible to use base 10 integers unless they were provided in the #10r600 form (Emacs doesn't support #d600 notation). I think the best bet is to change the radix for bare integers to 8 when reading that particular header, however I don't know how complex that would be to implement. If we don't want to change the radix to 8 then here are some suggestions. If #o0600 already parses correctly, then I suggest we leave things as is. Adding complexity just to drop the leading # seems wasteful. We may want to warn or raise an error if someone uses a value such as the base 10 integer 600 which does not map to the usual expected octac codes so that they don't silently get bad file modes that could leave files readable to the world. Best, Tom
