Re: [PATCH] Re: Q: org-export-headline-levels doc problem?

David Masterson writes: > Patch (from git format-patch) attached. > > From 651863abef42faaabf60d829503f0da9393cfc88 Mon Sep 17 00:00:00 2001 > From: David Masterson > Date: Wed, 30 Apr 2025 22:53:20 -0700 > Subject: [PATCH] Cleanup documentation on definition of "headline level" Thanks! Applied

Re: [PATCH] Re: Q: org-export-headline-levels doc problem?

David Masterson writes: > I'll put a new patch together tomorrow. Patch (from git format-patch) attached. >From 651863abef42faaabf60d829503f0da9393cfc88 Mon Sep 17 00:00:00 2001 From: David Masterson Date: Wed, 30 Apr 2025 22:53:20 -0700 Subject: [PATCH] Cleanup documentation on definition of

Re: [PATCH] Re: Q: org-export-headline-levels doc problem?

Ihor Radchenko writes: > David Masterson writes: > #+begin_example -,* Top level headline +,* Top (or first) level headline >>> >>> IMHO, this sounds like "top" and "first" are two different things. Maybe >>> it is my non-native English. >> >> In keeping with the rest of the exam

Re: [PATCH] Re: Q: org-export-headline-levels doc problem?

David Masterson writes: >>> #+begin_example >>> -,* Top level headline >>> +,* Top (or first) level headline >> >> IMHO, this sounds like "top" and "first" are two different things. Maybe >> it is my non-native English. > > In keeping with the rest of the example, how about: > > * First (AKA top

Re: [PATCH] Re: Q: org-export-headline-levels doc problem?

Ihor Radchenko writes: > David Masterson writes: > >> Ah, should've used the MIME commmand -- resending PATCH. > > This is a diff, not a patch :) Oops > A patch would also need to have a commit message. > See https://orgmode.org/worg/org-contribute.html#patches I'll look at that. >> #+begin

Re: [PATCH] Re: Q: org-export-headline-levels doc problem?

David Masterson writes: > Ah, should've used the MIME commmand -- resending PATCH. This is a diff, not a patch :) A patch would also need to have a commit message. See https://orgmode.org/worg/org-contribute.html#patches (Note that this is not a big deal as I can write commit message and format

[PATCH] Re: Q: org-export-headline-levels doc problem?

David Masterson writes: > Okay, I'll try to put together a patch for what we've talked about in a > few days. Ah, should've used the MIME commmand -- resending PATCH. diff --git a/doc/org-guide.org b/doc/org-guide.org index 205623525..ef5ad1b43 100644 --- a/doc/org-guide.org +++ b/doc/org-guide

[PATCH] was Re: Q: org-export-headline-levels doc problem?

David Masterson writes: > Okay, I'll try to put together a patch for what we've talked about in a > few days. Patch attached (did I do it right?) -- David Masterson --8<---cut here---start->8--- diff --git a/doc/org-guide.org b/doc/org-guide.org index 20562

Re: Q: org-export-headline-levels doc problem?

Ihor Radchenko writes: > David Masterson writes: > >> Also, I note the use of 'top level' in "2.1 Headlines" and would >> probably replace it with 'first level' to keep with the numbering >> scheme. > > I'd use "Top level (level 1)" because many docstrings use "top level" > terminology. Okay, I

Re: Q: org-export-headline-levels doc problem?

David Masterson writes: >> ** Is a top level headline when there are no other parent >> headlines > > Whoa. Not said in 2.1. Hmm. I was actually wrong. I think, most of the manual and code refer to top level strictly as to "level 1". > Also, I note the use of 'top level' in "2.1 Headlines"

Re: Q: org-export-headline-levels doc problem?

Ihor Radchenko writes: > David Masterson writes: > >> Also, I note the use of 'top level' in "2.1 Headlines" and would >> probably replace it with 'first level' to keep with the numbering >> scheme. > > No, because > > ** Is a top level headline when there are no other parent > headlines Wh

Re: Q: org-export-headline-levels doc problem?

