Re: [O] Stable 9.1.3 demands explicit empty string in (file) as capture target
Yes, you are right about the docs, alas many features are undocumented. But I must say I really haven't used org-mode in sufficient depth to say how long this glitch has been there... thank you On Fri, Nov 17, 2017 at 10:24 PM, Nicolas Goaziou wrote: > Hello, > > Umbromancer writes: > >> This may be intended, but before it was possible (and there is a lot >> of code and examples in the wild) to have a capture template element >> such as: > > I don't see this documented either in `org-capture-templates' docstring > or in the manual. It could be some glitch that disappeared during > a refactoring. AFAICT, the empty string has always been the way to go. > > Regards, > > -- > Nicolas Goaziou
[O] where is org-table-toggle-column-visibility
Hi I am still running an old git version of org mode, which I installed because there was a new function org-table-toggle-column-visibility which is very important to me. However I thought of trying out the official 9.1.3 version. However, in that version either the function is gone, still not implemented, or renamed. I recall a discussion about removing or rewriting this function but I don't remember the conclusion. For me that is a *very* useful feature since from time to time I am forced to deal with large table with a lot of columns, so that function comes in handy. Could it be please reintroduced or maybe it was just renamed? Uwe Brauer
Re: [O] [PATCH]: Fix ob-haskell.el to work with custom ghci prompts
Nicolas Goaziou writes: > Hello, > > Doro Rose writes: > >> In summary, yes I'm accessing user settings but in a rather >> noninvasive way. Unfortunately I can't think of a more elegant way to >> do this. > > Let's put it differently then. Isn't it the job of the user, who changed > their prompt, to configure properly "inf-haskell" library? I don't get > why it should be a task for "ob-haskell". > > This is a genuine question: I don't use Haskell at all. > > Regards, Well the "inf-haskell" library is fine as it is, i.e. the code sent to its buffer is evaluated correctly in the corresponding buffer. The problem occurs when sending code to that buffer via org-babel, since the interpreter output isn't parsed correctly in `org-babel-comint-with-output`. As an org-babel user my expectation would be for that to just work out of the box. -> Without having to figure out that I need to set internal variables defined in "inf-haskell" or that I need to add `ansi-color-filter-apply` to `comint-preoutput-filter-functions`.
[O] Bug: linum-mode + org-indent-mode cursor movement problems [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2/lisp/org/)]
If both linum-mode (or nlinum-mode) and org-indent-mode are enabled, then moving the cursor to the previous line using causes it to jump horizontally to the right. The jump matches the current indentation. I would expect the cursor to remain in the same column. Load linum.org (contents below) with minimal config. linum.org will enable linum-mode and org-indent-mode: emacs -Q linum.org Place your cursor on the "2" in the fourth line and press . The cursor will jump two columns to the right to the "4" in the third line. Press again and the cursor will move to the "4" in the second line. Press again and the cursor will jump back to the "e" in the first line. What is interesting is that you get different behavior when using . The cursor remains in the same column as you move down each line. So starting on the "e" in the first line, pressing moves the cursor to the "2" on the second line. If you insert a second level heading in between the first and the second line, then the jumps will be four columns instead of two. I discovered this problem first in nlimum-mode, but it is easier to reproduce using linum-mode when starting Emacs with -Q. Contents of linum.org: * heading 1234 line 2 1234 line 3 1234 line 4 # Local Variables: # eval: (org-indent-mode 1) # eval: (linum-mode 1) # End: Emacs : GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21) of 2017-09-22, modified by Debian Package: Org-mode version 8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2/lisp/org/) current state: == (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) 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-after-todo-state-change-hook '(org-clock-out-if-current) 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 '(#[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil "\300\301\302\303\304$\207" [org-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-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) )
[O] Bug: Org-mode easy templates stopped working after org-mode update [9.1.2 (release_9.1.2-190-g9cac9d @ /home/renato/.emacs.d/el-get/org-mode/lisp/)]
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
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Org-mode easy templates stopped working after org-mode update (e.g mailto:"; path
("news" :follow
(lambda (path) (browse-url (concat "news:"; path
("shell" :follow org--open-shell-link))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
)
Re: [O] Bug: linum-mode + org-indent-mode cursor movement problems [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2/lisp/org/)]
Hello, Tom Schutter writes: > But how long will we wait for Emacs 26? I don't know. It could be less long than waiting for someone to fix it, though. Anyway, I think the issue is on the Emacs C-side of code. Try playing with (vertical-motion '(2.0 . -1)) and (vertical-motion '(2.0 . 1)) in the buffer, for example from the "1" in "1234". They give different results. You may want to ask you question on Emacs Devel mailing list. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] Stable 9.1.3 demands explicit empty string in (file) as capture target
Hello, Umbromancer writes: > Yes, you are right about the docs, alas many features are > undocumented. If you think documentation is lacking somewhere, please report it. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] where is org-table-toggle-column-visibility
Hello, Uwe Brauer writes: > I am still running an old git version of org mode, > which I installed because there was a new function > org-table-toggle-column-visibility which is very important to me. > > However I thought of trying out the official 9.1.3 version. > > However, in that version either the function is gone, still not > implemented, or renamed. > > I recall a discussion about removing or rewriting this function but I > don't remember the conclusion. > > For me that is a *very* useful feature since from time to time I am > forced to deal with large table with a lot of columns, so that function > comes in handy. Could it be please reintroduced or maybe it was just > renamed? It in in master branch, so it will not be added before Org 9.2. Regards, -- Nicolas Goaziou
[O] ob-python newline & indentation behavior
ob-python newline & indentation behavior in :session is very ugly and possibly broken. For example, consider the following code block: #+BEGIN_SRC python :session :results output foo = 0 for _ in range(10): foo += 1 foo += 1 print(foo) #+END_SRC Ideally this would print "20", but instead it prints "11", because the second "foo+=1" is executed after the for loop. OTOH "python-shell-send-region" (from python.el) gives the correct answer of "20". The inconsistent behavior of "python-shell-send-region" and "org-babel-eval" often causes me problems, because I want to use both (the former for testing and async eval; the latter for inserting into the document). There is a 2 year old patch that fixes this behavior but has not yet been incorporated: https://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00505.html The patch follows the python.el behavior of using a temporary file and executing that from the shell. Could this patch, or something similar, be incorporated into org-mode, to fix this behavior? Thanks, Jack Kamm
Re: [O] Bug: linum-mode + org-indent-mode cursor movement problems [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2/lisp/org/)]
On Fri, Nov 17, 2017, 6:20 PM Tom Schutter wrote: > But how long will we wait for Emacs 26? > The release is "imminent" as the first pretest is already out. Adding of new features to Emacs 26 has been stopped for a while now. So now only bug fixes and doc improvements happen. I have been building Emacs from emacs-26 branch pretty regularly and it's very stable for my daily use. Pretest download links: For GNU/Linux systems: ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.0.90.tar.xz For Windows: http://alpha.gnu.org/gnu/emacs/pretest/windows/ Try it out! :) > -- Kaushal Modi
[O] Deletion immediately after insertion should leave org-mode tables unaltered but it doesn't
Given a simple table such as | Name | Age | |---+-| | John | 20 | | Peter | 25 | |---+-| place the cursor in the cell containing 'Age', insert two columns pressing 'M-S-right' each time and, immediately after that, delete two columns with "M-S-left". One would expect the table to return to its original state, but is doesn't. In reality the table becomes | | Age | |---+-| | | 20 | | | 25 | |---+-| because the second deletion actually kills the column labeled "Name". Contrast this with the behaviour of inserting and deleting characters in text-mode and you will see that the above behaviour is counter intuitive. I believe this is due to the fact that 'M-S-right' inserts a column at the cursor, placing the cursor within the inserted column, while, after deletion, the cursor is placed in the column to the LEFT of the deleted column (except after deleting the leftmost column). A possible solution is to place the column to the RIGHT of the deleted column after deletion (except after deleting the rightmost column). Best wishes, Ruy
Re: [O] ob-python newline & indentation behavior
Hello, Jack Kamm writes: > ob-python newline & indentation behavior in :session is very ugly and > possibly broken. For example, consider the following code block: [...] > There is a 2 year old patch that fixes this behavior but has not yet > been incorporated: > https://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00505.html [...] > The patch follows the python.el behavior of using a temporary file and > executing that from the shell. > > Could this patch, or something similar, be incorporated into org-mode, > to fix this behavior? Here's what I said in a recent post about ob-python sessions: https://lists.gnu.org/archive/html/emacs-orgmode/2017-10/msg00198.html I dropped my attempt to fix it because 1) I was still having trouble getting a complete understanding of what the issue was and 2) I didn't have the motivation to spend time digging deeper because I don't use ob-python (and in general am not a heavy Org-Babel user). Perhaps you or some other ob-python user could help make ob-python sessions more robust? Perhaps you are the "you"? -- Kyle
Re: [O] Do not inherit unnumbered property: help needed
On November 17, 2017 10:09:55 PM GMT+00:00, Nicolas Goaziou
wrote:
>
>OOC, what is the output you expect from your initial example?
>
in LaTeX:
* section-one
blah
* unnumbered-header
:PROPERTIES:
:UNNUMBERED:
:SKIP-OUTLINE-LEVEL:
:END:
** section-two
blah
** section-three
blah
* section-four
blah
should export as
\section{section-one}
blah
\section*{unnumbered-header}
\section{section-two}
blah
\section{section-three}
blah
\section{section-four}
blah
I agree, this is structurally incorrect but will look ok, or can be made look
ok.
This is the first time I post to mailing list from K9-mail, hopefully it goes
to proper thread, sorry if doesn't.
signature.asc
Description: PGP signature
Re: [O] Do not inherit unnumbered property: help needed
Hello,
Akater writes:
> On November 17, 2017 10:09:55 PM GMT+00:00, Nicolas Goaziou
> wrote:
>>
>>OOC, what is the output you expect from your initial example?
>>
>
> in LaTeX:
>
> * section-one
> blah
> * unnumbered-header
> :PROPERTIES:
> :UNNUMBERED:
> :SKIP-OUTLINE-LEVEL:
> :END:
> ** section-two
> blah
> ** section-three
> blah
> * section-four
> blah
>
> should export as
>
> \section{section-one}
> blah
> \section*{unnumbered-header}
> \section{section-two}
> blah
> \section{section-three}
> blah
> \section{section-four}
> blah
>
> I agree, this is structurally incorrect but will look ok, or can be
> made look ok.
I see. I don't think UNNUMBERED should be able to modify the structure
of the document. I suggest to write a parse tree filter that does that
change to the tree.
Regards,
--
Nicolas Goaziou0x80A93738
Re: [O] Beginner installing org-mode 9.1.2 from git fails on homebrew emacs-mac
Thanks for putting me on the right track. I would not find that out by
my self (+1 for the /etc/paths file too!).
That was in fact the problem, somewhere /usr/local/bin/emacs is being
called which has an outdate cl-lib.
I installed both emacs-mac and emacs-plus via homebrew and was able to
successfully upgrade the bundled org-mode to the git stable
origin/maint in both cases.
Miguel
On Thu, Nov 16, 2017 at 8:56 PM, Tim Cross wrote:
>
> That error you see re: missing cl-lib is an error I have seen because
> the system is getting confused over emacs versions. Essentially,
> somewhere in the scripts, a call is being made to 'emacs' and it is
> finding the old /usr/bin/emacs rather than the one you have installed
> with homebrew.
>
> I have found this happens when I use the 'macports' version i.e. the
> brew cask version of emacs. I don't get this problem when I just do a
> brew install emacs (remembering to manually add the cocoa, svg,
> imagemagick etc command line switches). I've not really looked into it
> as the non-cask version of emacs works just fine, but I think the issue
> is that the cask version does not create binaries or sym links to
> binaries in /usr/local/bin for 'emacs' (note lower case), so the version
> in /usr/bin/emacs is being picked up and that version predates cl-lib.
>
> Try doing a `which emacs` in a terminal to see which version is being
> found and then do whatever you need to do to ensure the homebrew version
> is found in the PATH before the stock standard OSX version.
>
> Tim
>
> BTW it is also a good idea to add /usr/local/bin to the /etc/paths file
> to ensure that directory is added before /usr/bin by default when you
> login etc.
>
>
>
>
>
>> Solved.
>>
>> I was successful following the same steps using homebrew emacs-plus
>> (https://github.com/d12frosted/homebrew-emacs-plus) instead of
>> homebrew emacs-mac
>> (https://github.com/railwaycat/homebrew-emacsmacport). So it seems
>> this must be an issue with the railwaycat distro or its homebrew
>> formula.
>>
>> On Mon, Nov 13, 2017 at 11:51 PM, Umbromancer wrote:
>>> Hi all,
>>>
>>> This is my first post on the list, and an definitively an emacs/org-mode
>>> newbe.
>>>
>>> I've just upgraded to emacs 25.3.1 via homebrew (emacs-mac) and the
>>> included org-version is 8.2.10. I'm trying to setup the git stable
>>> release_9.1.2 as per suggestion on the worg faq. I've cloned the git
>>> repo and duplicated default.mk into local.mk and edited it so as to
>>> point to the homebrew Emacs location.
>>>
>>> I've upgraded org-mode on my previous Emacs 24 install using the
>>> "same" method. The only difference being previously I used the
>>> org-mode stable download from org-mode.org instead of the git sources.
>>>
>>> After editing local.mk and issuing the make commands, I get:
>>> $ make cleanall
>>> ...
>>> $ make install
>>> Miguels-MBP:org-mode me$ make install
>>> /Library/Developer/CommandLineTools/usr/bin/make -C doc install
>>> org-version: 9.1.2 (release_9.1.2)
>>> makeinfo --no-split org.texi -o org
>>> /Users/me/elisp/org-mode/doc//docstyle.texi:3: warning: unrecognized
>>> encoding name `UTF-8'.
>>> if [ ! -d /usr/local/Cellar/emacs-mac/emacs-25.3-mac-6.8/share/info/emacs
>>> ]; then install -m 755 -d
>>> /usr/local/Cellar/emacs-mac/emacs-25.3-mac-6.8/share/info/emacs; else
>>> true; fi ;
>>> install -m 644 -p org
>>> /usr/local/Cellar/emacs-mac/emacs-25.3-mac-6.8/share/info/emacs
>>> install-info
>>> --infodir=/usr/local/Cellar/emacs-mac/emacs-25.3-mac-6.8/share/info/emacs
>>> org
>>> /Library/Developer/CommandLineTools/usr/bin/make -C etc install
>>> for dir in styles schema ; do \
>>> if [ ! -d
>>> /usr/local/Cellar/emacs-mac/emacs-25.3-mac-6.8/share/emacs/25.3/etc/org/${dir}
>>> ] ; then \
>>> install -m 755 -d
>>> /usr/local/Cellar/emacs-mac/emacs-25.3-mac-6.8/share/emacs/25.3/etc/org/${dir}
>>> ; \
>>> fi ; \
>>> install -m 644 -p ${dir}/*
>>> /usr/local/Cellar/emacs-mac/emacs-25.3-mac-6.8/share/emacs/25.3/etc/org/${dir}
>>> ; \
>>> done ;
>>> /Library/Developer/CommandLineTools/usr/bin/make -C lisp install
>>> rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc
>>> org-install.elc
>>> org-version: 9.1.2 (release_9.1.2)
>>> Loading /Users/me/elisp/org-mode/lisp/org-compat.el (source)...
>>> Cannot open load file: cl-lib
>>> make[1]: *** [org-version.el] Error 255
>>> make: *** [install-lisp] Error 2
>>> Miguels-MBP:org-mode me$
>>>
>>> cl-lib is of course available when I run Emacs.
>>> I'm mostly likely missing something which fails to be obvious for me...
>>>
>>> Thanks in advance for all the help,
>>> Miguel
>
>
> --
> Tim Cross
Re: [O] Do not inherit unnumbered property: help needed
On November 18, 2017 5:18:10 PM GMT+00:00, Nicolas Goaziou >I see. I don't think UNNUMBERED should be able to modify the structure >of the document. I suggest to write a parse tree filter that does that >change to the tree. > >Regards, Please note: it is not UNNUMBERED that modifies the structure in my suggestion but rather SKIP-OUTLINE-LEVEL. signature.asc Description: PGP signature
Re: [O] Do not inherit unnumbered property: help needed
On November 18, 2017 5:18:10 PM GMT+00:00, Nicolas Goaziou wrote: > I suggest to write a parse tree filter that does that >change to the tree. > I got an impression that UNNUMBERED's children get cut off prior to what user can do, hence writing a simple backend won't help, and I'll have to patch org (ox) source. Do you know for sure I'm wrong? That's what I asked for originally---which function is responsible for excluding unnumbered's children from exported entries. signature.asc Description: PGP signature
[O] Bug: Template Expansion with prompt-specific history [9.1.2 (9.1.2-37-g3f8d67-elpa @ /Users/ke/.emacs.d/elpa/org-20171113/)]
Template expansion no longer works as documented:
%^{PROMPT} prompt the user for a string and replace this sequence with it.
You may specify a default value and a completion table with
%^{prompt|default|completion2|completion3...}.
The arrow keys access a prompt-specific history.
After the last update, the prompt-specific history is gone for me.
Unfortunately, I di not remember which org version I used before the update.
Emacs : GNU Emacs 25.3.1 (x86_64-apple-darwin14.5.0, NS appkit-1348.17 Version
10.10.5 (Build 14F2511))
of 2017-09-19
Package: Org mode version 9.1.2 (9.1.2-37-g3f8d67-elpa @
/Users/ke/.emacs.d/elpa/org-20171113/)
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-capture-templates '(("t" "Todo" entry
(file+headline "~/notes/gtd.org" "Tasks")
"* TODO %?\n %i\n %a")
("j" "Journal" entry
(file+datetree "~/notes/journal.org")
"* %?\nEntered on %U\n %i\n %a")
("b" "Benn-Briefe")
("bb" "Oelze-Benn" entry
(file+headline "~/github/benn/briefe/oelze.org"
"Benn")
"** %^{datum|19|1950}\n :PROPERTIES:\n
:CUSTOM_ID: oeb%\\1\n :TRAD:\n :ORT: %^{ort|Berlin|Berlin}\n :END:\n***
BOe2016\n%^{NR}p%^{BD}p%^{S}p%^{AUSL}p%^{FAKS}p%^{S_KOM}p\n")
("bo" "Benn-Oelze" entry
(file+headline "~/github/benn/briefe/oelze.org"
"Oelze, Friedrich Wilhelm")
"** %^{datum|19|1950}\n :PROPERTIES:\n
:CUSTOM_ID: oe%\\1\n :TRAD:\n :ORT: %^{ort|Bremen}\n :END:\n***
BOe2016\n%^{NR}p%^{BD}p%^{S}p%^{AUSL}p%^{FAKS}p%^{S_KOM}p\n***
BOe\n%^{NR}p%^{BD}p%^{S}p%^{AUSL}p%^{S_KOM}p\n")
("bs" "Benn-Seyerlen" entry
(file+headline "~/github/benn/briefe/seyerlen.org"
"Seyerlen, Egmont")
"** %^{datum}\n :PROPERTIES:\n :CUSTOM_ID:
sey%\\1\n :TRAD:\n :ORT: %^{ort}\n :END:\n***
BSey1993\n%^{NR}p%^{S}p%^{AUSL}p%^{FAKS}p%^{S_KOM}p\n")
("bx" "x-Benn" entry
(file+headline "~/github/benn/briefe/benn.org"
"Benn")
"** %^{datum}\n :PROPERTIES:\n :CUSTOM_ID:
oeb%\\1\n :TRAD:\n :ORT: %^{ort}\n :END:\n***
BOe2016\n:PROPERTIES:%^{NR}p%^{BD}p%^{S}p%^{AUSL}p%^{FAKS}p%^{S_KOM}p\n:END:")
("by" "b1962" entry
(file+headline "~/github/benn/briefe/benn.org"
"Benn")
"*** B1962\n%^{S}p%^{AUSL}p%^{FAKS}p%^{S_KOM}p\n")
)
org-after-todo-state-change-hook '(org-clock-out-if-current)
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 '(#[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-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
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-
Re: [O] ob-python newline & indentation behavior
Thanks Kyle, and sorry for missing that recent related thread.
I adapted your old patch to the current master branch. I also extended it
to work for ":results value" (the original patch only worked for ":results
output"). I did this by not writing the last line of the code block to the
tmpfile, unless it is indented.
I've never contributed before so would appreciate any comments on this
patch, and how to get it accepted. Cheers, Jack.
>From a5d553ece9f6ee35cd1e273e554a21a19e80ec3c Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sat, 18 Nov 2017 21:47:09 +
Subject: [PATCH] fix newline/indentation issues in ob-python :session
---
lisp/ob-python.el | 33 +
1 file changed, 33 insertions(+)
diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 60ec5fa47..6623ef5fc 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -303,6 +303,10 @@ last statement in BODY, as elisp."
(mapc (lambda (line) (insert line) (funcall
send-wait))
(split-string body "[\r\n]"))
(funcall send-wait)))
+(indented-p (org-babel-python--indented-p body))
+(body (if indented-p
+ (org-babel-python--replace-body-tmpfile body)
+body))
(results
(pcase result-type
(`output
@@ -340,6 +344,35 @@ last statement in BODY, as elisp."
(substring string 1 -1)
string))
+
+(defun org-babel-python--indented-p (input)
+ "Non-nil if any line in INPUT is indented."
+ (string-match-p "^[ \t]" input))
+
+(defun org-babel-python--replace-body-tmpfile (body)
+ "Place body in tmpfile, and return string to exec the tmpfile.
+If last line of body is not indented, place it at end of exec string
+instead of tmpfile, so shell can see the result"
+ (let* ((tmp-file (org-babel-temp-file "python-"))
+(lines (split-string body "\n" t))
+(lastline (car (last lines)))
+(newbody (concat
+ (format "__pyfilename = '%s'; " tmp-file)
+ "__pyfile = open(__pyfilename); "
+ "exec(compile("
+ "__pyfile.read(), __pyfilename, 'exec'"
+ ")); "
+ "__pyfile.close()")))
+(if (string-match-p "^[ \t]" lastline)
+ (progn
+ (with-temp-file tmp-file (insert body))
+ newbody)
+ (with-temp-file tmp-file
+ (insert (mapconcat 'identity
+ (butlast lines) "\n")))
+ (concat newbody "\n" lastline)))
+ )
+
(provide 'ob-python)
--
2.15.0
On Sat, Nov 18, 2017 at 3:05 PM, Kyle Meyer wrote:
> Hello,
>
> Jack Kamm writes:
>
> > ob-python newline & indentation behavior in :session is very ugly and
> > possibly broken. For example, consider the following code block:
>
> [...]
>
> > There is a 2 year old patch that fixes this behavior but has not yet
> > been incorporated:
> > https://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00505.html
>
> [...]
>
> > The patch follows the python.el behavior of using a temporary file and
> > executing that from the shell.
> >
> > Could this patch, or something similar, be incorporated into org-mode,
> > to fix this behavior?
>
> Here's what I said in a recent post about ob-python sessions:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2017-10/msg00198.html
>
> I dropped my attempt to fix it because 1) I was still having trouble
> getting a complete understanding of what the issue was and 2) I didn't
> have the motivation to spend time digging deeper because I don't use
> ob-python (and in general am not a heavy Org-Babel user). Perhaps you
> or some other ob-python user could help make ob-python sessions more
> robust?
>
> Perhaps you are the "you"?
>
> --
> Kyle
>
Re: [O] Do not inherit unnumbered property: help needed
Hello, Akater writes: > I got an impression that UNNUMBERED's children get cut off prior to > what user can do, UNNUMBERED headings are not cut off, at least not by "ox.el". > hence writing a simple backend won't help, and I'll have to patch org > (ox) source. Do you know for sure I'm wrong? I'm quite certain you're wrong. > That's what I asked for > originally---which function is responsible for excluding unnumbered's > children from exported entries. Three functions actually check UNNUMBERED properties: - org-export-numbered-headline-p - org-export-collect-headlines - org-export-excluded-from-toc-p You can ignore the last two because it's a special case (when value is "notoc"). So, if you want to control UNNUMBERED property, just don't trust `org-export-numbered-headline-p', or any function calling it. Regards, -- Nicolas Goaziou
Re: [O] Deletion immediately after insertion should leave org-mode tables unaltered but it doesn't
Hello, Ruy Exel writes: > Given a simple table such as > > | Name | Age | > |---+-| > | John | 20 | > | Peter | 25 | > |---+-| > > place the cursor in the cell containing 'Age', insert two columns pressing > 'M-S-right' each time and, immediately after that, delete two columns with > "M-S-left". One would expect the table to return to its original state, > but is doesn't. In reality the table becomes > > | | Age | > |---+-| > | | 20 | > | | 25 | > |---+-| > > because the second deletion actually kills the column labeled "Name". > > Contrast this with the behaviour of inserting and deleting characters in > text-mode and you will see that the above behaviour is counter intuitive. > > I believe this is due to the fact that 'M-S-right' inserts a column at the > cursor, placing the cursor within the inserted column, while, after > deletion, the cursor is placed in the column to the LEFT of the deleted > column (except after deleting the leftmost column). > > A possible solution is to place the column to the RIGHT of the deleted > column after deletion (except after deleting the rightmost column). The deletion is triggered by pressing the arrow. Your suggestion would make the point move right. This is not optimal either. Maybe the other way is better. Since column creation is triggered by pressing arrow, we might create it to the right of the current column, and point would move into it. WDYT? Regards, -- Nicolas Goaziou
Re: [O] Deletion immediately after insertion should leave org-mode tables unaltered but it doesn't
Hi Nicolas, This is indeed a good idea as it mimics the creation of a row in emacs text-mode with "C-o". Best wishes, Ruy On Sat, Nov 18, 2017 at 9:37 PM, Nicolas Goaziou wrote: > Hello, > > Ruy Exel writes: > > > Given a simple table such as > > > > | Name | Age | > > |---+-| > > | John | 20 | > > | Peter | 25 | > > |---+-| > > > > place the cursor in the cell containing 'Age', insert two columns > pressing > > 'M-S-right' each time and, immediately after that, delete two columns > with > > "M-S-left". One would expect the table to return to its original state, > > but is doesn't. In reality the table becomes > > > > | | Age | > > |---+-| > > | | 20 | > > | | 25 | > > |---+-| > > > > because the second deletion actually kills the column labeled "Name". > > > > Contrast this with the behaviour of inserting and deleting characters in > > text-mode and you will see that the above behaviour is counter intuitive. > > > > I believe this is due to the fact that 'M-S-right' inserts a column at > the > > cursor, placing the cursor within the inserted column, while, after > > deletion, the cursor is placed in the column to the LEFT of the deleted > > column (except after deleting the leftmost column). > > > > A possible solution is to place the column to the RIGHT of the deleted > > column after deletion (except after deleting the rightmost column). > > The deletion is triggered by pressing the arrow. Your suggestion > would make the point move right. This is not optimal either. > > Maybe the other way is better. Since column creation is triggered by > pressing arrow, we might create it to the right of the current > column, and point would move into it. > > WDYT? > > Regards, > > -- > Nicolas Goaziou > On Sat, Nov 18, 2017 at 9:37 PM, Nicolas Goaziou wrote: > Hello, > > Ruy Exel writes: > > > Given a simple table such as > > > > | Name | Age | > > |---+-| > > | John | 20 | > > | Peter | 25 | > > |---+-| > > > > place the cursor in the cell containing 'Age', insert two columns > pressing > > 'M-S-right' each time and, immediately after that, delete two columns > with > > "M-S-left". One would expect the table to return to its original state, > > but is doesn't. In reality the table becomes > > > > | | Age | > > |---+-| > > | | 20 | > > | | 25 | > > |---+-| > > > > because the second deletion actually kills the column labeled "Name". > > > > Contrast this with the behaviour of inserting and deleting characters in > > text-mode and you will see that the above behaviour is counter intuitive. > > > > I believe this is due to the fact that 'M-S-right' inserts a column at > the > > cursor, placing the cursor within the inserted column, while, after > > deletion, the cursor is placed in the column to the LEFT of the deleted > > column (except after deleting the leftmost column). > > > > A possible solution is to place the column to the RIGHT of the deleted > > column after deletion (except after deleting the rightmost column). > > The deletion is triggered by pressing the arrow. Your suggestion > would make the point move right. This is not optimal either. > > Maybe the other way is better. Since column creation is triggered by > pressing arrow, we might create it to the right of the current > column, and point would move into it. > > WDYT? > > Regards, > > -- > Nicolas Goaziou >
Re: [O] ob-python newline & indentation behavior
Hello Jack:
What versions of emacs and org-mode are you using?
I tried your example on Emacs 25.3.1 and org-mode 9.1.2-22 and I got "20"
as result
It has happened to me in the past that some bug I was seeing goes away just
by updating org-mode.
Regards,
Martin
On Sat, Nov 18, 2017 at 5:16 PM Jack Kamm wrote:
> Thanks Kyle, and sorry for missing that recent related thread.
>
> I adapted your old patch to the current master branch. I also extended it
> to work for ":results value" (the original patch only worked for ":results
> output"). I did this by not writing the last line of the code block to the
> tmpfile, unless it is indented.
>
> I've never contributed before so would appreciate any comments on this
> patch, and how to get it accepted. Cheers, Jack.
>
> From a5d553ece9f6ee35cd1e273e554a21a19e80ec3c Mon Sep 17 00:00:00 2001
>
> From: Jack Kamm
> Date: Sat, 18 Nov 2017 21:47:09 +
> Subject: [PATCH] fix newline/indentation issues in ob-python :session
>
> ---
> lisp/ob-python.el | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/lisp/ob-python.el b/lisp/ob-python.el
> index 60ec5fa47..6623ef5fc 100644
> --- a/lisp/ob-python.el
> +++ b/lisp/ob-python.el
> @@ -303,6 +303,10 @@ last statement in BODY, as elisp."
>(mapc (lambda (line) (insert line) (funcall
> send-wait))
> (split-string body "[\r\n]"))
>(funcall send-wait)))
> +(indented-p (org-babel-python--indented-p body))
> +(body (if indented-p
> + (org-babel-python--replace-body-tmpfile body)
> +body))
> (results
>(pcase result-type
> (`output
> @@ -340,6 +344,35 @@ last statement in BODY, as elisp."
>(substring string 1 -1)
> string))
>
> +
> +(defun org-babel-python--indented-p (input)
> + "Non-nil if any line in INPUT is indented."
> + (string-match-p "^[ \t]" input))
> +
> +(defun org-babel-python--replace-body-tmpfile (body)
> + "Place body in tmpfile, and return string to exec the tmpfile.
> +If last line of body is not indented, place it at end of exec string
> +instead of tmpfile, so shell can see the result"
> + (let* ((tmp-file (org-babel-temp-file "python-"))
> +(lines (split-string body "\n" t))
> +(lastline (car (last lines)))
> +(newbody (concat
> + (format "__pyfilename = '%s'; " tmp-file)
> + "__pyfile = open(__pyfilename); "
> + "exec(compile("
> + "__pyfile.read(), __pyfilename, 'exec'"
> + ")); "
> + "__pyfile.close()")))
> +(if (string-match-p "^[ \t]" lastline)
> + (progn
> + (with-temp-file tmp-file (insert body))
> + newbody)
> + (with-temp-file tmp-file
> + (insert (mapconcat 'identity
> + (butlast lines) "\n")))
> + (concat newbody "\n" lastline)))
> + )
> +
> (provide 'ob-python)
>
>
> --
> 2.15.0
>
>
> On Sat, Nov 18, 2017 at 3:05 PM, Kyle Meyer wrote:
>
>> Hello,
>>
>> Jack Kamm writes:
>>
>> > ob-python newline & indentation behavior in :session is very ugly and
>> > possibly broken. For example, consider the following code block:
>>
>> [...]
>>
>> > There is a 2 year old patch that fixes this behavior but has not yet
>> > been incorporated:
>> > https://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00505.html
>>
>> [...]
>>
>> > The patch follows the python.el behavior of using a temporary file and
>> > executing that from the shell.
>> >
>> > Could this patch, or something similar, be incorporated into org-mode,
>> > to fix this behavior?
>>
>> Here's what I said in a recent post about ob-python sessions:
>>
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2017-10/msg00198.html
>>
>> I dropped my attempt to fix it because 1) I was still having trouble
>> getting a complete understanding of what the issue was and 2) I didn't
>> have the motivation to spend time digging deeper because I don't use
>> ob-python (and in general am not a heavy Org-Babel user). Perhaps you
>> or some other ob-python user could help make ob-python sessions more
>> robust?
>>
>> Perhaps you are the "you"?
>>
>> --
>> Kyle
>>
>
>
Re: [O] ob-python newline & indentation behavior
Sorry Jack, I overlooked the :session bit.
Disregard my email please
On Sat, Nov 18, 2017 at 10:27 PM Martin Alsinet
wrote:
> Hello Jack:
>
> What versions of emacs and org-mode are you using?
>
> I tried your example on Emacs 25.3.1 and org-mode 9.1.2-22 and I got "20"
> as result
> It has happened to me in the past that some bug I was seeing goes away
> just by updating org-mode.
>
> Regards,
>
>
> Martin
>
> On Sat, Nov 18, 2017 at 5:16 PM Jack Kamm wrote:
>
>> Thanks Kyle, and sorry for missing that recent related thread.
>>
>> I adapted your old patch to the current master branch. I also extended it
>> to work for ":results value" (the original patch only worked for ":results
>> output"). I did this by not writing the last line of the code block to the
>> tmpfile, unless it is indented.
>>
>> I've never contributed before so would appreciate any comments on this
>> patch, and how to get it accepted. Cheers, Jack.
>>
>> From a5d553ece9f6ee35cd1e273e554a21a19e80ec3c Mon Sep 17 00:00:00 2001
>>
>> From: Jack Kamm
>> Date: Sat, 18 Nov 2017 21:47:09 +
>> Subject: [PATCH] fix newline/indentation issues in ob-python :session
>>
>> ---
>> lisp/ob-python.el | 33 +
>> 1 file changed, 33 insertions(+)
>>
>> diff --git a/lisp/ob-python.el b/lisp/ob-python.el
>> index 60ec5fa47..6623ef5fc 100644
>> --- a/lisp/ob-python.el
>> +++ b/lisp/ob-python.el
>> @@ -303,6 +303,10 @@ last statement in BODY, as elisp."
>>(mapc (lambda (line) (insert line) (funcall
>> send-wait))
>> (split-string body "[\r\n]"))
>>(funcall send-wait)))
>> +(indented-p (org-babel-python--indented-p body))
>> +(body (if indented-p
>> + (org-babel-python--replace-body-tmpfile body)
>> +body))
>> (results
>>(pcase result-type
>> (`output
>> @@ -340,6 +344,35 @@ last statement in BODY, as elisp."
>>(substring string 1 -1)
>> string))
>>
>> +
>> +(defun org-babel-python--indented-p (input)
>> + "Non-nil if any line in INPUT is indented."
>> + (string-match-p "^[ \t]" input))
>> +
>> +(defun org-babel-python--replace-body-tmpfile (body)
>> + "Place body in tmpfile, and return string to exec the tmpfile.
>> +If last line of body is not indented, place it at end of exec string
>> +instead of tmpfile, so shell can see the result"
>> + (let* ((tmp-file (org-babel-temp-file "python-"))
>> +(lines (split-string body "\n" t))
>> +(lastline (car (last lines)))
>> +(newbody (concat
>> + (format "__pyfilename = '%s'; " tmp-file)
>> + "__pyfile = open(__pyfilename); "
>> + "exec(compile("
>> + "__pyfile.read(), __pyfilename, 'exec'"
>> + ")); "
>> + "__pyfile.close()")))
>> +(if (string-match-p "^[ \t]" lastline)
>> + (progn
>> + (with-temp-file tmp-file (insert body))
>> + newbody)
>> + (with-temp-file tmp-file
>> + (insert (mapconcat 'identity
>> + (butlast lines) "\n")))
>> + (concat newbody "\n" lastline)))
>> + )
>> +
>> (provide 'ob-python)
>>
>>
>> --
>> 2.15.0
>>
>>
>> On Sat, Nov 18, 2017 at 3:05 PM, Kyle Meyer wrote:
>>
>>> Hello,
>>>
>>> Jack Kamm writes:
>>>
>>> > ob-python newline & indentation behavior in :session is very ugly and
>>> > possibly broken. For example, consider the following code block:
>>>
>>> [...]
>>>
>>> > There is a 2 year old patch that fixes this behavior but has not yet
>>> > been incorporated:
>>> > https://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00505.html
>>>
>>> [...]
>>>
>>> > The patch follows the python.el behavior of using a temporary file and
>>> > executing that from the shell.
>>> >
>>> > Could this patch, or something similar, be incorporated into org-mode,
>>> > to fix this behavior?
>>>
>>> Here's what I said in a recent post about ob-python sessions:
>>>
>>>
>>> https://lists.gnu.org/archive/html/emacs-orgmode/2017-10/msg00198.html
>>>
>>> I dropped my attempt to fix it because 1) I was still having trouble
>>> getting a complete understanding of what the issue was and 2) I
>>> didn't
>>> have the motivation to spend time digging deeper because I don't use
>>> ob-python (and in general am not a heavy Org-Babel user). Perhaps
>>> you
>>> or some other ob-python user could help make ob-python sessions more
>>> robust?
>>>
>>> Perhaps you are the "you"?
>>>
>>> --
>>> Kyle
>>>
>>
>>
[O] Bug: #+INCLUDE: :only-contents not recognized [9.1.2 (9.1.2-37-g3f8d67-elpa @ /home/data1/protected/.emacs.d/elpa/org-20171113/)]]
I can see that if I use: #+INCLUDE: "~/Documents/Org/With-Ease.org" :only-contents t that the #+TITLE variable is then included in the main file, and is concatenated to the main title. I am exporting "visible only" and that is happening. That is not expected. If I try to export with subtree from a section, I do not get the #+TITLE of included file shown in ASCII export. Do I need to do something to avoid the title being exported wrongly? Jean Louis Emacs : GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2017-11-11 Package: Org mode version 9.1.2 (9.1.2-37-g3f8d67-elpa @ /home/data1/protected/.emacs.d/elpa/org-20171113/)
Re: [O] ob-python newline & indentation behavior
Sorry, I should have mentioned my version info anyways. I have tested on
emacs 25.3.1 and emacs 26.0.90, and org-mode versions 9.1.2 and 9.1.3
(current master).
The same error occurs on all emacs and org-mode versions. However the error
slightly differs between Python and IPython interpreters. IPython prints
"11" (instead of the expected "20"), whereas Python raises an
IndentationError then prints "10".
I've cleaned up my patch to deal with a few edge cases. In particular:
1) Fixed a bug where I was removing blank lines (these may be needed if
they are part of a multiline string object)
2) Send to tmpfile any multiline block even if not indented. This follows
the python.el behavior and gives more consistent behavior for ":results
output"
3) Allow ":results value" to work when the block ends in several newlines,
using string-trim-right
Here is the new version of the patch:
>From f009da37d3b7e2730abb8cbb10f4d07b3d456dd8 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 19 Nov 2017 07:13:56 +
Subject: [PATCH] Squashed commit of the following:
commit d1fe88a9f61a8e7082f08b7c190a29737bb655d5
Author: Jack Kamm
Date: Sun Nov 19 07:08:31 2017 +
fix block ending in blank lines; send multiline blocks to tmpfile
commit fcc5a7795e882716775c9d925b0cd5b657da041b
Author: Jack Kamm
Date: Sat Nov 18 22:40:31 2017 +
fix newlines and blanklines when sending codeblock to tmpfile
commit a5d553ece9f6ee35cd1e273e554a21a19e80ec3c
Author: Jack Kamm
Date: Sat Nov 18 21:47:09 2017 +
fix newline/indentation issues in ob-python :session
---
lisp/ob-python.el | 29 +
1 file changed, 29 insertions(+)
diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 60ec5fa47..c3dba1565 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -303,6 +303,9 @@ last statement in BODY, as elisp."
(mapc (lambda (line) (insert line) (funcall
send-wait))
(split-string body "[\r\n]"))
(funcall send-wait)))
+(body (if (string-match-p ".\n+." body) ;; Multiline
+ (org-babel-python--replace-body-tmpfile body)
+body))
(results
(pcase result-type
(`output
@@ -340,6 +343,32 @@ last statement in BODY, as elisp."
(substring string 1 -1)
string))
+
+(defun org-babel-python--replace-body-tmpfile (body)
+ "Place body in tmpfile, and return string to exec the tmpfile.
+If last line of body is not indented, place it at end of exec string
+instead of tmpfile, so shell can see the result"
+ (let* ((body (string-trim-right body))
+(tmp-file (org-babel-temp-file "python-"))
+(lines (split-string body "[\r\n]"))
+(lastline (car (last lines)))
+(newbody (concat
+ (format "__pyfilename = '%s'; " tmp-file)
+ "__pyfile = open(__pyfilename); "
+ "exec(compile("
+ "__pyfile.read(), __pyfilename, 'exec'"
+ ")); "
+ "__pyfile.close()")))
+(if (string-match-p "^[ \t]" lastline)
+ (progn
+ (with-temp-file tmp-file (insert body))
+ newbody)
+ (with-temp-file tmp-file
+ (insert (mapconcat 'identity
+ (butlast lines) "\n")))
+ (concat newbody "\n" lastline)))
+ )
+
(provide 'ob-python)
--
2.15.0
On Sun, Nov 19, 2017 at 3:34 AM, Martin Alsinet
wrote:
> Sorry Jack, I overlooked the :session bit.
> Disregard my email please
>
>
> On Sat, Nov 18, 2017 at 10:27 PM Martin Alsinet
> wrote:
>
>> Hello Jack:
>>
>> What versions of emacs and org-mode are you using?
>>
>> I tried your example on Emacs 25.3.1 and org-mode 9.1.2-22 and I got "20"
>> as result
>> It has happened to me in the past that some bug I was seeing goes away
>> just by updating org-mode.
>>
>> Regards,
>>
>>
>> Martin
>>
>> On Sat, Nov 18, 2017 at 5:16 PM Jack Kamm wrote:
>>
>>> Thanks Kyle, and sorry for missing that recent related thread.
>>>
>>> I adapted your old patch to the current master branch. I also extended
>>> it to work for ":results value" (the original patch only worked for
>>> ":results output"). I did this by not writing the last line of the code
>>> block to the tmpfile, unless it is indented.
>>>
>>> I've never contributed before so would appreciate any comments on this
>>> patch, and how to get it accepted. Cheers, Jack.
>>>
>>> From a5d553ece9f6ee35cd1e273e554a21a19e80ec3c Mon Sep 17 00:00:00 2001
>>>
>>> From: Jack Kamm
>>> Date: Sat, 18 Nov 2017 21:47:09 +
>>> Subject: [PATCH] fix newline/indentation issues in ob-python :session
>>>
>>> ---
>>> lisp/ob-python.el | 33 +
>>> 1 file changed, 33 insertions(+)
>>>
>>> diff --git a/lisp/ob-python.el b/lisp/ob-python.el
>>> index 60ec5fa47..6623ef5fc 100644
>>> --- a/lisp/ob-python.el
>>> +++ b/lisp/ob-python.el
>>> @@ -303,6 +303,10 @@ last statement in BODY, as eli
