How to tweak org-log-into-file, how to leverage state history.

[Lawrence Bottorff]

I've been trying to understand the whole TODO universe, now that I've
finally tackled it. The ability to create all the various states (I haven't
tried SEQ of state groups yet) on an issue entered as a heading in an org
file and then change the status of that heading is marvelous. For example,
I've created states TOGROK, GROKKING, and GROKKED for issues I'm "thinking
hard" about.

My frustration is when I create/change a state (all my states have @ for
"add log blurb"), the LOGBOOK only allows a single rambling sentence, i.e.,
no paragraphs. For example, I want to start out with my own custom
PROPERTIES drawer, then start the text.

To elaborate, I create a heading and give it the status TOGROK. So I say a
lot about this initial state and save it. Then I want to change the state
to GROKKING when I've something new to say. Then I "change" to GROKKING
again -- because some new thing occurs to me. After maybe a few of those, I
change to GROKKED and finalize this whole heading-as-issue. This is exactly
what I want, because this heading-as-issue is leveraging the TODO state
history.

Sure, I could have just done elaborations as they came to me as text,
graphs, pics, whatever under the heading, paragraph after paragraph, *but
then I've lost the whole state change dynamic of attaching new information
to a new state, and with it the tracked history. *

So I see org-log-into-drawer has three possible values in its customize
buffer: nil, LOGBOOK, and Other. The LOGBOOK option allows the nice (but
limited to one sentence) logging of each change of state, creating a history

** GROKKING ...My first attempts at tracking issue
:LOGBOOK:
- State "GROKKING"   from "GROKKING"   [2020-02-29 Sat 23:50] \\
  Still grokking this one.
  But will return to this issue.
- State "GROKKING"   from "TOGROK" [2020-02-29 Sat 23:49] \\
  Will "ask around" on this issue.
- State "TOGROK" from  [2020-02-29 Sat 23:43] \\
  Aware that I need to grok this whole thing.

So what can I do with org-log-into-drawer's Other option? I tried
(org-log-into-drawer  (current-time)), which is apparently just the same
as (org-log-into-drawer  t), i.e., just a LOGBOOK entry happened.

Is there something that can happen in sub-headings that keeps track of the
state history of the main heading?

LB

Re: Bug or not a bug? dot expansion in ob-shell

[Jack Kamm]

Hi Tom,

Tom Gillespie  writes:

> As with many things in emacs, I sometimes feel like I'm loosing my
> mind, or loosing track of just exactly what variables are set

You're not losing your mind. After some further testing I find that
you're right, and my understanding of the situation was incorrect.

The reason I got confused was the initial example that started this
thread:

> #+begin_src sh
>   echo .
> #+end_src
> 
> #+RESULTS:
> : 0

Which looks like it's returning the exit code. However, it turns out
that this is just a coincidence, and it's an entirely unrelated bug.

If I had read the thread more carefully, I would have seen Bastien had
already noted this here:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-02/msg00716.html

I fear my confusion of the issues lead to some misinformed comments on
my part. Sorry about that. I think I wasn't the only commenter confused
about this...

Anyways, it seems the current behavior of ob-shell blocks is:

- If no ":results" specified: returns the output, transformed to a
  table. Same as the old ":results value".
- If ":results value" explicitly specified: returns the exit code. This
  is a change from the old default behavior.

I can see why you, and other regular users of ob-shell, would be annoyed
by this change of behavior.

Now that I understand what's going on, I think it would be better to
stick with the old behavior (no exit code), just fixing the original bug
that prompted this thread.

Re: Bug or not a bug? dot expansion in ob-shell

[Tom Gillespie]

Hi Jack,
As with many things in emacs, I sometimes feel like I'm loosing my
mind, or loosing track of just exactly what variables are set or not
set, but I could swear that for at least the past year when running
#+begin_src bash blocks with C-c C-c and no :results header set the
results are the stdout. This is also true for sh and shell language
options. Maybe that was a recent change, but I just tested with emacs
-q and (org-version) -> 9.1.9 and am getting stdout (as seen below). I
have included the results of org-submit-bug-report for reference.
Best,
Tom

#+begin_src bash
pip install --user pudb
#+end_src

#+RESULTS:
| Requirement | already | satisfied: | pudb  | in |
/usr/lib/python3.7/site-packages | (2018.1) |   | |
| Requirement | already | satisfied: | urwid>=1.1.1  | in |
/usr/lib/python3.7/site-packages | (from| pudb) | (2.1.0) |
| Requirement | already | satisfied: | pygments>=1.0 | in |
/usr/lib/python3.7/site-packages | (from| pudb) | (2.5.2) |


Subject: Bug: test [9.1.9 (release_9.1.9-65-g5e4542 @
/usr/share/emacs/26.3/lisp/org/)]

Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, X toolkit)
 of 2019-10-09
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/usr/share/emacs/26.3/lisp/org/)

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-clock-out-if-current)
 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-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-block-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-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-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-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME
