Re: Bug: org-babel-execute:emacs-lisp does not allow changing window configuration from within code block [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Hi,

I still can reproduce the bug, following the recipe.

Org mode version 9.3.6 (release_9.3.6-441-gba6855 @ 
/home/yantar92/.emacs.d/straight/build/org/)

Best,
Ihor

Bastien  writes:

> Hi Ihor,
>
> this is fixed in maint now, thanks!
>
> -- 
>  Bastien

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

Re: Bug: org-agenda-open-link disallow permanenly changing point position while opening some links (e.g. elisp:) [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Hi Bastien,

Seems _not_ to be fixed. I see the same problem following my recipe.

Org mode version 9.3.6 (release_9.3.6-441-gba6855 
@/home/yantar92/.emacs.d/straight/build/org/)

Best,
Ihor

Bastien  writes:

> Hi Ihor,
>
> thanks for reporting this, this should be fixed now.
>
> -- 
>  Bastien
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

[PATCH] org-shift*: Honor org-support-shift-select for table cell movement

[Kyle Meyer]

Kyle Meyer  writes:

> The change in behavior happened with 09f950723 (Added keybindings for
> `org-table-move-cell-*' functions), which was a part of the v9.3
> release.  Looking at that commit and scanning the associated thread [^],
> I'm guessing the interaction with org-support-shift-select was simply
> overlooked and those org-table-move-cell-* calls should be updated to
> inspect org-support-shift-select, like (some of) the other neighboring
> branches in the code.
>
> I'll take a look at doing that tomorrow.

Here's a patch that prevents calling org-table-move-cell-* when
org-support-shift-select is `always'.  I'll apply this in a day or two
if no one chimes in to explain why org-table-move-cell-* shouldn't
consider org-support-shift-select.

-- >8 --
Subject: [PATCH] org-shift*: Honor org-support-shift-select for table cell
 movement

* lisp/org.el (org-support-shift-select): Mention table context.
(org-shiftup):
(org-shiftdown):
(org-shiftright):
(org-shiftleft): Don't move table cells when org-support-shift-select
is `always'.

Reported-by: Vladimir Panteleev 

---
 lisp/org.el | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3d841dfa6..c1dffab3c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -854,6 +854,7 @@ (defcustom org-support-shift-select nil
 - in a plain list item, changing the bullet type
 - in a property definition line, switching between allowed values
 - in the BEGIN line of a clock table (changing the time block).
+- in a table, moving the cell in the specified direction.
 Outside these contexts, the commands will throw an error.
 
 When this variable is t and the cursor is not in a special
@@ -863,9 +864,9 @@ (defcustom org-support-shift-select nil
 if the cursor is exactly on the bullet.
 
 If you set this variable to the symbol `always', then the keys
-will not be special in headlines, property lines, and item lines,
-to make shift selection work there as well.  If this is what you
-want, you can use the following alternative commands:
+will not be special in headlines, property lines, item lines, and
+table cells, to make shift selection work there as well.  If this is
+what you want, you can use the following alternative commands:
 `\\[org-todo]' and `\\[org-priority]' \
 to change TODO state and priority,
 `\\[universal-argument] \\[universal-argument] \\[org-todo]' \
@@ -17435,7 +17436,9 @@ (defun org-shiftup ( arg)
((and (not org-support-shift-select) (org-at-item-p))
 (call-interactively 'org-previous-item))
((org-clocktable-try-shift 'up arg))
-   ((org-at-table-p) (org-table-move-cell-up))
+   ((and (not (eq org-support-shift-select 'always))
+(org-at-table-p))
+(org-table-move-cell-up))
((run-hook-with-args-until-success 'org-shiftup-final-hook))
(org-support-shift-select
 (org-call-for-shift-select 'previous-line))
@@ -17461,7 +17464,9 @@ (defun org-shiftdown ( arg)
((and (not org-support-shift-select) (org-at-item-p))
 (call-interactively 'org-next-item))
((org-clocktable-try-shift 'down arg))
-   ((org-at-table-p) (org-table-move-cell-down))
+   ((and (not (eq org-support-shift-select 'always))
+(org-at-table-p))
+(org-table-move-cell-down))
((run-hook-with-args-until-success 'org-shiftdown-final-hook))
(org-support-shift-select
 (org-call-for-shift-select 'next-line))
@@ -17499,7 +17504,9 @@ (defun org-shiftright ( arg)
 (org-at-property-p))
 (call-interactively 'org-property-next-allowed-value))
((org-clocktable-try-shift 'right arg))
-   ((org-at-table-p) (org-table-move-cell-right))
+   ((and (not (eq org-support-shift-select 'always))
+(org-at-table-p))
+(org-table-move-cell-right))
((run-hook-with-args-until-success 'org-shiftright-final-hook))
(org-support-shift-select
 (org-call-for-shift-select 'forward-char))
@@ -17537,7 +17544,9 @@ (defun org-shiftleft ( arg)
 (org-at-property-p))
 (call-interactively 'org-property-previous-allowed-value))
((org-clocktable-try-shift 'left arg))
-   ((org-at-table-p) (org-table-move-cell-left))
+   ((and (not (eq org-support-shift-select 'always))
+(org-at-table-p))
+(org-table-move-cell-left))
((run-hook-with-args-until-success 'org-shiftleft-final-hook))
(org-support-shift-select
 (org-call-for-shift-select 'backward-char))

base-commit: 561e9efd062e23321f3b56b2e3482ef3afc7416f
-- 
2.26.0

Re: Bug: org-agenda-tag-filter-preset not respected [9.3.6 (9.3.6-19-gf360f9-elpaplus @ /home/jorge/.config/emacs/elpa/27.0/develop/org-plus-contrib-20200302/)]

[Kyle Meyer]

Kyle Meyer  writes:

> Subject: [PATCH] agenda: Fix regression in handling of non-caterory filters

Applied to maint (561e9efd0).

Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

[Kyle Meyer]

No Wayman  writes:

> Subject: [PATCH] org-archive.el: fix org-archive-subtree-save-file-p

I've applied your patch with a few tweaks in 374cb4b41.

Note that you're approaching the "tiny change" limit.  In order to be
able to make future contributions, please consider the signing the FSF
copyright papers.  More information is at
.

Thanks for the report and the fix!

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Tue, Apr 7, 2020 at 5:13 PM Joost Kremers  wrote:

> On Tue, Apr 07 2020, Bruce D'Arcus wrote:
> > While I of course can't speak for John, I would hope and expect
> > org
> > ref to support the new syntax.
> >
> > I would hope and expect the same of other packages (like ebib)
> > that
> > use their own custom syntax.
>
> Ebib maintainer here. I would certainly include support in Ebib
> for any citation syntax that Org would adopt.
>
> What would help, BTW, is if there's an easy way to find out what
> the bibliography file or files are that are associated with the
> current Org buffer.

I guess the simplest and most flexible option would be to specify the
bib file in the header?

So if present use that; otherwise use the global bib file(s) specified
in the init?

Bruce

Re: org-footnote renumbering

[Kyle Meyer]

Sharon Kimble  writes:

> In the org manual v9.3 on page 139 it explains how to renumber the
> footnotes. I am presuming from reading it that it requires me to C-c
> C-x r.

I don't spot any mention of 'C-c C-x r'.  The table in the footnote
section that lists keys is describing the menu that org-footnote-action
(bound to 'C-c C-x f' by default) shows when it's called with a prefix
argument.  So, the full sequence to get to 'r' listed in that table
would be 'C-u C-c C-x f r`.

Re: Bug: New agenda filtering multiple tags broken [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200406/)]

[Kyle Meyer]

Allen Li  writes:

> The new agenda filtering doesn't seem to work properly with multiple
> tags.
>
> Opening the file below, e.g., at /tmp/tmp.org
>
> * TODO foo  :foo:
> * TODO bar  :foo:bar:
> * TODO baz
>
> Open an agenda buffer M-x org-agenda RET < t
>
> Filter / +foo-bar RET
>
> I expect to see only
>
> TODO foo
>
> But instead I see all of the items, as if the filter was ignored.

Thanks for the report.  The underlying issue is the same source as the
bug reported at this thread:

  https://yhetil.org/orgmode/87369g0y2a@kyleam.com/T/#u

I've confirmed that the patch there fixes the test case you described.

Bug: org-eldoc should require org-refile [9.3.6 (release_9.3.6-442-g97f0f1 @ /home/ryan/.emacs.d/straight/build/org-plus-contrib/)]

[Ryan C. Thompson]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


`org-eldoc-get-breadcrumb' in org-eldoc.el calls `org-get-outline-path' 
which is defined in org-refile.el, but org-eldoc does not load 
org-refile. This results in void-function errors when the Eldoc idle 
timer runs in an org buffer, unless you manually load org-refile. To fix 
this, org-eldoc should load org-refile.


Emacs : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d 
scroll bars)

of 2019-09-23, modified by Debian
Package: Org mode version 9.3.6 (release_9.3.6-442-g97f0f1 @ 
/home/ryan/.emacs.d/straight/build/org-plus-contrib/)


current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

org-after-todo-state-change-hook '(org-checklist)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function

org-odt-format-headline-function 'org-odt-format-headline-default-function
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-reveal-start-hook '(org-decrypt-entry)
org-mode-hook '((lambda nil (org-bullets-mode 1))
#[0 "\301\211\207" [imenu-create-index-function org-imenu-get-tree] 2]
#[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook 
org-show-all append local] 5]

