Re: Bug: Failed to render org file during first load on buffer emacs 27.1 windows binaries [9.3 (release_9.3 @ c:/ProgramFilesh/emacs-27.1-x86_64/share/emacs/27.1/lisp/org/)]
Hello everyone,
I wanted to thank you guys for your guidance.
I was able to trace the issue through the debugger this far (27.2 binaries):
* org-mode()
* apply(#f(compiled-function () (interactive nil) #) nil)
* #f(compiled-function () (interactive nil) #)
nil) ()
* org-load-modules-maybe()
* require(ol-docview)
*
byte-code("\300\301!\210\300\302!\210\303\304\305\306\307\310\311\312&\7\207"
[require doc-view ol org-link-set-parameters "docview" :follow
org-docview-open :export org-docview-export :store org-docview-store-link]
8)
* require(doc-view)
*
byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\305\306\307\310\311\312\313\314\315\316\315\317\315\320\321\322&\17\210\323\324\325\326\327DD\330\331\332\313\333&\7\210..."
[require cl-lib dired image-mode jka-compr custom-declare-group doc-view
nil "In-buffer viewer for PDF, PostScript, DVI, and DJV..." :link
(function-link doc-view) :version "22.2" :group applications data
multimedia :prefix "doc-view-" custom-declare-variable
doc-view-ghostscript-program funcall function #f(compiled-function ()
#) "Program to convert PS and PDF files to PNG." :type
file "27.1" doc-view-pdfdraw-program #f(compiled-function () #) "Name of MuPDF's program to convert PDF files to PN..." "24.4"
doc-view-pdftotext-program-args #f(compiled-function () #) "Parameters to give to the pdftotext command." (repeat string)
doc-view-pdf->png-converter-function #f(compiled-function () #) "Function to call to convert a PDF file into a PNG ..." (radio
(function-item doc-view-pdf->png-converter-ghostscript :doc "Use
ghostscript") (function-item doc-view-pdf->png-converter-mupdf :doc "Use
mupdf") function) doc-view-ghostscript-options #f(compiled-function ()
#) "A list of options to give to ghostscript." (repeat
string) doc-view-ghostscript-device #f(compiled-function () #) "Output device to give to ghostscript." string
doc-view-resolution #f(compiled-function () #) ...] 16)
Once I got that far, it started evaluating too quickly for me to catch the
"shell command succeeded with no output".
I was able to create a workaround by adding (require 'ol-docview) to my
.emacs though so everything is at least functional again.
I'll probably try to learn more about debugging to see if I can pinpoint
the exact spot that's acting up but if anyone sees this again I think the
workaround should do fine.
All good things,
Aaron
On Sat, May 22, 2021 at 8:29 AM Ihor Radchenko wrote:
> Aaron Rea writes:
> > As for the org version, I hit this issue even when running it out of the
> > box.
>
> I recall exactly same issue reported some time ago on Reddit. It appears
> to be very rare and hard to debug from our side.
>
> > Is there perhaps a different set of windows binaries I should be
> > using?
>
> I believe that you should have no problem if you use Linux subsystem and
> install Linux version of Emacs there.
>
> > Or is there a way to run a stack trace on the entire emacs session?
> > It's not running into any actual error so debug isn't yielding anything.
>
> If you are willing to debug it, I suggest running
> 1. M-x debug-on-entry org-mode
> 2. Opening the file (first time)
> 3. Stepping through debugger to figure out what part of the org-mode
>startup is triggering the problem. See 19.1.8 Debugger Commands
>section of the Emacs manual for guide how to use the debugger.
>
> Hope it helps.
>
> Best,
> Ihor
>
Re: [wip-cite-new] Initial implementation of `csl' citation processor
On Sun, May 30, 2021 at 4:20 PM Nicolas Goaziou wrote: > > Would you have this nil by default, or is there a reasonable default > > you could set? > > I wrote "oc-basic" to be a reasonable, albeit very limited, default. > I just need to make it grow JSON support first. It might not line up with your timeline for this, , and I'm not sure if you want to depend on an external library, but you should probably be aware of the work that Joost is doing on parsebib to integrate CSL JSON support. The branch, including documentation: https://github.com/joostkremers/parsebib/tree/wip/csl Feedback etc: https://github.com/joostkremers/parsebib/issues/12 Bruce
Re: [org-cite, oc-csl] print_bibliography options
On Mon, May 31, 2021 at 2:11 PM András Simonyi wrote: > > Dear All, > > I think a useful default/baseline for handling the occurrence of > multiple #+print_bibliography keywords would be to implement the > "chapter use case", which, for each #+print_bibliography, would > collect only the citations occurring after to previous > #+print_bibliography (if there is one) and before the current one, and > print out an independent bibliography corresponding to the citations. > All citations in this section would refer to this bibliography, and > would be disambiguated accordingly. This would have two advantages: 1) add support for the "per section/chapter" use case András notes to oc-csl 2) avoid duplicate bibliographies in the example I raised; what we might call "multi-section bibliography" use case; then if and when citeproc-el adds support this, the documents would be gracefully enhanced Bruce
[PATCH] org-mac-link.el: Change homepage.
Hi, would like to move the homepage. See attached patch. Thanx. Salut Aimé Bertrand >From 1b95d433f03dd8fdb151874340c82bd801d9dcfa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Aim=C3=A9=20Bertrand?= Date: Mon, 31 May 2021 23:04:55 +0200 Subject: [PATCH] org-mac-link.el: Change homepage. * lisp/org-mac-link.el: Change homepage by maintainer. --- lisp/org-mac-link.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-mac-link.el b/lisp/org-mac-link.el index b94df7b..68be823 100644 --- a/lisp/org-mac-link.el +++ b/lisp/org-mac-link.el @@ -9,7 +9,7 @@ ;; Alan Schmitt ;; Mike McLean ;; Maintainer: Aimé Bertrand -;; Homepage: https://sr.ht/~aimebertrand/org-mac-link/ +;; Homepage: https://gitlab.com/aimebertrand/org-mac-link ;; ;; This file is not part of GNU Emacs. ;; -- 2.30.1 (Apple Git-130)
Re: Texinfo exporter fails to export M-x helm-documentation
Nicolas Goaziou writes: > The problem is that you are explicitly requesting a level of headlines > without providing a sectioning command for them. By default > `org-texinfo-classes' stops at level 4. > > Anyway, this should be fixed. Thank you. You did that in f99f26306c57d2342069880eac4dca324d7579ec but I think you added a off-by-one error in the process. In (>= (org-export-get-relative-level h info) (length sections)) the ">=" should be a ">", or it can match with 4 >= 4, which should result in valid menus, but is currently disallowed by this check. Jonas
Re: [org-cite, oc-csl] print_bibliography options
Dear All, I think a useful default/baseline for handling the occurrence of multiple #+print_bibliography keywords would be to implement the "chapter use case", which, for each #+print_bibliography, would collect only the citations occurring after to previous #+print_bibliography (if there is one) and before the current one, and print out an independent bibliography corresponding to the citations. All citations in this section would refer to this bibliography, and would be disambiguated accordingly. This could be implemented without any dedicated support on the processor's side, the basic processor could support this as well. Sectioned bibliographies, on the other hand, seem to be more complicated, and require processor-side support. best regards, András
Re: [wip-cite-new] Initial implementation of `csl' citation processor
Dear All, On Sat, 29 May 2021 at 18:22, Nicolas Goaziou wrote: > Here's another proposal: > > `org-cite-export-processor' is now an alist, where keys are export > back-ends or t, which is the default key. > > '((latex biblatex bibstyle citestyle) > (beamer natbib nil nil) > (my-latex natbib bibstyle) > (t csl nil nil)) > The selected processor is the one associated to the back-ends closest to > the current one used for export, by `org-export-derived-backend-p' > order. So if `my-other-latex' is derived from beamer, it will use > (natbib nil nil). This looks perfect. > OTOH, I suggest to stick to a single "cite_export" keyword, which > overrides any selected processor above. IOW > >#+cite_export: basic > > will use basic whatever the current export back-end is. > > In practice, I think it is sufficient. The only case where it may be > limiting is if you need to export with two different back-ends with two > processors different from those set in `org-cite-export-processor'. But > in that situation, I think swapping the cite_export keyword is > acceptable. > > So overall, I think it is a good compromise between simplicity and > power. > WDYT? I agree, can be revisited later if necessary, but seems to be a very strong starting point -- thanks. best regards, András
Re: TMIO Pre-release, request for feedback
Timothy, Thanks for your work on this. I think it is an excellent resource. Best regards, John On Sun, May 30, 2021 at 12:36 PM Timothy wrote: > Hi Everyone, > > As we arrive at the end of May, I'm about to publish the 3rd issue of > /This Month in Org/. I thought I'd share the current draft with the list > the day before I publish to so that those of you who are interested have > the chance to point out any errors, let me know if there's anything I > haven't covered that you'd like to see, along with any other feedback > you may have. > > For the next day, you can find the draft at: > https://blog.tecosaur.com/tmio/DRAFT-2021-05-31.html > and then once published it will live at: > https://blog.tecosaur.com/tmio/2021-05-31.html > > All the best, > > Timothy. > > p.s. Based on the response to this, I may or may not keep on doing this. > If you would (or wouldn't) like to see me repeat this, let me know :) > >
Re: [bug] org-agenda-set-tags does not append tags to headline but at cursor
Jakob Schöttl writes: > I checked again, C-c C-q in org-agenda is definitely mapped to > org-agenda-set-tags. Can the reason be a certain minor mode in the org > or org-agenda buffer? I'm having evil mode, for example. Do you have > another tipp for debugging? You can try to bisect your config with bug-hunter. See comments in https://github.com/yantar92/org/issues/11 Best, Ihor
Re: [PATCH] org-table.el: Fix usage of user-error
Ping! -- Utkarsh Singh http://utkarshsingh.xyz
Re: [oc-csl] testing status
On Mon, May 31, 2021 at 10:33 AM András Simonyi wrote: > > Dear All, > > (what follows is a copy of my reply to the corresponding citeproc-el issue) > I think I managed to track this down. First of all, the issue doesn't > affect html and latex Org exports, which use the html and latex output > of citeproc-el directly; the problematic behavior occurs only when > citeproc-el produces org output and this gets embedded in the Org > document before exporting. In the latter case, the Org exporter treats > the doi links in the bibliography as it would any doi link in the > document, and, apparently, this means converting them to urls by > default. (I don't know what is the easiest way of turning this off.) I'll also copy my reply: Thanks for looking into this! I'm glad I was wrong about it also happening with the HTML output; I got confused as I was switching styles. If this doesn't happen with HTML and LaTeX, it's much less of an issue. But still, ideally it would work consistently (across backends). Bruce
Re: [oc-csl] testing status
Dear All, (what follows is a copy of my reply to the corresponding citeproc-el issue) I think I managed to track this down. First of all, the issue doesn't affect html and latex Org exports, which use the html and latex output of citeproc-el directly; the problematic behavior occurs only when citeproc-el produces org output and this gets embedded in the Org document before exporting. In the latter case, the Org exporter treats the doi links in the bibliography as it would any doi link in the document, and, apparently, this means converting them to urls by default. (I don't know what is the easiest way of turning this off.) best regards, András On Sun, 30 May 2021 at 23:36, Bruce D'Arcus wrote: > > On Sun, May 30, 2021 at 5:24 PM András Simonyi > wrote: > > > > Dear All, > > > > On Sun, 30 May 2021 at 22:38, Bruce D'Arcus wrote: > > > > > There is one thing I can't figure out. Here's the output I get: > > > I don't understand why that URL is included, as that entry has no URL. > > > > > It seems citeproc-el may have a parameter that substitutes DOI URL if > > > DOI is present, but URL is absent if t? > > > > > András: Is that correct? > > > > citeproc-el definitely doesn't have this kind of functionality, it > > must come from the used CSL style somehow. Is the result different > > with other citeprocs? > > It's maybe a style issue, though I haven't figured it out yet. > > This is what pandoc produces with the same style etc. > > Low, Setha M. “The Edge and the Center: Gated Communities and the > Discourse of Urban Fear.” American Anthropologist 103, no. 1 (March 1, > 2001): 45–58. doi:10.1525/aa.2001.103.1.45. > > ... which is what I read the style > (chicago-note-bibliography-16th-edition.csl) to specify. > > I'll explore more, probably tomorrow. > > Bruce
Re: [bug] org-agenda-set-tags does not append tags to headline but at cursor
Am 31.05.21 um 15:17 schrieb Ihor Radchenko: Jakob Schöttl writes: Reproduce: ... The tags are not appended to the task's headline but to the line the cursor was. I tried with Org 9.4.4 and with current master. I cannot reproduce. Can you try to repeat your steps from emacs -Q? Thanks for your response! I cannot reproduce with emacs -Q either. I checked again, C-c C-q in org-agenda is definitely mapped to org-agenda-set-tags. Can the reason be a certain minor mode in the org or org-agenda buffer? I'm having evil mode, for example. Do you have another tipp for debugging?
Re: Bug: Reclocking errors out if org-log-note-clock-out is t [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]
"Jorge P. de Morais Neto" writes: > - Expected behavior: Org should clock in the first heading, then clock > out from it, prompt for a note, and clock in the second heading (in > batch mode, Emacs should print some clocking messages and then exit > successfully). > - What happens: Org errors out: > user-error: Before first headline at position 164 in buffer *Org Note* Confirmed The fix is attached. Best, Ihor >From 7dc855ae1d7992eaacc2cab13a39c6000e4e66bf Mon Sep 17 00:00:00 2001 Message-Id: <7dc855ae1d7992eaacc2cab13a39c6000e4e66bf.1622468529.git.yanta...@gmail.com> From: Ihor Radchenko Date: Mon, 31 May 2021 21:39:51 +0800 Subject: [PATCH] Correctly handle org-log-note-clock-out non-interactively * lisp/org-clock.el (org-clock-out): Delay log popup to after-command-hook to avoid messing up non-interactive calls. `org-add-log-setup' without 'note argument would raise interactive note buffer immediately, so we do pass the 'note argument. --- lisp/org-clock.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 3b7d97639..0328bddd3 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1691,7 +1691,7 @@ (defun org-clock-out ( switch-to-state fail-quietly at-time) (line-beginning-position 2))) (org-log-note-clock-out (org-add-log-setup - 'clock-out nil nil nil + 'clock-out nil nil 'note (concat "# Task: " (org-get-heading t) "\n\n" (when org-clock-mode-line-timer (cancel-timer org-clock-mode-line-timer) -- 2.26.3
Re: [bug] org-agenda-set-tags does not append tags to headline but at cursor
Jakob Schöttl writes: > Reproduce: > ... > The tags are not appended to the task's headline but to the line the > cursor was. I tried with Org 9.4.4 and with current master. I cannot reproduce. Can you try to repeat your steps from emacs -Q? Best, Ihor
Re: How to hide *Org Links* buffer when insert new links?
Shiyao MA writes:
> Hi,
>
> When insert org links with org-insert-link, an Org Links buffer is created.
>
> How can I hide it?
You cannot prevent it from being created. It is hard-coded. However, you
should be able to prevent Emacs from showing the buffer window by
modifying your display-buffer-alist:
(add-to-list 'display-buffer-alist '(("Org Links" display-buffer-no-window
(allow-no-window . t
... except you cannot. Apparently, Org mode is being too aggressive and
ignores display-buffer-alist. I do not think that it is supposed to
happen. The patch fixing current aggressive behaviour and allowing the
above code to work is attached.
Dear All,
I do not think that unconditionally setting display-buffer-alist to nil
in org-no-popups macro is the right thing to do. I updated the macro
using pop-up-windows setting to nil instead of completely trashing
user-defined display-buffer-alist. The latter is nil by default and if
not, the user should know what he/she is doing.
Best,
Ihor
>From c598f0208738f16b6d00c05a7338c226d15f5d12 Mon Sep 17 00:00:00 2001
Message-Id:
From: Ihor Radchenko
Date: Mon, 31 May 2021 20:47:45 +0800
Subject: [PATCH] Do not ignore user-defined display-buffer-alist in
org-insert-link
* lisp/ol.el (org-insert-link): Handle case when *Org Links* window is
not created.
* lisp/org-macs.el (org-no-popups): Do not override
`display-buffer-alist'. Use `pop-up-windows' instead.
---
lisp/ol.el | 13 +++--
lisp/org-macs.el | 2 +-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/lisp/ol.el b/lisp/ol.el
index a2cf872b8..ae0177695 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1856,12 +1856,13 @@ (defun org-insert-link ( complete-file link-location description)
(reverse org-stored-links)
"\n")))
(goto-char (point-min)))
- (let ((cw (selected-window)))
- (select-window (get-buffer-window "*Org Links*" 'visible))
- (with-current-buffer "*Org Links*" (setq truncate-lines t))
- (unless (pos-visible-in-window-p (point-max))
- (org-fit-window-to-buffer))
- (and (window-live-p cw) (select-window cw)))
+ (when (get-buffer-window "*Org Links*" 'visible)
+(let ((cw (selected-window)))
+ (select-window (get-buffer-window "*Org Links*" 'visible))
+ (with-current-buffer "*Org Links*" (setq truncate-lines t))
+ (unless (pos-visible-in-window-p (point-max))
+ (org-fit-window-to-buffer))
+ (and (window-live-p cw) (select-window cw
(setq all-prefixes (append (mapcar #'car abbrevs)
(mapcar #'car org-link-abbrev-alist)
(org-link-types)))
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index d56fc3bce..133960fea 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -170,7 +170,7 @@ (defmacro org-preserve-local-variables ( body)
(defmacro org-no-popups ( body)
"Suppress popup windows and evaluate BODY."
- `(let (pop-up-frames display-buffer-alist)
+ `(let (pop-up-frames pop-up-windows)
,@body))
--
2.26.3
import xls(x) into org on MacOS
Hi
I am usually using Ubuntu 16.04, but for the coming days, I have to use
a MacBook, running 10.15 and fink installed.
I usually convert xls(x) to org, using
'(org-odt-convert-process "gnumeric")
'(org-odt-convert-processes '(("gnumeric" "/usr/bin/ssconvert %i %o")))
But gnumeric does not exist in fink, does anybody know about an
alternative?
(Yes I know I should have used macports or homebrew, but now it is too
late).
Regards
Uwe Brauer
An attempt to convert Elfeed entries (with parameters) to Org trees
Hi all, I like to keep up to date with new LaTeX packages that are being uploaded to CTAN and I'm subscribed to the CTAN news feed. I always use Elfeed to check my subscriptions, but it occurred to me to write a function (with org-map-entries) to be able to pass Elfeed entries (with certain parameters) to Org trees. For example, something like: * New on CTAN :PROPERTIES: :ELFEED: @6-months-ago +TeX New on CTAN :END: Or, for /This Month in Org/: * /This Month in Org/ :PROPERTIES: :ELFEED: @3-months-ago +tmio :END: And then run `my-org/insert-entries-elfeed'. If anyone wants to try it, I attach an Org document with the code, which is very preliminary, not too fancy and quite improvable. Feedback welcome! :-) Best regards, Juan Manuel elfeed-to-org.org Description: Lotus Organizer
Re: source blocks mangled when edited
On 31/05/21 9:42 pm, Sébastien Miquel wrote: > There must be an issue with the `replace-buffer-contents` calls. Can > you call `trace-function` on `replace-buffer-contents` and trigger the > behaviour again to see what it returns ? > This is all the *trace-output* buffer shows: == 1 -> (replace-buffer-contents #) 1 <- replace-buffer-contents: nil
Re: source blocks mangled when edited
Michael Gauland writes: I didn't instrument the functions, but found that there are two places that test '(if (version< emacs-version "26.1"...'. If I change that to use "version<=", the problem goes away (I'm still running 26.1). I don't know whether this is the right fix (the underlying problem may be a quirk in my system, and this is just masking it). I'm hesitant to submit a patch unless someone else can replicate the problem. The commit `d02ad1f207e1579aff8f36f740a065d71472c182` introduced the use of `replace-buffer-contents` when available. This function was introduced in emacs 26.1, hence the version tests. There must be an issue with the `replace-buffer-contents` calls. Can you call `trace-function` on `replace-buffer-contents` and trigger the behaviour again to see what it returns ? You said it also happens with `emacs -q`, right ? I'll try to see if I can reproduce with emacs 26.1 tomorrow. -- Sébastien Miquel
Re: source blocks mangled when edited
On 31/05/21 8:15 pm, Sébastien Miquel wrote: > The relevant functions are `org-edit-src-exit` and perhaps > `org-src--contents-for-write-back`. > > Can you instrument these functions to see what's happening ? Is > `org-src--contents-for-write-back` populating the buffer correctly ? > Does the `replace-buffer-contents` call in `org-edit-src-exit` return > `t` ? > I didn't instrument the functions, but found that there are two places that test '(if (version< emacs-version "26.1"...'. If I change that to use "version<=", the problem goes away (I'm still running 26.1). I don't know whether this is the right fix (the underlying problem may be a quirk in my system, and this is just masking it). I'm hesitant to submit a patch unless someone else can replicate the problem.
Re: source blocks mangled when edited
Hi Michael,
Michael Gauland writes:
The file has two identical source blocks. The first generally behaves
fine, though some lines get extra indentation.
The second suffers more serious distortions. For example, the first line
changes from "digraph G {" to "aph G {".
I'm unable to reproduce with a recent emacs version.
I'm not even sure how to start tracking this down. Any help would be
greatly appreciated!
The relevant functions are `org-edit-src-exit` and perhaps
`org-src--contents-for-write-back`.
Can you instrument these functions to see what's happening ? Is
`org-src--contents-for-write-back` populating the buffer correctly ?
Does the `replace-buffer-contents` call in `org-edit-src-exit` return
`t` ?
Regards,
--
Sébastien Miquel
Re: source blocks mangled when edited
On 31/05/21 4:21 pm, Samuel Wales wrote: > idk if this will help as you probably know all of it already. butg > you asked for any help so here goes. i run maint, not master or any > emacs versions. weird that you are missing 3 cols? Switching to the maint branch didn't change anything, but I found that I was unable to reproduce the problem with commit 9802877fbe442a52b4e63782b84921f46cf5d56b, but *could* reproduce it from commit d02ad1f207e1579aff8f36f740a065d71472c182. Since that commit affects org-src.el, I may be on the right track.
