Re: [BUG] error on org-add-note? [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

brizly  writes:

> i was in a java-project and [alt]-x "org-add-note", when the
> warnings apperes an i should file bug, so here i am.
>
> (I was not using this function for a long time, perhaps there is
> missing a config for a folder?)

Do I understand correctly that you tried to run M-x org-add-note from a
non-Org file?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] JUSTIFYRIGHT does not justify to the right any more in ASCII export [9.7-pre (release_9.6.11-927-g819cd7 @ /home/grfz/src/org-mode/lisp/)]

[Ihor Radchenko]

Gregor Zattler  writes:

> left or right
> ...
>
> while correctly this:
>
>
>  left or right
>
> with
> Org mode version 9.6.10 (release_9.6.10 @ 
> /home/grfz/src/emacs-master--078cfe807295038fa321c9297e24de5145065622--2023-11-02T00-38+01-00/lisp/org/)
> on the very same Emacs.
>
>
> Git bisecting found
> [69383dfc240a3be08cfb57d4f1d8727bbb0df902] org-ascii--current-justification: 
> Use `org-element-lineage-map'
>
> but I'm not sure this makes sense since the org-version
> numbers went backwards when doing it.

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0740e62df

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] error on org-add-note? [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[brizly]

Am Freitag, dem 17.11.2023 um 08:19 + schrieb Ihor Radchenko:
> brizly  writes:
> 
> > i was in a java-project and [alt]-x "org-add-note", when the
> > warnings apperes an i should file bug, so here i am.
> > 
> > (I was not using this function for a long time, perhaps there is
> > missing a config for a folder?)
> 
> Do I understand correctly that you tried to run M-x org-add-note from
> a
> non-Org file?
> 

That is correct, perhaps my fault, but surprising to get a stacktrace?

Meanwhile i recognized it was the wrong function for what i wanted to
do. I was searching for "org-capture", which works on any file in my
homefolder, as it creates relative links in the matching file
"notes.org" as configured in my setting.

So, long story short, perhaps this is not a (relevant) bug, i just used
it the wrong way.

--
Greetings
brizly

Re: [BUG] error on org-add-note? [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

brizly  writes:

>> Do I understand correctly that you tried to run M-x org-add-note from
>> a
>> non-Org file?
>> 
>
> That is correct, perhaps my fault, but surprising to get a stacktrace?

`org-add-note' assumes that it is called from an Org buffer. So, as
you may expect, all kinds of unexpected things might happen when it is
called outside Org buffer.

Starting from Emacs 28, we are able to limit commands to show up only in
Org buffers (if necessary). However, we still support Emacs 27 that does
not have that feature, and I know no good way to add mode declaration to
commands without breaking Emacs 27. So, for now, we should leave the
situation as is, until Emacs 30 is release when we can drop Emacs 27
support.

I will leave this open until then.
Confirmed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: bash source code block: problem after ssh commands

[Ihor Radchenko]

Matt  writes:

> Thank you for clarifying.
>
>  > Anyway, this gives me the opportunity to come back to the question of
>  > whether or not there is a problem with emacs itself (like some people
>  > here thought), and if some message should be sent to some emacs list.
>  > Again my argument was that the 2 commands copy/yank'ed in an emacs
>  > terminal don't work as expected, while they do if the same is done in
>  > an X terminal.
>
> Okay, I follow you now.
>
> Yes, I agree with what others have said, it's related to Emacs (probably 
> comint-mode).  It happens with M-x shell and *not* with M-x eshell.   It's 
> hard to reproduce with M-x term because term-char-mode doesn't allow 
> copy-paste.  M-x with term-line-mode doesn' t print "bar".

I think that I need to clarify here.
We are talking about two different things:
1. Bash src block without session
2. Bash src block with session

The original report used bash src blocks _without_ session.
In such scenario, comint (and M-x shell) is not relevant.
Org simply uses `process-file' with INFILE argument.
This is equivalent of someone opening __X shell__, and literally typing

  ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file"
  echo "bar"

In the scenario described in the report, when ssh asks for password, it
is equivalent to

$ ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file"
Password: 

This has nothing to do with Emacs comint and this is also not a bug in
Emacs - we use INFILE argument, that is equivalent to the above as _per
docstring_. So, Org mode is simply not using `process-file' function as
users expect - instead of executing a bash script, we emulate
interactive user input to bash.