#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes org-eldoc-load)
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

org-adapt-indentation nil
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)

org-checklist-export-function 'org-export-as-ascii
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME 
CONTENTS WIDTH)"]

org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . 
php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer" . latex) ("calc" . 
fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp" . emacs-lisp) ("ocaml" 
. tuareg)

("screen" . shell-script) ("shell" . sh) ("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-show-empty-lines

org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence "TODO" "|" "DONE" "CANCELLED"))
org-support-shift-select t
org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
org-odt-format-inlinetask-function 
'org-odt-format-inlinetask-default-function

org-html-allow-name-attribute-in-anchors t
org-export-async-init-file 
"/home/ryan/.emacs.d/.temp-org-export-async-init.el"
org-export-before-parsing-hook '(org-attach-expand-links 
org-latex-header-blocks-filter)

org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete 
org-attach-complete-link)

("id" :follow org-id-open) ("message" :follow org-mac-message-open)
("x-devonthink-item" :follow org-devonthink-item-open)
("mac-evernote" :follow org-mac-evernote-note-open)
("mac-outlook" :follow org-mac-outlook-message-open)
("acrobat" :follow org-mac-acrobat-open) ("skim" :follow org-mac-skim-open)
("addressbook" :follow org-mac-addressbook-item-open)
("x-together-item" :follow org-mac-together-item-open)
("mairix" :follow org-mairix-open :store org-mairix-store-gnus-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)
("roll" :follow 

Re: wip-cite status question and feedback

[Joost Kremers]

On Tue, Apr 07 2020, Bruce D'Arcus wrote:
While I of course can't speak for John, I would hope and expect 
org

ref to support the new syntax.

I would hope and expect the same of other packages (like ebib) 
that

use their own custom syntax.


Ebib maintainer here. I would certainly include support in Ebib 
for any citation syntax that Org would adopt. 

What would help, BTW, is if there's an easy way to find out what 
the bibliography file or files are that are associated with the 
current Org buffer.


--
Joost Kremers
Life has its moments

Bug: New agenda filtering multiple tags broken [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200406/)]

[Allen Li]

The new agenda filtering doesn't seem to work properly with multiple
tags.

Opening the file below, e.g., at /tmp/tmp.org

* TODO foo  :foo:
* TODO bar  :foo:bar:
* TODO baz

Open an agenda buffer M-x org-agenda RET < t

Filter / +foo-bar RET

I expect to see only

TODO foo

But instead I see all of the items, as if the filter was ignored.

Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29
Package: Org mode version 9.3.6 (9.3.6-29-g6a3dff-elpaplus @ 
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20200406/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-checklist)
 org-columns-default-format "%60ITEM %TODO %Effort{:} %CLOCKSUM"
 org-agenda-skip-scheduled-if-deadline-is-shown t
 org-link-shell-confirm-function 'yes-or-no-p
 org-agenda-sticky t
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 2))
 org-speed-commands-user '(("a" progn (forward-char 1) (call-interactively 
'org-insert-heading-respect-content) (org-demote)) ("N" . 
org-toggle-narrow-to-subtree))
 org-enforce-todo-dependencies t
 org-special-ctrl-k t
 org-checkbox-hierarchical-statistics nil
 org-export-use-babel nil
 org-edit-src-content-indentation 0
 org-special-ctrl-a/e t
 org-columns-modify-value-for-display-function 
'orgx-columns-remove-stars-for-display
 org-log-redeadline 'note
 org-modules '(org-bibtex org-docview org-eww org-gnus org-habit org-id 
org-info org-irc org-mhe org-protocol org-rmail org-w3m org-checklist 
org-depend)
 org-blocker-hook '(org-depend-block-todo 