David Masterson writes: >>> The issue is level -- is it (1) the number of stars in the header or do >>> the stars mean (2) 1=highest and N=lowest level. Since this is a >>> "programmer's editor", my tendency is toward #1 (level=star#) and avoid >>> the use of inferior/superior in favor of above/b

Re: Q: org-export-headline-levels doc problem?

Ihor Radchenko writes: > David Masterson writes: > >> 1. docstring mentions inferior without defining inferior. I think a >>natural mistake is to assume inferior is where the headline level is >>less than org-export-headline-levels (ie. < 3) >> 2. In "13.2 Export Setting", 'H' says "bel

Re: Q: org-export-headline-levels doc problem?

David Masterson writes: > 1. docstring mentions inferior without defining inferior. I think a >natural mistake is to assume inferior is where the headline level is >less than org-export-headline-levels (ie. < 3) > 2. In "13.2 Export Setting", 'H' says "below that level" -- again where >

Re: Q: org-export-headline-levels doc problem?

Ihor Radchenko writes: > David Masterson writes: > >> The documentation for 'org-export-headline-levels' seems problematic. I >> was going to suggest a patch, but thought I'd ask first. >> >> The problem is in the definition of 'level'.

Re: Q: org-export-headline-levels doc problem?

David Masterson writes: > The documentation for 'org-export-headline-levels' seems problematic. I > was going to suggest a patch, but thought I'd ask first. > > The problem is in the definition of 'level'. One could see a header > with one '*'

Q: org-export-headline-levels doc problem?

The documentation for 'org-export-headline-levels' seems problematic. I was going to suggest a patch, but thought I'd ask first. The problem is in the definition of 'level'. One could see a header with one '*' as "above" one with two. On the other

Re: Problem with finding css file with orgmode blogging setup

HTML head to locate it? That's what Rohit was getting at, I think. Apologies if this is obvious and your problem is a different one, but it's not clear from your reply. You say that a link to a remote stylesheet already on the web works fine, but a link to a local stylesheet doesn

Re: Problem with finding css file with orgmode blogging setup

But is your local stylesheet uploaded to the server, as it has to be for the stylesheet link in your HTML head to locate it? That's what Rohit was getting at, I think. Apologies if this is obvious and your problem is a different one, but it's not clear from your reply. You say that a

Re: Problem with finding css file with orgmode blogging setup

;; org-html-head "") org-html-head "https://cdn.jsdelivr.net/npm/@exampledev/new.css@1.1.2/new.min.css\"; />") works just fine. It only seems to have a problem when the css file is local. Any way to mitigate this? I initially thought that perhaps its an issu

Re: Problem with finding css file with orgmode blogging setup

Org-publish, by default, only processes org files. If you want to include CSS files, images, and other non-org content, you need to process them as attachments. So, for example, this is what I have: (setq org-publish-project-alist '(("website-orgfiles" :base-directory "$HOME/website_src/"

Problem with finding css file with orgmode blogging setup

Hi all, I'm trying to shift from my current blogging setup to using orgmode only with org-publish. I seem to be having trouble with org-publish finding my css file. The following is the file tree of my current situation: . ├── build.sh ├── css │   └── style.css ├── html │   └── index.html ├── M

Re: Tab problem in emacs 30.1

race: > nil > Please report this to Org mode mailing list (M-x org-submit-bug-report). > I have posted the error with org-submit-bug-report, but wondered if > there is a workaround, because this problem was pretty annoying. No workaround, but it turns out editorconfig was the c

Tab problem in emacs 30.1

org-submit-bug-report). I have posted the error with org-submit-bug-report, but wondered if there is a workaround, because this problem was pretty annoying. Thanks!

Re: [BUG] Imenu, problem at first pass [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

Christoph writes: > Short description: When called first imenu does not correctly process an > org-mode file. With the file's buffer killed and reloaded or with any > other org-mode-file after the first take, imenu works correctly. > > How to reproduce: Start emacs -q and load an org-mode file

Re: problem in sorting headings that start with timestamps

Uwe Brauer writes: >> You can sort alphabetically. But timestamp is considered a part of the >> headline. >> If you need something custom, provide custom key/comparison function for >> `org-sort-entries'. > > So you mean I should write a new sort function myself and use advice to > «connect» it

Re: problem in sorting headings that start with timestamps

> Uwe Brauer via "General discussions about Org-mode." > writes: > You can sort alphabetically. But timestamp is considered a part of the > headline. > If you need something custom, provide custom key/comparison function for > `org-sort-entries'. So you mean I should write a new sort function

Re: problem in sorting headings that start with timestamps

Uwe Brauer via "General discussions about Org-mode." writes: > I am not sure this is a feature or a bug. > Consider the following > > --8<---cut here---start->8--- > * Test 1 > ** <2025-02-08 09:46> First > ** <2025-02-08 09:51> All > --8<---cut h

[BUG] Imenu, problem at first pass [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

n the expected way on that file. + Any org-file I tested showed the same problem. Here is a simple one: * One ** One a * Two * Three * Four Emacs : GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43,

problem in sorting headings that start with timestamps

Hi I am not sure this is a feature or a bug. Consider the following --8<---cut here---start->8--- * Test 1 ** <2025-02-08 09:46> First ** <2025-02-08 09:51> All --8<---cut here---end--->8--- If I run `org-sort` the head

Re: Problem installing Org using the Emacs packaging system

Ihor Radchenko writes: > I think that we should: > 1. Remove this from Org 9.7 manual (bugfix) > 2. Add a note that the one-liner requires Emacs 30 in the Org 9.8-re >manual (main) Fixed, on main, and on bugfix. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9f5fce73e9 https

Re: Problem installing Org using the Emacs packaging system

Ihor Radchenko writes on Sun 22 Dec 2024 09:19: > May you please elaborate what you mean? The command from the manual is > indeed not working in Emacs 29. It just was a bit funny to me when you said "Maybe forgot to test on older Emacs", considering that 29.4 is the last version that one can d

Re: Problem installing Org using the Emacs packaging system

alain.coch...@unistra.fr writes: > > I suspect that it is some kind of bug in Emacs 29. It seems that the > > command is only properly working in Emacs 30. > ... > Thanks a lot for the feedback. I hope Emacs 29 (the current official > version, right?) is not too old already :-) May you please

Re: Problem installing Org using the Emacs packaging system

Ihor Radchenko writes on Mon 16 Dec 2024 19:08: > I suspect that it is some kind of bug in Emacs 29. It seems that the > command is only properly working in Emacs 30. > > I am not sure how I overlooked the problem. Maybe forgot to test things > on older Emacs somehow. >

Re: Problem installing Org using the Emacs packaging system

alain.coch...@unistra.fr writes: > Hello. About 2 weeks ago I already sent the following message. I just > realized that I must have failed in removing all the 'In-Reply-To:' and > similar fields, so it is part of another thread. I was thinking this might > be the reason why it was ignored and

Re: Problem installing Org using the Emacs packaging system

;org))" > > I have used the emacs batch command above on a number of machines but it > always failed (see below), so I guess I am doing something wrong, but what? I suspect that it is some kind of bug in Emacs 29. It seems that the command is only properly working in Emacs 30. I am n

Problem installing Org using the Emacs packaging system

Hello. About 2 weeks ago I already sent the following message. I just realized that I must have failed in removing all the 'In-Reply-To:' and similar fields, so it is part of another thread. I was thinking this might be the reason why it was ignored and I dare submit it again. I apologize for

Problem installing Org using the Emacs packaging system

Hello. An excerpt of the page https://orgmode.org/manual/Installation.html is Using Emacs packaging system Recent Emacs distributions include a packaging system which lets you install Elisp libraries. You can install Org from the “package menu”, with M-x list-packages. See Packag

Re: Org v9.7.7 org-assert-version problem?

David Masterson writes: > I just tried to package-install org-9.7.7 and I'm getting a problem with > org-assert-version. It looks like a conflict between the system > installed version of 9.5.5 and my ~/.emacs.d/elpa install of 9.7.7. The > main problem (so far) seems to be o

Org v9.7.7 org-assert-version problem?