CONTENTS WIDTH)"]
 org-occur-hook '(org-first-headline-recenter)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 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-confirm-shell-link-function 'yes-or-no-p
 org-link-parameters '(("id" :follow org-id-open)
   ("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)
   ("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) ("file+sys")
   ("file+emacs") ("doi" :follow org--open-doi-link)
   ("elisp" :follow org--open-elisp-link)
   ("file" :complete org-file-complete-link)
   ("ftp" :follow
(lambda (path) (browse-url (concat "ftp:" path
   ("help" :follow org--open-help-link)
   ("http" :follow
(lambda (path) (browse-url (concat "http:" path
   ("https" :follow
(lambda (path) (browse-url (concat "https:" path
   ("mailto" :follow
(lambda (path) (browse-url (concat "mailto:; path
   ("news" :follow
(lambda (path) (browse-url (concat "news:; path
   ("shell" :follow org--open-shell-link))
 

Re: Bug: org-highest-priority not defined [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Actually, on closer inspection. Shouldn't:

(defalias 'org-highest-priority 'org-priority-highest)

be

(defvaralias ...)?

On Sat, Feb 29, 2020 at 8:09 PM No Wayman 
wrote:

> After updating Org, I'm  hitting errors for an undefined
> `org-highest-priority'.
> I see that this is an alias for `org-priority-highest', but
> describe-function (and I'm not sure why it's describe-function vs
> describe-variable) dutifully reports:
>
>  org-highest-priority is an alias for ‘org-priority-highest’,
>  which is not
>  defined. Please make a bug report.
>
>  Not documented.
>
> My first hunch is that this is due to a mixed installation of Org,
> but I'm having trouble diagnosing this. I've installed
> org-plus-contrib using the straight package manager.
> I've ensured that Org is not loaded before/during upgrading Org.
> (locate-library "org") points to the correct file:
>
>  "/home/n/.emacs.d/straight/build/org/org.elc"
>
> In the src elisp file,
> /home/n/.emacs.d/straight/repos/org/lisp/org.el there defalias is
> there as I would expect:
>
> (defalias 'org-highest-priority 'org-priority-highest)
>
> My usual technique for debugging this is evaling:
>
>   (eval-after-load "org"
> '(debug))
>
> prior to loading Org. However, in this case it looks like it's
> loading the proper file:
>
> Debugger entered: nil
>   (closure (t) nil (debug))()
>   funcall((closure (t) nil (debug)))
>   mapc(funcall ((closure (t) nil (debug)) (closure (t) nil
>   (add-to-list 'org-src-lang-modes '("php" . php))) (closure (t)
>   nil (add-to-list 'org-src-lang-modes '("redis" . redis)
>   do-after-load-evaluation("/home/n/.emacs.d/straight/build/org/org.elc")
>   require(org)
>   byte-code("\300\301!\210\300\302!\210\300\303!\207" [require
>   cl-lib org org-refile] 2)
>   autoload-do-load((autoload "org-capture" 1424805 t nil)
>   org-capture)
>   command-execute(org-capture)
>
> I plan on reporting with the author of straight.el, too. Just
> following through on the describe-function message here.
> Not sure how to proceed with debugging. Apologies if this is
> noise.
>
>
> Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X
> toolkit, cairo version 1.17.3, Xaw3d scroll bars)
>  of 2020-02-23
> Package: Org mode version 9.3.6 (release_9.3.6-399-ge6df03 @
> /home/n/.emacs.d/straight/build/org/)
>
> current state:
> ==
> (setq
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer
>  org-src-mode-configure-edit-buffer
>  doom-modeline-set-org-src-modeline)
>  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-refile-targets '((org-agenda-files :maxlevel . 20)
>  (my/org-files-list :maxlevel . 20))
>  org-enforce-todo-dependencies t
>  org-agenda-category-icon-alist '(("[Ww]ork"
>(#("" 0 1
>   (rear-nonsticky t display
>   (raise -0.24) font-lock-face
>(:family "FontAwesome"
>:height 1.2) face
>(:family "FontAwesome"
>:height 1.2))
>   )
> )
>nil nil :ascent center)
>   ("[Rr]efile"
>(#("" 0 1
>   (rear-nonsticky t display
>   (raise -0.24) font-lock-face
>(:family "FontAwesome"
>:height 1.2) face
>(:family "FontAwesome"
>:height 1.2))
>   )
> )
>nil nil :ascent center)
>   ("[Aa]ccounting"
>(#("" 0 1
>   (rear-nonsticky t display
>   (raise -0.24) font-lock-face
>(:family "FontAwesome"
>:height 1.2) face
>(:family "FontAwesome"
>:height 1.2))
>   )
> )
>nil nil :ascent center)
>   ("[Hh]abit"
>(#("" 0 1
>   (rear-nonsticky t display
>   (raise -0.24) font-lock-face
>(:family "FontAwesome"
> 

Re: Bug or not a bug? dot expansion in ob-shell

[Jack Kamm]

Hi Tom,

Tom Gillespie  writes:

> First a disclosure, I would be very unhappy if option 1 were selected,
> it would require me to make a whole bunch of changes and try to find
> an option to revert to the current default behavior.

Wasn't option 1 already the default behavior, until the changes made
earlier this month due to this thread? That is the behavior I get when I
check out earlier commits, or maint.

> The principle is that block defaults for results should default to the
> value that the language itself makes the most accessible.

I agree that this would be a good principle.

My understanding is that in 9.3 and earlier, the default was generally
":results value", but now due to this thread we are adding an exception
for ob-shell.

It sounds like after 9.4 is released, there will be a general survey of
how org-babel behaves across languages, after which there will be a
discussion of sensible default behavior.

Re: Bug or not a bug? dot expansion in ob-shell

[Tim Cross]

It seems to me that two separate issues have been mixed up and causing
some confusion here. However, I think it is actually quite simple once
we consider the issues separately.

Issue 1: Defining the meaning of :result value and :result output
Issue 2: Specifying what the default :result setting would be i.e.
:result without a value/output specifier.

Issue 1 seems the most straight-forward to me
- output :: Whatever goes to stdout/stderr
- value :: whatever would be returned by the execution of the code. This
might be a return value (i.e. for some shell commands) or the value
returned by a function (including shell functions i.e. bash function) or
the last command executed etc. Essentially, anything returned (including
nil) by the block. STDOUT/STDERR is never a return value (though some
languages may send output to STDOUT/STDERR as well as returning it, in
which case it would also be in :return value).

Note that I don't agree that the only 'useful' result from shell blocks
is output. You might have a complex shell script which uses source
blocks to define shell functions
that return values which you use via oweb expansion to include in other
blocks etc.s

With this definition, essentially :result value is essentially anything
except whatever is sent to stdout/stderr.

Issue 2 is a little more difficult. It is likely that a 'standard'
default for :result that is the same for all languages is not
possible/desired. The default will likely be a combination of what seems
most natural for that language and what is most common usage for the
majority of users. It could be that for some languages, the default for
:result should be :result output and for others it should be :result
value.

Personally, I care less about issue 2 than issue 1. In the worst case, I
will need to change my header arguments for some blocks and that would
be easily automated. Far more critical is that :result value and :result
output are clear, unambiguous and consistent. Any proposal to change
these meanings because of different uses cases in languages is a bad
idea. Instead, changing the 'default' would be preferable. Having shell
source blocks return STDOUT/STDERR output for :result value is IMO a bad
idea. Having shell blocks default to :result output when only specifying
:result while having other languages, like python or clojure default to
:result value seems far more preferable (provided differences are
clearly documented of course).

The current situation seems inconsistent to me e.g.

#+begin_src shell :results value
  echo .

#+end_src

#+RESULTS:
: .


#+begin_src shell :results output
  echo .

#+end_src

#+RESULTS:
: .

You get the same results value regardless of whether :results value or
:results output. I think :results value should return 0 (return code for
echo). Whether shell blocks defaults to :results output or :results
value is a different questions (it probably should default to :result
output). e.g.


#+begin_src shell
  echo .

#+end_src

#+RESULTS:
: .


#+begin_src shell :results value
  echo .

#+end_src

#+RESULTS:
: 0


#+begin_src shell :results output
  echo .

#+end_src

#+RESULTS:
: .

Tom Gillespie  writes:

> Hi all,
> Sorry to be late to this thread (and for a wall of text), but as a
> heavy user of ob-shell I wanted to chime in. First a disclosure, I
> would be very unhappy if option 1 were selected, it would require me
> to make a whole bunch of changes and try to find an option to revert
> to the current default behavior. When I run a bash block in org mode,
> I want what is going to stdout, why else would I run it in org? If I
> don't want to capture the output then it is either in a pipeline
> inside the block, or I will silence the results. Option two is by far
> the most reasonable answer in my opinion and there is a consistent
> principle which can be applied in many cases so that it would not be
> an exception. The principle is that block defaults for results should
> default to the value that the language itself makes the most
> accessible. Shell return codes are esoteric from this point of view, I
> had been writing bash scripts for years before I learned about $?. By
> far the most actionable and accessible thing to a user of a shell
> program is the stdout -- ignore the naming for a moment, because the
> meaning is not in the name, it is in how it interacts with other
> programs in the larger environment. If we apply the logic that says
> that option 1 should be the default, then python blocks set to results
> value should return nothing unless an error is raised and then they
> should return the error. This is clearly absurd, no python programmer
> cares about the absence of an error and making the default behavior of
> python blocks verbosely report their non-errorness by default would
> likely incite a riot. What has happened with shells is that the
> nomenclature has been switched with respect to how users and other
> code consume and deal with 'outputs' aka return values in 

Re: Bug or not a bug? dot expansion in ob-shell

[Tom Gillespie]

Hi all,
Sorry to be late to this thread (and for a wall of text), but as a
heavy user of ob-shell I wanted to chime in. First a disclosure, I
would be very unhappy if option 1 were selected, it would require me
to make a whole bunch of changes and try to find an option to revert
to the current default behavior. When I run a bash block in org mode,
I want what is going to stdout, why else would I run it in org? If I
don't want to capture the output then it is either in a pipeline
inside the block, or I will silence the results. Option two is by far
the most reasonable answer in my opinion and there is a consistent
principle which can be applied in many cases so that it would not be
an exception. The principle is that block defaults for results should
default to the value that the language itself makes the most
accessible. Shell return codes are esoteric from this point of view, I
had been writing bash scripts for years before I learned about $?. By
far the most actionable and accessible thing to a user of a shell
program is the stdout -- ignore the naming for a moment, because the
meaning is not in the name, it is in how it interacts with other
programs in the larger environment. If we apply the logic that says
that option 1 should be the default, then python blocks set to results
value should return nothing unless an error is raised and then they
should return the error. This is clearly absurd, no python programmer
cares about the absence of an error and making the default behavior of
python blocks verbosely report their non-errorness by default would
likely incite a riot. What has happened with shells is that the
nomenclature has been switched with respect to how users and other
code consume and deal with 'outputs' aka return values in any other
langues, shell return values are error signals and should be treated
as such, unfortunately (or perhaps fortunately?) org-mode doesn't have
an error handling/signaling system, but if a python code block fails
emacs will yell at us, shells don't do this, it is up to the user to
detect and handle the error case themselves, but that is a language
internal matter. In summary, option 2 seems to me to be the most
consistent with how users interact with shell commands and shell
scripts, return codes are more akin to error handling in other
languages, so ignoring the naming issues, if `my-org-block` behave
like a shell function, then pipe would be the more appropriate default
behavior than `$?`. I think that the underlying principle can be
applied to other languages as well to arrive at sane defaults.
Thoughts?
Tom


On Sat, Feb 29, 2020 at 7:41 AM Jack Kamm  wrote:
>
> Sorry, I was confused about this:
>
> > According to my reading of this thread, most of the commenters were in
> > agreement that we should keep the original behavior and return the exit
> > code, as we do in 9.3.
>
> Actually, it looks like ":results value" does return the exit code. I
> just got confused because shell blocks now return the output when no
> ":results" is specified.
>

Bug: org-highest-priority not defined [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

After updating Org, I'm  hitting errors for an undefined 
`org-highest-priority'.
I see that this is an alias for `org-priority-highest', but 
describe-function (and I'm not sure why it's describe-function vs 
describe-variable) dutifully reports:


org-highest-priority is an alias for ‘org-priority-highest’, 
which is not

defined. Please make a bug report.

Not documented.

My first hunch is that this is due to a mixed installation of Org, 
but I'm having trouble diagnosing this. I've installed 
org-plus-contrib using the straight package manager.

I've ensured that Org is not loaded before/during upgrading Org.
(locate-library "org") points to the correct file:

"/home/n/.emacs.d/straight/build/org/org.elc"

In the src elisp file, 
/home/n/.emacs.d/straight/repos/org/lisp/org.el there defalias is 
there as I would expect:


(defalias 'org-highest-priority 'org-priority-highest)

My usual technique for debugging this is evaling:

 (eval-after-load "org"
   '(debug))

prior to loading Org. However, in this case it looks like it's 
loading the proper file:


Debugger entered: nil
 (closure (t) nil (debug))()
 funcall((closure (t) nil (debug)))
 mapc(funcall ((closure (t) nil (debug)) (closure (t) nil 
 (add-to-list 'org-src-lang-modes '("php" . php))) (closure (t) 
 nil (add-to-list 'org-src-lang-modes '("redis" . redis)

 do-after-load-evaluation("/home/n/.emacs.d/straight/build/org/org.elc")
 require(org)
 byte-code("\300\301!\210\300\302!\210\300\303!\207" [require 
 cl-lib org org-refile] 2)
 autoload-do-load((autoload "org-capture" 1424805 t nil) 
 org-capture)

 command-execute(org-capture)

I plan on reporting with the author of straight.el, too. Just 
following through on the describe-function message here.
Not sure how to proceed with debugging. Apologies if this is 
noise.



Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X 
toolkit, cairo version 1.17.3, Xaw3d scroll bars)

of 2020-02-23
Package: Org mode version 9.3.6 (release_9.3.6-399-ge6df03 @ 
/home/n/.emacs.d/straight/build/org/)


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

doom-modeline-set-org-src-modeline)
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-refile-targets '((org-agenda-files :maxlevel . 20) 
(my/org-files-list :maxlevel . 20))

org-enforce-todo-dependencies t
org-agenda-category-icon-alist '(("[Ww]ork"
  (#("" 0 1
 (rear-nonsticky t display 
 (raise -0.24) font-lock-face
  (:family "FontAwesome" 
  :height 1.2) face
  (:family "FontAwesome" 
  :height 1.2))

 )
   )
  nil nil :ascent center)
 ("[Rr]efile"
  (#("" 0 1
 (rear-nonsticky t display 
 (raise -0.24) font-lock-face
  (:family "FontAwesome" 
  :height 1.2) face
  (:family "FontAwesome" 
  :height 1.2))

 )
   )
  nil nil :ascent center)
 ("[Aa]ccounting"
  (#("" 0 1
 (rear-nonsticky t display 
 (raise -0.24) font-lock-face
  (:family "FontAwesome" 
  :height 1.2) face
  (:family "FontAwesome" 
  :height 1.2))

 )
   )
  nil nil :ascent center)
 ("[Hh]abit"
  (#("" 0 1
 (rear-nonsticky t display 
 (raise -0.24) font-lock-face
  (:family "FontAwesome" 
  :height 1.2) face
  (:family "FontAwesome" 
  :height 1.2))

 )
   )
  nil nil :ascent center)
 ("[Hh]ealth"
  (#("" 0 1
 

Re: Bug: org-indent-region doesn't restore cursor position when org-src-tab-acts-natively is t [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]

[Sébastien Miquel]

Hi Bastien,

Thank you again for looking into this. I guess you couldn't find an easy 
fix.


This bug is quite the pain, since it gets triggered by the comment-line 
function: every time I try to comment something, the cursor goes to the 
beginning of the block.


With org-src-tab-acts-natively being set to t by default, it may impact 
a lot of people.


Sorry to be nagging you, my elisp-fu is barely above kill/yank level, 
but I'm still curious why save-excursion seemingly isn't doing its job here.




Hi Sébastien,

yes, the initial fix was wrong.

The current behavior when the region is active in a src block is to
indent the whole source block, which is not what the user expect.  The
problem with the cursor going back to the beginning of the block comes
on top of this (bigger?) problem.

I could not find a proper fix yet, I will try later this week.

Thanks,

Bug: org-block face isn't applied to special blocks

[Sébastien Miquel]

Afaict, the org-block face isn't applied to special blocks. Its 
documentation implies it applies to any block.


The relevant function is org-fontify-meta-lines-and-blocks-1.

It may be a simple matter of changing the logic a bit and adding 
(add-face-text-property bol-after-beginline beg-of-endline 'org-block t).

Re: Bug: assignment to named column - not working as expected [9.3.6 (9.3.6-elpa @ ~/.emacs.d/elpa/org-9.3.6/)]

[Lester Longley]

Hello,

The functionality which I was trying is documented as not supported:

http://www.gnu.org/software/emacs/manual/html_node/org/Column-formulas.html

The left-hand side of a column formula cannot be the name of column, it
must be the numeric column reference or $>.


Regards,
Lester

On Sat, Feb 29, 2020 at 9:39 AM Lester Longley  wrote:

> Hello,
>
> I'm trying to use named fields.
>
> This works:
>
> | ! | col2 | col3 |
> | # | abc  | abc  |
> #+TBLFM: $3 = $col2
>
> However, assignment to named field "$col3":
>
> | ! | col2 | col3 |
> | # | abc  |  |
> #+TBLFM: $col3 = $col2
>
> ... results in error "Unknown field: col3".
>
> I was expecting assignment to the named column to work, as per
> https://orgmode.org/manual/Advanced-features.html
>
>
> ‘!’
>
> The fields in this line define names for the columns, so that you may
> refer to a column as ‘$Tot’ instead of ‘$6’.
> ‘^’
>
> This row defines names for the fields *above* the row. With such a
> definition, any formula in the table may use ‘$m1’ to refer to the value ‘
> 10’. Also, if you assign a formula to a names field, it is stored as ‘$name
> = ...’.
>
> However, the documentation doesn't specifically indicate that assignment
> to "$name" should work w/ "!"--it's mentioned only w/ "^" (and works fine
> for this case)--so possibly what I'm trying simply isn't supported (i.e.,
> not a bug).  Please pardon if that's not right expectation.
>
> Thank you for your help.
>
> Regards,
> Lester
>
> Emacs  : GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
>  of 2017-09-15, modified by Debian
> Package: Org mode version 9.3.6 (9.3.6-elpa @ ~/.emacs.d/elpa/org-9.3.6/)
>
> current state:
> ==
> (setq
>  org-tab-first-hook '(org-babel-hide-result-toggle-maybe
>  org-babel-header-arg-expand)
>  org-speed-command-hook '(org-speed-command-activate
>  org-babel-speed-command-activate)
>  org-occur-hook '(org-first-headline-recenter)
>  org-metaup-hook '(org-babel-load-in-session-maybe)
>  org-confirm-shell-link-function 'yes-or-no-p
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
>  org-agenda-before-write-hook '(org-agenda-add-entry-text)
>  org-babel-pre-tangle-hook '(save-buffer)
>  org-mode-hook '((closure
>  (org--rds reftex-docstruct-symbol
>   org-element-greater-elements org-clock-history
>   org-agenda-current-date org-with-time org-defdecode org-def
>   org-read-date-inactive org-ans2 org-ans1
>   org-columns-current-fmt-compiled org-clock-current-task
>   org-clock-effort org-agenda-skip-function
>   org-agenda-skip-comment-trees org-agenda-archives-mode
>   org-end-time-was-given org-time-was-given
>   org-log-note-extra org-log-note-purpose
>   org-log-post-message org-last-inserted-timestamp
>   org-last-changed-timestamp
>   org-entry-property-inherited-from org-blocked-by-checkboxes
>   org-state org-agenda-headline-snapshot-before-repeat
>   org-capture-last-stored-marker org-agenda-start-on-weekday
>   org-agenda-buffer-tmp-name org-priority-regexp
>   buffer-face-mode-face org-tbl-menu org-org-menu
>   org-struct-menu org-entities org-last-state
>   org-id-track-globally org-clock-start-time texmathp-why
>   remember-data-file
>   org-agenda-tags-todo-honor-ignore-options
>   iswitchb-temp-buflist calc-embedded-open-mode
>   calc-embedded-open-formula calc-embedded-close-formula
>   align-mode-rules-list org-emphasis-alist
>   org-emphasis-regexp-components
>   org-export-registered-backends org-modules
>   org-babel-load-languages org-indent-indentation-per-level
>   org-element-paragraph-separate ffap-url-regexp
>   org-inlinetask-min-level t)
>  nil
>  (add-hook (quote change-major-mode-hook)
>   (quote org-show-all) (quote append) (quote local))
>  )
> (closure
>  (org-src-window-setup *this*
>   org-babel-confirm-evaluate-answer-no
>   org-src-preserve-indentation org-src-lang-modes
>   org-edit-src-content-indentation org-babel-library-of-babel
>   t)
>  nil
>  (add-hook (quote change-major-mode-hook)
>   (quote org-babel-show-result-all) (quote append)
>   (quote local))
>  )
> org-babel-result-hide-spec org-babel-hide-all-hashes)
>  org-bibtex-headline-format-function '(closure
>   (org-id-locations
> org-agenda-search-view-always-boolean
> org-agenda-overriding-header t)
>   (entry) (cdr (assq :title entry)))
>  org-archive-hook '(org-attach-archive-delete-maybe)
>  org-cycle-hook '(org-cycle-hide-archived-subtrees
> org-cycle-show-empty-lines
>  org-optimize-window-after-visibility-change)
>  org-link-shell-confirm-function 'yes-or-no-p
>  org-link-elisp-confirm-function 'yes-or-no-p
>  org-confirm-elisp-link-function 'yes-or-no-p
>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>  org-link-parameters '(("attachment" :follow org-attach-open-link :export
> org-attach-export-link :complete
> org-attach-complete-link)
>   ("id" :follow org-id-open)
>   ("eww" :follow eww :store org-eww-store-link)
>   ("rmail" :follow 

Re: correct remote path handling

[Jack Kamm]

Hi Felipe,

It looks like you've made some quite substantial changes to ob-shell.

I think it would be a good idea to split this up into 2 patches, and to
start a new thread for the ob-shell patch.

I'm not as familiar with ob-shell, and it's also had some work
lately. So it'd be good to get some more visibility for these changes
with a new thread for it.

Also, I think it'd be a good idea to provide some explanation of what
you've changed in ob-shell, the reason for these changes, and some
examples of how the behavior has changed.

If possible, it'd also be good to split up the ob-shell changes into a
few smaller patches, each addressing a specific issue.

Before starting a new thread, I would recommend waiting until Org 9.4 is
released, which should be any day now.

Below are some specific feedback for your updated patch:

> diff --git a/lisp/ob-python.el b/lisp/ob-python.el
> index dbcfac08d..1afea9cb3 100644
> --- a/lisp/ob-python.el
> +++ b/lisp/ob-python.el
> @@ -327,7 +327,8 @@ last statement in BODY, as elisp."
> "python-")))
>  (with-temp-file tmp-src-file (insert body))
>  (format org-babel-python--exec-tmpfile
> -tmp-src-file))
> +(org-babel-local-file-name
> + tmp-src-file)))

You should use `org-babel-process-file-name' here, not
`org-babel-local-file-name'.

> -tmp-src-file
> -   (org-babel-comint-with-output
> -   (session org-babel-python-eoe-indicator nil body)
> +(org-babel-local-file-name
> + tmp-src-file)
> +(org-babel-comint-with-output
> +(session org-babel-python-eoe-indicator nil body)

Same comment as above.

> diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el
> index 347ffedd1..66cdfb94c 100644
> --- a/lisp/ob-shell.el
> +++ b/lisp/ob-shell.el
> @@ -82,12 +82,17 @@ This function is called by `org-babel-execute-src-block'."
>(value-is-exit-status
> (member "value" (cdr (assq :result-params params
>(cmdline (cdr (assq :cmdline params)))
> +  (shebang (cdr (assq :shebang params)))
> +  (padline (not (equal "no" (cdr (assq :padline params)
> +  (result-params (cdr (assq :result-params params)))
>   (full-body (concat
>(org-babel-expand-body:generic
> body params (org-babel-variable-assignments:shell params))
>(when value-is-exit-status "\necho $?"
>  (org-babel-reassemble-table
> - (org-babel-sh-evaluate session full-body params stdin cmdline)
> + (org-babel-sh-evaluate session full-body
> + stdin cmdline shebang value-is-exit-status padline
> + result-params)

These variables used to be let-bound inside `org-babel-sh-evaluate', but
now you've changed the signature of that function to pass them in from
the outside.

I don't see a good reason for this change, since as far as I can tell,
those variables aren't used outside `org-babel-sh-evaluate'.

> -(defun org-babel-sh-evaluate (session body  params stdin cmdline)
> -  "Pass BODY to the Shell process in BUFFER.
> -If RESULT-TYPE equals `output' then return a list of the outputs
> -of the statements in BODY, if RESULT-TYPE equals `value' then
> -return the value of the last statement in BODY."

It looks like you've changed the indentation of this function, which
causes a hard-to-read diff. Please stick to the original indentation so
we can more easily review the changes here.

> + (let* ((block-output-lines
> + (let ((fun-body
> +(format "%s(){\n%s\n}\n%s"
> + org-babel-sh-block-function-name
> + ;; function block
> + (concat
> +  body
> +  "\n"
> +  org-babel-sh-eoe-indicator) ;; mark eoe
> + ;; mark "function has been input"
> + org-babel-sh-eoe-indicator)))

This is a very interesting idea, to wrap the shell block inside a
function.

I think it's a good idea and would fix some issues with leaky prompts,
among other things.

As an aside, I've been working on developing an async evaluation feature
for org-babel blocks, but we were struggling with ob-shell. This idea to
wrap the block in a function might be the solution.

Anyways, it would be good to discuss this change further with motivation
and examples.

Re: Bug or not a bug? dot expansion in ob-shell

[Jack Kamm]

Sorry, I was confused about this:

> According to my reading of this thread, most of the commenters were in
> agreement that we should keep the original behavior and return the exit
> code, as we do in 9.3.

Actually, it looks like ":results value" does return the exit code. I
just got confused because shell blocks now return the output when no
":results" is specified.

Re: Bug or not a bug? dot expansion in ob-shell

[Jack Kamm]

Hi Bastien,

Bastien  writes:

> thanks for your thoughtful inputs.  I've now removed the option.

I think it's good you removed the option.

However, it looks like the behavior now is to return the output, instead
of the exit code, when ":results value".

According to my reading of this thread, most of the commenters were in
agreement that we should keep the original behavior and return the exit
code, as we do in 9.3.

Bug: assignment to named column - not working as expected [9.3.6 (9.3.6-elpa @ ~/.emacs.d/elpa/org-9.3.6/)]

[Lester Longley]

Hello,

I'm trying to use named fields.

This works:

| ! | col2 | col3 |
| # | abc  | abc  |
#+TBLFM: $3 = $col2

However, assignment to named field "$col3":

| ! | col2 | col3 |
| # | abc  |  |
#+TBLFM: $col3 = $col2

... results in error "Unknown field: col3".

I was expecting assignment to the named column to work, as per
https://orgmode.org/manual/Advanced-features.html


‘!’

The fields in this line define names for the columns, so that you may refer
to a column as ‘$Tot’ instead of ‘$6’.
‘^’

This row defines names for the fields *above* the row. With such a
definition, any formula in the table may use ‘$m1’ to refer to the value ‘10’.
Also, if you assign a formula to a names field, it is stored as ‘$name = ...
’.

However, the documentation doesn't specifically indicate that assignment to
"$name" should work w/ "!"--it's mentioned only w/ "^" (and works fine for
this case)--so possibly what I'm trying simply isn't supported (i.e., not a
bug).  Please pardon if that's not right expectation.

Thank you for your help.

Regards,
Lester

Emacs  : GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-09-15, modified by Debian
Package: Org mode version 9.3.6 (9.3.6-elpa @ ~/.emacs.d/elpa/org-9.3.6/)

current state:
==
(setq
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
 org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate
 org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '((closure
 (org--rds reftex-docstruct-symbol
  org-element-greater-elements org-clock-history
  org-agenda-current-date org-with-time org-defdecode org-def
  org-read-date-inactive org-ans2 org-ans1
  org-columns-current-fmt-compiled org-clock-current-task
  org-clock-effort org-agenda-skip-function
  org-agenda-skip-comment-trees org-agenda-archives-mode
  org-end-time-was-given org-time-was-given
  org-log-note-extra org-log-note-purpose
  org-log-post-message org-last-inserted-timestamp
  org-last-changed-timestamp
  org-entry-property-inherited-from org-blocked-by-checkboxes
  org-state org-agenda-headline-snapshot-before-repeat
  org-capture-last-stored-marker org-agenda-start-on-weekday
  org-agenda-buffer-tmp-name org-priority-regexp
  buffer-face-mode-face org-tbl-menu org-org-menu
  org-struct-menu org-entities org-last-state
  org-id-track-globally org-clock-start-time texmathp-why
  remember-data-file
  org-agenda-tags-todo-honor-ignore-options
  iswitchb-temp-buflist calc-embedded-open-mode
  calc-embedded-open-formula calc-embedded-close-formula
  align-mode-rules-list org-emphasis-alist
  org-emphasis-regexp-components
  org-export-registered-backends org-modules
  org-babel-load-languages org-indent-indentation-per-level
  org-element-paragraph-separate ffap-url-regexp
  org-inlinetask-min-level t)
 nil
 (add-hook (quote change-major-mode-hook)
  (quote org-show-all) (quote append) (quote local))
 )
(closure
 (org-src-window-setup *this*
  org-babel-confirm-evaluate-answer-no
  org-src-preserve-indentation org-src-lang-modes
  org-edit-src-content-indentation org-babel-library-of-babel
  t)
 nil
 (add-hook (quote change-major-mode-hook)
  (quote org-babel-show-result-all) (quote append)
  (quote local))
 )
org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-bibtex-headline-format-function '(closure
  (org-id-locations
org-agenda-search-view-always-boolean
org-agenda-overriding-header t)
  (entry) (cdr (assq :title entry)))
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
 org-optimize-window-after-visibility-change)
 org-link-shell-confirm-function 'yes-or-no-p
 org-link-elisp-confirm-function 'yes-or-no-p
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-open-link :export
org-attach-export-link :complete
org-attach-complete-link)
  ("id" :follow org-id-open)
  ("eww" :follow eww :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 

Bug: error in org-table-justify-field-maybe - in conjunction with org-sbe [9.3.6 (9.3.6-elpa @ ~/.emacs.d/elpa/org-9.3.6/)]

[Lester Longley]

Hello,

I am encountering an error when using this .org code:

--
| abc | hello |
#+TBLFM: :: $2 = '(org-sbe hello_world)

#+NAME: hello_world
#+BEGIN_SRC shell -n
  echo "hello"
#+END_SRC
--

The error can be reproduced as follows:

(1) setup: (org-babel-do-load-languages 'org-babel-load-languages
'((emacs-lisp . t) (shell . t)))
(2) with position at beg of table - C-c C-c - succeeds
(3) with position (still) at beg of table - C-c C-c (again) - fails, with
Backtrace as attached.

The error is from this line in function "org-table-justify-field-maybe()"
of "org-table.el":

 ((<= (org-string-width new) width)

... where "width" is nil.

It seems to be caused by a wrong state of variable
"org-table-last-column-widths".

After the 1st C-c C-c, org-table-last-column-widths contains: "(3 5)" -
correct
After the 2nd C-c C-c, org-table-last-column-widths contains: "(5)" - wrong

The latter value results, I think, from a prior invocation of
"org-table-import" overwriting "org-table-last-column-widths".

(There are other ways to trigger the error; this is the simplest recipe I
have found.)

Thanks for your help.

Regards,
Lester

Emacs  : GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-09-15, modified by Debian
Package: Org mode version 9.3.6 (9.3.6-elpa @ ~/.emacs.d/elpa/org-9.3.6/)

current state:
==
(setq
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '((closure
 (org--rds reftex-docstruct-symbol org-element-greater-elements
  org-clock-history org-agenda-current-date org-with-time
  org-defdecode org-def org-read-date-inactive org-ans2 org-ans1
  org-columns-current-fmt-compiled org-clock-current-task
  org-clock-effort org-agenda-skip-function
  org-agenda-skip-comment-trees org-agenda-archives-mode
  org-end-time-was-given org-time-was-given org-log-note-extra
  org-log-note-purpose org-log-post-message
  org-last-inserted-timestamp org-last-changed-timestamp
  org-entry-property-inherited-from org-blocked-by-checkboxes
  org-state org-agenda-headline-snapshot-before-repeat
  org-capture-last-stored-marker org-agenda-start-on-weekday
  org-agenda-buffer-tmp-name org-priority-regexp buffer-face-mode-face
  org-tbl-menu org-org-menu org-struct-menu org-entities
  org-last-state org-id-track-globally org-clock-start-time
  texmathp-why remember-data-file
  org-agenda-tags-todo-honor-ignore-options iswitchb-temp-buflist
  calc-embedded-open-mode calc-embedded-open-formula
  calc-embedded-close-formula align-mode-rules-list org-emphasis-alist
  org-emphasis-regexp-components org-export-registered-backends
  org-modules org-babel-load-languages
  org-indent-indentation-per-level org-element-paragraph-separate
  ffap-url-regexp org-inlinetask-min-level t)
 nil
 (add-hook (quote change-major-mode-hook) (quote org-show-all)
  (quote append) (quote local))
 )
(closure
 (org-src-window-setup *this* org-babel-confirm-evaluate-answer-no
  org-src-preserve-indentation org-src-lang-modes
  org-edit-src-content-indentation org-babel-library-of-babel t)
 nil
 (add-hook (quote change-major-mode-hook)
  (quote org-babel-show-result-all) (quote append) (quote local))
 )
org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-bibtex-headline-format-function '(closure
  (org-id-locations
org-agenda-search-view-always-boolean
org-agenda-overriding-header t)
  (entry) (cdr (assq :title entry)))
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
 org-optimize-window-after-visibility-change)
 org-link-shell-confirm-function 'yes-or-no-p
 org-link-elisp-confirm-function 'yes-or-no-p
 org-table-automatic-realign nil
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-open-link :export
org-attach-export-link :complete org-attach-complete-link)
  ("id" :follow org-id-open)
  ("eww" :follow eww :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" 

Re: error - Feedback page

[Bastien]

Hi Lester,

Lester Longley  writes:

> At https://orgmode.org/manual/Feedback.html:
> I believe that this should be "M-x toggle-debug-on-error ",
> instead of "M-x toggle-debug-or-error ".

Fixed, thanks!

-- 
 Bastien

error - Feedback page

[Lester Longley]

Hello,

At https://orgmode.org/manual/Feedback.html:
I believe that this should be "M-x toggle-debug-*on*-error ",
instead of "M-x toggle-debug-*or*-error ".

Regards,
Lester

Re: equal syntax highlighting for publishing code blocks to html and pdf

[Johannes Brauer]

In the meantime I figure out these two options, too. But I decided the effort 
seems to high for me. Especially as emacs an minted use different syntactic 
categories.

Johannes

Am 01.02.2020 um 14:50 schrieb John Kitchin 
mailto:jkitc...@andrew.cmu.edu>>:

My guess is you have two options:

1. Customize the colors in minted to match what is on your screen. I am pretty 
sure that code in html looks very much like what is on your screen. This might 
be an entry point to customizing minted style. 
https://tex.stackexchange.com/questions/131456/customize-comment-color-in-minted-style

2. Customize the faces emacs uses for syntax highlighting to match the look in 
minted.

either way, I don't see a simple way to have a common theme between them, and 
they will probably always have some minor differences. It might be easier to 
hack a new exporter for src blocks that turns the htmlized code into latex 
markup perhaps.

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Sat, Feb 1, 2020 at 4:28 AM Bastien mailto:b...@gnu.org>> 
wrote:
Hi Johannes,

Johannes Brauer mailto:bra...@nordakademie.de>> writes:

> Frequently I publish org-mode documents containing source code blocks
> to html (htmlize) and pdf (minted). I would like to see the same
> colors in both export types. But
> I cannot figure out, what’s the best way to achieve this.
>
> Has anyone solved this problem? Are there any hints?

I don't know how to do this and I guess it's difficult.

If you find a solution, please mention it here, others may be
interested.

Thanks!

--
 Bastien