org-block-todo-from-children-or-siblings-or-parent)
 org-id-link-to-org-use-id 'create-if-interactive
 org-clock-persist 'history
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-clock-string-limit 25
 org-clock-history-length 25
 org-agenda-persistent-filter t
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-adapt-indentation nil
 org-log-reschedule 'time
 org-agenda-text-search-extra-files '(agenda-archives)
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-agenda-search-view-always-boolean t
 org-babel-load-languages '((dot . t) (emacs-lisp . t) (ledger . t) (python . 
t) (shell . t) (ditaa . t))
 org-log-done 'time
 org-agenda-skip-deadline-prewarning-if-scheduled 'pre-scheduled
 org-export-backends '(ascii html md texinfo)
 org-checklist-export-function 'org-export-as-ascii
 org-ellipsis "..."
 org-attach-store-link-p 'attached
 org-agenda-span 'day
 org-trigger-hook '(org-depend-trigger-todo)
 org-latex-packages-alist '(("" "siunitx" t))
 org-clock-into-drawer "CLOCK"
 org-clock-out-remove-zero-time-clocks t
 org-confirm-babel-evaluate nil
 org-use-sub-superscripts '{}
 org-use-speed-commands '(lambda nil (and (looking-at org-outline-regexp) 
(looking-back "^**")))
 org-agenda-todo-ignore-scheduled 'future
 org-ctrl-k-protect-subtree 'error
 org-agenda-skip-unavailable-files t
 )

Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

No Wayman  writes:


Attaching a proper patch with your suggested revisions here.


Sorry, I'm not used to submitting patches through email.
I see it inlined on my end, but it does not appear as if it was 
attached.

Trying once more:

>From 289d3ff93c9f7f56ee54d98fd7d6294c4472a37b Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Tue, 7 Apr 2020 14:39:29 -0400
Subject: [PATCH] org-archive.el: fix org-archive-subtree-save-file-p

Consider case of 'from-org setting in saving logic.
Improve docstring.
Remove dead code comment.
---
 lisp/org-archive.el | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 10a5eb501..5e11c3743 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -92,14 +92,20 @@ When a string, a %s formatter will be replaced by the file name."
 	  (const :tag "Always" t)))
 
 (defcustom org-archive-subtree-save-file-p 'from-org
-  "Non-nil means save the archive file after archiving a subtree."
+  "Conditionally save the archive file after archiving a subtree.
+This variable can be any of the following symbols:
+
+t  saves in all cases.
+`from-org' prevents saving from an agenda-view.
+`from-agenda'  saves only when the archive is initiated from an agenda-view.
+nilprevents saving in all cases."
   :group 'org-archive
   :package-version '(Org . "9.4")
   :type '(choice
-	  (const :tag "Always save the archive buffer" t)
-	  (const :tag "Save target buffer when archiving from an agenda view" from-agenda)
-	  (const :tag "Save target buffer when archiving from an org buffer" from-org)
-	  (const :tag "Do not save the archive buffer")))
+ (const :tag "from-org"from-org)
+ (const :tag "from-agenda" from-agenda)
+ (const :tag "t" t)
+ (const :tag "nil")))
 
 (defcustom org-archive-save-context-info '(time file olpath category todo itags)
   "Parts of context info that should be stored as properties when archiving.
@@ -373,14 +379,13 @@ direct children of this heading."
 		 value
 	  ;; Save and kill the buffer, if it is not the same
 	  ;; buffer and depending on `org-archive-subtree-save-file-p'
-	  (unless (eq this-buffer buffer)
-		(when (or (eq org-archive-subtree-save-file-p t)
-			  (and (boundp 'org-archive-from-agenda)
-			   (eq org-archive-subtree-save-file-p 'from-agenda)))
-		  (save-buffer)))
-	  ;; (unless (or (not org-archive-subtree-save-file-p)
-	  ;; 		  (eq this-buffer buffer))
-	  ;; 	(save-buffer))
+  (unless (eq this-buffer buffer)
+(when (or (eq org-archive-subtree-save-file-p t)
+  (and (boundp 'org-archive-from-agenda)
+   (eq org-archive-subtree-save-file-p 'from-agenda))
+  (and (not (boundp 'org-archive-from-agenda))
+   (eq org-archive-subtree-save-file-p 'from-org)))
+  (save-buffer)))
 	  (widen
 	;; Here we are back in the original buffer.  Everything seems
 	;; to have worked.  So now run hooks, cut the tree and finish
-- 
2.26.0

Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Kyle Meyer  writes:

Thanks for the suggestion.  The code is somewhat oddly 
formatted, at
least on my end.  Could you send a proper git-format-patch 
output to

this thread (either via git-send-email or as an attachment)?


Apologies, I pasted that from an Org buffer without reformatting.
Attaching a proper patch with your suggested revisions here.

I suppose the main argument against from-org is that it's not 
clear
from the name alone that it's referring to a non-agenda Org 
buffer
because "org" is of course a bit overloaded. Considered 
alongside

from-agenda, I don't think it's too bad though.



I agree. 'from-org is pretty vague. That, combined with the old 
saving logic was

part of the reason for my initial confusion.
I don't mind keeping it if you feel it's satisfactory, though.
I'm more after the proper functionality.

This current buffer bit also applies to unless-agenda/from-org. 
Perhaps
it'd make sense to just mention the current buffer behavior in 
the main

docstring, given it applies to all options (even though for
only-agenda/from-agenda, it's never the case that the archive 
buffer is

the current buffer).


I've dropped the mention of the current-buffer case in the 
docstring altogether.



In summary

  * I'd prefer to make a more minimal change on top of 
  3d0282ef8,
keeping the names chosen there.  Functionally that comes 
down to
adjusting the condition that guards the save-buffer call to 
consider

from-org.

  * I think it'd be good to expand the docstring (along the 
  lines of
what you suggested) as well as trim and clarify the tag text 
a bit.


Took a look at `org-archive-save-context-info' as you suggested. 
The new docstring is similar to that.




===File 
/home/n/.emacs.d/straight/repos/org/0001-org-archive.el-fix-org-archive-subtree-save-file-p.patch===
From 289d3ff93c9f7f56ee54d98fd7d6294c4472a37b Mon Sep 17 00:00:00 

2001
From: Nicholas Vollmer 
Subject: [PATCH] org-archive.el: fix 
org-archive-subtree-save-file-p


Consider case of 'from-org setting in saving logic.
Improve docstring.
Remove dead code comment.
---
lisp/org-archive.el | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 10a5eb501..5e11c3743 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -92,14 +92,20 @@ When a string, a %s formatter will be replaced 
by the file name."

  (const :tag "Always" t)))

(defcustom org-archive-subtree-save-file-p 'from-org
-  "Non-nil means save the archive file after archiving a 
  subtree."

+  "Conditionally save the archive file after archiving a subtree.
+This variable can be any of the following symbols:
+
+t  saves in all cases.
+`from-org' prevents saving from an agenda-view.
+`from-agenda'  saves only when the archive is initiated from an 
agenda-view.

+nilprevents saving in all cases."
  :group 'org-archive
  :package-version '(Org . "9.4")
  :type '(choice
- (const :tag "Always save the archive buffer" t)
-	  (const :tag "Save target buffer when archiving from an agenda 
view" from-agenda)
-	  (const :tag "Save target buffer when archiving from an org 
buffer" from-org)

- (const :tag "Do not save the archive buffer")))
+ (const :tag "from-org"from-org)
+ (const :tag "from-agenda" from-agenda)
+ (const :tag "t" t)
+ (const :tag "nil")))

(defcustom org-archive-save-context-info '(time file olpath 
category todo itags)
  "Parts of context info that should be stored as properties when 
  archiving.

@@ -373,14 +379,13 @@ direct children of this heading."
 value
  ;; Save and kill the buffer, if it is not the same
	  ;; buffer and depending on 
`org-archive-subtree-save-file-p'

- (unless (eq this-buffer buffer)
-   (when (or (eq org-archive-subtree-save-file-p t)
- (and (boundp 'org-archive-from-agenda)
-  (eq org-archive-subtree-save-file-p 
'from-agenda)))
- (save-buffer)))
- ;; (unless (or (not org-archive-subtree-save-file-p)
- ;;  (eq this-buffer buffer))
- ;;(save-buffer))
+  (unless (eq this-buffer buffer)
+(when (or (eq org-archive-subtree-save-file-p t)
+  (and (boundp 'org-archive-from-agenda)
+   (eq 
org-archive-subtree-save-file-p 'from-agenda))
+  (and (not (boundp 
'org-archive-from-agenda))
+   (eq 
org-archive-subtree-save-file-p 'from-org)))

+  (save-buffer)))
  (widen
;; Here we are back in the original buffer.  Everything seems
;; to have worked.  So now run hooks, cut the tree and finish
--
2.26.0

Re: wip-cite status question and feedback

[Bruce D'Arcus]

Sorry for the typos, and also a more important mistake: a didn't mean
citeproc-hs, but citeproc-rs.

https://github.com/cormacrelf/citeproc-rs

On Tue, Apr 7, 2020 at 2:27 PM Bruce D'Arcus  wrote:
>
> Thank you for this thorough reply, Nicholas!
>
> See below.
>
> On Tue, Apr 7, 2020 at 1:51 PM Nicolas Goaziou  wrote:
> >
> > Hello,
> >
> > "Bruce D'Arcus"  writes:
> >
> > > Hi everyone; first post.
> >
> > Welcome!
> >
> > > I see from the archive there was an encouraging thread from April of 2018
> > > 
> > > (so, two years ago) that seemed to suggest merging to master was close,
> > > with perhaps some uncertainty around syntax being the primary hold up?
> > >
> > > My main question: how do we get this done?
> >
> > Good question. I don't think syntax is the primary hold up. It seems to
> > me that the glue part between the parser and the export back-ends is
> > missing. If we merge wip-cite branch in master, where do we plug it? How
> > do Org folks use it, out of the box? It also need tooling. For example,
> > citations could be a link to a database.
>
> OK, gotcha. That does explain the "hold up."
>
> I'll come back to this below, but for now simply say that ideal would
> probably be a default formatting library and database, with room to
> replace with other options.
>
> For the database, it would make to do as existing tools do; allow
> users to define default bib(la)tex files.
>
> [snip]
>
> > Actually, barring the "cite:" prefix, you can use the exact same syntax
> > as Pandoc, i.e.:
> >
> >   [cite:see @doe99, pp. 33-35; also @smith04, chap. 1]
> >   [cite:@doe99, pp. 33-35, 38-39 and *passim*]
> >   [cite:@smith04; @doe99]
> >
> > Only the semicolon is meaningful in there, not the commas. Also, for
> > readability, spacing after the "cite:" prefix is ignored, so one can
> > write, e.g.,
> >
> >   [cite: see @doe99, pp. 33-35; also @smith04, chap. 1]
>
> OK, that's good.
>
> Note that in CSL processors, the locators are meaningful key-values,
> basically; not plain text strings.
>
> This is because different citation styles have different requirements
> for rendering them.
>
> Description from the spec:
>
> a cite-specific pinpointer within the item (e.g. a page number within
> a book, or a volume in a multi-volume work). Must be accompanied in
> the input data by a label indicating the locator type (see the
> Locators term list), which determines which term is rendered by
> cs:label when the “locator” variable is selected.
>
> And this is the list of CSL locators keys:
>
> http://docs.citationstyles.org/en/stable/specification.html#locators
>
> > > Or the first one might treat the “see” as a prefix for the list, though 
> > > I’m
> > > not sure what the practical benefit of that more hierarchical modelling 
> > > is.
> >
> > No, IIRC, the common prefix is the part before the first semicolon, but
> > only if that part contains no citation key. IOW, in the example above,
> > "see " is the prefix of the first citation reference, not a global
> > prefix.
> >
> > > While I do wonder if the syntax could be simplified, my main hope is that
> > > it actually gets merged to master and deployed, to harmonize the variety 
> > > of
> > > different ways emacs tools (org-ref, ebib, pandoc, etc.) are dealing with
> > > citation links in org currently.
> >
> > If the syntax is practical, we could merge it, yes. Maybe that's the way
> > forward, after all. But then? What library is going to use it?
> >
> > Org Ref is well established and is unlikely to switch to the new syntax.
> > It would be nice if both syntax could converge at some point, though.
> > The point of the new syntax is to make it easier for this kind of
> > extension.
>
> While I of course can't speak for John, I would hope and expect org
> ref to support the new syntax.
>
> I would hope and expect the same of other packages (like ebib) that
> use their own custom syntax.
>
> > "citeproc-el" is not included in Emacs, so integrating "citeproc-org" in
> > Org may not be helpful at this point. Since Org is bundled with Emacs,
> > it cannot use external libraries.
>
> I hadn't considered that.
>
> I'm thinking two options:
>
> 1. just have a super simple citation export formatter, with (per
> above) room to configure an external one
>
> 2. while I don't know its status, include citeproc-org in org and emacs
>
> I'd say if citeproc-org is far along and free of substantial bugs, 2
> might make sense. I am, of course, biased, but CSL's been widely
> deployed in the wild for more than a decade, and there are thousands
> of available styles.
>
> Otherwise, and more likely, 1 would be the best path; users get basic
> output formatting for citations, but then can plug in more elaborate
> tools (citeproc-org, citeproc-hs*, etc.) if they need them.
>
> Obviously, if a user is exporting to LaTeX, the formatting is
> straightforward, because you're just exporting to the latex cite code,
> 

Re: wip-cite status question and feedback

[Bruce D'Arcus]

Thank you for this thorough reply, Nicholas!

See below.

On Tue, Apr 7, 2020 at 1:51 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > Hi everyone; first post.
>
> Welcome!
>
> > I see from the archive there was an encouraging thread from April of 2018
> > 
> > (so, two years ago) that seemed to suggest merging to master was close,
> > with perhaps some uncertainty around syntax being the primary hold up?
> >
> > My main question: how do we get this done?
>
> Good question. I don't think syntax is the primary hold up. It seems to
> me that the glue part between the parser and the export back-ends is
> missing. If we merge wip-cite branch in master, where do we plug it? How
> do Org folks use it, out of the box? It also need tooling. For example,
> citations could be a link to a database.

OK, gotcha. That does explain the "hold up."

I'll come back to this below, but for now simply say that ideal would
probably be a default formatting library and database, with room to
replace with other options.

For the database, it would make to do as existing tools do; allow
users to define default bib(la)tex files.

[snip]

> Actually, barring the "cite:" prefix, you can use the exact same syntax
> as Pandoc, i.e.:
>
>   [cite:see @doe99, pp. 33-35; also @smith04, chap. 1]
>   [cite:@doe99, pp. 33-35, 38-39 and *passim*]
>   [cite:@smith04; @doe99]
>
> Only the semicolon is meaningful in there, not the commas. Also, for
> readability, spacing after the "cite:" prefix is ignored, so one can
> write, e.g.,
>
>   [cite: see @doe99, pp. 33-35; also @smith04, chap. 1]

OK, that's good.

Note that in CSL processors, the locators are meaningful key-values,
basically; not plain text strings.

This is because different citation styles have different requirements
for rendering them.

Description from the spec:

a cite-specific pinpointer within the item (e.g. a page number within
a book, or a volume in a multi-volume work). Must be accompanied in
the input data by a label indicating the locator type (see the
Locators term list), which determines which term is rendered by
cs:label when the “locator” variable is selected.

And this is the list of CSL locators keys:

http://docs.citationstyles.org/en/stable/specification.html#locators

> > Or the first one might treat the “see” as a prefix for the list, though I’m
> > not sure what the practical benefit of that more hierarchical modelling is.
>
> No, IIRC, the common prefix is the part before the first semicolon, but
> only if that part contains no citation key. IOW, in the example above,
> "see " is the prefix of the first citation reference, not a global
> prefix.
>
> > While I do wonder if the syntax could be simplified, my main hope is that
> > it actually gets merged to master and deployed, to harmonize the variety of
> > different ways emacs tools (org-ref, ebib, pandoc, etc.) are dealing with
> > citation links in org currently.
>
> If the syntax is practical, we could merge it, yes. Maybe that's the way
> forward, after all. But then? What library is going to use it?
>
> Org Ref is well established and is unlikely to switch to the new syntax.
> It would be nice if both syntax could converge at some point, though.
> The point of the new syntax is to make it easier for this kind of
> extension.

While I of course can't speak for John, I would hope and expect org
ref to support the new syntax.

I would hope and expect the same of other packages (like ebib) that
use their own custom syntax.

> "citeproc-el" is not included in Emacs, so integrating "citeproc-org" in
> Org may not be helpful at this point. Since Org is bundled with Emacs,
> it cannot use external libraries.

I hadn't considered that.

I'm thinking two options:

1. just have a super simple citation export formatter, with (per
above) room to configure an external one

2. while I don't know its status, include citeproc-org in org and emacs

I'd say if citeproc-org is far along and free of substantial bugs, 2
might make sense. I am, of course, biased, but CSL's been widely
deployed in the wild for more than a decade, and there are thousands
of available styles.

Otherwise, and more likely, 1 would be the best path; users get basic
output formatting for citations, but then can plug in more elaborate
tools (citeproc-org, citeproc-hs*, etc.) if they need them.

Obviously, if a user is exporting to LaTeX, the formatting is
straightforward, because you're just exporting to the latex cite code,
as pandoc does (though it also has an option to use citeproc to
produce "cooked" formatted output in latex).

For HTML, the output doesn't need to be anything fancy.

So the #1 path is the more iterative approach to implementing the functionality.

WDY about that?

Bruce

* citeproc-hs is a newer effort, funded by zotero, to create a very
high performance, fully compliant, CSL implementation, that is easy to
embed and use pretty much 

Re: wip-cite status question and feedback

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> Hi everyone; first post.

Welcome!

> I see from the archive there was an encouraging thread from April of 2018
> 
> (so, two years ago) that seemed to suggest merging to master was close,
> with perhaps some uncertainty around syntax being the primary hold up?
>
> My main question: how do we get this done?

Good question. I don't think syntax is the primary hold up. It seems to
me that the glue part between the parser and the export back-ends is
missing. If we merge wip-cite branch in master, where do we plug it? How
do Org folks use it, out of the box? It also need tooling. For example,
citations could be a link to a database.

Of course, that doesn't mean the syntax is perfect, but as it is,
I assume it theoretically goes a long way towards solving most citation
needs.

> I'm happy to help resolve any syntax questions, if that's the primary hold
> up, though my coding skills in general are minimal.

Actually, the coding part is the easiest one. I can help on that part.
Unfortunately, I do not use citations, so I cannot speak for the people
who would make use of them in Org.

> While I’m here, some feedback and thoughts below. I think the proposed
> syntax is basically sound, but maybe could be simplified.

Great!

> The only documentation I can find on the proposal is at the citeproc org
> project.
>
> https://github.com/andras-simonyi/citeproc-org#citations
>
> If the above is correct, then:
>
>1. There are two forms of citations: short and long.
>2. Short is of this syntax, and can only have a single citekey as content:
>   [@doe2019].
>3. Anything else (multiple citations, locators, prefixes and/or suffixes)
>   requires the long form.
>4. In addition, there is a standard long form, and what the doc above calls
>   “parenthetical” form of the long form.
>
> So do I have all that right?

You do.

> First question:
>
> Why #4 above; a distinction between two different long forms?

I think this is because you may want to mix two styles in the same
document: inline and parenthesised. I think the idea comes from BibTeX.

> Moving on, assuming the above is correct, let’s borrow these examples from
> the pandoc citation syntax for markdown
>  (which it also supports in org):
>
> Blah blah [see @doe99, pp. 33-35; also @smith04, chap. 1].
>
> Blah blah [@doe99, pp. 33-35, 38-39 and *passim*].
>
> Blah blah [@smith04; @doe99].
>
> So from a model perspective, a citation in pandoc is a list of one-or-more
> cites (or whatever we want to call them), each of which has optional:
>
>- prefix
>- Locators (page numbers and such)
>- suffix
>
> I believe this is similar to the proposed org model, with one difference:
> the org proposal adds prefix and suffix for the list (the citation) as a
> whole.
>
> So the pandoc version is a flat list, and the org version has two levels.
>
> Am I still understanding everything correctly?

Org syntax has no notion of locators. Is that an issue for later
interpretation?

It just uses optional prefix and suffix around keys. The "(prefix) key
(suffix)" is called a citation reference. A full citation may contain
one ore more citation references, separated by semicolons.

You are right about the global prefix and suffix. I'm not sure why they
are here, but were probably suggested at some point.

If there is no practical use for them, we can also drop them.

> So ... am I correct that in none of these cases can one use the “short”
> form, and that the above would look like this converted to the proposed org
> syntax?

True. I think the short form is just a quick reference that should be
expanded in a predefined style, e.g., "(author, year)".

> Blah blah [cite:see @doe99 pp. 33-35; also @smith04 chap. 1].
>
> Blah blah [cite:@doe99 pp. 33-35, 38-39 and *passim*].
>
> Blah blah [cite:@smith04; @doe99].

Actually, barring the "cite:" prefix, you can use the exact same syntax
as Pandoc, i.e.:

  [cite:see @doe99, pp. 33-35; also @smith04, chap. 1]
  [cite:@doe99, pp. 33-35, 38-39 and *passim*]
  [cite:@smith04; @doe99]

Only the semicolon is meaningful in there, not the commas. Also, for
readability, spacing after the "cite:" prefix is ignored, so one can
write, e.g.,

  [cite: see @doe99, pp. 33-35; also @smith04, chap. 1]

> Or the first one might treat the “see” as a prefix for the list, though I’m
> not sure what the practical benefit of that more hierarchical modelling is.

No, IIRC, the common prefix is the part before the first semicolon, but
only if that part contains no citation key. IOW, in the example above,
"see " is the prefix of the first citation reference, not a global
prefix.

> While I do wonder if the syntax could be simplified, my main hope is that
> it actually gets merged to master and deployed, to harmonize the variety of
> different ways emacs tools (org-ref, ebib, pandoc, etc.) 

Re: R session and plotting in x11 window

[Berry, Charles]

Matt,

I am glad you got past your roadblock.

I am puzzled by your use of `dev.set'. I have never explicitly invoked that 
function. 