(Side note: for someone aware about these details, it is possible to do
something like

#+begin_src bash
ssh remote-server;
<>
#+end_src

or, as a demo

#+begin_src bash
read x;
value2
echo "We just read \"$x\"";
#+end_src

#+RESULTS:
: We just read "value2"

)

Another case is (2), when we do use comint is session is what we
discussed in
https://list.orgmode.org/orgmode/cal1eyujntgbxy6a794qm7ptbxh3diu1af6oays7clf3kobs...@mail.gmail.com/
I guess we can try to report this as a bug, especially since it also
manifests itself when comint is used interactively.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Suggestion: User-contributed use-cases on orgmode.org ?

[Ihor Radchenko]

David Masterson  writes:

>> FYI, WORG is listed in "Repositories" right at https://sr.ht/~bzg/org/
>
> I see no mention of "~bzg/org" in worg-about.
> ... I think my lack of
> experience for many years is showing -- I didn't think to click on the
> ~bzg/worg link which would've told me about ~bzg/org.  I assumed the
> link was just telling me what to put on 'git clone'.  Perhaps that
> should be explained a little more in worg-about.

I guess that you are confused about

It is made of numerous .org files that you can clone from 
https://git.sr.ht/~bzg/worg.

Would it help if we change it to

It is made of numerous .org files from https://git.sr.ht/~bzg/worg.

?
  
>> Or we might consider https://git.sr.ht/~bzg/woof to automatically update
>> WORG pages for appropriately marked mailing list threads.
>
> Hmm. That sounds most interesting becuase it command line driven.
> Perhaps a new mailing list should be created for this?

I don't think so. We intentionally keep Org mailing list as a single
place for all the discussions, not just Org development.
AFAIU, Bastien is firmly into this policy (CCing him in case if I
misunderstood).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: bash source code block: problem after ssh commands

[Alain . Cochard]

Ihor Radchenko writes on Fri 17 Nov 2023 09:22:

 > I think that I need to clarify here.

Thank you.

Well, thank you for _trying_: most of the discussion in this thread is
way beyond my pay grade.

At the most basic user level (i.e., non lisp aware), why is it not
necessarily a bug if "something" does the expected in an X terminal
but not in an emacs terminal?  I think Matt and I (and others) are on
the same page here, and he already essentially drafted the bug report
I would have sent (only better).

What also confuses me is that it seems to me that, in the minimum
working example, you consider the ssh command and the read command as
equivalent.  But I don't even enter the password when using ssh...


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: bash source code block: problem after ssh commands

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> Ihor Radchenko writes on Fri 17 Nov 2023 09:22:
>
>  > I think that I need to clarify here.
>
> Thank you.
>
> Well, thank you for _trying_: most of the discussion in this thread is
> way beyond my pay grade.

My reply was to Matthew, the current ob-shell maintainer.
If you want, you need to examine ob-shell (`org-babel-sh-evaluate') and
ob-eval (`org-babel-eval') code, and try to step through the code using
debugger to understand technical details in thread better.

> At the most basic user level (i.e., non lisp aware), why is it not
> necessarily a bug if "something" does the expected in an X terminal
> but not in an emacs terminal?  I think Matt and I (and others) are on
> the same page here, and he already essentially drafted the bug report
> I would have sent (only better).

WRT M-x shell, feel free to submit a bug report. I mostly pointed that
the problem with M-x shell is not the problem you originally ran to. It
is a different problem (also, we ran into it in the past).

> What also confuses me is that it seems to me that, in the minimum
> working example, you consider the ssh command and the read command as
> equivalent.  But I don't even enter the password when using ssh...

I was only able to reproduce your problem with ssh asking a password.
We are discussing the reproduced case.

If you see problems with
   #+begin_src bash :results output
   ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file"
   echo "bar"
   #+end_src
even when ssh does not ask for a password, please provide more detailed
reproducer that we can replicate locally without guessing your ssh config.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] org-element-at-point warning for org agenda [9.7-pre (release_9.6.11-928-g0740e6 @ /Users/wob/.emacs.d/straight/build/org/)]

[Will O'Brien]

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

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

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


I think the recent addition of an error check (downgraded to warning) is
erroneously triggering for some aspects of agenda view.  Should be
reproducible with this org file

--8<---cut here---start->8---
* Item
<2023-11-17 Fri 09:00-09:15 +1w>
--8<---cut here---end--->8---


If above is saved as /tmp/bug.org and agenda command set as follows I
get the warning.  Don't *think* it should trigger.

--8<---cut here---start->8---
  (setopt org-agenda-custom-commands
'(("b" "Bug Agenda"
 ((agenda "Schedule"
  ((org-agenda-prefix-format "%b"
 ((org-agenda-files (quote ("/tmp/bug.org")))
--8<---cut here---end--->8---

Warning:

--8<---cut here---start->8---
⛔ Warning (emacs): ‘org-element-at-point’ cannot be used in non-Org buffer 
# (org-agenda-mode)
--8<---cut here---end--->8---

Have recreated with `emacs -q`. Happy to try to help dig in.

Emacs  : GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin22.5.0, NS 
appkit-2299.60 Version 13.4 (Build 22F66))
 of 2023-09-06
Package: Org mode version 9.7-pre (release_9.6.11-928-g0740e6 @ 
/Users/wob/.emacs.d/straight/build/org/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function 'org-bibtex-headline-format-default
 org-agenda-custom-commands '(("b" "Bug Agenda" ((agenda "Schedule" 
((org-agenda-prefix-format "%b"
   ((org-agenda-files '("/tmp/bug.org"
  )
 org-agenda-files '("/Users/wob/orgx/inbox.org" "/Users/wob/orgx/hazy/work.org")
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines 
org-cycle-optimize-window-after-visibility-change
  org-cycle-display-inline-images)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-fold-show-all append local] 5]
 #[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
 org-persist-directory 
"/var/folders/dz/yn13k0ts6n183573mjyvrpbmgn/T/org-persist-pvoHhT"
 org-fold-core-isearch-open-function 'org-fold--isearch-reveal
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete 
org-attach-complete-link) ("id" :follow org-id-open)
   ("eww" :follow org-eww-open :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store 
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store org-irc-store-link 
:export org-irc-export)
   ("info" :follow org-info-open :export org-info-export 
:store org-info-store-link :insert-description
org-info-description-as-command)
   ("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
  

Re: [BUG] org-element-at-point warning for org agenda [9.7-pre (release_9.6.11-928-g0740e6 @ /Users/wob/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Will O'Brien  writes:

> I think the recent addition of an error check (downgraded to warning) is
> erroneously triggering for some aspects of agenda view.  Should be
> reproducible with this org file ...

That trigger was valid - a fault in logic.
Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a1fa52197

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-element-at-point warning for org agenda [9.7-pre (release_9.6.11-928-g0740e6 @ /Users/wob/.emacs.d/straight/build/org/)]

[O'Brien, Will]

On Fri, Nov 17 2023 at 13:06, Ihor Radchenko  wrote:

> Will O'Brien  writes:
>
>> I think the recent addition of an error check (downgraded to warning) is
>> erroneously triggering for some aspects of agenda view.  Should be
>> reproducible with this org file ...
>
> That trigger was valid - a fault in logic.
> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a1fa52197

Thanks for the lightning fast response.  Works a charm.

best
--
will

Re: bash source code block: problem after ssh commands

[Leo Butler]

On Fri, Nov 17 2023, Ihor Radchenko  wrote:

> I was only able to reproduce your problem with ssh asking a password.
> We are discussing the reproduced case.
>
> If you see problems with
>
>#+begin_src bash :results output
>ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file"
>echo "bar"
>#+end_src
>
> even when ssh does not ask for a password, please provide more detailed
> reproducer that we can replicate locally without guessing your ssh config.

I think you are confused, Ihor. The bug was confirmed here:

https://list.orgmode.org/orgmode/87bkcmlor9@t14.reltub.ca/

I mis-identified the culprit; you corrected me by pointing out the bug
is in `process-file'. And you confirmed the bug:

https://list.orgmode.org/orgmode/87fs1xbis1.fsf@localhost/

Russell Adams and I suggested ssh-specific work-arounds that prevent ssh
from grabbing stdin (either -n or -f).

Leo

Re: bash source code block: problem after ssh commands

[Bruno Barbier]

Hi Matt, Ihor, Alain,

Ihor Radchenko  writes:

> alain.coch...@unistra.fr writes:
>
>> At the most basic user level (i.e., non lisp aware), why is it not
>> necessarily a bug if "something" does the expected in an X terminal
>> but not in an emacs terminal?  I think Matt and I (and others) are on
>> the same page here, and he already essentially drafted the bug report
>> I would have sent (only better).
>
> WRT M-x shell, feel free to submit a bug report. I mostly pointed that
> the problem with M-x shell is not the problem you originally ran to. It
> is a different problem (also, we ran into it in the past).

FWIW, M-x shell differs from what a plain terminal is doing (xterm, in
my case), but, I do prefer 'M-x shell' behavior: it allows me to copy
multiple lines, getting the same results as when I type them manually,
or copy them line by line. My xterm doesn't seem to allow me to do that.


>> What also confuses me is that it seems to me that, in the minimum
>> working example, you consider the ssh command and the read command as
>> equivalent.  But I don't even enter the password when using ssh...

I've introduced the 'read' example, as a simpler way to modify the
standard input and get the same kind of "unexpected" results, without
relying on SSH.  It seems that I have only caused confusion, sorry about
that.

IIUC, the OP example is not working because SSH is modifying the
standard input (with or without passwords).

> I was only able to reproduce your problem with ssh asking a password.
> We are discussing the reproduced case.
>
> If you see problems with
>#+begin_src bash :results output
>ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file"
>echo "bar"
>#+end_src
>
> even when ssh does not ask for a password, please provide more detailed
> reproducer that we can replicate locally without guessing your ssh config.
>

I'm not the OP, but, my SSH is configured to work without passwords and
SSH is still consuming lines from standard input:

#+begin_src bash :results output
ssh phone echo "remote"
echo "local"
#+end_src

#+RESULTS:
: remote

It looks like it is a known SSH "feature" (see
https://unix.stackexchange.com/a/688024):

#+begin_src bash :results output
seq 100 | (ssh phone sleep 1; wc -l)
#+end_src

#+RESULTS:
: 675173

Same block, but asking SSH to not use stdin (using '-n' as mentionned in
this thread):

#+begin_src bash :results output
seq 100 | (ssh -n phone sleep 1; wc -l)
#+end_src

#+RESULTS:
: 100

IMHO, what ob-shell is doing today seems a valid way of evaluating
source blocks (and it seems to have been like that for a long time).  It
should probably be documented somewhere, so that users know how to write
their source blocks, or switch to another way, like adding a :cmdline
parameter as mentionned in this thread.


Hoping I didn't increase the confusion again,
:-)


Bruno




> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Suggestion: User-contributed use-cases on orgmode.org ?

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> I see no mention of "~bzg/org" in worg-about.
>
> Would it help if we change it to
>
> It is made of numerous .org files from https://git.sr.ht/~bzg/worg.
>
> ?

Perhaps:

Follow the link https://git.sr.ht/~bzg/worg for information (including
cloning) on the WORG Git repository at SourceHut (https://sourcehut.org).

>>> Or we might consider https://git.sr.ht/~bzg/woof to automatically update
>>> WORG pages for appropriately marked mailing list threads.
>>
>> Hmm. That sounds most interesting becuase it's command line driven.
>> Perhaps a new mailing list should be created for this?
>
> I don't think so. We intentionally keep Org mailing list as a single
> place for all the discussions, not just Org development.  AFAIU,
> Bastien is firmly into this policy (CCing him in case if I
> misunderstood).

Ok.  There might be enough capability in WOOF to sort thru the mailing
list properly.

-- 
David Masterson

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> I think that the most reasonable approach to fontify ANSI sequences will
> be the following:
>
> 1. We will consider ANSI within (a) all greater elements and lesser
>elements that have RESULTS affiliated keyword (indicating that they
>are result of code block evaluation); (b) otherwise, just lesser
>elements, like paragraph, src block, example block, export block,
>etc., but _not_ tables (c) otherwise, within verbatim-like objects,
>like code, export-snippet, inline-src-block, table-cell, verbatim.
>
>The three groups above should be declared via variables, so that
>users can tweak them as necessary.
>
> 2. If ANSI sequence is encountered inside a verbatim-like object and we
>did not see any ANSI sequences within parent element or greater
>element, limit ANSI triggers to the current object.
>
>Example:
>
>#+RESULTS:
>Lorem upsum =valor=. Some more text.
>
>(only "valor" will be affected)
>
> 3. If the first ANSI sequence is encountered inside element and outside
>verbatim-like object, the rest of the element is affected, including
>all the objects.
>
>Example:
>
>#+RESULTS:
>Lorem upsum =valor=. Some more text.
>
>(the first ANSI affects everything, including verbatim; the second
>ANSI also affects everything)
>
> 4. If the first ANSI sequence is encountered inside greater element with
>RESULTS affiliated keyword, all the lesser elements inside will be
>affected.
>
>Example:
>
>#+RESULTS:
>:drawer:
>Lorem upsum =valor=. Some more text.
>
>Another paragraph inside drawer.
>:end:
>
>(everything down to :end: is affected)
>
>or
>
>#+RESULTS:
>- list
>- one
>- two
>- three
>

Hello Ihor,

Attached is the updated version of the patch.  I've also attached an
updated file that I've been using for testing the feature.

What I have is essentially a function, org-fontify-ansi-sequences, that
scans the buffer for an ANSI sequence and depending on the
element-context processes the region that should be affected according
to the rules you stated (see above).  The org-fontify-ansi-sequences-1
function scans the buffer element-wise and processes the appropriate
regions of the elements, even if no sequences appear in those regions,
according to an ansi-context.  This is to support the fourth rule you
mentioned.

Note that modifications to highlighted regions hasn't really been
considered so if you have a scenario like

#+RESULTS:
- Paragraph one
- Paragraph two
  Line 3

where the sequence affects everything down to "Line 3" and you make a
modification to line three, the fontification due to the sequence
disappears on that line.

Also note that lesser elements contained in greater elements that
don't have a RESULTS keyword are handled at the lesser element level
so if you have something like

#+begin_center
Paragraph one.

Paragraph two.
#+end_center

It would be the same as if you just had the paragraphs without the
greater element.

Please review the code and let me know what you think and how you
think we can move forward on this feature.

Thanks in advance.

#+TITLE: Test

Section 1

* Greater elements
:PROPERTIES:
:CUSTOM_ID: 123
:END:

#+begin_center
Inner paragraph one

Inner paragraph two
#+end_center

:drawer:
Inner paragraph one

Inner paragraph two
:end:

#+BEGIN: dblock1 :scope subtree :maxlevel 2
- Item 1
- Item 2
  - Item 3
- Item 4
#+END:

[fn:1] Footnote definition

*** TODO Inline task 1
Inner contents
*** END

*** TODO Inline task 2

- Paragraph one
- Paragraph two
  - Paragraph three
- Paragraph four

| cell 1 | cell 2 |
| cell 3   | cell 4 |

#+begin_quote
open 
#+end_quote

should not be highlighted

#+begin_quote
close 
#+end_quote

* Lesser elements
:PROPERTIES:
:DESCRIPTION: value
:END:

#+CALL: fn(str="text")

# Line one

#+begin_comment
Line one
Line two
#+end_comment

%%(diary-anniversary 10 31 1948) Arthur's Birthday

#+begin_example
Line one
Line two
#+end_example

#+begin_export latex
Line one
Line two
#+end_export

: Line one
: Line two

#+AUTHOR: First Last

\begin{quote}
Line one
Line two
\end{quote}

Paragraph one
Line two

#+begin_src python
for x in y:
print(x + "test")
#+end_src

* Object contexts

=verbatim= one

Lorem upsum =valor=. Some more text.

This is a paragraph src_python{return "testing"} {{{results(=testing=)}}} with
multiple inline src_python{return 5*4} {{{results(=20=)}}} source blocks.

An inline source block src_python{return 1+ 1 without an
end.  src_python{return "testing"}.

 Paragraph =one=

_underlined  text *bold  text * underlined  text_

_underlined [43

Re: bash source code block: problem after ssh commands

[Matt]

  On Fri, 17 Nov 2023 10:20:28 +0100  Ihor Radchenko  wrote --- 

 > This has nothing to do with Emacs comint and this is also not a bug in
 > Emacs 

Ihor, there were two claims made in the original report.  I was referring to 
Claim 2.  That deals with M-x shell and therefore comint-mode.

Regarding Claim 1:

- Can anyone verify Claim 1?
- Is anyone else unable to verify Claim 1 (like me)?
- What versions are people using?
  + M-x org-version
  + M-x emacs-version

I'm running Org mode version 9.7-pre (release_9.6.10-903-g9183e3.dirty @ 
/home/ahab/.emacs.d/straight/build/org/) on GNU Emacs 29.1 (build 1, 
x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0).

* The original report has two claims:
** Claim 1.
The following block is expected to write a remote file called "foo_file" with 
contents "foo" as well as give "bar" as the result.

#+begin_src bash :results output
ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file"
echo "bar"
#+end_src

The reported behavior is that "foo_file" is created with "foo" (with "foo" is 
not stated, but implied) and "bar" is *not* given as the result.

** Claim 2.
Copying and pasting the two lines from the first claim into a terminal like 
xfce4-terminal executes the ssh line as expected and outputs the result of the 
second line.  It was noted that this does not happen with M-x shell.

* Comments about the claims:
** Comment 1.
tl;dr I can't reproduce the claim that "bar" is *not* the result.  The result 
is "bar" for me.

The exact "expected behavior" for a shell block is a little fuzzy.  According 
to my analysis (given below), what Alain reports (remote file and no "bar") is 
the "expected" behavior.  What I see (no remote file and "bar") is actually 
"unexpected".

I used the following to test the claim:

#+begin_src bash :results output
ssh localhost "echo foo>foo_file"
echo "bar"
#+end_src

I am unable to reproduce the reported behavior (of "bar" not returning).  
Instead, I get an ssh-askpass permission denied error, foo_file is not created, 
and "bar" is given as the result.  I do not see anywhere in the thread that the 
original claim was reproduced.

The thread preceded something like follows.

Leo Butler suggested two work arounds:

- add the -f to the ssh command
- add a semi-colon and line continuation to the first line.

Russell Adams suggested another work around:

- add -n to the ssh command

Ihor identified that a non-session call does something like the following 
command:

bash -c bash /tmp/temp-file-with-source-block-code.sh

where

- /tmp/temp-file-with-source-block-code -
ssh localhost "echo foo>foo_file"
echo "bar" | tee /tmp/bar.txt
-

The second line (significantly different from the original report) pipes the 
echo result to stdout and to a file, bar.txt.  Writing to a file allows us to 
confirm if that line was executed.

Ihor suggested that

bash -c bash /tmp/temp-file-with-source-block-code.sh

does not run the second line because an interactive password prompt is 
displayed by ssh.  The reasoning is that the prompt hangs the process while 
waiting for input and the second line never runs.  Indeed, running the command 
does not produce /tmp/bar.txt.

Ihor is correct about prompts messing with shell blocks (this is not the first 
time he's seen this).  However, the way it's stated does not demonstrate it. 
This is because Emacs does *not* make a call like

bash -c bash /tmp/temp-file-with-source-block-code.sh

Alain responded by pointing out that

bash -c bash /tmp/temp-file-with-source-block-code.sh

does not execute the first line.  This is true.  Consider calling

bash -c bash /tmp/two-lines.sh

where

-- /tmp/two-lines.sh --
echo "first" > /tmp/first.txt
echo "second" > /tmm/second.txt
---

Neither first.txt or second.txt are created.

Max Nikulin interjected with a helpful reminder that Bash scripting is a 
snakepit of footguns.  (What Max said is more than that and interesting.  I 
skip it here because it depends on the form of the call.)

Before trying to untangle what a given Bash command does, we need to be sure 
what command is actually called.  Unfortunately, there's not a clear Bash 
command corresponding to how Emacs makes the call.

What happens goes something like this:

1. The Lisp function process-file is called with PROGRAM "bash", INFILE a path 
to a temp file containing the source block code, and ARGS ("-c" "bash")
2. This information is passed to DEFUN ("call-process"), a Lisp object 
implemented in C
3. DEFUN ("call-process") forwards this information to the C function 
call_process
4. call_process calls emacs_spawn
5. emacs_spawn creates a subprocess

A lot of cleaning and setup happens which is dependent on the system (GNU, 
Window, Darwin, etc.).  There's a call to openp which looks for the executable. 
 An emacs_pipe is set up (

Re: [BUG] JUSTIFYRIGHT does not justify to the right any more in ASCII export [9.7-pre (release_9.6.11-927-g819cd7 @ /home/grfz/src/org-mode/lisp/)]

[Gregor Zattler]

Hi Ihor, org-mode community,
* Ihor Radchenko  [2023-11-17; 08:32 GMT]:
> Gregor Zattler  writes:
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0740e62df

thank you very much, it now again works for me.

Ciao; Gregor

Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands)

[Max Nikulin]

On 18/11/2023 05:07, Matt wrote:

Consider calling

 bash -c bash /tmp/two-lines.sh


Matt, could you, please, describe what this command should do 
accordingly to your expectations?


From my point of view it was a plain mistake in attempts to simulate 
the issue outside of Emacs. There is no point to concentrate on this 
command. I tried to explain that it is incorrect usage of "-c" shell 
option and what is the actual effect of this call, but I seems I failed.


Hints:
- Try this command in a regular shell prompt outside of Emacs
- Try "echo $$" before and after this command
- Try it with a script having a clear side effect and check whether it 
is produced, e.g. "date >>/tmp/touch-tmp-file.txt"