Sorting WAITING tasks from old to new
If I look at all my TODOs (org-todo-list) and filter to WAITING (4 r) then all the tasks in this view are shown in the order they appear in the files where the tasks are listed. Is there a way to sort them from old to new (or new to old) so I can see which ones have been in that status for the longest? I looked in the manual and the mailing list archives, and did some searching elsewhere, but didn't turn up any examples of this, which surprised me, so perhaps I overlooked something obvious, but if not, perhaps someone has some code? Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: #9 [[bbb:OrgMeetup]] on Wed, July 10, 19:00 UTC+3
On Wednesday, June 26th, 2024 at 11:48, Ihor Radchenko wrote: > Another OrgMeetup will be scheduled on the second Wednesday of July, > in two weeks. > > URL: https://bbb.emacsverse.org/b/iho-h7r-qg8-led > Time & Date: <2024-07-10 Wed 19:00-21:00 @+03,Europe/Istanbul> If my time zone figuring is correct, the meeting should be on now, but the Big Blue Button session hasn't started so I'm checking in. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: does org mode require a separate LaTeX installation to export?
On Wednesday, June 19th, 2024 at 08:55, Christopher W. Ryan wrote: > In other words, if a complete novice, knowing nothing about LaTeX and > not having it on their machine ever, installed emacs and created an org > mode file, could they export via latex to PDF? Could they export to html? To HTML, yes. They could export to a LaTeX file, but they wouldn't be able to do anything with it: to make the PDF they'd need the LaTeX environment, which Org relies on. (Exporting to OpenDocument, .odt, works out of the box, so if they have LibreOffice or Word they could use that to convert to PDF, which might be more approachable, if that helps.) Cheers, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Citations: strip braces {} in titles in bibliographies in basic style?
On Saturday, May 4th, 2024 at 15:19, Ihor Radchenko wrote: > > I tried to ask for bibtex.el to handle the accurate parsing in > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57712, but it looks like > > it is not of interest upstream. So, we may have to implement a Bibtex > > entry parser according to the spec. > > Fixed, on main. > There is no formal Bibtex format reference, so approximate parsing has to do. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d2df9624c Thanks for coming back to this months later and making it better. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere
On Wednesday, April 17th, 2024 at 06:21, Ihor Radchenko wrote: > I'd like to ask you, Org mode users, whether we should flip the default > value of ~org-auto-align-tags~ to t or leave it as nil I use proportional fonts for regular text (with the mixed-pitch package). In this situation, as far as I know the only way to make tags look at consistent is to set org-tags-column to 0 so they directly follow the text (I make the font size smaller, so there's a large heading then small tag) or to jam them way over as far right as they'll go. Anything else and they look ragged. So I suspect people using variable pitches will already have this turned on, and making it the default won't bother them. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Seeing all the steps when I run an R code block
On Tuesday, April 9th, 2024 at 09:03, Ihor Radchenko wrote: > > Here's one big problem. I have a file, /home/wtd/books/reading/test-r.org, > > and > > in it is this R block: > > > > # - > > > > #+begin_src R :session R:testing :results value > > 1 > > #+end_src > > > > # - > > > > If I execute that with C-c C-c, the R session buffer starts, but in the > > wrong > > working directory. This is in the R session buffer, reported by ESS: > > > > # - > > > > > setwd('/home/wtd/books') > > > I just tested with the latest version of ESS and I am no longer able to > reproduce the problem. > > Do you still see it on your side? Thanks for following up. No, I don't see it any more ... an ESS upgrade or something fixed the problem. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Question about citation formatting
On Tuesday, March 26th, 2024 at 23:17, Christian Wittern wrote: > This paper is discussing and comparing translations to the same text. So > when I mention publications in the text, I want to have the keyword to > be the translator, rather than the author. You could do the citations by hand, the old-fashioned way! But that doesn't use the full power of Org. You could trick the system if you had a bib file where every book had two keys, for example @dogenMoonDewdrop1985 and @t_dogenMoonDewdrop1985. The t_ entries are used for citations in the text, and you've set the translator's name as author so they show the way you want. Their data is copied from the real bib entry, but can be kept simple because only author-date is used. The real bib entries all have some keyword in them (such as "use_this") and you use "#+print_bibliography: :keyword use_this" to print the references. This means if you edit a source's metadata you might need to do it in two places, but it would let you think, "Do I want to cite by translator or author here?" Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
check.sh setup.sh, nohup.out
Some unusual files sneaked in with commit 37cd00bb120. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Bug (?): org-fontify-quote-and-verse-blocks
This variable was new to me when I saw it mentioned last week, so I turned it on, but either it doesn't work or I'm doing something wrong. My steps: In Org source tree, `make repro`. In Emacs: `M-: (setq org-fontify-quote-and-verse-blocks t) RET` Create a temporary Org file like this: #+begin_quote This is a quote. #+end_quote Put pointer inside the quote block and run `M-x describe-text-properties`. It says that the face is org-block, not org-quote as expected: There are text properties here: face (org-block) Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Things got very slow: profiler output
On Saturday, March 16th, 2024 at 14:56, Ihor Radchenko wrote: > Did you try setting org-highlight-latex-and-related to nil? That did it! Thank you! Org is back to normal, fast and responsive. What do you make of all this? Was it just something about my individual setup? (In fact I now have it set to '(script entities). Both 'latex and 'native gave me the problems, but this works.) Thanks again, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Things got very slow: profiler output
On Saturday, March 16th, 2024 at 11:56, Ihor Radchenko wrote: > > > What if you try the following version of `org-activate-folds'? > > > ... > > > > It makes almost no difference. > > Ok. > Then, what about the latest main? I tried it, and I'm sorry to say all the same problems keep happening. I tried the test you mentioned here: https://lists.gnu.org/archive/html/emacs-orgmode/2024-03/msg00362.html I loaded up my big Org file and moved around a while. I got: Function Name Call Count Elapsed Time Average Time org-fold-core--property-symbol-get-create 33325 0.0058796690 1.764...e-07 I don't know if that's helpful. For me all this is triggered by my work-diary.org file, which has fair bit of fontification in it: headings, 1200 clock entries, links, and so on. It had a big clockable at the bottom, which gave me the "Stack overflow in regexp matcher" I mentioned last month: https://lists.gnu.org/archive/html/emacs-orgmode/2024-02/msg00347.html I moved the clocktable to another file and the error stopped. But now it's back. I've been adding to work-diary.org in the meantime, so perhaps the problem was triggered by going over some limit, and I got it down under that limit, but now it's back over. Bruno's problem is triggered by a large file---but surely many people here have large files in Org, so why aren't they seeing this? Frustrating. I turned on debugging and will the regex overflow stack trace below in case it's helpful. (This is beyond my debugging skills, so I'm just pasting in anything I've got now.) To be clear: all these problems happen when I use the latest Org development source. Using the Org in the current Emacs development tree (I'm on 30.0.50), there's no problem. The Emacs source doesn't have the commit I identified earlier as being where my problems started. I'm toggling between versions by commenting this on or off: (use-package org ;; :pin manual ;; :load-path "/usr/local/src/org-mode/lisp" Ihor and Bruno, might it help if we did a video call and shared screens to see problems live? My Lisp is limited but I'll help how I can. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada Debugger entered--Lisp error: (error "Stack overflow in regexp matcher") re-search-forward("^[ \11]*\\(begin{\\([a-zA-Z0-9\\*]+\\)\\(?:.\\|\n\\)+?end{\\2}\\)\\|\\([^$]\\|^\\)\\(\\$[^ \11\15\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\|\\([^$]\\|^\\)\\(\\(\\$\\([^ \11\n,;.$][^$\n\15]*?\\(\n[^$\n\15]*?\\)\\{0,2\\}[^ \11\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\|(\\(?:.\\|\n\\)*?)\\|\\[\\(?:.\\|\n\\)*?\\]\\|\\$\\$\\(?:.\\|\n\\)*?\\$\\$" nil t) org-do-latex-and-related(#) font-lock-fontify-keywords-region(522 # nil) font-lock-default-fontify-region(522 # nil) font-lock-fontify-region(522 #) #f(compiled-function (beg end) #)(522 #) font-lock-ensure(522 #) org-table-align() org-table-map-tables(org-table-align t) org-mode() set-auto-mode-0(org-mode nil) set-auto-mode--apply-alist((("\\.yml$" . yaml-mode) ("\\.\\(r\\(?:ng\\|ss\\)\\|s\\(?:ch\\|vg\\)\\|x\\(?:ml\\|s\\(?:d\\|lt\\)\\)\\)\\'" . nxml-mode) ("\\.[pP][dD][fF]\\'" . pdf-view-mode) ("README\\.md\\'" . gfm-mode) ("\\(?:\\(?:\\.\\(?:b\\(?:\\(?:abel\\|ower\\)rc\\)\\|json\\(?:ld\\)?\\)\\|composer\\.lock\\)\\'\\)" . json-mode) ("\\.hva\\'" . LaTeX-mode) ("\\.tsv\\'" . tsv-mode) ("\\.[Cc][Ss][Vv]\\'" . csv-mode) ("\\.[Ss][Aa][Ss]\\'" . SAS-mode) ("\\.Sout\\'" . S-transcript-mode) ("\\.[Ss]t\\'" . S-transcript-mode) ("\\.Rd\\'" . Rd-mode) ("DESCRIPTION\\'" . conf-colon-mode) ("/Makevars\\(\\.win\\)?\\'" . makefile-mode) ("\\.[Rr]out\\'" . ess-r-transcript-mode) ("CITATION\\'" . ess-r-mode) ("NAMESPACE\\'" . ess-r-mode) ("\\.[rR]profile\\'" . ess-r-mode) ("\\.[rR]\\'" . ess-r-mode) ("/R/.*\\.q\\'" . ess-r-mode) ("\\.[Jj][Aa][Gg]\\'" . ess-jags-mode) ("\\.[Bb][Mm][Dd]\\'" . ess-bugs-mode) ("\\.[Bb][Oo][Gg]\\'" . ess-bugs-mode) ("\\.[Bb][Uu][Gg]\\'" . ess-bugs-mode) ("/git-rebase-todo\\'" . git-rebase-mode) ("\\.\\(?:md\\|markdown\\|mkd\\|mdown\\|mkdn\\|mdwn\\)\\'" . markdown-mode) ("\\.\\(e?ya?\\|ra\\)ml\\'" . yaml-mode) ("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" . elis
Best way to make the Org source tree?
I looked on the site and in the source but didn't see this, but forgive me if I missed something obvious. Say I cloned the Git repository and now I'm in that directory and want to update Org. I'm not doing any development, I just want to stay current. I think these are equivalent: $ make update $ git pull && make Is that right? Is `make autoloads` needed? What should I be running? I ask because I suddenly wondered if I'd been doing this wrong and it was triggering a problem. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Things got very slow: profiler output
On Wednesday, March 13th, 2024 at 19:19, Bruno Cardoso wrote: > For me this improved the situation a bit, but I still get significant > slow-downs as before. > > I don't know if it is related, but if I set a property (C-c C-x p) in a new > heading with no drawers, I'm unable to unfold the newly created drawer (TAB > over it does nothing), although I am able to fold/unfold other already > existent drawers as expected. I don't have that problem, if I understand your description right, but like you Ihor's tweak didn't get things back to normal for me. I'm now using Emacs from the development tree and its Org (which doesn't yet have commit 5d186b499dde97f5 from 25 February) and it's back to normal for now. Could it be something our systems or configurations have in common, Bruno? My Org configuration is here, if you want to compare: https://github.com/wdenton/.emacs.d/blob/master/init.org#org Thanks for looking at this problem, Ihor. If there's anything else to try, I'll try it. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Things got very slow: profiler output
On Thursday, March 7th, 2024 at 11:12, William Denton wrote: > I recompiled Emacs and Org last night and closed all my buffers except for > two medium-sized ones, neither with any LaTeX in them. I restarted and spent > a minute or two with one buffer, closing and expanding headings, and just > moving around without typing, and it quickly slowed down. When I did do a bit > of typing it was very laggy (and will only get worse). The profiler said this: > > 44032 66% - redisplay_internal (C function) > 42619 63% - jit-lock-function > 42603 63% - jit-lock-fontify-now > 42551 63% - jit-lock--run-functions > 42547 63% - run-hook-wrapped > 42543 63% - # > > 42535 63% - font-lock-fontify-region > 42531 63% - font-lock-default-fontify-region > 41987 62% - font-lock-fontify-keywords-region > 40255 60% - org-do-latex-and-related > 40243 60% re-search-forward > 12 0% org-string-nw-p > 1224 1% + org-activate-folds > 156 0% re-search-forward > ... > > I'm happy to try anything else ... I spent a while with git bisect this afternoon and the problem (for me) started here: commit 5d186b499dde97f59a91dc11f4c4a15113d29f4d Author: Ihor Radchenko Date: Sun Feb 25 11:42:44 2024 +0300 org-fold: Refactor fontifying newlines after folds That seems to fit with some of what the profiling showed, in that it's about font-locking, though why LaTeX is mentioned is beyond me. When I was going through the bisect process I wasn't testing on files with LaTeX, I was expanding and folding some I regularly use that have some code blocks and tables with a few hundred lines. My Lisp isn't good enough to see why this commit might have changed behaviour. A couple of people had slowness caused by a spell-checker that was easily fixed ... has no one else seen a problem dating back to late February? Ihor, does this suggest anything to you? Is there anything else I could try? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Emacs slow-down
On Thursday, March 7th, 2024 at 11:03, Pedro Andres Aranda Gutierrez wrote: > Interestingly enough, this redisplay_internal function seems to be the real > pain. I think we need to switch to the main > emacs devel list here... I wonder if those of us seeing this have something in common about our configurations. Might it be a package that's getting in the way, and a change there is causing this? Or does the profiling show it's in base Org? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Things got very slow: profiler output
On Thursday, February 29th, 2024 at 04:25, Bruno Barbier wrote: > Oops, sorry, the customization option is: > > org-highlight-latex-and-related > > (the other value is computed by Org) > > You may try to change that option org-highlight-latex-and-related to see > if it helps. I checked: | Its value is (latex) | Original value was nil I didn't have a chance to dig back into this but now I see other people are reporting slowness and I hope this helps. I recompiled Emacs and Org last night and closed all my buffers except for two medium-sized ones, neither with any LaTeX in them. I restarted and spent a minute or two with one buffer, closing and expanding headings, and just moving around without typing, and it quickly slowed down. When I did do a bit of typing it was very laggy (and will only get worse). The profiler said this: 44032 66% - redisplay_internal (C function) 42619 63% - jit-lock-function 42603 63% - jit-lock-fontify-now 42551 63%- jit-lock--run-functions 42547 63% - run-hook-wrapped 42543 63% - # 42535 63% - font-lock-fontify-region 42531 63%- font-lock-default-fontify-region 41987 62% - font-lock-fontify-keywords-region 40255 60% - org-do-latex-and-related 40243 60% re-search-forward 12 0% org-string-nw-p 1224 1% + org-activate-folds 156 0%re-search-forward ... I'm happy to try anything else ... Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: R session error (org-babel)
On Wednesday, March 6th, 2024 at 05:56, Esteban Venialgo wrote: > I tried the =emacs -Q=, and still get the same problem. Before exporting the > code, I ran this lisp from the scratch pad: > > ;; enable language support for R > (org-babel-do-load-languages > 'org-babel-load-languages > '((R . t) > (shell . t) > (latex . t) > (emacs-lisp . nil))) Hmm! It does work for me. I'm on Ubuntu 22.04, running Emacs and Org from the development tree (so 30.0.50 and 9.7-pre). I ran =emacs -Q= (and also =make repro= from in the Org source tree, which is another useful tool for testing), and executed these lines in a scratch buffer: # - (org-babel-do-load-languages 'org-babel-load-languages '( (R . t) (shell . t) )) (add-to-list 'load-path "~/.emacs.d/elpa/ess-20240229.2054") (require 'ess-r-mode) # - We're the same up to ESS. (I had to check the version number on ESS to get the path right, but that's the latest release installed.) Looking back, did you not mention using ESS? I've never used R in Emacs without it. If you weren't using ESS, what happens if you install it and use it? Just for the sake of documentation: then I made an r.org file with the snippet and ran it, and it worked: # #+begin_src R :session test A <- 1 #+end_src # Cheers, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: R session error (org-babel)
On Tuesday, March 5th, 2024 at 09:12, Esteban Venialgo wrote: > I'm a newbie with org-babel, but I think I'm facing a bug for R code > execution. Basically, I have a simple code for testing: > > #+begin_src R :session test > A = 1 > #+end_src > > I get a lisp error when I try to export this code to latex. Also, if I remove > the session name "test", the code will run in the second attempt. I'm using > Emacs version 28.2 and org-mode version 9.6.17. I can't help understand the error message, but I did try the R sample and have no problem running it and exporting it. I suspect it might be something about your local setup. Could you try starting with =emacs -Q= and loading in Org and enough else to run the R snippet? How to get started with that is here: https://orgmode.org/manual/Feedback.html It doesn't cover getting R working, but we can help with that. I can look for a snippet of code if you need one. Cheers, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Things got very slow: profiler output
I rebuilt Org and Emacs from the development trees and something is wrong, because some Org files I use regularly have become incredibly slow to use. I rarely use the profiler and don't know what to make of what it says, but I opened a file and ran it while I moved around and expanded and collapsed some headings for a minute or so. (It was so slow that it took me a minute to do what would usually take me a few seconds.) I'll paste the results below. Does that say anything useful? There is a little LaTeX in the file but not much. Any help on interpreting this would be welcome. I can try reverting to an earlier Git commit tomorrow. Bill Samples% Function 73203 70% - redisplay_internal (C function) 71496 68% - jit-lock-function 71488 68% - jit-lock-fontify-now 71472 68%- jit-lock--run-functions 71472 68% - # 71472 68% - font-lock-fontify-region 71468 68% - font-lock-default-fontify-region 71436 68%- font-lock-fontify-keywords-region 71124 68% - org-do-latex-and-related 71124 68%re-search-forward 228 0% + org-activate-folds 16 0% + org-fontify-meta-lines-and-blocks 12 0% + org-activate-footnote-links 8 0% org-activate-dates 8 0% + org-activate-links 4 0% org-do-emphasis-faces 4 0% org-fontify-drawers 4 0% org-raise-scripts 28 0%+ font-lock-unfontify-region 4 0%+ font-lock-extend-region-wholelines 4 0% text-property-any 30951 29% + command-execute ... -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax? (was: Subscript with parenthesis)
On Saturday, February 17th, 2024 at 07:07, Ihor Radchenko wrote: > I tentatively propose to remove the x^(2-i) example from the docstring > and mark the ^(...) syntax deprecated. > > WDYT? I think it's very sensible. It's surprising ^(...) works like this, and if anyone was using it (perhaps by accident) it will be easy to change when necessary. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: (jit-lock-function 1) signaled (error "Stack overflow in regexp matcher")
On Thursday, February 15th, 2024 at 15:40, William Denton wrote: > I am having a problem I've never seen before: Org can't handle anything more > in a large file I have! > > This file is where I keep my notes day to day for work, with headings for > months and days and categories of work, with a lot of notes and clocking in > and out. It has about 10,000 lines and is about 550K in size. Update: moving the 600-line clock table in that file to another file fixed the problem. (In that new file, it generates its clock table from the clocking in the remote file, the old one.) Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
(jit-lock-function 1) signaled (error "Stack overflow in regexp matcher")
I am having a problem I've never seen before: Org can't handle anything more in a large file I have! This file is where I keep my notes day to day for work, with headings for months and days and categories of work, with a lot of notes and clocking in and out. It has about 10,000 lines and is about 550K in size. When I add today's notes to the file (fifty lines and ten clockings), it starts throwing these errors: File mode specification error: (error Stack overflow in regexp matcher) Error during redisplay: (jit-lock-function 1) signaled (error "Stack overflow in regexp matcher") Error during redisplay: (jit-lock-function 1501) signaled (error "Stack overflow in regexp matcher") Error during redisplay: (jit-lock-function 3001) signaled (error "Stack overflow in regexp matcher") Org works, but it's not displaying properly: no fancy bullets, no proportional spacing, no font size differences---it looks like I was running it in terminal mode. This makes sense if the problem is with font locking. If I remove today's notes and reload, everything looks fine. If I add in even one more heading and reload, it chokes again and the formatting is all lost. I turned on debugging and restarted, and got a big stack trace, which I will paste in below. If "marker at 770" means line 770 then I don't know what's going on, because it's just regular stuff there and around it. What can I do to determine where the problem is? Any help appreciated. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada Debugger entered--Lisp error: (error "Stack overflow in regexp matcher") re-search-forward("^[ \11]*\\(begin{\\([a-zA-Z0-9\\*]+\\)\\(?:.\\|\n\\)+?end{\\2}\\)\\|\\([^$]\\|^\\)\\(\\$[^ \11\15\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\|\\([^$]\\|^\\)\\(\\(\\$\\([^ \11\n,;.$][^$\n\15]*?\\(\n[^$\n\15]*?\\)\\{0,2\\}[^ \11\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\|(\\(?:.\\|\n\\)*?)\\|\\[\\(?:.\\|\n\\)*?\\]\\|\\$\\$\\(?:.\\|\n\\)*?\\$\\$" nil t) org-do-latex-and-related(#) font-lock-fontify-keywords-region(522 # nil) font-lock-default-fontify-region(522 # nil) font-lock-fontify-region(522 #) #f(compiled-function (beg end) #)(522 #) font-lock-ensure(522 #) org-table-align() org-table-map-tables(org-table-align t) org-mode() set-auto-mode-0(org-mode nil) set-auto-mode--apply-alist((("\\.yml$" . yaml-mode) ("\\.\\(r\\(?:ng\\|ss\\)\\|s\\(?:ch\\|vg\\)\\|x\\(?:ml\\|s\\(?:d\\|lt\\)\\)\\)\\'" . nxml-mode) ("\\.[pP][dD][fF]\\'" . pdf-view-mode) ("README\\.md\\'" . gfm-mode) ("\\(?:\\(?:\\.\\(?:b\\(?:\\(?:abel\\|ower\\)rc\\)\\|json\\(?:ld\\)?\\)\\|composer\\.lock\\)\\'\\)" . json-mode) ("\\.hva\\'" . LaTeX-mode) ("\\.tsv\\'" . tsv-mode) ("\\.[Cc][Ss][Vv]\\'" . csv-mode) ("\\.[Ss][Aa][Ss]\\'" . SAS-mode) ("\\.Sout\\'" . S-transcript-mode) ("\\.[Ss]t\\'" . S-transcript-mode) ("\\.Rd\\'" . Rd-mode) ("DESCRIPTION\\'" . conf-colon-mode) ("/Makevars\\(\\.win\\)?\\'" . makefile-mode) ("\\.[Rr]out\\'" . ess-r-transcript-mode) ("CITATION\\'" . ess-r-mode) ("NAMESPACE\\'" . ess-r-mode) ("\\.[rR]profile\\'" . ess-r-mode) ("\\.[rR]\\'" . ess-r-mode) ("/R/.*\\.q\\'" . ess-r-mode) ("\\.[Jj][Aa][Gg]\\'" . ess-jags-mode) ("\\.[Bb][Mm][Dd]\\'" . ess-bugs-mode) ("\\.[Bb][Oo][Gg]\\'" . ess-bugs-mode) ("\\.[Bb][Uu][Gg]\\'" . ess-bugs-mode) ("/git-rebase-todo\\'" . git-rebase-mode) ("\\.\\(?:md\\|markdown\\|mkd\\|mdown\\|mkdn\\|mdwn\\)\\'" . markdown-mode) ("\\.\\(e?ya?\\|ra\\)ml\\'" . yaml-mode) ("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" . elisp-byte-code-mode) ("\\.zst\\'" nil jka-compr) ("\\.dz\\'" nil jka-compr) ("\\.xz\\'" nil jka-compr) ("\\.lzma\\'" nil jka-compr) ("\\.lz\\'" nil jka-compr) ("\\.g?z\\'" nil jka-compr) ("\\.bz2\\'" nil jka-compr) ("\\.Z\\'" nil jka-compr) ("\\.vr[hi]?\\'" . vera-mode) ("\\(?:\\.\\(?:rbw?\\|ru\\|rake\\|thor\\|axlsx\\|jbuilder\\|rabl\\|gemspec\\|podspec\\)\\|/\\(?:Gem\\|Rake\\|Cap\\|Thor\\|Puppet\\|Berks\\|Brew\\|Fast\\|Vagrant\\|Guard\\|Pod\\)file\\)\\'" . ruby-mode) ("\\.re?st\\'" . rst-mode) ("/\\(?:Pipfile\\|\\.?flake8\\)\\'" . conf-mode) ("\\.py[iw]?\\'" . python-mo
Re: Help: How to change faces of words between parenthesis
On Sunday, February 11th, 2024 at 08:57, Ypo wrote: > Could it be possible to change the color of words between parentheses? > > For example, in: > > "mejorar su bienestar psicológico (Cronin et al., 2012; Molero, Fuster, > Jetten y Moriano, 2011; Outten, Schmitt, García y Branscombe, 2009; > Pérez-Garín et al., 2016)." For citations in brackets, another approach might be to use Org's citation system with the CSL export processor, and then use András Simonyi's org-cite-csl-activate and customize the face: https://github.com/andras-simonyi/org-cite-csl-activate That might involve changing your whole citation process, which is a big step, but citations are on my mind so I thought I'd mention it. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada > > > > Best regards
Re: An academic journal made entirely in Org-Mode
On Monday, January 29th, 2024 at 15:05, Juan Manuel Macías wrote: > In last December, issue 23 of the "Revista de Estudios Latinos" (Journal > of Latin Studies) was published, sponsored by the Spanish Society of > Latin Studies. It is designed and produced by me using Org-Mode, > Org-Publish and LuaTeX. If anyone is interested in the code I used for > specific aspects of the publication, I can share it here :-). Fantastic work! Congratulations. Open scholarship in every sense of the word. I'd love to see how you handled the publishing of such a complex project. (And what citation style is used by that journal?) Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Basic citations: problems with quotes in LaTeX export
While trying out more about basic citations, with quotes to mark strings so I can see where whitespace matters, I found that when exporting to LaTeX some regular quote marks (") turn into fancy ones (“”) but others don't. Let's say we have Basic.bib (now in testing/examples/, adjust path as needed) and this Org file: # -- #+bibliography: Basic.bib #+cite_export: basic [cite: "prefix one" @friends "suffix one"] [cite: "global"; "prefix one" @friends "suffix one"; "prefix two" @friends 'suffix two'; "global"]. # -- Export that to LaTeX and you'll see this (also attached): https://www.miskatonic.org/tmp/latex-quotes.png The suffix quote marks don't turn fancy. Same if you change the citation processor to csl. It's rare to have quotes in citations, but for complex ones with some commentary I could certainly imagine them, for example where you want to refer to a certain word or mention how an author translates it. In any case there's something unexpected going on here. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Basic citations: bugs with citation objects with multiple keys, prefixes, suffixes
I'm figuring out complex citation objects with prefixes and suffixes and multiple keys, and found that not all styles export properly (from what I understand). Here's an Org file that runs through all the citation styles (the Basic.bib is below). Each citation object has a global prefix ("Citing") and global suffix ("is duplication") and the second citation has a local prefix ("and") and local suffix ("also"). # -- #+bibliography: Basic.bib #+cite_export: basic Default: [cite:Citing ; @friends; and @friends also; is duplication.] Author: [cite/a:Citing ; @friends; and @friends also; is duplication.] Note: [cite/ft:Citing ; @friends; and @friends also; is duplication.] Nocite (should be blank): [cite/n:Citing ; @friends; and @friends also; is duplication.] Noauthor: [cite/na:Citing ; @friends; and @friends also; is duplication.] Numeric (should "use global affixes and ignore local ones"): [cite/nb:Citing ; @friends; and @friends also; is duplication.] Text: [cite/t: Citing ; @friends; and @friends also; is duplication.] # -- Export that and you will see some bugs. Default, nocite and numeric look correct, but author and noauthor are missing all the surrounding text (I don't see anything in oc-basic.el about why it shouldn't be there), and in note and text "also" should be outside the brackets. # -- Default: (Citing van Dongen, M.R.C., 2012, and van Dongen, M.R.C., 2012 also is duplication.) Author: van Dongen, M.R.C., van Dongen, M.R.C. Note:[1] Nocite (should be blank): Noauthor: (2012, 2012) Numeric (should "use global affixes and ignore local ones"): (Citing 1, 1 is duplication.) Text: Citing van Dongen, M.R.C. (2012), and van Dongen, M.R.C. (2012 also) is duplication. Footnotes _ [1] Citing van Dongen, M.R.C. (2012), and van Dongen, M.R.C. (2012 also) is duplication. # -- Thanks for looking, Bill Basic.bib is still: @book{friends, title = {{{LaTeX}} and Friends}, author = {van Dongen, M.R.C.}, date = {2012}, location = {Berlin}, publisher = {Springer}, doi = {10.1007/978-3-642-23816-1}, isbn = {9783642238161} } -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Basic citations: should default citation style have a name and style code?
On Sunday, January 14th, 2024 at 03:26, András Simonyi wrote: > I'm not an active Ivy user (although I was in the past) but now I > tried it out with the basic cite-insert processor and "C-u C-j" seems > to be working as "empty input". Phew, what a morning. I removed Ivy, Swiper and Counsel from my configuration and tried Vertico and its connected packages; then find-file didn't work; eventually I discovered some code I'd copied a decade ago and forgotten that was now interfering with completion somewhere; I tried org-cite-insert again and had the same problem; I wondered if I'd have to declare Emacs bankruptcy; I read this response and Joost Kremer's ("You'll run into the same issue with Vertico, I suspect"); I tried C-u C-j in Vertico and was glad it worked; I did some more tweaking to Vertico; I broke something and spent half an hour on that; finally I got everything working. So after about four hours of fiddling things look more or less how they did before, except that Emacs now starts up much, much faster, *and* a long-standing problem with searching in a buffer is now gone: with Swiper, C-s to search would make Org lose the formatting on links and they would show [[in their raw naked form]]. I know someone else had this problem too, so I'm noting this for anyone searching the archives for Swiper. Thanks to you both for your help, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Basic citations: should default citation style have a name and style code?
On Sunday, January 14th, 2024 at 00:08, William Denton wrote: > While we're talking about citations, I'm stuck on something else. If I run > "C-c C-x @" to insert a citation into a file, I'm shown a list of > bibliography entries and I can go up and down and hit RET on any I chose. > That works well. But---the prompt says, "Key (empty input exits)." What makes > empty input? I can't figure it out. I've never seen that phrase before. I > can't make it exit properly---I either keep adding citations or C-g or DEL > cancels it---so I can't make the function work. If anyone knows, I can try > making a patch to make it clearer. As so often happens, a few minutes after sending an email I think I found the answer: it's seems to be a problem with the completion mechanism Ivy. https://stackoverflow.com/q/77489325/854346 I ran "emacs -Q" and I see how it works there, with RET closing things off, which makes sense. Last year I looked at Vertico and thought about trying it out, but since everything was working fine, I didn't. Now I've found a reason, I guess. Ah, Emacs! Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Basic citations: should default citation style have a name and style code?
On Saturday, January 13th, 2024 at 14:03, Ihor Radchenko wrote: > I tried to clarify about the default style and #+cite_export keyword in > the manual: > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=56f6d8d1a > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=83f17091e Thanks! That helps. While we're talking about citations, I'm stuck on something else. If I run "C-c C-x @" to insert a citation into a file, I'm shown a list of bibliography entries and I can go up and down and hit RET on any I chose. That works well. But---the prompt says, "Key (empty input exits)." What makes empty input? I can't figure it out. I've never seen that phrase before. I can't make it exit properly---I either keep adding citations or C-g or DEL cancels it---so I can't make the function work. If anyone knows, I can try making a patch to make it clearer. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at https://orgmode.org/. > > Support Org development at https://liberapay.com/org-mode, > > or support my work at https://liberapay.com/yantar92
Re: Basic citations: should default citation style have a name and style code?
On Thursday, January 11th, 2024 at 13:07, Ihor Radchenko wrote: > Another way is [cite/style-that-surely-does-not-exist:@friends] Useful, thanks. The same thing happens with cite_export: these don't match any real options so they fall through to the defaults. #+cite_export: basic stuff nonsense Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at https://orgmode.org/. > > Support Org development at https://liberapay.com/org-mode, > > or support my work at https://liberapay.com/yantar92
Re: Basic citations: should default citation style have a name and style code?
On Thursday, January 11th, 2024 at 07:30, Ihor Radchenko wrote: > > As far as I can tell, there's nothing that can be done to the first > > citation object to make it use the "default" style. The > > document-level setting makes a new default, and because the original > > "default" has no name or style code, there's no way to get at it. > > You can just use [cite/nil:@friends]. Huh! Thanks, I didn't see that at all. Looking again at the definition of org-cite-basic-export-citation in oc-basic.el, I see the doc string says, "Export CITATION object. STYLE is the expected citation style, as a pair of strings or nil." And then there's a section below starting: ;; Default ("nil") style. Now that I know what that does, I can sort of see what's going on. The same thing is in the CSL code as well, so it's all making more sense now. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at https://orgmode.org/. > > Support Org development at https://liberapay.com/org-mode, > > or support my work at https://liberapay.com/yantar92
Basic citations: should default citation style have a name and style code?
This is a small point, but I think I've found a situation where the lack of a name for a default means there are situations where it can't be used. Let's say we have Basic.bib with this: @book{friends, title = {{{LaTeX}} and Friends}, author = {van Dongen, M.R.C.}, date = {2012}, location = {Berlin}, publisher = {Springer}, doi = {10.1007/978-3-642-23816-1}, isbn = {9783642238161} } Also we have this Org file. Note that it's using the basic citation processor and the author-year bibliography style. There's no bibliography printed, but that doesn't matter for this example. The author-year bibliography style is the default: if it was left out of the cite_export line it would still be used, but it can be specified by name. Because no citation style is set for the document, the default (which has no name) will be used. The first citation object will use the default and the second will be text with caps (/t/c means the style is set with t for text, variant with c for caps): # -- #+bibliography: Basic.bib #+cite_export: basic author-year "Most scholarly works have citations and a bibliography or reference section," wrote a computer scientist [cite:@friends]. [cite/t/c:@friends] wrote, "Most scholarly works have citations and a bibliography or reference section." # -- This exports (C-c C-e t A) to: # -- "Most scholarly works have citations and a bibliography or reference section," wrote a computer scientist (van Dongen, M.R.C., 2012). Van Dongen, M.R.C. (2012) wrote, "Most scholarly works have citations and a bibliography or reference section." # -- But let's say we set the citation style for the document to "text". Now there is no way to use the unnamed "default" citation style! Note the change in the second citation object here, because now text is the default. # -- #+bibliography: Basic.bib #+cite_export: basic author-year text "Most scholarly works have citations and a bibliography or reference section," wrote a computer scientist [cite:@friends]. [cite//c:@friends] wrote, "Most scholarly works have citations and a bibliography or reference section." # -- This exports to: # -- "Most scholarly works have citations and a bibliography or reference section," wrote a computer scientist van Dongen, M.R.C. (2012). Van Dongen, M.R.C. (2012) wrote, "Most scholarly works have citations and a bibliography or reference section." # -- As far as I can tell, there's nothing that can be done to the first citation object to make it use the "default" style. The document-level setting makes a new default, and because the original "default" has no name or style code, there's no way to get at it. The basic citation processor is a proof of concept and shouldn't be used for real work, so this is probably never going to result in a real problem. Nevertheless, it seems like a bug. There is a combination that should be possible but isn't. Sadly my Lisp isn't good enough for me to offer a working solution, but if the default citation style had, for example, the name "default" and one-letter code "d" then I think the problem would go away. With thanks to everyone who did all the great citation work originally, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: #5 [[bbb:OrgMeetup]] on Wed, Jan 17, 19:00 UTC+3
On Tuesday, January 2nd, 2024 at 06:31, Ihor Radchenko wrote: > Another OrgMeetup will be scheduled on the third Wednesday of January, > in two weeks. > ... > URL: https://bbb.emacsverse.org/b/iho-h7r-qg8-led > Time & Date: <2024-01-17 Wed 19:00-21:00 @+03,Europe/Istanbul> Thanks for organizing another one, Ihor. So I make sure I have the time right, it's at 1600 UTC, so this will give anyone the correct local time? (With apologies for stepping outside Org.) $ date -d '17 January 2024 16:00 UTC' Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: [PATCH] Set Python shell in Org edit buffer
On Sunday, January 7th, 2024 at 14:06, Jack Kamm wrote: > It looks like ob-R and ob-julia are the only languages that start > sessions on edit (based on grepping for "edit-prep" and > "associate-session"). > > I think their behavior is peculiar enough to have an ob-R/julia-specific > option on whether to initiate session on edit, with options nil, t, and > earmuffs. Earmuffs is the current behavior, but it's surprising enough > (IMO) that it might be worth changing the default to nil or t. But still > worth keeping the earmuffs option since this behavior seems to go back > to the original implementation (30931bfe1). I'm a regular R user and think this is a great idea. A while back I had a bunch of problems with Org unexpectedly opening R buffers unexpectedly and I had no idea why it was happening. (In fact I never really did until reading this.) I fixed it by simplifying my R setup and removing some hooks and such, and now things work reasonably and I'm familiar with what happens when. Having an option to control this would be a helpful addition. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: strange error exporting to ascii
On Thursday, December 21st, 2023 at 10:44, Fraga, Eric wrote: > So, long story short, I try to export the original document to ascii and > I get an error related to citations. Having seen some updates to > exporting citations on the list over the past few weeks, I figured I > should upgrade org to the latest version. Now exporting to LaTeX still > works just fine but exporting to ascii still does not work (with the > same error: see backtrace-ascii.txt attached) and exporting to ODT now > no longer works (see backtrace-odt.txt). I've been doing a lot of exporting to various formats lately, testing out basic and CSL citations, and ran into a few bugs but not what you're showing. And nothing about ODT was touched, IIRC. Could you try narrowing down to citations only, and commenting out one by one until it works? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Citations bug with basic processor, plain bibliographies, LaTeX
On 18 December 2023, Ihor Radchenko wrote: Sigh... Fixed, on main. (I hope) https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=41726d408 Fixed! Thanks. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 422.67 ppm (Mauna Loa Observatory, 2023-12-17)
Re: Citations bug with basic processor, plain bibliographies, LaTeX
Ihor, you patched this, but I rebuilt Org and tried again and it fails with a *Messages* showing a slightly different error: org-cite-basic--shorten-names: Wrong type argument: stringp, (raw nil #("van Dongen, M.R.C." 0 18 (:parent #0))) Soon all of these bugs will be squashed! Thanks, Bill On 15 December 2023, William Denton wrote: I've found a bug on main that I think is related to the recent patches about raw string objects. Try this as Basic.bib: @book{friends, title = {{{LaTeX}} and Friends}, author = {van Dongen, M.R.C.}, date = {2012}, location = {Berlin}, publisher = {Springer}, doi = {10.1007/978-3-642-23816-1}, isbn = {9783642238161} } And then this as basic.org: # -- #+bibliography: Basic.bib #+cite_export: basic plain numeric [cite:@friends] #+print_bibliography: # -- Exporting to text, HTML or ODT works, but trying with LaTeX gives this error: mapconcat: Wrong type argument: stringp, (raw nil #("van Dongen, M.R.C." 0 18 (:parent #0))) -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 422.67 ppm (Mauna Loa Observatory, 2023-12-17)
Citations bug with basic processor, plain bibliographies, LaTeX
I've found a bug on main that I think is related to the recent patches about raw string objects. Try this as Basic.bib: @book{friends, title = {{{LaTeX}} and Friends}, author = {van Dongen, M.R.C.}, date = {2012}, location = {Berlin}, publisher = {Springer}, doi = {10.1007/978-3-642-23816-1}, isbn = {9783642238161} } And then this as basic.org: # -- #+bibliography: Basic.bib #+cite_export: basic plain numeric [cite:@friends] #+print_bibliography: # -- Exporting to text, HTML or ODT works, but trying with LaTeX gives this error: mapconcat: Wrong type argument: stringp, (raw nil #("van Dongen, M.R.C." 0 18 (:parent #0))) Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.80 ppm (Mauna Loa Observatory, 2023-12-14)
Re: Citations: strip braces {} in titles in bibliographies in basic style?
On 13 December 2023, Ihor Radchenko wrote: This is a more difficult problem actually, because Bibtex allows more than just curly braces - see https://www.bibtex.org/SpecialSymbols/ and https://www.bibtex.org/Format/. I tried to ask for bibtex.el to handle the accurate parsing in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57712, but it looks like it is not of interest upstream. So, we may have to implement a Bibtex entry parser according to the spec. Wow, I didn't see any of that when I was looking at this. I should have guessed there was more under the surface---there always is with LaTeX. Thanks for the history. "If this doesn't fit your needs for org mode, I suggest you develop a LaTeX parser that can process LaTeX code according to your needs." Ah well. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.99 ppm (Mauna Loa Observatory, 2023-12-12)
Re: Strange behaviour detected today
On 13 December 2023, Pedro Andres Aranda Gutierrez wrote: I've recompiled emacs master today and when I try to export an org presentation to latex and I get the following error: Exporting to LaTeX [class: beamer]... set-face-attribute: Invalid face box: :line-width, 1, :color, grey40 This happens when calling (org-beamer-export-to-latex) both from emacs in interactive and in batch mode. Is that perhaps related to commit dcd755dabcf9ef95d6d0534c11c668f44c6f89c2, "Fix validation of :box face attribute"? It caused similar errors in solarized-theme (for example this bug¹). Bill ¹ https://github.com/bbatsov/solarized-emacs/issues/447 -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.99 ppm (Mauna Loa Observatory, 2023-12-12)
Citations: strip braces {} in titles in bibliographies in basic style?
Let's say we have a file Basic.bib, like so, with one or two pairs of braces around words that need special case preservation: @book{friends, title = {{LaTeX} and Friends}, author = {van Dongen, M.R.C.}, date = {2012}, location = {Berlin}, publisher = {Springer}, doi = {10.1007/978-3-642-23816-1}, isbn = {9783642238161} } @book{lispandc, title = {Lisp and {C}}, author = {Example, Example}, publisher = {Example}, date = {2023} } Either one or two braces works and could well be used. The Zotero extension Better Bibtex has a FAQ explaining why it uses two by default: "because the Bib(La)TeX case protection rules are incredibly convoluted."¹ We also have an Org file (where "/n" means no citation but the work stills goes in the bibliography; note that the basic citation style is set): # - #+bibliography: Basic.bib #+cite_export: basic [cite/n:@friends] [cite/n:@lispandc] #+print_bibliography: # -- Exporting to text (C-c C-e t A) gives this: # -- Example, Example (2023). /Lisp and {C}/, Example. van Dongen, M.R.C. (2012). /{{LaTeX}} and Friends/, Springer. # -- The braces are there. The're also visible in the HTML and ODT exports. In LaTeX, in this example, they're exported but ultimately invisible because of how LaTeX handles "\textit{Lisp and {C}}". Should they be stripped? I suggest they should. The basic style is very basic and doesn't do anything fancy in bibliographies---just some italics on titles, which it's showing in the text export with slashes, and does nicely in the others---but I wonder if it should remove the braces. They are used to preserve case in titles, but the basic exporter doesn't change case. Passing the braces through means people will have to edit them out in every basic export. Bill ¹ https://retorque.re/zotero-better-bibtex/support/faq/#why-the-double-braces -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.66 ppm (Mauna Loa Observatory, 2023-12-11)
Re: [PATCH] Add new option 'org-imenu-flatten'
On 8 December 2023, Morgan Smith wrote: Have you considered adding a "flatten" option to imenu itself? That way, you could automatically get the functionality for free everywhere, not just in Org mode. I have considered that but gave up with minimal investigation because it seemed harder then this solution. It's possible imenu did actually have this functionality sometime before 1998 (see commit fe2908be7b09f4c765ebdaf16fe07b0a77f78ba8). One of the things I love about Emacs is the longevity, which leads to someone musing about a feature that might have existed 25 (!) years ago. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 420.74 ppm (Mauna Loa Observatory, 2023-12-07)
Re: Citations and basic processor: examples of some things that don't work
On 7 December 2023, Ihor Radchenko wrote: This is another, new bug I introduced while fixing the previous one :) Fixed, on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a59193e47 Fantastic! Thanks. Now it all works. It would be nice to have proper tests for oc-basic and other oc-* backends. I'll have a look in there and see if I can add some. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 420.04 ppm (Mauna Loa Observatory, 2023-12-01)
Re: Citations and basic processor: examples of some things that don't work
Thanks for digging into this, Ihor. It exports now, but I'm afraid it's doing too much capitaliztion. A name like "van Dongen" should become "Van Dongen" when cited with a caps variant, for example [cite/a/c:@friends]. This is turning it into "VAN DONGEN", upcasing the whole string when it should just be doing the first letter. I looked into how the CSL versions handles it. In citeproc-el's citeproc-site.el there's this: "CAPITALIZE-FIRST is non-nil if the first word of the rendered citation should be capitalized." That goes with this in oc-csl.el in the definition of org-cite-csl--create-structure-params for doing a /a/c author-caps citation: ((or "caps" "c") '(:mode author-only :capitalize-first t)) So for the basic exporter to do what the CSL one does, it should just capitalize the first letter. I hope you don't mind opening up that file one last time for this fix ... Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 420.04 ppm (Mauna Loa Observatory, 2023-12-01)
Re: Citations and basic processor: examples of some things that don't work
On 29 November 2023, Ihor Radchenko wrote: William Denton writes: Attached (I think attachments work on this list) is a small Org file that has a table that sets out all the various options possible with the basic processor for citations. Most work, but not the author style, and the caps and bare-caps variants never do. Seems to work for me on main. Unless I miss something: ASCII export: Huh! I never tried ASCII export. I see HTML works, too. Try LaTeX or ODT. My apologies, I should have specified that. It should throw an error that starts like this: Debugger entered--Lisp error: (wrong-type-argument char-or-string-p (raw nil #("van Dongen, M.R.C." 0 18 (:parent #3 capitalize((raw nil #("van Dongen, M.R.C." 0 18 (:parent #1 (if caps (capitalize a) a) (org-cite-concat p (if caps (capitalize a) a) ", " y s) (closure ((caps "c" "bc")) (p a y s) (org-cite-concat p (if caps (capitalize a) a) ", " y s))(nil (raw nil #("van Dongen, M.R.C." 0 18 (:parent #2))) "2012" nil) funcall((closure ((caps "c" "bc")) (p a y s) (org-cite-concat p (if caps (capitalize a) a) ", " y s)) nil (raw nil #("van Dongen, M.R.C." 0 18 (:parent #3))) "2012" nil) I can reproduce this by running "make repro" on main and then loading in that basic.org file. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 420.59 ppm (Mauna Loa Observatory, 2023-11-28)
Citations and basic processor: examples of some things that don't work
Attached (I think attachments work on this list) is a small Org file that has a table that sets out all the various options possible with the basic processor for citations. Most work, but not the author style, and the caps and bare-caps variants never do. To test try changing parentheses to square brackets, for example (cite/t/c:@friends) to [cite/t/c:@friends], and exporting. From what I see in oc-basic.el, everything in the table should work. Changing the processor to use CSL, they all do. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.47 ppm (Mauna Loa Observatory, 2023-11-24)@book{chassellIntro, title = {An Introduction to Programming in {{Emacs Lisp}}}, author = {Chassell, Robert}, date = {2023}, publisher = {{GNU Press}}, location = {Boston}, url = {https://www.gnu.org/software/emacs/manual/eintr.html} } @book{friends, title = {{{LaTeX}} and Friends}, author = {van Dongen, M.R.C.}, date = {2012}, location = {Berlin}, publisher = {Springer}, doi = {10.1007/978-3-642-23816-1}, isbn = {9783642238161} } #+title: Org citations with the basic processor #+author: #+date: #+startup: showall align #+options: num:nil ^:nil toc:nil #+bibliography: Basic.bib #+cite_export: basic Something like =(cite//c:@friends)= is a citation that does not work. Test by changing the parentheses to square brackets and exporting. #+attr_latex: :environment longtable | style | variant| cite| result| |---++-+---| | || : | [cite:@friends] | | | b (bare) | //b:| [cite//b:@friends]| | | c (caps) | //c:| (cite//c:@friends)| | a (author)|| /a: | (cite/a:@friends) | | a (author)| c (caps) | /a/c: | (cite/a/c:@friends) | | ft (note) || /ft:| [cite/ft:@friends]| | ft (note) | b (bare) | /ft/b: | [cite/ft/b:@friends] | | ft (note) | bc (bare-caps) | /ft/bc: | (cite/ft/bc:@friends) | | ft (note) | c (caps) | /ft/c: | (cite/ft/c:@friends) | | n (nocite)|| /n: | [cite/n:@friends] | | na (noauthor) || /na:| [cite/na:@friends]| | na (noauthor) | b (bare) | /na/b: | [cite/na/b:@friends] | | nb (numeric) || /nb:| [cite/nb:@friends]| | t (text) || /t: | [cite/t:@friends] | | t (text) | b (bare) | /t/b: | [cite/t/b:@friends] | | t (text) | bc (bare-caps) | /t/bc: | (cite/t/bc:@friends) | | t (text) | c (caps) | /t/c: | (cite/t/c:@friends) | * Bibliography # You can specify "plain" or "numeric," and anything else turns into author-year. #+print_bibliography:
Re: Citation bug with basic and nb style: no matching number on bibliographic entry
Ignore this. To make the numbering appear in the bibliography, use this: #+cite_export: basic numeric I'm working my way through all the combinations and will submit some patches for the documentation when I have it figured out more. Bill On 27 November 2023, William Denton wrote: I'm trying citations with the basic processor, and have found what seems to be a problem with the "nb" (numeric) style: the citation has a number, but it's not matched to anything in the bibliography. Try this as Basic.bib: @book{chassellIntro, title = {An Introduction to Programming in {{Emacs Lisp}}}, author = {Chassell, Robert}, date = {2023}, publisher = {{GNU Press}}, location = {Boston}, isbn = {1-882114-43-4}, url = {https://www.gnu.org/software/emacs/manual/eintr.html}, keywords = {emacs} } And this as basic.org: # -- #+bibliography: Basic.bib #+cite_export: basic Emacs comes with a guide to learning Emacs Lisp [cite/nb:@chassellIntro]. * Bibliography #+print_bibliography: # -- Exporting to PDF, the citation becomes (1), but there's no matching number in the bibliography, so the citation and the source are not connected. You can't connect (1) to Chassell, Robert. (Using two sources doesn't make numbers suddenly appear.) Using the CSL processor and the IEEE style (the sort of style on which I assume the basic nb style is based) the citation is [1] and the book is listed as [1] in the bibliography. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.47 ppm (Mauna Loa Observatory, 2023-11-24) -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.47 ppm (Mauna Loa Observatory, 2023-11-24)
Citation bug with basic and nb style: no matching number on bibliographic entry
I'm trying citations with the basic processor, and have found what seems to be a problem with the "nb" (numeric) style: the citation has a number, but it's not matched to anything in the bibliography. Try this as Basic.bib: @book{chassellIntro, title = {An Introduction to Programming in {{Emacs Lisp}}}, author = {Chassell, Robert}, date = {2023}, publisher = {{GNU Press}}, location = {Boston}, isbn = {1-882114-43-4}, url = {https://www.gnu.org/software/emacs/manual/eintr.html}, keywords = {emacs} } And this as basic.org: # -- #+bibliography: Basic.bib #+cite_export: basic Emacs comes with a guide to learning Emacs Lisp [cite/nb:@chassellIntro]. * Bibliography #+print_bibliography: # -- Exporting to PDF, the citation becomes (1), but there's no matching number in the bibliography, so the citation and the source are not connected. You can't connect (1) to Chassell, Robert. (Using two sources doesn't make numbers suddenly appear.) Using the CSL processor and the IEEE style (the sort of style on which I assume the basic nb style is based) the citation is [1] and the book is listed as [1] in the bibliography. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.47 ppm (Mauna Loa Observatory, 2023-11-24)
Citation bug with print_bibliography :filter "keyword phrase" with spaces
I think I've found another bug with citations, this time about filtering on keywords when printing bibliographies with the CSL processor. Either that or I'm wrong about how it works. Here's a test .bib file; note the "keyword phrase" keywords. Filtering doesn't work on them. Test.bib: @article{article1, title = {Title Here}, author = {Denton, William}, date = {2020-01-01}, journaltitle = {Journal Title}, issue = {1}, keywords = {keyword phrase} } @article{article2, title = {Title Here Too}, author = {Denton, William}, date = {2023-11-01}, journaltitle = {Journal Title Too}, issue = {2}, keywords = {keyword phrase} } @book{book1, title = {Mastering Emacs}, author = {Petersen, Mickey}, date = {2022}, keywords = {emacs} } And here's an Org file. For exporting I'm using CSL, referring to a style in my Zotero directory. Any Zotero user will have this, but I don't know how to make it easily reproducible for others. ### - Org file starts #+bibliography: Test.bib #+cite_export: csl ~/Zotero/styles/chicago-author-date.csl * Text One article: [cite:@article1]. Another article: [cite:@article2]. And a real book: [cite:@book1]. * Everything #+print_bibliography: * Emacs #+print_bibliography: :keyword emacs * Keyword phrase #+print_bibliography: :keyword "keyword phrase" ### -- Org file ends When exported to LaTeX, the complete bibliography and the Emacs bibliography are there, but the "keyword phrase" one isn't. The manual says, "Values including spaces must be surrounded with double quotes." I did that, but based on this it doesn't seem to be working. (I'm running Org from the development branch.) Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.56 ppm (Mauna Loa Observatory, 2023-11-22)
Citation bug: cite/a does not work with basic
I'm finally starting to investigate citations (what an astounding amount of work went into it all!) and ran across what seems to be a small bug. Test.bib file: @article{test2023, title = {Title Here}, author = {Denton, William}, date = {2023-11-23}, journaltitle = {Journal Title}, volume = {2}, number = {3}, issue = {5} } Make an Org file with three lines, using cite/a to get the author citation: ┌ │ #+bibliography: Test.bib │ #+cite_export: basic author author-year │ [cite/a:@test2023] └ Try to export it to LaTeX with "C-c C-e l l" and we get this error: Wrong type argument: characterp, raw However, change it to cite/n: or cite/t: or just plain cite: and it will work. I think it should work with cite/a, but I'm not sure what's going on. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 420.61 ppm (Mauna Loa Observatory, 2023-11-21)
Re: org-agenda t giving "Wrong type argument: stringp, nil"
On 11 October 2023, Ihor Radchenko wrote: Thanks for reporting! I am unable to reproduce the problem on my side, unfortunately. May you enable `debug-on-error' and post the backtrace? Or provide a reproducer. Whatever my problem was, it has now gone away. I updated the source tree and all was fine. Whew! Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 419.81 ppm (Mauna Loa Observatory, 2023-10-15)
org-agenda t giving "Wrong type argument: stringp, nil"
I updated things from source today and got an error when trying to view my agenda: M-x org-agenda t showed the error Wrong type argument: stringp, nil In *Messages* I saw: Press key for agenda command (unrestricted): org-agenda-get-todos: Wrong type argument: stringp, nil I ran git bisect and narrowed it down to this (all else about my config remaining the same): 37d6bde27fe228cdadcb5cdaa09287872a508777 is the first bad commit commit 37d6bde27fe228cdadcb5cdaa09287872a508777 Author: Ihor Radchenko Date: Tue Oct 10 13:53:07 2023 +0300 org-element-parse-secondary-string: Prevent altering current buffer cache I can't tell what's going on, but I hope this helps identify something. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 418.33 ppm (Mauna Loa Observatory, 2023-10-09)
How to hide square brackets around [[url][links]]?
A fix by Ihor a few weeks ago solved a problem ("org-cycle does not unfold some subtrees") but I think there's still a related little bug with searching, perhaps just with Swiper, that I can't replicate but am watching. Sometimes when searching with Swiper, the display of (some) links is changed and instead of seeing the anchor text formatted as a link I see the full raw [[URL][anchor text]]. How can I make this go back to showing just the anchor text? I've tried toggling visible-mode and using org-toggle-link-display but neither work, so I have to C-x C-v and reload the file. Should these commands be reformatting all the links in the buffer, and the fact they don't work is a sign of the bug? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 418.58 ppm (Mauna Loa Observatory, 2023-09-20)
Wider margins on text, but no margins on tables?
I have always run Emacs full screen and never set any margins, so the text goes from one side of my screen to the other. (It's not a big screen.) Today I'm trying out narrowing how text is displayed by setting left-margin-width and right-margin-width, so there's blank space on either side. It looks good for most things, and helps readability. But for tables it can be a problem because sometimes I have a table that i want as wide as possible. Is there a way to have tables fit inside the margin-width settings until they get too wide, then expand out? That way a small table isn't flush left, but a big one is. Or perhaps there is a way to set Org tables to have margin-widths of 0, so it would be: narrowed paragraph, narrowed paragraph, table flush left, narrowed paragraph. Has anyone here configured something like this? If there's a hook to use it's beyond what I can hack. Any related tips or configurations would be welcome too. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 419.19 ppm (Mauna Loa Observatory, 2023-08-17)
Re: [SUMMARY] [[bbb:OrgMeetup]] on Wed, Aug 9, 19:00 UTC+3 (was: Interest in an Org video meetup?)
On 10 August 2023, Ihor Radchenko wrote: Thanks everyone who participated! We had quite a few people by Emacs meetup standards. Thanks for organizing this! It was a good session, and I picked up a few tips and things to try out. Seeing the Arabic dissertation was a highlight. It was also interesting seeing how others make great use of some parts of Org I use very little. And of course just seeing what someone else's Emacs looks like is always fun. (For those who weren't there: No one had their camera on, it was screen-sharing and people talking.) Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.30 ppm (Mauna Loa Observatory, 2023-08-10)
Re: BUG: org-cycle does not unfold some subtrees
On 4 August 2023, Michael Dauer wrote: I'm on main (Org mode version 9.7-pre (release_9.6.7-594-gf03b83), and it's not fixed. Am I missing something? The fix did fix it for me, and the problem went away. It did seem to introduce a new problem with searching in a buffer with Swiper, where the search would fail or throw an error or require me to collapse headings before it would work, but that hasn't happened in a while and I didn't try to debug it. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.92 ppm (Mauna Loa Observatory, 2023-08-03)
Re: Preserving leading zeros
On 28 May 2023, Berry, Charles wrote: Have you considered http://gewhere.github.io/org-bibtex ?? Or using the approach therein, viz. use properties to store bib data in org? That would be great for a smaller bibliography, but I'm dealing with over 2,400 books. They're in a simple database now, with a web front end I wrote over twenty years ago in Perl. Amazingly it's worked ever since, maybe with one fix required along the way, but some update to a library or package broke it recently and I haven't figured out why yet. Even if I do, I'm thinking it's time to get away from that code. I don't feel like getting into the overhead of writing a new web-based system, so I might try managing the database through Org with R. I was thinking I might add a new book by having a table like this, which the code would read and operate on: | isbn | title| pub_date | |+--+--+ | 0006145396 | A Buyer's Market | 1952 | I guess I could have the code pad the left with zeros if the ISBN is a number with fewer than 10 digits. That way I'd see the right ISBN on the screen, and if Emacs removes the zeros they get put back before it's added to the catalogue. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 424.57 ppm (Mauna Loa Observatory, 2023-05-27)
Preserving leading zeros
I'm thinking about moving a personal library catalogue system into Org. This would involve ISBNs, and when ISBNs had 10 digits some would have leading zeros. It turns out leading zeros are removed when something looks like a number. #+name:isbn | 0006145396 | #+begin_src shell :results output :var string=isbn echo $string #+end_src #+RESULTS: : 6145396 I looked at org-babel-read, which calls org-babel--string-to-number ("If STRING represents a number return its value"), so it looks like that's always going to happen. I could use a hack like prepending an X and then removing it later, but that's a bit ugly. Has anyone had this problem and worked around it some other way? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 424.57 ppm (Mauna Loa Observatory, 2023-05-27)
Re: BUG: org-cycle does not unfold some subtrees
On 12 May 2023, Ihor Radchenko wrote: What is the value of `isearch-mode-end-hook' in your Org buffers? (anzu--reset-mode-line org-fold-core--clear-isearch-overlays t) Local in buffer conforguration.org; global value is nil I checked in a few buffers, and it always says it's local in that buffer, with global value of nil, if that matters. This looks right. I am wondering how it could be that `isearch-mode-end-hook' does not get called. Have you experienced slowness of isearch? Did you abort it in any special ways? No and no, but now that I'm thinking about searching, I remember I use Swiper (and Ivy and Counsel).¹ C-s runs =swiper=, which is =isearch-forward= "with an overview," as it describes itself. If we've narrowed it down to searching, could it be connected to that? To the other people with this problem: do you use Swiper? Bill ¹ https://github.com/abo-abo/swiper -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 423.90 ppm (Mauna Loa Observatory, 2023-05-11)
Re: BUG: org-cycle does not unfold some subtrees
On 11 May 2023, Ihor Radchenko wrote: William Denton writes: Do you use evil-mode? Definitely not. Curious. This function is supposed to be run upon finishing or aborting isearch. What is the value of `isearch-mode-end-hook' in your Org buffers? (anzu--reset-mode-line org-fold-core--clear-isearch-overlays t) Local in buffer conforguration.org; global value is nil I checked in a few buffers, and it always says it's local in that buffer, with global value of nil, if that matters. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 424.32 ppm (Mauna Loa Observatory, 2023-05-10)
Re: BUG: org-cycle does not unfold some subtrees
On 11 May 2023, Ihor Radchenko wrote: William Denton writes: Does it also help if you run M-: (org-fold-core--clear-isearch-overlays)? That worked! I just had the problem. I ran that, and the tree popped open! Do you use evil-mode? Definitely not. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 424.17 ppm (Mauna Loa Observatory, 2023-05-09)
Re: BUG: org-cycle does not unfold some subtrees
On 10 May 2023, Ihor Radchenko wrote: "Fraga, Eric" writes: And if it helps further, I have had this problem for some time now. The solution, for me, is to search for some text I know is present in the folded section and it unfolds! But the situation is sporadic and I cannot reproduce it at will. Does it also help if you run M-: (org-fold-core--clear-isearch-overlays)? That worked! I just had the problem. I ran that, and the tree popped open! Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 424.17 ppm (Mauna Loa Observatory, 2023-05-09)
Re: BUG: org-cycle does not unfold some subtrees
On 8 May 2023, Thomas S. Dye wrote: Would it be useful for me to search for calls to the folding functions from outline.el in the source code of the Org packages that Spacemacs and I load? This problems happens to me regularly, and I don't use Spacemacs. Wherever it is, I don't think it's in there. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 424.26 ppm (Mauna Loa Observatory, 2023-05-08)
Re: Why am I being told to use "straight.el"?
On 21 April 2023, Max Nikulin wrote: Then I am completely confused what happened. Org compiled by make should not be affected by the mixed compile issue, especially after "make clean". How do you load updated version without restarting of Emacs? Do you use `org-reload'? Please, try to specify all you steps from "git pull" to first time when you got the warning. If I remember right---this may be related or not---I saw this warning myself little while ago, but "make maintainer-clean" in the Emacs source (I track the development tree) and recompiling made it go away. (I find I need to do that a couple of times a year, for one reason or another.) Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 423.25 ppm (Mauna Loa Observatory, 2023-04-20)
Clocktable :formatter to record time in hours or work-days
I've been clocking in and out of a project for a few months and now it's over. I tagged each entry with "search", so a brief clocktable report looks like this: #+BEGIN: clocktable :maxlevel 1 :scope file :tags t :match "search" #+CAPTION: Clock summary at [2023-04-11 Tue 13:48] | Tags | Headline |Time | |--+---+-| | | Total time| 4d 6:23 | |--+---+-| | | 2022-09 September |0:38 | | | 2022-10 October |2:46 | | | 2022-11 November |7:41 | | | 2022-12 December | 10:41 | | | 2023-01 January | 10:16 | | | 2023-02 February | 1d 3:56 | | | 2023-03 March | 1d 3:47 | | | 2023-04 April | 14:38 | #+END How could I format the Time column in hours? How could I format it to hours/8, rounded, to represent work-days? I only want this formatting for this table, I have other clocktables in the same file I don't want to change. I've read about clocktables and the :formatter option, which I assume is what will do it, but I can't find any helpful examples so I'm stuck. Thanks for any help, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 422.29 ppm (Mauna Loa Observatory, 2023-04-10)
Re: [BUG] Incorrect display of folded headings after cycling with subheading with VISIBILITY content/children
On 14 February 2023, Bruno Barbier wrote: Daniel Hubmann writes: After using org-cycle-overview (or org-cycle-content) and then using org-cycle-set-visibility-according-to-property I get this: * Heading Lvl 1...** Heading Lvl 2 with VISIBILITY content... *** Heading Lvl 3... I'm observing the same behavior. Similar things have been happening to me since the middle of last year. See: https://lists.gnu.org/archive/html/emacs-orgmode/2022-07/msg00368.html https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00811.html (my screenshots are gone by they looked like what's been described) Ihor did some work but the problem is still going on now and then, in the sort of way that seems unreproducible to me. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 421.18 ppm (Mauna Loa Observatory, 2023-02-13)
Re: LaTeX tutorial (focused on what Org exports) ??
On 5 January 2023, David Masterson wrote: With the Org files that you create, how many levels of headers do you use? I use Org for personal task management mostly, but I'd like to produce good PDFs to give to my wife (Org is too complicated). My problem is that I'll structure my documents with many (5+) header levels with tasks at the bottom. The problem is that the 'article' and 'report' document classes used by Org don't look right if you go beyond 3 levels -- if you know what I mean. (NOTE: LaTeX newbie) By default the first three levels go to LaTeX headings, and then after that they become lists. You can change that with the H option in a header, as described here, to set org-export-headline-levels: https://orgmode.org/org.html#Export-Settings So you could say: #+options: H:5 Level four headings become paragraphs, and level five become subparagraphs. With that in place, you might like how the titlesec package can give a great deal of control over section headings. I use this for some reports---it wraps text around level three headings, which about as far as I usually go for documents I export. #+LATEX_HEADER: \usepackage[]{titlesec} #+LATEX_HEADER: \titleformat{\section} {\centering\Large}{\thesection}{}{} #+LATEX_HEADER: \titleformat{\subsubsection}[drop]{\itshape}{\thesection}{}{}{} #+LATEX_HEADER: \titlespacing{\subsubsection}{0.75in}{\baselineskip}{0.5in} Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
How to make change the appearance of org-date inside a drawer?
I would like to make drawers look fainter and smaller. I have this mostly working, with this: (face-spec-set 'org-drawer '((t (:foreground "dim gray" :weight normal :height 0.9 (face-spec-set 'org-special-keyword '((t (:foreground "dim gray" :weight normal :height 0.9 (face-spec-set 'org-property-value '((t (:weight normal :height 0.9 But then there is this case: :LOGBOOK: CLOCK: [2023-01-04 Wed 14:05]--[2023-01-04 Wed 17:33] => 3:28 :END: Here LOGBOOK and CLOCK are smaller, but the timestamps are full size. (This won't come across in plain text email, of course.) describe-char there tells me the timestamp has the face org-date. Is there a way to make org-date smaller when it's in a drawer? I don't want to make a global setting for it, because I often use dates in headings. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: LaTeX tutorial (focused on what Org exports) ??
On 30 December 2022, Thomas S. Dye wrote: Org's latex exporter is exceptionally capable. AFAICT, it doesn't have practical limits on the LaTeX it produces, at least for my academic use case. I'm able to use all of the LaTeX packages I've ever wanted to use. Me too, and the more I use Org with LaTeX, the more I'm seeing how I can use Org as a way to organize a large publishing project: use literate programming and export the LaTeX piece by piece, documenting what I'm doing; use source blocks to run necessary code to prepare images or files before inclusion; and so on. Using Org (simple markup plus some +latex_header lines) and exporting to LaTeX is straightforward enough ... managing a project, with the LaTeX as code to be generated, can get a lot more complicated, but on the other hand, Org makes that kind of thing simpler. (Of course, anything involving LaTeX is bound to get complicated pretty soon.) I've learned a lot from several regulars on this mailing list, including Juan Manuel Macías, who does remarkable work on dictionaries and translations. Here's an example: https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00348.html Along with all the other recommendations, it's worth looking at the user guide for the memoir class, which is great for books: https://www.ctan.org/pkg/memoir It'll be somewhere on your system as memman.pdf. I learned a lot about page design and LaTeX from it. Cheers, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: org-persist files in /tmp
On 21 December 2022, Ihor Radchenko wrote: Could be. If so, it may indicate some issue with logic. The index should not be written if the only entry inside index file is index version itself. You should _not_ see something like ((:container ((index "2.7")) :persist-file "d0/5078fe-5e31-4ddb-95a0-93ceae58df0c" :associated nil :expiry never :last-access 1671637032.483552 :last-access-hr "2022-12-21T18:37:12+0300")) as the only contents of "index" file. I just checked my /tmp/ and I have 32 org-persist directories, and I must sadly report they all have index files like I shouldn't see: ((:container ((index "2.7")) :persist-file "2f/859289-dcc1-4d55-8c91-e22b4ccc92dd" :associated nil :expiry never :last-access 1671429856.980864 :last-access-hr "2022-12-19T01:04:16-0500")) Nineteen of them were made on Monday ago, and I may have rebuilt Emacs and Org then, and maybe restarted Emacs, but not nineteen times. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Org functions in source blocks
On 10 December 2022, Max Nikulin wrote: @I$A and the "remote" function are available in table formulas only. Moreover you quoted remote, so this s-expression is not evaluated. In addition, unlike in table formulas, in elisp function arguments are separated by space, not by comma. Thanks for your explanation about this and the rest. I have a better sense now of what works where and how Elisp code blocks can interact with the Org document they're in. I'll be back with more questions eventually, I'm sure, but for now just learning about all the table features I've overlooked so far will keep me busy. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Images generated by R code blocks do not display
On 10 December 2022, Ihor Radchenko wrote: Ihor Radchenko writes: I now reported this to Emacs upstream. I do not see anything wrong on Org side in this case. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59902 Since the bug will affect older Emacs versions, I pushed a workaround to bugfix. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7fefc3027 It will no longer be necessary when Emacs fixes the issue and when we stop supporting all the older Emacs versions with this bug being present. Thank you! It's so nice to have this working again. I have a couple of Org files where I'm updating data and images a few times a week, and when this broke it was a real pain---particularly because everything had worked so well for so long. Now my life is easy again. I appreciate your work on this and everything else, Ihor. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Org functions in source blocks
I ran org-lookup-all in a source block, but it didn't give any output. I think I don't know something basic about Org or Lisp (likely both) and I hope someone can point out what's going on. For example, I have this table, and I can count how many times x appears: #+name: test_table | | A | |---+---| | ! | A | | | x | | | | | | x | | | x | |---+---| | # | 3 | #+TBLFM: $2='(length(org-lookup-all "x" '(@I..@II) nil)) I can do the count from another table, referring to a remote table: #+name: summary | A | |---| | 3 | #+TBLFM: @2$1='(length(org-lookup-all "x" '(remote(test_table, @I$A..@II$A)) nil)) But running org-lookup-all on its own like this gives result nil, not something with some xs in it. Why not? #+begin_src emacs-lisp :results raw (org-lookup-all "x" '(remote(test_table, @I$A..@II$A)) nil) #+end_src Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Images generated by R code blocks do not display
On 8 December 2022, Ihor Radchenko wrote: I now reported this to Emacs upstream. I do not see anything wrong on Org side in this case. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59902 Thanks for reporting this there. I like how you simplified the bug example with the two images, so nothing needs to be generated on the fly. As a reminder for anyone else having this problem, where updated images don't appear, this will refresh them: M-: (clear-image-cache) Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
On 6 December 2022, Greg Minshall wrote: given that, iiuc, 9.5 presented a list as (the equivalent of) multiple rows of a table, i'd vote for staying with (going back to) that. (i think that's what the two modifications in Chuck's e-mail give you.) I agree: I've never used this, but if it used to become rows of a table, let's keep it that way. In R we might think of the list as a vector, I guess, but there's no way to represent that nicely in Org, though it is easy to step through the rows of a column or table. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Displaying macros differently
On 4 December 2022, Vikas Rawal wrote: I frequently use orgmode macros -- like {{{M(Year 1998--99)}}} -- in tables designed for latex export. I find that the macro syntax occupies many character spaces. At the very least, 9 spaces are taken up even if my macro shortcut is just one character long. This is very difficult with wide tables as often the tables go off the screen just because of this. I was wondering if there is a simple way of making org display the macros differently. That is, use some kind of overlay, and display the above macro may be like M:Year 1998--99. Or some special character could be used to denote that there is a macro underlying what is visible here. Is this close enough? (setq org-hide-macro-markers t) That hides the {{{macro}}} curly brackets (if there's no leading space). I also have this to toggle macro visibility in the document so I can see them when I want to: #+begin_src emacs-lisp (defun wtd/toggle-org-macro-markers () "Toggle visibility of {{{macro}}} markers" (interactive) (setq org-hide-macro-markers (not org-hide-macro-markers)) (font-lock-mode) (font-lock-mode)) #+end_src I think there's been some discussion about evaluating the macros and showing the result, but I don't think that's possible. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: [BUG] ob-R: session evaluation returns empty ouputs with Org 9.6 [9.6 ( @ /home/fsantos/.emacs.d/elpa/org-9.6/)]
On 1 December 2022, Ihor Radchenko wrote: With Org 9.6 released yesterday, I noticed a bug with ob-R: all R code blocks with ":results output :session *R*" in the header will return no output at all (although the code is correctly processed in the inferior ESS buffer). May it be a duplicate of https://orgmode.org/list/87bkoxj50h.fsf@localhost? I did not test this report itself, but if my guess is correct, setting `ess-startup-directory' to 'default-directory might be a temporary workaround until we find the fix to this breaking change in ESS. I tried that, but it didn't fix it. :( With a minimal setup, running the R block with a :session makes it ask where the working directory should be (the default in the prompt is the directory the test Org file is in). Setting ess-startup-directory to 'default-directory doesn't change that, or the output problem. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Images generated by R code blocks do not display
I tried git bisect and, if I did it right, the problem may have started here: commit 46b71f910844c14d8db1feb54c07de26d101cc05 Author: stardiviner Date: Tue Oct 4 12:36:32 2022 +0800 org.el: Support auto display inline images when cycling * lisp/org.el (org-toggle-inline-images): Support region. (org-display-inline-images): Fix refresh argument logic. (org-remove-inline-images): Support region. ... Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Images generated by R code blocks do not display
On 25 November 2022, Ihor Radchenko wrote: 1. cd /path/to/org/repo 2. git checkout main 3. make repro 4. M-: (require 'ob-shell) 5. Open the following org file #+begin_src sh :results graphics file :file /tmp/colour.png convert -size 300x300 xc:#002b36 /tmp/colour.png #+end_src 6. Move point to the source block and C-c C-c yes 7. C-c C-x C-v 8. Observe the 300x300 image appearing 9. Edit the source code to 500x300 10. C-c C-c yes 11. Image disappears 12. C-c C-x C-v 13. Observe what appears to be the old 300x300 image 14. Move the cursor to the image 15. Observe the correct 500x300 appearing while the cursor is on it!! Could you please confirm? Confirmed! Just as Jeremie did also. I'd seen this image-switching behaviour before and hadn't been able to recreate it with a simple example, but there it is. "This is very strange," indeed. I don't know if this is useful, but: 16. Edit source code back to 300x300 17. C-c C-c yes 18. Image disappears 19. C-c C-x C-v 20. 300x300 image appears (a new one? or the first one?) 21. Move the cursor to the image 22. The now incorrect 500x300 appears while the cursor is on it, same as 15 Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Images generated by R code blocks do not display
On 24 November 2022, Ihor Radchenko wrote: William Denton writes: What if you run M-: (clear-image-cache) before C-c C-x C-v? That does it! Strange. I am unable to reproduce the issue on my side (using the earlier bash code block you provided). What is your Emacs version? I refreshed the source just now, and it's at commit 183c66be97c: GNU Emacs 29.0.50 (build 7, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 2022-11-23 I reran the convert image command, and the (clear-image-cache) problem is still there. If you generate an image that's 300x300, then change the command so it makes a 500x500 image, and rerun the command, a 500x500 image appears right away? Or does after you C-c C-x C-v? I have to run M-: (clear-image-cache) and then the image in the buffer updates to the larger one. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Images generated by R code blocks do not display
On 24 November 2022, Ihor Radchenko wrote: William Denton writes: + C-c C-c (execute R block again) + answer yes to "Evaluate this?" question + image disappears + C-c C-x C-v (to see image) + image is still 300 pixels square! What if you run M-: (clear-image-cache) before C-c C-x C-v? That does it! Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Images generated by R code blocks do not display
On 24 November 2022, Ihor Radchenko wrote: The image should appear immediately in the buffer, shouldn't it? No, it should not. Though it is often requested. Huh, strange. It's always done it for me, at least with R code blocks, as far as I can remember. But back to my original problem! Here's another angle on it, with images not being refreshed even though they've changed. Setup: my minimal-init.el from my first email. File, r.org: # - #+begin_src R :results graphics file :file /tmp/plot.png :width 300 :height 300 plot(c(1, 2, 3, 4), c(1, 8, 27, 64)) #+end_src # - Steps: + C-x C-f (load r.org) + C-c C-c (execute R block) + answer yes to "Evaluate this?" question + #RESULTS appears, but image doesn't show + C-c C-x C-v (to see image) + look at /tmp/plot.png: it is 300 x 300 + edit width and height settings so they are each 500 pixels + C-c C-c (execute R block again) + answer yes to "Evaluate this?" question + image disappears + C-c C-x C-v (to see image) + image is still 300 pixels square! + look at /tmp/plot.png: it is 500 x 500 + C-x C-s (save file r.org) + quit and restart Emacs with minimal init + C-x C-f (load r.org) + C-c C-x C-v (to see image) + image is 500 x 500! So R is generating a new, larger image, and it's there on disk, but Emacs won't show it. Thanks again, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Images generated by R code blocks do not display
Thanks for looking at this. You've fixed the org-toggle-inline-images problem, but the image generation and display problem is still there for me. Here's a one-liner shell block that generates an image with Imagemagick, so no extra Emacs packages necessary: # - #+begin_src sh :results graphics file :file /tmp/colour.png convert -size 300x300 xc:#002b36 /tmp/colour.png #+end_src # - But the image doesn't appear right away: + C-x C-f (load this file) + C-c C-c (to execute) + Say yes to "Evalute this sh code block on your system?" + #RESULTS block appears (good) but image does not show + But: C-c C-x C-v does work to toggle image display (fixed!) This is the simplest way I could think of to generate an image with minimal dependencies, so I hope this boils the problem down in a helpful way. The image should appear immediately in the buffer, shouldn't it? Thanks, Bill On 24 November 2022, Ihor Radchenko wrote: William Denton writes: In Emacs: + C-x C-f (load r.org wherever it is) + C-c C-c (to execute the R code) + Say yes to "Evaluate this R code block on your system?" + #RESULTS block appears (good) but image does not show + C-c C-x C-v (to toggle image display) + image appears + C-c C-c (to execute R code again) + Say yes to "Evaluate this R code block on your system?" + image disappears + C-c C-x C-v says "Inline image display turned off" + C-c C-x C-v says "Inline image display turned off" (and so on) Expected behaviour: Images should appear when this code block is run or rerun, and C-c C-X C-v (org-toggle-inline-images) should toggle the setting, not keep it off. I am currently not able to test third-party packages in clear environment, but I think I know what could have caused the problem. I think I fixed the issue on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d4522dd4d Can you try the latest main and see if the problem persists? -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Images generated by R code blocks do not display
I have a problem with images made by R code blocks in Org: not being displayed or refreshed. (This has been going on for a while, but I can't remember when it started.) Here's a minimal reproducible example I hope others can check. It requires R on your system and the ESS package. First, here's my minimal-init.el file: #- minimal-init.el (setq debug-on-error t debug-on-signal nil debug-on-quit nil) (add-to-list 'load-path (expand-file-name "/usr/local/src/org-mode/lisp")) (org-babel-do-load-languages 'org-babel-load-languages '( (R . t) (shell . t) )) (add-to-list 'load-path "~/.emacs.d/elpa/ess-20221121.1627") ;; "/usr/local/src/ESS/lisp" (require 'ess-r-mode) # - For me this runs Org from the source tree (up to date today) and ESS from where it was installed (package updated yesterday, as it happens). Adjust paths as necessary. Next, here is r.org, with one R code block that makes a simple chart: # - r.org #+begin_src R :results graphics file :file /tmp/plot.png :width 300 :height 300 plot(c(1, 2, 3, 4), c(1, 8, 27, 64)) #+end_src # - Run Emacs: $ emacs -Q -l minimal-init.el In Emacs: + C-x C-f (load r.org wherever it is) + C-c C-c (to execute the R code) + Say yes to "Evaluate this R code block on your system?" + #RESULTS block appears (good) but image does not show + C-c C-x C-v (to toggle image display) + image appears + C-c C-c (to execute R code again) + Say yes to "Evaluate this R code block on your system?" + image disappears + C-c C-x C-v says "Inline image display turned off" + C-c C-x C-v says "Inline image display turned off" (and so on) Expected behaviour: Images should appear when this code block is run or rerun, and C-c C-X C-v (org-toggle-inline-images) should toggle the setting, not keep it off. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Seeing all the steps when I run an R code block
On 15 November 2022, Ihor Radchenko wrote: I tried to test with a clean config and bare ESS installation will raise the following query: R:2 starting project directory? /tmp/ Note the default value /tmp which is `default-directory' containing test Org file in my testing. You might have set some customization that overrides `default-directory' setting in ESS. You were quite right---thanks for checking. Recently ESS changed ess-startup-directory and now it's aware of projects. I'd recently put some files under Git, which made them a project. So it was ESS, nor R. For the record, this will stop that: (setq ess-startup-directory 'default-directory) ;; "Always start the process in the directory of the current file" But I have another R problem that does seem to be with Org, coming next ... Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Seeing all the steps when I run an R code block
I've got a few problems with R source blocks that I can't figure out. They started late last month, I think. I'm running Emacs and Org from the development trees, refreshing and recompiling regularly. ESS (the package for working with R) is up to date too. Here's one big problem. I have a file, /home/wtd/books/reading/test-r.org, and in it is this R block: # - #+begin_src R :session R:testing :results value 1 #+end_src # - If I execute that with C-c C-c, the R session buffer starts, but in the wrong working directory. This is in the R session buffer, reported by ESS: # - setwd('/home/wtd/books') # - It's in the directory *above* where the Org file is! It should be in /home/wtd/books/reading/. I copied the test file to /tmp/r/test/, and it's fine there. The session's working directory is /tmp/r/test/, not /tmp/r/. Something strange is going on, but I can't see why. Is there some way I can see all the steps that are happening when I hit C-c C-c on that code block? Or maybe there's some other way to figure it out? Any suggestions welcome. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
[BUG] Cache warning [9.6-pre (release_9.5.5-1086-g7f7280 @ /usr/local/src/org-mode/lisp/)]
org-w3m-store-link) ("doi" :follow org-link-doi-open :export org-link-doi-export) ("id" :follow org-id-open) ("file+sys") ("file+emacs") ("shell" :follow org-link--open-shell) ("news" :follow (closure ((scheme . "news")) (url arg) (browse-url (concat scheme ":" url) arg) ) ) ("mailto" :follow (closure ((scheme . "mailto") ) (url arg) (browse-url (concat scheme ":" url) arg) ) ) ("https" :follow (closure ((scheme . "https")) (url arg) (browse-url (concat scheme ":" url) arg) ) ) ("http" :follow (closure ((scheme . "http")) (url arg) (browse-url (concat scheme ":" url) arg) ) ) ("ftp" :follow (closure ((scheme . "ftp")) (url arg) (browse-url (concat scheme ":" url) arg) ) ) ("help" :follow org-link--open-help :store org-link--store-help) ("file" :complete org-link-complete-file) ("elisp" :follow org-link--open-elisp) ) org-metaup-hook '(org-babel-load-in-session-maybe) org-startup-with-inline-images t org-return-follows-link t org-special-ctrl-a/e t org-tags-column 120 org-hide-macro-markers t org-footnote-section nil org-list-allow-alphabetical t ) -- -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: R code blocks in org version 9.5
On 19 October 2022, Naresh Gurbuxani wrote: It seems that org 9.5 has simplified header arguments for R code blocks that use grid graphics. Org 9.4 requires :results output graphics file Org 9.5 requires :results output file Do other users find the same change? They both work for me, though I've never put "output" in such a block: I always use ":results graphics file". Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: R code blocks in org version 9.5
On 18 October 2022, Naresh Gurbuxani wrote: Recently I started using org version 9.5 with my init.el that worked well for org 9.4 In org 9.5, I can run stand-alone R code blocks. But when I try to run them in a session, emacs hangs. I haven't had any problems like that, and I use R session code blocks pretty much every day. Can you narrow it down any? Does even the most basic block, just adding 1 + 1, not work? What about with emacs -Q? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Reinstalling compat fixed everything breaking
On 14 September 2022, Charles Philip Chan wrote: I am seeing the same problem. However, it did not resolve for me after upgrading the compat library to the current git version. I am still getting: , | Warning (emacs): Org version mismatch. Make sure that correct ‘load-path’ is | set early in init.el This warning usually appears when a built-in Org version is | loaded prior to the more recent Org version. ` during "make install". I never had this problem before. I've never done a "make install" because I run it from the source tree,¹ so maybe that's why my configuration works now but yours still doesn't. I hope someone who knows more about all this can pitch in. Bill ¹ Configured so: (use-package org :pin manual :load-path "/usr/local/src/org-mode/lisp" :init ;; Lots of stuff here ) -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Reinstalling compat fixed everything breaking
Yesterday I pulled the current source trees for Org and Emacs and compiled as I usually do ... and everything broke, with Org complaining about mixed versions, and all kinds of warnings and backtraces and "Invalid function: compat-declare-version" errors. After looking at various things I noticed a couple of mild warnings related to the package compat, which I'd seen for a while (several weeks, at least) but never bothered about, because everything worked. I thought maybe it was all connected, what with the new version-checking and such, and indeed "M-x package-reinstall compat" did the trick and now everything works. In case someone else has the same problem I thought I'd mention this. Cheers, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Simple but repetitive http links
On 7 September 2022, Perry Smith wrote: I added: #+LINK: rails https://rubyonrails.org to my org file and then I wrote [[rails][Rails]] and when I clicked the text, it asked me if I wanted to create a section. I had to kill the buffer and reload it to get it to work. That's fine but I'm wondering if there is a way to make it active without killing the buffer. And I also wanted to suggest adding something about that in the manual. Perhaps this is a common fact with many of Org modes features that I missed somewhere? To tell Org about new keywords like that you need to hit C-c C-c on the keyword (or restart). This is in "The Very Busy C-c C-c Key" in the manual,¹ and "Summary of In-Buffer Settings," but the manual is dense and it's easily overlooked. However, as a general rule, if you ever want something to happen in Org, try hitting C-c C-c on the line and it probably will. Welcome to Org! Bill ¹ https://orgmode.org/org.html#The-Very-Busy-C_002dc-C_002dc-Key -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Recent folding issues
On 11 July 2022, Jack Kamm wrote: 2. When folded, I frequently found multiple headlines to be displayed on the same line, like so: * Headline 1... * Headline 2...* Headline 3... * Headline 4 Hitting Shift-Tab a few times (org-global-cycle) usually fixed the problem. That's very much like a problem I've been getting (see the message I just sent to the list), which Ihor has also been helping with. For me, just now when the problem happened again (I realize this is anecdotal, not reproducible) hitting TAB a lot on the headline might work, but hitting TAB on other headlines did nothing, and Shift-TAB would expand /some/ headlines but not the one where the pointer was! So I'm in the same boat as you, and trying various things to figure out what's going on. Cheers, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Folded headlines with text showing where it shouldn't
On 3 June 2022, Ihor Radchenko wrote: William Denton writes: For me, this looks like either a mixed installation (please post the output of M-x org-version) or some third-party package misbehaving. M-x org-version says: Org mode version 9.5.3 (release_9.5.3-511-g8e69ad @ /usr/local/src/org-mode/lisp/) Is /usr/local/src/org-mode/lisp/ the folder where you installed the latest Org version? (If not, this is likely the problem or part of the problem). First of all, thanks for following up on this---I'm slow to respond, but appreciate your help in narrowing this down. The problem's been happening again, and tonight I can follow up with some details. That directory is where I installed Org. It's where I pull down the source tree with Git. Usually, the problem you are seeing is when something is interfering with 'invisible text property of links/other folded text. Can you post the value of org-link-parameters on your system? This is a new variable to me! I've never done anything with it, but it's got a lot in it. Value: (("attachment" :follow org-attach-follow :complete org-attach-complete-link) ("eww" :follow org-eww-open :store org-eww-store-link) ("rmail" :follow org-rmail-open :store org-rmail-store-link) ("mhe" :follow org-mhe-open :store org-mhe-store-link) ("irc" :follow org-irc-visit :store org-irc-store-link :export org-irc-export) ("info" :follow org-info-open :export org-info-export :store org-info-store-link) ("gnus" :follow org-gnus-open :store org-gnus-store-link) ("docview" :follow org-docview-open :export org-docview-export :store org-docview-store-link) ("bibtex" :follow org-bibtex-open :store org-bibtex-store-link) ("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete org-bbdb-complete-link :store org-bbdb-store-link) ("w3m" :store org-w3m-store-link) ("doi" :follow org-link-doi-open :export org-link-doi-export) ("id" :follow org-id-open) ("file+sys") ("file+emacs") ("shell" :follow org-link--open-shell) (#1="news" :follow #f(compiled-function (url arg) #)) (#3="mailto" :follow #f(compiled-function (url arg) #)) (#6="https" :follow #f(compiled-function (url arg) #)) (#7="http" :follow #f(compiled-function (url arg) #)) (#8="ftp" :follow #f(compiled-function (url arg) #)) ("help" :follow org-link--open-help :store org-link--store-help) ("file" :complete org-link-complete-file) ("elisp" :follow org-link--open-elisp)) Original value was nil You may also put the cursor onto unexpectedly visible link and check the output of M-x describe-text-properties. Then, put the cursor right after the link and run M-x describe-text-properties again. Then, share the output. Here's a screenshot of the problem I get: https://www.miskatonic.org/tmp/org-problem.png And here's the output of describe-text-properties when the pointer is in the link that shouldn't be there: Text content at position 56157: There are 3 overlays here: From 55909 to 56345 face hl-line priority -50 window # From 56149 to 56170 evaporatet invisibleorg-link isearch-open-invisible delete-overlay org-invisibleorg-link priority 1 From 56151 to 56168 evaporatet invisibleorg-link-description isearch-open-invisible ignore isearch-open-invisible-temporary ignore org-invisibleorg-link-description priority 2 There are text properties here: face org-link font-lock-multiline t fontifiedt help-echo"LINK: fig_rereading_pct" htmlize-link (:uri "fig_rereading_pct") isearch-open-invisible org-fold-core--isearch-show isearch-open-invisible-temporary org-fold-core--isearch-show-temporary keymap [Show] line-prefix [Show] mouse-face highlight org-fold--spec-org-fold-outline--876068932062118346 org-fold-outline org-fold--spec-org-link-description-global org-link-description org-fold--spec-org-link-global org-link wrap-prefix [Show] If you don't have time to dig into the problem, you can also set org-fold-core-style to 'overlays in your config to activate legacy folding support. It will most likely solve the immediate issue on your side and let you work on more pressing things involving your Org workflow. I've changed this (which was also mentioned in another thread yesterday) and will try it out for a while to see if that makes a difference. Thanks again, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Change both width and height of R plot in SRC block
On 30 June 2022, Gerardo Moro wrote: I have been trying for over a year to change the output plot size when using Orgmode SRC blocks with R. I have tried both using orgmode settings and R settings. I have a table from which I take some values. #+name: cost #+begin_src R :results output file graphics :file imag/cost.jpg :var tab=cost You can put height and width attributes for the image into the source block header: #+begin_src R :results output file graphics :file imag/cost.jpg :var tab=cost :width 800 :height 400 (You mention #+attr_org, but there's a bad colon in what you quote.) If this doesn't work, please give a reproducible example, and we can figure it out. The code you quote doesn't work because we don't have the cost data. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Utility of description lists
On 17 June 2022, Cletip Cletip wrote: Final question : why do you use description lists and not another ? When I have a list of things I want to briefly descibe! That's all. It's just a way of formatting a list of things where there's a term (a word, a name, a title) that has some descriptive text. Sometimes I use them when there's an obvious term/description pairing, and sometimes when I have a text-heavy list of things and I want to have a brief summary of each to make it easier to read. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Folded headlines with text showing where it shouldn't
On 31 May 2022, Ihor Radchenko wrote: For me, this looks like either a mixed installation (please post the output of M-x org-version) or some third-party package misbehaving. M-x org-version says: Org mode version 9.5.3 (release_9.5.3-511-g8e69ad @ /usr/local/src/org-mode/lisp/) Can you try to open that file from emacs -Q? See https://orgmode.org/manual/Feedback.html It's not just that file, it's been happening recently with almost all my Org files, now and then. I'll try with -Q and work on a file for a while and see if I can recreate the problem. Is there anything from all your excellent folding work that would let me check some value or variable that would be helpful when I see such a problem? Some way of inspecting the state of something that might be useful? Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Folded headlines with text showing where it shouldn't
I've had a problem lately that is related to folding headlines but I'm not sure how to narrow it down (short of turning on debugging, which I can do). I wonder if anyone else has seen this kind of thing happen or can recommend something I should look for or do when next it happens. I was working on a file and did a SHIFT-RET to collapse all the headlines. I saw this, with a bit of text appearing in a headline where it shouldn't be: https://www.miskatonic.org/tmp/org-01.png I went to the headline and hit RET. It expanded, and now the bit of text was appearing a sub headline: https://www.miskatonic.org/tmp/org-02.png Expanding that headline shows what it looks like normally: https://www.miskatonic.org/tmp/org-03.png The "Tidyverse" there is a link. I think that's a part of the problem: if I remember right, every time I've seen this happen, it's a link that is displayed out of place. (This is with Emacs and Org built from source on 22 May; Org was at 8e69adabe2026. Maybe it's been fixed since then but I haven't seen this mentioned, so I thought I'd grab a screenshot while I could.) Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: export regions of a org files to other formats (most likely only to a buffer).
On 25 May 2022, Uwe Brauer wrote: Sometimes I only want to convert/export a region or a paragraph of an org file to another format, most likely as html or latex. Is this different from subtree export? After C-c C-e, C-s will toggle "export scope" between buffer and subtree. (There's also C-v to toggle "visible only" export, which I've never used.) Or would it work to add a heading for the paragraph temporarily, just for export? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: [BUG] when open a large org file, emacs get stuck and show a warning "org-element--cache: Unregistered buffer modifications detected"
I'm also having problems like this with large files. I haven't been able to narrow it down but I'll try what you say about org-startup-folded. Do you also have a problem where sometimes TAB or SHIFT-TAB on a heading has no effect? Some Org files seem to get broken after editing them for a while, and some folding no longer works (that is, some headings stay closed, while others can be cycled), and the only way to fix it is to reload. I'll turn on debugging and see what that says. Bill On 17 May 2022, imymorror wang wrote: - desktop environment - GNU Emacs 29.0.50 (build 2, x86_64-apple-darwin20.4.0, NS appkit-2022.44 Version 11.3.1 (Build 20E241)) of 2022-01-08 - Org mode version 9.5.1 - bug description - influence factor - a large org file : 11053 lines。1092 headlines。 - (setq org-startup-folded t) - org-indent-mode : (add-hook 'org-mode-hook 'org-indent-mode) - My Observation - if setting org-startup-folded t , open the large org file, emacs get stuck, the mouse can't move。 - if keeping org-startup-folded defaul value(i.e "showeverything") , enable org-indent-mode , open the large org file, get a warning: #+begin_quote Warning (org-element-cache): org-element--cache: Unregistered buffer modifications detected. Resetting. If this warning appears regularly, please report it to Org mode mailing list (M-x org-submit-bug-report). #+end_quote - if keeping org-startup-folded defaul value and disable org-indent-mode , open the large org file, everything works fine -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada