Re: [Q] startup hook: How do I detect if the current buffer has been opened programmatically?
`find-file-hook` seems not to have false negatives, at least. Using `(window-live-p (get-buffer-window (current-buffer) 'visible))` has false negatives for me (i.e., it returns nil for some interactive buffers). Thanks, everyone. On Tue, Apr 9, 2024 at 11:06 PM Karthik Chikmagalur < karthikchikmaga...@gmail.com> wrote: > >> Org-mode occasionally opens files automatically, for instance, when > >> inserting or opening ID links, or during certain searches. I need to > >> determine if a buffer was opened programmatically or manually by the > user > >> within the startup hooks. This distinction is important because, e.g., I > >> want to automatically preview all LaTeX fragments if the buffer was > opened > >> by the user, but not if it was opened programmatically. > > > > AFAIK, there is no reliable way to do this. > > You may play around with `find-file-hook'. See `org-with-file-buffer' > > macro in org-macs.el (on main). > > A heuristic I use is to check if the window is visible. It's not > perfect but good enough for my use (which includes previewing LaTeX > fragments): > > (defun my/latex-preview-maybe () > (when (window-live-p (get-buffer-window (current-buffer))) > (org-latex-preview 'buffer) > (org-latex-preview-auto-mode 1))) > > (add-hook 'org-mode-hook #'my/latex-preview-maybe) > > Karthik >
[Q] startup hook: How do I detect if the current buffer has been opened programmatically?
Org-mode occasionally opens files automatically, for instance, when inserting or opening ID links, or during certain searches. I need to determine if a buffer was opened programmatically or manually by the user within the startup hooks. This distinction is important because, e.g., I want to automatically preview all LaTeX fragments if the buffer was opened by the user, but not if it was opened programmatically. PS: Please use reply-to-all.
Re: How do I link to a specific line in an org-babel block?
Thanks, that works great. Can these work with ID links, too? (`[[id:9bbb6468-2907-4e74-a4d1-2e391e33e0fe::...]]`) On Sun, Mar 17, 2024 at 4:47 PM Ihor Radchenko wrote: > Rudi C writes: > > > How do I link to a specific line in an org-babel block? > > a.org: > > #+begin_src emacs-lisp > (message "Hello world!") > (message "Hello other worlds!!!") ; (ref:greetworlds) > #+end_src > > b:org > [[./a.org::(greetworlds)]] > > See https://orgmode.org/manual/Literal-Examples.html > > > I tried using [[file:.../my.org::search-term]] , but this only works for > > jumping to a heading, not an arbitrary line. (It does work for non-org > > files.) > > That's because "search-term" is used for fuzzy search, which is limited > to headings by default. You can customize > `org-link-search-must-match-exact-headline' to change this. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> >
How do I link to a specific line in an org-babel block?
How do I link to a specific line in an org-babel block? I tried using [[file:.../my.org::search-term]] , but this only works for jumping to a heading, not an arbitrary line. (It does work for non-org files.) PS: Please use Reply to All.
Re: Forcing tab-width to be 8 makes using Python source blocks very difficult
Thanks, I don't have any problems now, so we can consider this closed. On Sat, Mar 16, 2024 at 2:32 PM Ihor Radchenko wrote: > Rudi C writes: > > > ... runs `evil-shift-right`, which > > indents the selected region by the `evil-shift-width` amount. > > `evil-shift-width` is set based on `tab-width`. > > Are you sure? > I am looking at > https://github.com/emacs-evil/evil/blob/master/evil-vars.el#L175 > and it appears that `evil-shift-width' has nothing to do with > `tab-width'. It is a customization with default value of 4. > > Also, do note that `evil-shift-width' in python code blocks may break > things when the code block itself is also indented. Org mode normally > discards this common indentation and takes care about distinguishing > (and not merging!) the tabs belonging to the code itself and the > tabs/spaces that are used to indent the whole code block: > > This whole code block is indented > #+begin_src python > def foo(): >if True: > return 1; > #+end_src > > Indentation in Org mode blocks can be tricky and generic editing > commands may not cut it. Org mode itself does the indentation using the > code block's major mode in a separate buffer in order to keep things > consistent. > > > ... I solved this specific > > problem by overriding `evil-shift-width` using a timer in an org-mode > hook. > > The delay introduced by the timer was necessary, as something kept > > overriding my settings. Perhaps the magic machinery that sets `tab-width` > > in the source blocks can also set `evil-shift-width`. The best-case > > scenario would be to have a list of variables that need to be set from > > their major-mode buffer in the source blocks. > > Why not simply setting `evil-shift-width' to 4? > > >> May you please provide a detailed example where 8 spaces causes issues? > > > > My lists are still indenting with 2 spaces, so I am not actually seeing 8 > > spaces. I have no idea why that is, but I very much like the 2-space > > indentation. > > > > ``` > > - a > > - b > > ``` > > > > I see 4 spaces in numerical lists, which again, I have no idea about: > > > > ``` > > 1. hi > >2. hi > > 3. hi > > ``` > > Org mode aligns child sub-lists with parent item text. So, "-" is right > below "a" and "2." is right below "hi". List depth is not defined by the > absolute number of spaces/tabs. > See https://orgmode.org/manual/Plain-Lists.html > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> >
Re: Principled Handling of Breaking Changes
> what other breaking changes caused problems for you? I remember these three: - `tab-width` - fontification in example blocks ( https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9daad41cc) - `org-fold-core-style` changing to `text-properties` (from `overlays`) broke custom code I had for coloring links. > Rather for Emacs in general. Would you be interested to post this > suggestion on emacs-devel list? That's also a good idea, but I don't remember being bitten by changes in emacs itself. It might help emacs adopt better defaults for new users though, as the backward compatibility of emacs makes its UX terrible for new users. > The very first section in https://orgmode.org/Changes.html lists > breaking and important changes. I don't care about "important changes" though, I just want the breaking changes ... I guess I should allocate the needed time for reading this anyway. Thanks. On Sat, Mar 16, 2024 at 1:48 PM Ihor Radchenko wrote: > Rudi C writes: > > > The recent upgrades to Org mode have been a source of great frustration > for > > me. Many of the configurations I had previously set up stopped working as > > intended, and it took me several days to properly identify the issues, > > debug them, and find suitable workarounds. > > Apart from the issue with tab-width you reported, what other breaking > changes caused problems for you? > > > To address this concern, I suggest that all breaking changes in Org mode > > follow a versioning scheme similar to Perl's `use v5.34.0;`. This could > be > > achieved by introducing an `org-defaults-use-version` variable, which > would > > be set to nil by default, allowing the package to adapt its behavior as > > necessary. However, when `org-defaults-use-version` is set to a specific > > version, all configuration variables should adhere to the behavior > > associated with that particular version. Furthermore, I propose that all > > breaking changes be accompanied by a configuration flag, enabling users > to > > disable the change if they so desire. By implementing these suggestions, > > users would be able to upgrade Org mode without the fear of spending > hours > > dealing with frustration and debugging. > > This might be a good idea, but not necessary for Org mode in particular. > Rather for Emacs in general. Would you be interested to post this > suggestion on emacs-devel list? > > > PS: Is there a changelog that ONLY lists breaking changes? There should > be > > one ... > > The very first section in https://orgmode.org/Changes.html lists > breaking and important changes. Users are free to limit reading the > changelog to this first section. It is not clear for me why we need a > separate page. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> >
Re: Forcing tab-width to be 8 makes using Python source blocks very difficult
`evil-org->` doesn't matter per se. It runs `evil-shift-right`, which indents the selected region by the `evil-shift-width` amount. `evil-shift-width` is set based on `tab-width`. I solved this specific problem by overriding `evil-shift-width` using a timer in an org-mode hook. The delay introduced by the timer was necessary, as something kept overriding my settings. Perhaps the magic machinery that sets `tab-width` in the source blocks can also set `evil-shift-width`. The best-case scenario would be to have a list of variables that need to be set from their major-mode buffer in the source blocks. > May you please provide a detailed example where 8 spaces causes issues? My lists are still indenting with 2 spaces, so I am not actually seeing 8 spaces. I have no idea why that is, but I very much like the 2-space indentation. ``` - a - b ``` I see 4 spaces in numerical lists, which again, I have no idea about: ``` 1. hi 2. hi 3. hi ``` So I don't see the effects of `tab-width` anywhere except in `evil-shift-width`, as far as I can see currently. On Sat, Mar 16, 2024 at 1:11 PM Ihor Radchenko wrote: > Rudi C writes: > > > Recently, a breaking change has been introduced in Org mode that sets the > > default tab-width to 8 spaces ( > > https://list.orgmode.org/orgmode/8734y5d2gs.fsf@localhost/). This change > > has made using Python source blocks in Org mode challenging, as > operations > > like `evil-org->` rely on `tab-width`, and Python code conventions > > typically use 4 spaces for indentation. > > May you please provide more details on what exactly "evil-org->" refers > to and what specific problems you encountered? > > > Moreover, using 8 spaces for indentation is generally unsuitable for > small > > laptop screens, where screen real estate is of utmost importance. > > May you please provide a detailed example where 8 spaces causes issues? > In source blocks specifically, we make sure that tab width visually > looks as in the corresponding source code buffer. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> >
Principled Handling of Breaking Changes
The recent upgrades to Org mode have been a source of great frustration for me. Many of the configurations I had previously set up stopped working as intended, and it took me several days to properly identify the issues, debug them, and find suitable workarounds. I believe that Org mode would benefit greatly from adopting a more principled approach to backward compatibility. To address this concern, I suggest that all breaking changes in Org mode follow a versioning scheme similar to Perl's `use v5.34.0;`. This could be achieved by introducing an `org-defaults-use-version` variable, which would be set to nil by default, allowing the package to adapt its behavior as necessary. However, when `org-defaults-use-version` is set to a specific version, all configuration variables should adhere to the behavior associated with that particular version. Furthermore, I propose that all breaking changes be accompanied by a configuration flag, enabling users to disable the change if they so desire. By implementing these suggestions, users would be able to upgrade Org mode without the fear of spending hours dealing with frustration and debugging. PS: Is there a changelog that ONLY lists breaking changes? There should be one ... PPS: Please use Reply to All when responding to this message.
Forcing tab-width to be 8 makes using Python source blocks very difficult
Recently, a breaking change has been introduced in Org mode that sets the default tab-width to 8 spaces ( https://list.orgmode.org/orgmode/8734y5d2gs.fsf@localhost/). This change has made using Python source blocks in Org mode challenging, as operations like `evil-org->` rely on `tab-width`, and Python code conventions typically use 4 spaces for indentation. Moreover, using 8 spaces for indentation is generally unsuitable for small laptop screens, where screen real estate is of utmost importance. Personally, I have been using a hook to force `tab-width` back to 4 spaces, but this has resulted in persistent warnings: ``` Error running timer 'org-indent-initialize-agent': (error "Tab width in Org files must be 8, not 4. Please adjust your 'tab-width' settings for Org mode.") [4 times] ``` In my opinion, the touted benefits of consistency brought by this breaking change do not justify the inconvenience it causes. I prefer customizable software that can be adapted to various situations, rather than enforcing uniform behavior. PS: Please use Reply to All.
Re: [FR] Add a way to mark an item in a checklist as failed
I also use the partial tick for partial completion of tasks, so I cannot abuse it for marking failed tasks. :wry_smile: On Mon, Feb 26, 2024 at 11:25 PM Sławomir Grochowski < slawomir.grochow...@gmail.com> wrote: > Hi Rudy, > > Rudi C writes: > > > The use case is that I use checklists to remember and track doing some > > important stuff at the start of the day; all the items are at first in a > > neutral/todo state. Some of them get done (`[X]`), but some of them fail > > during the day. For example, I have an item `- [ ] No sugar` which tracks > > whether I have consumed artificial sugar during the day. I like to be > able > > to mark this as failed. > > It's nice to hear that someone is having the same need for a failed state > in the checkbox. > > Currently, the case looks like this: > > A checkbox can be in one of the three states: > 1. not checked =[ ]= > 2. partially checked =[-]= > 3. checked =[X]= > > So I use this partially checked =[-]= state to mark it as failed. > But this 'partially checked' is for checkboxes that are in parent-child > relation. > For example: > > If some but not all child checkboxes are checked, the parent checkbox is > partially checked. > #+begin_example > - [-] call people > - [X] Peter > - [ ] Sarah > #+end_example > > And this 'partially checked' is set automatically. > > But you can set it manually for checkbox that is not in parent-child > relation. Just insert '-' manually or press 'C-c C-c (org-toggle-checkbox)' > with a double prefix argument 'C-u C-u'. > > Statics cookie works as expected. > > #+begin_example > - call people [1/2] > - [X] Peter > - [-] Sarah > #+end_example > > > I know this can be simulated using headings, but checklists are visually > > nicer and have cookies `[/]` etc. > > You can also use statistics cookie '[/]' in checkbox items list. > > For example: > #+begin_example > - [ ] call people [1/2] > - [X] Peter > - [ ] Sarah > #+end_example > > -- > Sławomir Grochowski >
[FR] Add a way to mark an item in a checklist as failed
I think currently there is no way to mark an item in a checklist as failed? I would like to have such an ability ... Something like: - [F] task x or: - [0] task x The use case is that I use checklists to remember and track doing some important stuff at the start of the day; all the items are at first in a neutral/todo state. Some of them get done (`[X]`), but some of them fail during the day. For example, I have an item `- [ ] No sugar` which tracks whether I have consumed artificial sugar during the day. I like to be able to mark this as failed. I know this can be simulated using headings, but checklists are visually nicer and have cookies `[/]` etc. PS: Please use reply to all, as I am not subscribed to the list.
Re: org-mode: example blocks are no longer syntax highlighted in emacs
Thanks! On Sun, Feb 25, 2024 at 1:30 PM Ihor Radchenko wrote: > Rudi C writes: > > > After upgrading to emacs 29.2 and org 9.7, my example blocks are no > longer > > syntax highlighted in emacs. They used to be syntax highlighted when I > > specified the block's language. Any ideas? > > This is an undocumented feature. > Yet, there is no reason to remote it. > I recovered example block fontification on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9daad41cc > > Fixed. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> >
Re: org-mode: example blocks are no longer syntax highlighted in emacs
e blocks
(add-text-properties
beg (if whole-blockline bol-after-beginline end-of-beginline)
'(face org-block-begin-line))
(unless (eq (char-after beg-of-endline) ?*)
(add-text-properties
beg-of-endline
(if whole-blockline
(let ((beg-of-next-line (1+ end-of-endline)))
(min (point-max) beg-of-next-line))
(min (point-max) end-of-endline))
'(face org-block-end-line)))
t))
((member dc1 '("+title:" "+subtitle:" "+author:" "+email:" "+date:"))
(org-remove-flyspell-overlays-in
(match-beginning 0)
(if (equal "+title:" dc1) (match-end 2) (match-end 0)))
(add-text-properties
beg (match-end 3)
(if (member (intern (substring dc1 1 -1)) org-hidden-keywords)
'(font-lock-fontified t invisible t)
'(font-lock-fontified t face org-document-info-keyword)))
(add-text-properties
(match-beginning 6) (min (point-max) (1+ (match-end 6)))
(if (string-equal dc1 "+title:")
'(font-lock-fontified t face org-document-title)
'(font-lock-fontified t face org-document-info
((string-prefix-p "+caption" dc1)
(org-remove-flyspell-overlays-in (match-end 2) (match-end 0))
(remove-text-properties (match-beginning 0) (match-end 0)
'(display t invisible t intangible t))
;; Handle short captions
(save-excursion
(forward-line 0)
(looking-at (rx (group (zero-or-more (any " \t"))
"#+caption"
(optional "[" (zero-or-more any) "]")
":")
(zero-or-more (any " \t")
(add-text-properties (line-beginning-position) (match-end 1)
'(font-lock-fontified t face org-meta-line))
(add-text-properties (match-end 0) (line-end-position)
'(font-lock-fontified t face org-block))
t)
((member dc3 '(" " ""))
;; Just a comment, the plus was not there
(org-remove-flyspell-overlays-in beg (match-end 0))
(add-text-properties
beg (match-end 0)
'(font-lock-fontified t face font-lock-comment-face)))
(t ;; Just any other in-buffer setting, but not indented
(org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
(remove-text-properties (match-beginning 0) (match-end 0)
'(display t invisible t intangible t))
(add-text-properties beg (match-end 0)
'(font-lock-fontified t face org-meta-line))
t))
(advice-add 'org-fontify-meta-lines-and-blocks-1 :override
#'night/org-fontify-meta-lines-and-blocks-1)
```
On Thu, Feb 22, 2024 at 7:17 PM Bruno Barbier wrote:
>
> Hi Rudi,
>
> Rudi C writes:
>
> > After upgrading to emacs 29.2 and org 9.7, my example blocks are no
> longer
> > syntax highlighted in emacs. They used to be syntax highlighted when I
> > specified the block's language. Any ideas?
> >
> > I use Doom, so it might have been a third-party feature.
> >
> > I know org-mode officially suggests that example blocks should not have
> > syntax highlighting, but I want it anyway. IMO `:eval never` is just not
> as
> > good,
>
> Why is `:eval never` not as good ? You don't have to write it on each
> code block; you may set it globally, per file, per headline, etc.
>
> See https://orgmode.org/manual/Using-Header-Arguments.html.
>
>
> > not to mention tools like `pandoc` also produce example blocks from
> > markdown source blocks.
>
> My version of pandoc generates org source blocks from markdown code
> blocks (pandoc 3.1.11.1).
>
> I'm not sure you'll get a better answer than this SE answer:
>
>
> https://emacs.stackexchange.com/questions/76466/how-do-i-get-syntax-highlighting-in-example-blocks-when-exporting-org-mode-to-ht
>
> I.e. "begin_example" is just not designed for source blocks. It
> may have worked by chance before.
>
> Hoping this helps,
>
> Bruno
>
>
org-mode: example blocks are no longer syntax highlighted in emacs
After upgrading to emacs 29.2 and org 9.7, my example blocks are no longer syntax highlighted in emacs. They used to be syntax highlighted when I specified the block's language. Any ideas? I use Doom, so it might have been a third-party feature. I know org-mode officially suggests that example blocks should not have syntax highlighting, but I want it anyway. IMO `:eval never` is just not as good, not to mention tools like `pandoc` also produce example blocks from markdown source blocks. Current Behavior: [![enter image description here][1]][1] Old (Correct) Behavior: [![enter image description here][2]][2] I have asked about this on SE: - [org-mode: example blocks are no longer syntax highlighted in emacs - Emacs Stack Exchange]( https://emacs.stackexchange.com/questions/80459/org-mode-example-blocks-are-no-longer-syntax-highlighted-in-emacs ) PS: Please use reply-to-all, I am not subscribed to the list. [1]: https://i.stack.imgur.com/U9II9.png [2]: https://i.stack.imgur.com/lNNtO.png
Re: [BUG] babel runs bash instead of zsh when sessions are used
I tried using emacs -Q and org 9.4, and you're right, this bug is nonexistent there. I am using Doom, so that's where the bug is coming from most probably. Unfortunately, things don't work without that bug either. The evaluation hangs indefinitely. I have used C-g to cancel them and take a look at the session buffer: ``` echo $HOME $0 ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org ❯ echo $HOME $0echo $HOME $0 echo 'org_babel_sh_eoe' echo 'org_babel_sh_eoe' ]2;echo $HOME $0 ]1;echo /Users/evar /usr/local/bin/zsh ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org ❯ echo 'org_babel_sh_eoe'echo 'org_babel_sh_eoe' ]2;echo 'org_babel_sh_eoe' ]1;echo org_babel_sh_eoe ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org ~/cellar/notes/org master ~/cellar/notes/org master* ❯ echo $HOME $0 echo $echo 'org_babel_sh_eoe' HOME $0 ]2;echo $HOME $0 ]1;echo /Users/evar /usr/local/bin/zsh ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ echo 'org_babel_sh_eoe'echo 'org_babel_sh_eoe' ]2;echo 'org_babel_sh_eoe' ]1;echo org_babel_sh_eoe ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ echo $HOME $0 echo $echo 'org_babel_sh_eoe' HOME $0 ]2;echo $HOME $0 ]1;echo /Users/evar /usr/local/bin/zsh ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ echo 'org_babel_sh_eoe'echo 'org_babel_sh_eoe' ]2;echo 'org_babel_sh_eoe' ]1;echo org_babel_sh_eoe ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ~/cellar/notes/org master* ❯ ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ echo hi echo ]2;echo hi ]1;echo hi ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ echo jk echo ]2;echo jk ]1;echo jk ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ echo $HOME $0 echo $echo 'org_babel_sh_eoe' HOME $0 ]2;echo $HOME $0 ]1;echo /Users/evar /usr/local/bin/zsh ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ echo 'org_babel_sh_eoe'echo 'org_babel_sh_eoe' ]2;echo 'org_babel_sh_eoe' ]1;echo org_babel_sh_eoe ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org master* ❯ exit exit ]2;exit ]1;exit Process shell finished echo $HOME $0 ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org ❯ echo $echo 'org_babel_sh_eoe' HOME $0 ]2;echo $HOME $0 ]1;echo /Users/evar /usr/local/bin/zsh ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org ❯ echo 'org_babel_sh_eoe'echo 'org_babel_sh_eoe' ]2;echo 'org_babel_sh_eoe' ]1;echo org_babel_sh_eoe ]2;evar@Fereidoons-MacBook-Pro: ~/cellar/notes/org ]1;..lar/notes/org ~/cellar/notes/org ~/cellar/notes/org master ~/cellar/notes/org master* ~/cellar/notes/org master* ❯ ``` On Sat, Aug 22, 2020 at 8:39 AM Kyle Meyer wrote: > Rudi C writes: > > > #+BEGIN_SRC zsh :session z1 > > echo $HOME $0 > > #+END_SRC > > > > #+RESULTS: > > : /Users/evar /bin/bash > > What version of Org are you using? > > I tried with both the latest release (9.3.7) and the current master > branch (220f2b0d9), using default configuration aside from > > (org-babel-do-load-languages > 'org-babel-load-languages > '((shell . t))) > > I see "/usr/bin/zsh" in both cases. >
[BUG] babel runs bash instead of zsh when sessions are used
#+BEGIN_SRC zsh :session z1 echo $HOME $0 #+END_SRC #+RESULTS: : /Users/evar /bin/bash As compared to: #+BEGIN_SRC zsh echo $HOME $0 #+END_SRC #+RESULTS: : /Users/evar zsh