FWIW, I have used R for more than 20 years and routinely write packages or 
reports that create graphics.

And I use ESS (and used its predecessor S-mode) as my principal IDE for that 
work. (Org relies on ESS for modes relating to R.) I routinely use Mac OS, but 
occasionally work with Linux and Windows.

Invoking R from the terminal window (or equivalent on Windows) and typing 
interactive commands, I get:

> dev.cur()
null device 
  1 
> plot(1:5)
> dev.cur()
quartz 
 2 
> 

Note there is no call to dev.set(). 

The quartz device (the interactive default on Mac OS) is invoked implicitly by 
plot as described by the `Details' in the help page displayed by typing 
`?device' as the R prompt"

"If no device is open, calling any high-level graphics function will cause a 
device to be opened."

If I start emacs and open an org buffer with just this src block in it:

#+begin_src R
  dev.cur()
  plot(1:5)
  dev.cur()
#+end_src

then place point in the src block and type the line in this example block

#+begin_example
C-c ' C-n RET C-n C-n
#+end_example

I end up with the same output as above in my *R* session buffer. A new graphics 
device is opened and the plot appears in it.


Best,

Chuck

> On Apr 6, 2020, at 6:26 PM, Matt Price  wrote:
> 
> 
> 
> On Sun, Apr 5, 2020 at 1:19 PM Berry, Charles  wrote:
> 
> 
> > On Apr 4, 2020, at 4:27 PM, Matt Price  wrote:
> > 
> > Does anyone know much about the difference between an R session opened by 
> > typing M-x R, and the R session opened by org-babel?
> 
> 
> Short answer: almost none.
> 
> Long answer: what `org-babel-R-initite-session' and friends do.
> :-) thanks, I should have been looking for that 
> 
> > 
> > I'm just learning R and my usual method for learning a language is to keep 
> > a kind of notebook in org with code snippets they I can execute and iterate 
> > on rapidly as I learn. This works great in R when I'm just doing math.  
> > When I am working on plots, it would be nice to have them open up quickly 
> > either in emacs or in the standard x11 window that R session opened switch 
> > M-x R opens up.  
> > 
> > I know I can set the src block headers to produ e a file, but when I'm just 
> > iterating rapidly I often switch back and forth between a data output and a 
> > graphical output, and typing/erasing those headers is clunky and slow. It 
> > would be easier to just paste the plot command into the console and have it 
> > pop open the window... But that doesn't seem to work. Anyone know if I can 
> > tweak something to make that possible?
> > 
> 
> 
> I sam really puzzled by this. Do you have an ECM that illustrates this?
> 
> Working interactively on my Mac (Quartz - X11 is the device), I routinely do 
> what you describe - usually working from the src edit buffer - and the plots 
> are displayed (and older plots are available via clover-left or some such).
> 
> If I had to guess, I'd say that you are opening an R session, but not using 
> it. If you execute a src block, but it does not have a `:session' header, a 
> new instance of R will create a plot file and then exit. If you look in the 
> default directory, you would see `Rplots.pdf' or some such.
> 
> The only other thing that comes to mind is that you opened a device that is 
> holding on to all your plots. Try `dev.cur()' in R immediately before and 
> after you create a plot and see what the result is.
> 
> This was the problem. I don't see that I'm calling dev.set() anywhere but 
> when the session initiates dev.cur() returns
> 
> null
>  1
> 
> calling dev.set(1) or dev.set(2) launches an R_x11 window and future plots 
> are displayed there.  As I say, I'm just learning R, and I don't really 
> understand how the device is set up. I also don't understand why it would be 
> set to X11 in a plain-old R session, but not in an org-babel R session. Most 
> references to "device" in ~ob-R.el~ seem to be managing file outputs, and 
> "X11". For now I don't think I'll explore  a proper solution as I'm already 
> pretty far down a rabit hole just learning R at all!  But thanks very much 
> for this workaround. 
> 
> Matt
> HTH,
> 
> Chuck

