Re: [PATCH] LSP support in org-src buffers
On Tue, November 22 2022 02:23, Ihor Radchenko wrote:
> It looks like you have done something very close to what we are
> discussing. Would you be interested to create a patch against Org core
> instead of relying on advises?
That would be wonderful! That code has some ugly hacks, some of which
gave me a little bit of headache when I was using it, but I think that
it could become something polished and well-behaved, specially taking
inspiration on Karthik's approach to it as well (I can, from a quick
glance, see some improvements that could be made. And who knows maybe we
make it work even with noweb...). Were you thinking of having a
=:context {yes|no}= option on src blocks?
Also, I will have more free time to work on it starting on the second
week of December. Before that I'll be incredibly busy, unfortunately.
Best regards,
--
João Pedro de A. Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Fix the confusing "result silenced" message
Rudolf Adamkovič writes: > Agreed. Please, see the updated patch. Oops, I dropped an important word in the commit message. Please see the third version of patch below. Rudy >From c3896ead3e46d705bc4fbee143df87016fe70389 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= Date: Thu, 24 Nov 2022 22:10:29 +0100 Subject: [PATCH] ob-core: Remove the confusing "result silenced" message * lisp/ob-core.el (org-babel-execute-src-block): Do not say "result silenced" after executing the source blocks with `:results none' to avoid confusion with `:results silent'. --- lisp/ob-core.el | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 5f679a5e9..7abe62022 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -849,8 +849,7 @@ guess will be made." (setq result (org-babel-ref-resolve post)) (when file (setq result-params (remove "file" result-params)) - (if (member "none" result-params) - (message "result silenced") + (unless (member "none" result-params) (org-babel-insert-result result result-params info new-hash lang (time-subtract (current-time) exec-start-time -- 2.38.1 -- "Programming reliably -- must be an activity of an undeniably mathematical nature […] You see, mathematics is about thinking, and doing mathematics is always trying to think as well as possible." -- Edsger W. Dijkstra, 1981 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: Fix the confusing "result silenced" message
Ihor Radchenko writes: > Hmm. Maybe not displaying message at all? Agreed. Please, see the updated patch. Rudy >From 0c04ca6dec740a5aba7d1934a4d59578ea98ed4e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= Date: Thu, 24 Nov 2022 22:10:29 +0100 Subject: [PATCH] ob-core: Remove the confusing "result silenced" message * lisp/ob-core.el (org-babel-execute-src-block): Do not say "silenced" after executing the source blocks with `:results none' to avoid confusion with `:results silent'. --- lisp/ob-core.el | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 5f679a5e9..7abe62022 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -849,8 +849,7 @@ guess will be made." (setq result (org-babel-ref-resolve post)) (when file (setq result-params (remove "file" result-params)) - (if (member "none" result-params) - (message "result silenced") + (unless (member "none" result-params) (org-babel-insert-result result result-params info new-hash lang (time-subtract (current-time) exec-start-time -- 2.38.1 -- "Programming reliably -- must be an activity of an undeniably mathematical nature […] You see, mathematics is about thinking, and doing mathematics is always trying to think as well as possible." -- Edsger W. Dijkstra, 1981 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages
Ihor Radchenko writes:
> Contributions for other languages are also welcome.
Slovak:
("sk" "Súbor" "L" "Časová značka" "Záhlavie" "Čas" "VŠETKO" "Celkový
čas" "Čas súboru" "Časový súhrn pre")
Rudy
--
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932
Rudolf Adamkovič [he/him]
Studenohorská 25
84103 Bratislava
Slovakia
Re: Adding #+name to result block in babel
Den tis 29 nov. 2022 kl 06:20 skrev Bill Burdick : > Hi Henrik, > > On Tue, Nov 29, 2022 at 2:11 AM Henrik Frisk wrote: > >> Hi, >> >> Maybe I'm missing something obvious but is it possible to have a name be >> added to the result block such as running: >> >> #+begin_src shell >> echo "Hello" >> #+end_src >> >> results in >> >> #+RESULTS: >> #+name: my_result >> : Hello >> >> Thank you! >> > > Name your block, like this: > #+name: my_result > #+begin_src sh > echo hello > #+end_src > > When you evaluate it, you'll get this: > > #+name: my_result > #+begin_src sh > echo hello > #+end_src > > #+RESULTS: my_result > : hello > > Then you can use the result like this: > > #+begin_src sh :var value=my_result > echo $value > #+end_src > > #+RESULTS: > : hello > Thank you! That was good to be reminded of, but I should have been more explicit in my first email. I'm working with a language (sclang) that for various reasons does not have support for variables in this way. The only option I have to include the results from one block is by using a noweb referens: #+begin_src shell echo "Hello" #+end_src #+RESULTS: #+name: my_result : Hello #+begin_src sclang :noweb yes <> #+end_src
Re: [PATCH] Explain how to end a buffer narrowing.
On Saturday, November 26th, 2022 at 04:26, Ihor Radchenko wrote: > yuvallangerontheroad yuvallangeronther...@proton.me writes: > > > > Extra [...] are redundant. > > > Please test the patch before submitting. > > > > Sorry. Removed redundant brackets. > > > Thanks. :) > It is also a good idea to add quotes around the command key. See the > example in 25.3 Substituting Key Bindings in Documentation > (I am honestly not sure how important quoting is, but let's better > follow the Elisp manual). Hopefully done. > Also, please make the commit message more concrete. > > Maybe something like > > org: Mention how to widen in docstrings of the commands that do narrowing Hopefully done. > Finally, please follow the commit message format as described in > https://orgmode.org/worg/org-contribute.html#commit-messages > In particular, add the changelog entries and TINYCHANGE cookie (I assume > that you don't have FSF copyright assignment). Hopefully done. Please review.From f53b141bd2057898f2606e884cf1a094876696c2 Mon Sep 17 00:00:00 2001 From: Yuval Langer Date: Fri, 25 Nov 2022 16:40:50 +0200 Subject: [PATCH] lisp/org.el: Mention how to widen in docstrings of commands that do narrowing lisp/org.el: (org-narrow-to-subtree, org-toggle-narrow-to-subtree, org-narrow-to-block, org-narrow-to-element) Mention how to widen in docstrings of commands that do narrowing. TINYCHANGE --- lisp/org.el | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 472e87b9b..2a1024c89 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7220,7 +7220,8 @@ If yes, remember the marker and the distance to BEG." (setq org-markers-to-move nil)) (defun org-narrow-to-subtree (&optional element) - "Narrow buffer to the current subtree." + "Narrow buffer to the current subtree. +Use the command `\\[widen]' to see the whole buffer again." (interactive) (if (org-element--cache-active-p) (let* ((heading (org-element-lineage @@ -7242,7 +7243,8 @@ If yes, remember the marker and the distance to BEG." (point (defun org-toggle-narrow-to-subtree () - "Narrow to the subtree at point or widen a narrowed buffer." + "Narrow to the subtree at point or widen a narrowed buffer. +Use the command `\\[widen]' to see the whole buffer again." (interactive) (if (buffer-narrowed-p) (progn (widen) (message "Buffer widen")) @@ -7250,7 +7252,8 @@ If yes, remember the marker and the distance to BEG." (message "Buffer narrowed to current subtree"))) (defun org-narrow-to-block () - "Narrow buffer to the current block." + "Narrow buffer to the current block. +Use the command `\\[widen]' to see the whole buffer again." (interactive) (let* ((case-fold-search t) (blockp (org-between-regexps-p "^[ \t]*#\\+begin_.*" @@ -21162,7 +21165,8 @@ ones already marked." (goto-char (org-element-property :begin element)) (defun org-narrow-to-element () - "Narrow buffer to current element." + "Narrow buffer to current element. +Use the command `\\[widen]' to see the whole buffer again." (interactive) (let ((elem (org-element-at-point))) (cond -- 2.30.2
Re: test-org-table/sort-lines: Failing test on macOS
On 26/11/2022 09:05, Ihor Radchenko wrote: Max Nikulin writes: This sounds like something to be adapted to Emacs upstream. I suggested to change `string-collate-lessp' fallback behaviour to use `downcase' when IGNORE-CASE is non-nil. See my last message in bug#59275. I do not share Eli's position "all or nothing". I prefer graceful degradation and best result achievable with reasonable efforts. However either the reason is performance or correctness, both variants are against modification of `string-collate-lessp'. I still think that Org will benefit from a compatibility wrapper with `downcase'. The only additional consideration is that compare function should be configurable. If a user access same files from Linux and macOS then it may be really annoying to get different order of entries in agenda. For most of Linux users it is better to use more smart `string-collate-lessp'. Some care is required to sort entries obtained from multiple buffers in predictable environment (locale, case conversion table).
Bug org-cycke fails after "replace-string" is
Attached is an example 1. Open all headings etc. show the contents then Collapse all headings 2. Cycle First Heading to show its content 3. Cycle Second Heading to show only the subheadings, but not the content of each subheading 3. Cycle Subheading B, to show its content. 4. go to point-min and then replace "Charlie" with a string of your choice After the replace string is executed, I cannot cycle Subheading A or Subheading B Likewise if all headings are collapsed and I execute a replace-string "Chas" I cannot org-cycle through "First heading" and "Second heading", but I can cycle "Third heading" If you add a Fourth heading with the string to be replaced, you cannot cycle through any headings if a string.is replaced in the fourth heading I just pulled Org 9.6 from git. However I noticed this behavior a while ago but cannot recall exactly when. I searched the list but no luck. Org mode version 9.6 (release_9.6 @ /usr/local/share/org-mode/lisp/) GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.16.0) of 2022-11-25 Charlie Millar* First heading Chas * Second heading ** Subheading A Chas ** Subheading B Chaz ** Subheading C Chat * Third heading some more text
Re: Mistake in LaTeX syntax not detected, strange pdf generated
Same problem here -- seeing mistakes in latex/pdf generation. i On Tue, Nov 29, 2022 at 1:27 PM Dominik Schrempf wrote: > > Hi! > > I wanted to chime in here, because sometimes I do have a similar > problem. > > Whenever I export to LaTeX + PDF, it is pretty difficult to see if the > compilation actually worked (or not). This is, because the compilation > happens asynchronously, and so, the message about the compilation > results in the modeling vanishes fast. > > Usually, I open the LaTeX compilation buffer manually, but I think it > would be great if Org Mode was a bit more verbose about the result of > the compilation (not the actual export). Not sure how this would work > though... (Not very helpful, I know). > > Thank you! > Dominik > > alain.coch...@unistra.fr writes: > > > alain.coch...@unistra.fr writes on Tue 29 Nov 2022 12:33: > > > > > I would expect that the mistake be reported in the *Org PDF LaTeX > > > Output* Compilation buffer. So far, what I saw in that buffer was > > > essentially what shows up when I run 'pdflatex org_generated_file.tex' > > > from a terminal. Not this time: the "regular" pdflatex compiles > > > correctly, not the pdflatex that Org uses internally. > > > > > I thought what Org did was simply run pdflatex+bibtex+etc. just as > > > what one would do manually, but apparently there is some difference. > > > > Hum, I correct myself here: the compilation buffer does report the > > mistake (I hadn't looked at it). Also, the manual compilation with > > > >pdflatex org_generated_file.tex > > > > does generate the same pdf provided that I hit many times. > > Also, I see that the message > > > >PDF file produced with errors. > > > > appears in the *Messages* buffer. > > > > So perhaps Org could display this message in the minibuffer instead of > > > >Running /usr/bin/xdg-open /home/cochard/Org/debug3.pdf...done > > > > which leads to the impression that the compilation is OK. > -- -- A man must either resolve to point out nothing new or to become a slave to defend it. -- Sir Isaac Newton
Re: Mistake in LaTeX syntax not detected, strange pdf generated
Hi! I wanted to chime in here, because sometimes I do have a similar problem. Whenever I export to LaTeX + PDF, it is pretty difficult to see if the compilation actually worked (or not). This is, because the compilation happens asynchronously, and so, the message about the compilation results in the modeling vanishes fast. Usually, I open the LaTeX compilation buffer manually, but I think it would be great if Org Mode was a bit more verbose about the result of the compilation (not the actual export). Not sure how this would work though... (Not very helpful, I know). Thank you! Dominik alain.coch...@unistra.fr writes: > alain.coch...@unistra.fr writes on Tue 29 Nov 2022 12:33: > > > I would expect that the mistake be reported in the *Org PDF LaTeX > > Output* Compilation buffer. So far, what I saw in that buffer was > > essentially what shows up when I run 'pdflatex org_generated_file.tex' > > from a terminal. Not this time: the "regular" pdflatex compiles > > correctly, not the pdflatex that Org uses internally. > > > I thought what Org did was simply run pdflatex+bibtex+etc. just as > > what one would do manually, but apparently there is some difference. > > Hum, I correct myself here: the compilation buffer does report the > mistake (I hadn't looked at it). Also, the manual compilation with > >pdflatex org_generated_file.tex > > does generate the same pdf provided that I hit many times. > Also, I see that the message > >PDF file produced with errors. > > appears in the *Messages* buffer. > > So perhaps Org could display this message in the minibuffer instead of > >Running /usr/bin/xdg-open /home/cochard/Org/debug3.pdf...done > > which leads to the impression that the compilation is OK.
Re: Mistake in LaTeX syntax not detected, strange pdf generated
alain.coch...@unistra.fr writes on Tue 29 Nov 2022 12:33: > I would expect that the mistake be reported in the *Org PDF LaTeX > Output* Compilation buffer. So far, what I saw in that buffer was > essentially what shows up when I run 'pdflatex org_generated_file.tex' > from a terminal. Not this time: the "regular" pdflatex compiles > correctly, not the pdflatex that Org uses internally. > I thought what Org did was simply run pdflatex+bibtex+etc. just as > what one would do manually, but apparently there is some difference. Hum, I correct myself here: the compilation buffer does report the mistake (I hadn't looked at it). Also, the manual compilation with pdflatex org_generated_file.tex does generate the same pdf provided that I hit many times. Also, I see that the message PDF file produced with errors. appears in the *Messages* buffer. So perhaps Org could display this message in the minibuffer instead of Running /usr/bin/xdg-open /home/cochard/Org/debug3.pdf...done which leads to the impression that the compilation is OK. -- 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: Mistake in LaTeX syntax not detected, strange pdf generated
Fraga, Eric writes on Tue 29 Nov 2022 11:16: > I think having the expectation that org will parse within LaTeX > blocks may be a little unrealistic. Org, no, but (pdf)latex yes. > But, also, what should it do? I would expect that the mistake be reported in the *Org PDF LaTeX Output* Compilation buffer. So far, what I saw in that buffer was essentially what shows up when I run 'pdflatex org_generated_file.tex' from a terminal. Not this time: the "regular" pdflatex compiles correctly, not the pdflatex that Org uses internally. I thought what Org did was simply run pdflatex+bibtex+etc. just as what one would do manually, but apparently there is some difference. -- 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: Mistake in LaTeX syntax not detected, strange pdf generated
On Tuesday, 29 Nov 2022 at 12:11, alain.coch...@unistra.fr wrote: > Yes. My point was that Org did not spot this mistake and generates > something ridiculous. Ah, okay. I think having the expectation that org will parse within LaTeX blocks may be a little unrealistic. But, also, what should it do? I would not want org to start manipulating my LaTeX code. -- : Eric S Fraga, with org release_9.5.5-1068-gbd4681 in Emacs 29.0.50
Re: Mistake in LaTeX syntax not detected, strange pdf generated
Fraga, Eric writes on Tue 29 Nov 2022 10:40:
> You cannot use a subscript within \text{}.
Yes. My point was that Org did not spot this mistake and generates
something ridiculous.
--
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: Mistake in LaTeX syntax not detected, strange pdf generated
On Tuesday, 29 Nov 2022 at 11:28, alain.coch...@unistra.fr wrote:
>#+begin_export latex
>\[
> \text{a_b}
>\]
>#+end_export
You cannot use a subscript within \text{}. Try \text{a}_{\text{b}}
instead?
--
: Eric S Fraga, with org release_9.5.5-1068-gbd4681 in Emacs 29.0.50
Mistake in LaTeX syntax not detected, strange pdf generated
I have file debug3.org which contains only
* strange
#+begin_export latex
\[
\text{a_b}
\]
#+end_export
Upon latex export (C-c C-e l o) the generated pdf shows a sequence of
4 "a subscript b" in a row (with 3 font sizes).
Result observed with various Org versions including
Org mode version 9.4.4 (release_9.4.4 @
/usr/share/emacs/27.2/lisp/org/)
with 'emacs -Q'.
NB: If I run pdflatex on the .tex created:
pdflatex debug3.tex
I get
! Missing $ inserted.
$
l.31 \text{a_b}
and no pdf is generated.
--
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 ]