I just tried to package-install org-9.7.7 and I'm getting a problem with org-assert-version. It looks like a conflict between the system installed version of 9.5.5 and my ~/.emacs.d/elpa install of 9.7.7. The main problem (so far) seems to be org-assert-version -- even Hyperbole seems

Re: bash source code block: problem after ssh commands

Max Nikulin writes: >> May you submit a patch for the WORG docs that documents this caveat? > > 9733cc41 2024-07-03 17:57:15 +0700 ob-doc-shell.org: Warn concerning > optional stdin Thanks! -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at

Re: bash source code block: problem after ssh commands

On 01/07/2024 23:01, Ihor Radchenko wrote: Max Nikulin writes: bug#71081 is about shell-command-on-region, not about mailcap. (and pty may actually not matter there, because Windows' cmd.exe is not even POSIX-compient...) Of course, there are no pty's on Windows and cmd.exe is a special case.

Re: bash source code block: problem after ssh commands

Max Nikulin writes: >> I guess not on Windows (bug#71081). But otherwise I agree. > > It was for starting mailcap viewer and Windows was not an issue. bug#71081 is about shell-command-on-region, not about mailcap. (and pty may actually not matter there, because Windows' cmd.exe is not even POSIX

Re: bash source code block: problem after ssh commands

On 01/07/2024 16:51, Ihor Radchenko wrote: Max Nikulin writes: My experience is that it is not easy to start a process without a tty in Emacs. Eli will object. I guess not on Windows (bug#71081). But otherwise I agree. It was for starting mailcap viewer and Windows was not an issue. Altho

Re: bash source code block: problem after ssh commands

Max Nikulin writes: I do not see a great benefit of re-implementing session support via actual terminal. (I think we agree here). >>> >>> `shell' and so comint allocates "actual" pty. >> >> Are you sure? > ... > 123454 pts/0Sl 0:16 \_ emacs -Q > 125104 pts/4Ss+0:00

Re: bash source code block: problem after ssh commands

On 30/06/2024 23:42, Ihor Radchenko wrote: Max Nikulin writes: On 30/06/2024 22:28, Ihor Radchenko wrote: I do not see a great benefit of re-implementing session support via actual terminal. (I think we agree here). `shell' and so comint allocates "actual" pty. Are you sure? ps wf PI

Re: bash source code block: problem after ssh commands

Max Nikulin writes: > On 30/06/2024 22:28, Ihor Radchenko wrote: >> I do not see a great benefit of re-implementing session support via >> actual terminal. (I think we agree here). > > `shell' and so comint allocates "actual" pty. Are you sure? -- Ihor Radchenko // yantar92, Org mode contribut

Re: bash source code block: problem after ssh commands

On 30/06/2024 22:28, Ihor Radchenko wrote: I do not see a great benefit of re-implementing session support via actual terminal. (I think we agree here). `shell' and so comint allocates "actual" pty. I expect that bracketed paste is just some escape sequences delimiting pasted text (fcntl calls

Re: bash source code block: problem after ssh commands

Max Nikulin writes: > ... ob-shell might offer variants for sessions: dumb > stdin, source a temporary file, or bracketed paste. Anything besides > stdin (with its confusing differences from interactive sessions) is > almost certainly requires shell-specific code. And `shell' is likely not >

Re: bash source code block: problem after ssh commands

On 30/06/2024 18:06, Ihor Radchenko wrote: Max Nikulin writes: https://debbugs.gnu.org/67259 Notice that the report is for *interactive* sessions. Org babel sessions are not so interactive. They are to maintain state, not to interact with users directly... You are not right. We have legitima

Re: bash source code block: problem after ssh commands

Max Nikulin writes: > https://debbugs.gnu.org/67259 > > Notice that the report is for *interactive* sessions. Org babel sessions > are not so interactive. They are to maintain state, not to interact with > users directly... You are not right. We have legitimate cases when people can switch to

Re: bash source code block: problem after ssh commands

On 18/11/2023 22:51, Matt wrote: On Fri, 17 Nov 2023 23:07:57 +0100 Matt wrote --- The second claim has nothing to do with Org Babel. I was able to confirm it and provide the steps to reproduce. I think it would make sense to report it upstream and let them decide if it's expected beh

Re: bash source code block: problem after ssh commands

On 18/11/2023 15:04, Max Nikulin wrote: On 17/11/2023 17:17, Ihor Radchenko wrote: I see bash vs. dash difference with public key authorization, so no need for password prompts. I have not figured out how to construct an example without ssh since this command *may* read stdin, but does not do

Re: strange export problem with a file: link

On Saturday, 20 Apr 2024 at 12:25, Ihor Radchenko wrote: > Fixed, on main. Thank you! -- : Eric S Fraga, with org release_9.6.23-1320-g1be2f9 in Emacs 30.0.50

Re: strange export problem with a file: link

"Fraga, Eric" writes: > I have a file that consists of these three lines: > > --8<---cut here---start->8--- > #+begin_src latex :results file raw :exports results :file function.png > \[ y = f(x) \] > #+end_src > --8<---cut here---end---

Re: strange export problem with a file: link

On Thursday, 18 Apr 2024 at 21:46, Max Nikulin wrote: > Sorry that I was not clear enough. Org code should be fixed. For a > while you may revert that commit in your local repository. Ah, okay! Thank you. I'll leave my documents as they are then. :-) -- : Eric S Fraga, with org release_9.6.23-

Re: strange export problem with a file: link

On 18/04/2024 21:37, Fraga, Eric wrote: On Thursday, 18 Apr 2024 at 19:08, Max Nikulin wrote: It is a side effect of 72b0e9ff0 2024-02-05 16:39:05 +0100 Ihor Radchenko: org-export: Do not strip link type by default during export I have now checked the ORG-NEWS file, which I probably should ha

Re: strange export problem with a file: link

moved to using MathML instead for what I need doing right now so the problem is no longer an issue for me (at the moment). However, although I'm sure there was a good reason for the change, it has broken quite a few of my documents! Not complaining; just noting. Living at the edge does carry a p

Re: strange export problem with a file: link

On 18/04/2024 17:50, Fraga, Eric wrote: #+begin_src latex :results file raw :exports results :file function.png \[ y = f(x) \] #+end_src org-odt-export-to-odt: OpenDocument export failed: Opening input file: No such file or directory, /tmp/file:function.png It is a side effect of 72b0e9ff0 2

strange export problem with a file: link

Hello all, I have a file that consists of these three lines: --8<---cut here---start->8--- #+begin_src latex :results file raw :exports results :file function.png \[ y = f(x) \] #+end_src --8<---cut here---end--->8--- With "

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

Uwe Brauer via "General discussions about Org-mode." writes: > Ok understood, but then, who can I add hlines to table that does not > possess any? #+name: test | 1 | 2 | | 3 | 4 | #+name: add-hlines #+begin_src emacs-lisp :var table='(1 2) :results value (let (result) (when table (unless

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

>>> "IR" == Ihor Radchenko writes: > Uwe Brauer via "General discussions about Org-mode." > writes: >> #+NAME: many-cols >> | a | b | c | >> | d | e | f | >> | g | h | i | >> >> #+NAME: hline-please >> #+BEGIN_SRC python :var tab=many-cols :hlines yes >> return tab >> #+END_SRC >> >> #+RESULT

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

Uwe Brauer via "General discussions about Org-mode." writes: > #+NAME: many-cols > | a | b | c | > | d | e | f | > | g | h | i | > > #+NAME: hline-please > #+BEGIN_SRC python :var tab=many-cols :hlines yes > return tab > #+END_SRC > > #+RESULTS: hline-please > | a | b | c | > | d | e | f | > | g

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

> Uwe Brauer via "General discussions about Org-mode." > writes: > No, this is because you customized `org-src-preserve-indentation' or > `org-edit-src-content-indentation', while the provided example only > works with default indentation settings. Python is sensitive to > whitespace and your c

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

Uwe Brauer via "General discussions about Org-mode." writes: > I tried to use the examples of the above link > ... > #+NAME: no-hline > #+BEGIN_SRC python :var tab=many-cols :hlines no > return tab > #+END_SRC > > Now already the first failed: > , > | > | File "", line 4 > | return t

problem with https://orgmode.org/manual/Results-of-Evaluation.html

t;, line 4 | return tab | ^ | IndentationError: unexpected indent | [ Babel evaluation exited with code 1 ] `---- Problem could be that which python on my Ubuntu system returns Python 2.7.12 I presume the code is for python 3.X. How can I tell org to use that one? Regards Uwe Brauer --

Re: bash source code block: problem after ssh commands

On 22/11/2023 02:01, Bruno Barbier wrote: Ihor Radchenko writes: __By default__, Org should produce more expected behavior - what users would get from running a script file rather than from redirecting stdin. We can optionally leave the stdin redirection as an option to be used by the users who

Re: bash source code block: problem after ssh commands

Ihor Radchenko writes: > Bruno Barbier writes: > >> 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

Re: Non-emacs shell (Re: bash source code block: problem after ssh commands)

Hi Max, Max Nikulin writes: > On 17/11/2023 22:47, Bruno Barbier wrote: >> 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, >

Non-emacs shell (Re: bash source code block: problem after ssh commands)

On 17/11/2023 22:47, Bruno Barbier wrote: 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

Re: bash source code block: problem after ssh commands

On 18/11/2023 17:43, Ihor Radchenko wrote: I still see it as a bug - what Org mode does to run the shell blocks is not what users expect. _By default_, we _should_ produce more expected behavior. A shell without unexpected behavior is neither POSIX nor a descendant shell like BASH https://my

Re: bash source code block: problem after ssh commands

On Fri, 17 Nov 2023 23:07:57 +0100 Matt wrote --- > The second claim has nothing to do with Org Babel. I was able to confirm it > and provide the steps to reproduce. I think it would make sense to report > it upstream and let them decide if it's expected behavior. I'm still hap

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

Matt writes: > Evaluating the following > > #+name: /tmp/test.sh > #+begin_src bash :results output > ssh localhost "echo foo>foo_file" > echo "bar" | tee /tmp/bar.txt > #+end_src > > does exactly what > > cat /tmp/test.sh | bash -c bash > > does. Both create a file "foo_file" containing "f

Re: bash source code block: problem after ssh commands

Max Nikulin writes: > ... > I have not expected this difference. > > dash reads a block from stdin (whole file in this case) and interprets > commands. > > BASH reads just the ssh command and executes it. SSH reads "echo done" > from stdin, so when control is returned to bash, stdin is exhauste

Re: bash source code block: problem after ssh commands

Bruno Barbier writes: >> 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

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

Matt writes: > On Sat, 18 Nov 2023 09:54:46 +0100 Bruno Barbier > > It's still not clear to me if this is "what Emacs does". However, that's the > best I could come up with. > > Evaluating the following > > #+name: /tmp/test.sh > #+begin_src bash :results output > ssh localhost "ec

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

On Sat, 18 Nov 2023 09:54:46 +0100 Bruno Barbier > But, you're right. To be safe, from now on, I'll use: > > cat /tmp/test.sh | bash -c bash It's still not clear to me if this is "what Emacs does". However, that's the best I could come up with. Evaluating the following

Re: bash source code block: problem after ssh commands

To clarify a previous typo I made. Everything I've written was also done using: 1. emacs -q 2. C-x b "*scratch*" 3. M-x org-mode 4. Execute #+begin_src emacs-lisp :results none (org-babel-do-load-languages 'org-babel-load-languages '((shell . t))) #+end_src This corresponds to Org mode v

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

Matt writes: > On Sat, 18 Nov 2023 09:29:56 +0100 Bruno Barbier > > > IIUC, what Max is saying is that you should not concentrate on > > *that specific command* because that command doesn't do what you think > > it does. > > Cool, it sounds like we're agreed (albeit for different reaso

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

On Sat, 18 Nov 2023 09:29:56 +0100 Bruno Barbier > IIUC, what Max is saying is that you should not concentrate on > *that specific command* because that command doesn't do what you think > it does. Cool, it sounds like we're agreed (albeit for different reasons). > To reproduce,

Re: bash source code block: problem after ssh commands

Max Nikulin writes: > On 25/10/2023 18:17, alain.coch...@unistra.fr wrote: >> By contrast, it works with this one: >> >> #+begin_src bash :results output >> sshcoch...@fruc.u-strasbg.fr "echo foo>foo_file" ; echo "bar" >> #+end_src > > What about > > #+begin_src bash :results ou

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

Matt writes: > On Sat, 18 Nov 2023 04:11:03 +0100 Max Nikulin wrote --- > > > > bash -c bash /tmp/two-lines.sh > > > > 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.

Re: bash source code block: problem after ssh commands

Hi Matt, Thanks this summary and for working on this! Just a few comments/corrections about some specific points, hoping it might help. Matt writes: > 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 b

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

On Sat, 18 Nov 2023 04:11:03 +0100 Max Nikulin wrote --- > > bash -c bash /tmp/two-lines.sh > > 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

Re: bash source code block: problem after ssh commands

On 25/10/2023 18:17, alain.coch...@unistra.fr wrote: By contrast, it works with this one: #+begin_src bash :results output sshcoch...@fruc.u-strasbg.fr "echo foo>foo_file" ; echo "bar" #+end_src What about #+begin_src bash :results output ssh coch...@fruc.u-strasbg.fr "echo

Re: bash source code block: problem after ssh commands

On 17/11/2023 17:17, Ihor Radchenko wrote: I was only able to reproduce your problem with ssh asking a password. We are discussing the reproduced case. I see bash vs. dash difference with public key authorization, so no need for password prompts. I have not figured out how to construct an

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

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

Re: bash source code block: problem after ssh commands

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.

Re: bash source code block: problem after ssh commands

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 origi

Re: bash source code block: problem after ssh commands

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 fo

Re: bash source code block: problem after ssh commands

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 conside

Re: bash source code block: problem after ssh commands

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"

Re: bash source code block: problem after ssh commands

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. &g

Re: bash source code block: problem after ssh commands

alaincochard alain.coch...@unistra.fr writes: > Yes. (So I think that explains the 'no' above.) 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 >

Re: bash source code block: problem after ssh commands

echo "bar" > #+end_src > > Clearly, the ssh line is intended to happen on the remote server. > Was the echo "bar" intended to happen locally? Yes. (So I think that explains the 'no' above.) Then I'm confused about your confusion... Anyway, this

Re: bash source code block: problem after ssh commands

On Thu, 16 Nov 2023 10:30:59 +0100 Ihor Radchenko wrote --- > Or we can make use of TRAMP as we usually do to access remote > environment. IMHO, it is more reliable as TRAMP takes care about > arranging all the Elisp FS interaction to work on remote system. Agreed. Also, I wasn't

Re: bash source code block: problem after ssh commands

Matt writes: > So, rather than start a comint and then ssh from there, it's possible to let > Emacs start the subprocess, manage the ssh connection, and just read that. > Emacs makes a buffer from a network stream by calling start-process` using > `shell-file-name`. `org-babel-shell-initiali

Re: bash source code block: problem after ssh commands

On Wed, 15 Nov 2023 17:32:19 +0100 Matt wrote --- > (let ((buff "*localhost-process-buffer*")) > (switch-to-buffer >(make-comint-in-buffer > "localhost-process" > buff > "ssh" > nil > (format "%s@localhost" (getenv "USER") It looks like the way thi

Re: bash source code block: problem after ssh commands

I was poking around, learning how sessions are started. Basically, `shell` creates the comint buffer using `make-comint-in-buffer`. What I find interesting is that `make-comint-in-buffer` can also create a comint buffer from a network stream: (let ((buff "*localhost-process-buffer*")) (sw

Re: bash source code block: problem after ssh commands

On Thu, 09 Nov 2023 13:13:36 +0100 Ihor Radchenko wrote --- > A bigger problem is that errors *Org Babel Error > Output* are not clickable: Interesting. > So, it looks like we may need an alternative `org-babel-eval' function > that works with script files rath

  1   2   3   4   5   6   7   8   9   10   >