wip-cite status question and feedback

[Bruce D'Arcus]

Hi everyone; first post.

>From what I can tell, there was a lot of activity here a few years back to
define org citation link support, which was reflected in what seems to be a
fairly developed wip-cite branch of the git repo.

But that stalled somewhere, and we still have diverse tools, using diverse
and incompatible methods to define citation links.

I see from the archive there was an encouraging thread from April of 2018

(so, two years ago) that seemed to suggest merging to master was close,
with perhaps some uncertainty around syntax being the primary hold up?

My main question: how do we get this done?


I'm happy to help resolve any syntax questions, if that's the primary hold
up, though my coding skills in general are minimal.

While I’m here, some feedback and thoughts below. I think the proposed
syntax is basically sound, but maybe could be simplified.

For background, I created the Citation Style Language (CSL), and the
initial XSLT-based proof-of-concept formatter, which I used to format the
citations and bibliography in my first book.

I work in a field that has pretty diverse citation practices, and myself
work at the borders of the social sciences and humanities, which influences
my thinking on design priorities around citation technology.

I also had a hand in the pandoc citation syntax, which is consistent with
the basic design goals I had, including:


   1.

   simple as possible plain-text format, consistent with markdown
   2.

   prefix and suffix free text, page number locators, etc.
   3.

   ability to radically change output style (for example, from author-date
   to footnote-based), without changing source.


I believe the pandoc syntax achieves all of these goals.

Which brings me to the org proposal.

The only documentation I can find on the proposal is at the citeproc org
project.

https://github.com/andras-simonyi/citeproc-org#citations

If the above is correct, then:


   1.

   There are two forms of citations: short and long.
   2.

   Short is of this syntax, and can only have a single citekey as content:
   [@doe2019].
   3.

   Anything else (multiple citations, locators, prefixes and/or suffixes)
   requires the long form.
   4.

   In addition, there is a standard long form, and what the doc above calls
   “parenthetical” form of the long form.


So do I have all that right?

First question:

Why #4 above; a distinction between two different long forms?

Moving on, assuming the above is correct, let’s borrow these examples from
the pandoc citation syntax for markdown
 (which it also supports in org):

Blah blah [see @doe99, pp. 33-35; also @smith04, chap. 1].

Blah blah [@doe99, pp. 33-35, 38-39 and *passim*].

Blah blah [@smith04; @doe99].

So from a model perspective, a citation in pandoc is a list of one-or-more
cites (or whatever we want to call them), each of which has optional:

   -

   prefix
   -

   Locators (page numbers and such)
   -

   suffix


I believe this is similar to the proposed org model, with one difference:
the org proposal adds prefix and suffix for the list (the citation) as a
whole.

So the pandoc version is a flat list, and the org version has two levels.

Am I still understanding everything correctly?

So ... am I correct that in none of these cases can one use the “short”
form, and that the above would look like this converted to the proposed org
syntax?

Blah blah [cite:see @doe99 pp. 33-35; also @smith04 chap. 1].

Blah blah [cite:@doe99 pp. 33-35, 38-39 and *passim*].

Blah blah [cite:@smith04; @doe99].

Or the first one might treat the “see” as a prefix for the list, though I’m
not sure what the practical benefit of that more hierarchical modelling is.

While I do wonder if the syntax could be simplified, my main hope is that
it actually gets merged to master and deployed, to harmonize the variety of
different ways emacs tools (org-ref, ebib, pandoc, etc.) are dealing with
citation links in org currently.

org-footnote renumbering

[Sharon Kimble]

In the org manual v9.3 on page 139 it explains how to renumber the
footnotes. I am presuming from reading it that it requires me to C-c
C-x r.

But in my case that isn't working because I did have that key
combination set to 'org-mark-ring-goto'.

I have since reconfigured 'org-mark-ring-goto' to use 'C-c C-c r', but
how do I find what the default code-string for 'C-c C-x r' is please?
And then, how do I show it in my config please?

Thanks
  Sharon.  
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 10.2, fluxbox 1.3.7, emacs 27.0.90, org 9.3.6

Re: tabbar or .... ?

[Sharon Kimble]

Eric S Fraga  writes:

Thanks for replying Eric.
  
> On Tuesday,  7 Apr 2020 at 10:49, Sharon Kimble wrote:
>> But, I'm using 'tabbar' and I've had to break the file up into 3
>> separate org-mode files because otherwise the buffer I'm working on
>> drops out of tabbar into its own frame. (File 1 is 1.5mbs, 2 is 1.1mbs,
>> and 3 is 413kbs.)
>
> Can you please explain this in more detail?  How does a buffer "drop out
> of tabbar"?

I can't explain it, but suddenly the buffer that I'm using loses its
separate tab in tabbar, as if its suddenly created a frame for itself.
It was most disturbing when it happened.
  
>
> Are you using the old tabbar.el implementation or the new tab-bar
> implementation available since Emacs v27?

I'm using tabbar from MELPA. I have tried Emacs-27 tab-mode but it
seemed to me that it wouldn't fit my case, where my tabbar groups all
org-mode buffers, and ditto my gnus mail buffers.
  
>
>> I have 'vlf' acting in my setup, but how can I avoid the file dropping
>> out of tabbar please?
>
> Ah, maybe it is the fault of vlf.  Your files are not that large so do
> you really need to use vlf?

I'm not convinced that I am actually using vlf. I'm configured to use
files up to 20mbs, and if necessary I could include a greater amount,
after all I do have 64gigs of ram available!
  
>
> In any case, I'm not sure this is an org issue (but that could be
> because I've not understood your problem) so you may have better luck in
> the emacs help group.

I think that I've found a way round the problem, where I use just one
file for my converted website to org-mode buffer, but I can toggle
tabbar off, so I only show the buffer that I'm working on, and when
necessary I'll call the bibliography to the right of buffer, and also
the glossary underneath my main buffer. And then when I need to I can
just toggle tabbar back on again, and it all works nicely again.

Thanks
  Sharon.  
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 10.2, fluxbox 1.3.7, emacs 27.0.90, org 9.3.6

Re: tabbar or .... ?

[Eric S Fraga]

On Tuesday,  7 Apr 2020 at 10:49, Sharon Kimble wrote:
> But, I'm using 'tabbar' and I've had to break the file up into 3
> separate org-mode files because otherwise the buffer I'm working on
> drops out of tabbar into its own frame. (File 1 is 1.5mbs, 2 is 1.1mbs,
> and 3 is 413kbs.)

Can you please explain this in more detail?  How does a buffer "drop out
of tabbar"?

Are you using the old tabbar.el implementation or the new tab-bar
implementation available since Emacs v27?

> I have 'vlf' acting in my setup, but how can I avoid the file dropping
> out of tabbar please?

Ah, maybe it is the fault of vlf.  Your files are not that large so do
you really need to use vlf?

In any case, I'm not sure this is an org issue (but that could be
because I've not understood your problem) so you may have better luck in
the emacs help group.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-438-g5b9698

Re: R session and plotting in x11 window

[briangpowell .]

"I also don't understand why it would be set to X11 in a plain-old R
session"

R is an open source derivative of S and S-PLUS--"S" was the "Statistics
Language"

MIT X Consortium's "X Motif" is the default output of R from its inception

R, S, S-PLUS have always made such output as its default

Suggest you just "get with the program"--thousands of R libraries are ready
for you to use, extend and create your own libraries if you like--all
leveraging the power of X11R6 --i.e. the XWindows system:
https://en.wikipedia.org/wiki/X_Window_System

By the way Micro$oft Windows is based on MIT's W--W stood for Windows--yet
another thing MicroSoft swiped and monopolized and then sued others about
whenever possible--rather than join the open source & free software movement

X11 is free & open source--all the best software is free & open
source--like Emacs Org-Mode



On Mon, Apr 6, 2020 at 9:27 PM Matt Price  wrote:

>
>
> On Sun, Apr 5, 2020 at 1:19 PM Berry, Charles 
> wrote:
>
>>
>>
>> > On Apr 4, 2020, at 4:27 PM, Matt Price  wrote:
>> >
>> > Does anyone know much about the difference between an R session opened
>> by typing M-x R, and the R session opened by org-babel?
>>
>>
>> Short answer: almost none.
>>
>> Long answer: what `org-babel-R-initite-session' and friends do.
>>
> :-) thanks, I should have been looking for that
>
>>
>> >
>> > I'm just learning R and my usual method for learning a language is to
>> keep a kind of notebook in org with code snippets they I can execute and
>> iterate on rapidly as I learn. This works great in R when I'm just doing
>> math.  When I am working on plots, it would be nice to have them open up
>> quickly either in emacs or in the standard x11 window that R session opened
>> switch M-x R opens up.
>> >
>> > I know I can set the src block headers to produ e a file, but when I'm
>> just iterating rapidly I often switch back and forth between a data output
>> and a graphical output, and typing/erasing those headers is clunky and
>> slow. It would be easier to just paste the plot command into the console
>> and have it pop open the window... But that doesn't seem to work. Anyone
>> know if I can tweak something to make that possible?
>> >
>>
>>
>> I sam really puzzled by this. Do you have an ECM that illustrates this?
>>
>> Working interactively on my Mac (Quartz - X11 is the device), I routinely
>> do what you describe - usually working from the src edit buffer - and the
>> plots are displayed (and older plots are available via clover-left or some
>> such).
>>
>> If I had to guess, I'd say that you are opening an R session, but not
>> using it. If you execute a src block, but it does not have a `:session'
>> header, a new instance of R will create a plot file and then exit. If you
>> look in the default directory, you would see `Rplots.pdf' or some such.
>>
>> The only other thing that comes to mind is that you opened a device that
>> is holding on to all your plots. Try `dev.cur()' in R immediately before
>> and after you create a plot and see what the result is.
>>
>> This was the problem. I don't see that I'm calling dev.set() anywhere but
> when the session initiates dev.cur() returns
>
> null
>  1
>
> calling dev.set(1) or dev.set(2) launches an R_x11 window and future plots
> are displayed there.  As I say, I'm just learning R, and I don't really
> understand how the device is set up. I also don't understand why it would
> be set to X11 in a plain-old R session, but not in an org-babel R session.
> Most references to "device" in ~ob-R.el~ seem to be managing file outputs,
> and "X11". For now I don't think I'll explore  a proper solution as I'm
> already pretty far down a rabit hole just learning R at all!  But thanks
> very much for this workaround.
>
> Matt
>
>> HTH,
>>
>> Chuck
>>
>>
>>

Bug: org-with-wide-buffer is used in org-refile.el without (require 'org-macs) [9.3.6 (release_9.3.6-441-gba6855 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Recently, I ran into a problem compiling org-mode asynchronously with
each .el file being compiled in a separate process (via
native-compile-async).
When I tried to compile org-refile.el in a separate Emacs process
(without compiling all other .el files), there was no way for the
byte-compiler to know that org-with-wide-buffer is a macro.

As I understand, normally org-mode compiles synchronously with all the
.el files being byte-compiled in alphabetic order. Then,
(eval-and-compile (require 'org-macs)) from org.el is defined prior
compiling all the org-*.el files, which accidentally allow the org-mode
to be compiled without any issues.

Note that I first reported this to bug-gnu-emacs mail-list [1], but it
seems that absence of (require 'org-macs) is wrong on the org-mode side.

Let me know what you think.

Best,
Ihor

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-04/msg00174.html


Emacs  : GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, 
cairo version 1.16.0)
 of 2020-04-01
Package: Org mode version 9.3.6 (release_9.3.6-441-gba6855 @ 
/home/yantar92/.emacs.d/straight/build/org/)
-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

tabbar or .... ?

[Sharon Kimble]

I'm converting a website (Romance University's site, where the original
site has closed and gone offline.), so I'm converting it to org-mode and
then building it with latex into a PDF file for my own interest. So far
I've converted 447 web-pages, into 843 pages of a PDF file. 

But, I'm using 'tabbar' and I've had to break the file up into 3
separate org-mode files because otherwise the buffer I'm working on
drops out of tabbar into its own frame. (File 1 is 1.5mbs, 2 is 1.1mbs,
and 3 is 413kbs.)

I have 'vlf' acting in my setup, but how can I avoid the file dropping
out of tabbar please?

I would prefer to keep using tabbar so that I can then have the
bibliography file alongside the file I'm working on whilst I'm adding to
it.

Any advice please?  

Thanks
  Sharon.  
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 10.2, fluxbox 1.3.7, emacs 27.0.90, org 9.3.6