How do I set attr_latex for the babel-block outputs?

[Vladimir Nikishkin]

And the same question: I am drawing pictures for my book suing TikZ and babel.

This is my code (almost and mwe):

#+name: figure-1-2
#+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 300
#+header: :fit yes :headers '("\\usepackage{tikz}")
#+header: :buffer on
#+begin_src latex :results value graphics file :exports both :file
figure-1-2-tree.png
\usetikzlibrary{trees}
\begin{tikzpicture}[color=gray]
\node {sqrt} % root
  child { node {sqrt-iter}
  child[sibling distance=5cm] { node{ good-enough }
  child[sibling distance=2cm] { node { square } }
  child[sibling distance=2cm] { node { abs } } }
  child { node{ improve }
  child { node { average } } } };
\end{tikzpicture}
#+end_src

The #+RESULTS has a link
[file:figure-1-2-tree.png]]
below it.

However, after export the picture is rendered \textwidth-wide.

If I manually set
#+attr_latex: :width 8cm above the #+RESULTS, it is displayed as
expected, but If I recompute the picture, it is pasted above my
manually added attr line.

As far as I understand, the "graphics" Format is essentially
org-mode-text. Is it possible to set proper width attributes?


-- 
Yours sincerely, Vladimir Nikishkin

Re: bug#34891: 25.2; ORG-PUBLISH-FIND-DATE should not use Creation/Publish date (#+DATE:) in file as a modification timestamp.

[David Trudgett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thank you, Nicolas and Bastien,

Apologies for the late reply.

The publishing functionality now appears to be working as it should. I
haven't changed anything myself, except to update Org. It's possible I
misdiagnosed the cause of the problem.

In any case, should the issue arise again, I will take another look at
it and let you all know.

Thanks for your attention on this one. It's really appreciated!

Kind regards,
David

- -- 
Key fingerprint: 1365 2C8F F9F1 188D C064 FB60 9F79 BB01 EEBF 48E6

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEs/RVZpgrZ1SbH+KGVnbxJ50cKpEFAl7K3RsACgkQVnbxJ50c
KpGIqQ/9FG/AHuo/H74OiMXbCsuUvAbsKo0HpmWP+pK1gDksx4WJ9fbRLd0nUzM6
xeDXo6dBBcFOYkt9u5HyOjC9Xq4x5z4leg6WuC18bGT9uTHVCIfwAyyMR+tAxwvG
kfJdSvfWs4UV3vMTYTotzXQ6DU3hILdUOYSuYIUJBctx2NsN1KKAZNlmb69PTuog
rdq8OBnA2dcYird62bSwPOOuwb8RnFBwqXNZ76O1a3eS5bTWx+TaLxSwFx3FGfzF
9zrFzNv6qMjw+TbAQxJ5kuNooF2l+xJTpszxGg/WZlaQ32S4kH7/vCKeHitoCFAX
z0ZsJevY9QkK2R4I9i3B6l2AAiMqfEICLouNIpQDhxgHB4w1aFlhi2mIUrtzQ7m+
n8SuUVbxYne4IAW7riF63YfHRbGqTWHZeIQ3YH62jcKIze8rhU+UW/1fVTUilVWh
JESIyQMOwZQ1BUVKPhBKrOpa0auxMhHGOj8chh9LBk2v4aj2rwNkwfTfA0GP0yzk
fdhvgUDgad5G6iovWcYi94ZR2oea43EpS6xih+n/hPSmZ7I2HsUP/ibaH7Jscu+F
sSwAohtAJ84l5SIC28LxHlqM/29ZWO21ZrfrXo0/eDX4hhTgKJLsGVtD8mnlXs8z
5SrYsGi/km8GAATmIWv6QfJ1v6jniUMnPks+3PJl9u8A8A1EQDs=
=/F3t
-END PGP SIGNATURE-

Re: How do I make TikZ pictures (babel) that are both viewable as block results, _and_ properly exportable? (invert colours?)

[Vladimir Nikishkin]

Additionally, what does the :buffer on header argument do?

I seem to see it in the examples, but can't find in the info document.

2020-05-25 11:10 GMT+08:00, Vladimir Nikishkin :
> Hello, everyone
>
> So...
>
> I have the following block:
>
> #+name: figure-1-2
> #+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry
> 300
> #+header: :fit yes :headers '("\\usepackage{tikz}")
> #+header: :buffer on
> #+begin_src latex :results value graphics file :exports both :file
> figure-1-2-tree.png
> \usetikzlibrary{trees}
> \begin{tikzpicture}[color=gray]
> \node {sqrt} % root
>   child { node {sqrt-iter}
>   child[sibling distance=5cm] { node{ good-enough }
>   child[sibling distance=2cm] { node { square } }
>   child[sibling distance=2cm] { node { abs } } }
>   child { node{ improve }
>   child { node { average } } } };
> \end{tikzpicture}
> #+end_src
>
> Note the [color=gray] parameter to the tikzpicture environment.
>
> I use a dark theme (arguably more merciful for the eyes when spending
> a lot of time working with computers).
>
> Therefore, when I type C-c at a picture block, I'm want to be getting
> a picture that is decently viewable on a black background. But when I
> am exporting the document, I expect to print it on a white piece of
> paper, so I want the pictures to be viewable too.
>
> These two requirements are contradictory to each other, so I need some
> additional level of abstraction somewhere here. But where?
>
> [color=gray] is a workaround, as it is visible on both the black
> background and the white background. If I don't find anything better,
> I will just either let it be, or replace it with [color=blue].
>
> But ideally, I'd like to export black-on-white pictures to LaTeX, and
> keep white-on-black when using the org document directly.
>
> Has this been already solved by some canned recipe? I'm getting lost
> in too many levels of abstraction:
> GTK Theme -> Emacs Theme -> org -> TikZ -> LaTeX -> Viewer
>
> --
> Yours sincerely, Vladimir Nikishkin
>


-- 
Yours sincerely, Vladimir Nikishkin

How do I make TikZ pictures (babel) that are both viewable as block results, _and_ properly exportable? (invert colours?)

[Vladimir Nikishkin]

Hello, everyone

So...

I have the following block:

#+name: figure-1-2
#+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 300
#+header: :fit yes :headers '("\\usepackage{tikz}")
#+header: :buffer on
#+begin_src latex :results value graphics file :exports both :file
figure-1-2-tree.png
\usetikzlibrary{trees}
\begin{tikzpicture}[color=gray]
\node {sqrt} % root
  child { node {sqrt-iter}
  child[sibling distance=5cm] { node{ good-enough }
  child[sibling distance=2cm] { node { square } }
  child[sibling distance=2cm] { node { abs } } }
  child { node{ improve }
  child { node { average } } } };
\end{tikzpicture}
#+end_src

Note the [color=gray] parameter to the tikzpicture environment.

I use a dark theme (arguably more merciful for the eyes when spending
a lot of time working with computers).

Therefore, when I type C-c at a picture block, I'm want to be getting
a picture that is decently viewable on a black background. But when I
am exporting the document, I expect to print it on a white piece of
paper, so I want the pictures to be viewable too.

These two requirements are contradictory to each other, so I need some
additional level of abstraction somewhere here. But where?

[color=gray] is a workaround, as it is visible on both the black
background and the white background. If I don't find anything better,
I will just either let it be, or replace it with [color=blue].

But ideally, I'd like to export black-on-white pictures to LaTeX, and
keep white-on-black when using the org document directly.

Has this been already solved by some canned recipe? I'm getting lost
in too many levels of abstraction:
GTK Theme -> Emacs Theme -> org -> TikZ -> LaTeX -> Viewer

-- 
Yours sincerely, Vladimir Nikishkin

Re: Is there a way to export only a subtree of a document to LaTeX (or anywhere)?

[Kyle Meyer]

Vladimir Nikishkin writes:

> I have a huge document written in org, which takes a lot of time to export.
>
> I want to preview chapters/sections as I'm writing, before finishing
> the whole book.
>
> Is it possible without copying a subtree to a temporary buffer?

When you enter the export dispatch, you should see an "Export scope"
option bound to C-s.  That toggles between buffer and subtree export.

Is there a way to export only a subtree of a document to LaTeX (or anywhere)?

[Vladimir Nikishkin]

I have a huge document written in org, which takes a lot of time to export.

I want to preview chapters/sections as I'm writing, before finishing
the whole book.

Is it possible without copying a subtree to a temporary buffer?


-- 
Yours sincerely, Vladimir Nikishkin

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

Nicolas Goaziou  writes: 

Hello, 

Timothy  writes: 

Well that didn't quite work as intended. Here's a take two. 


This doesn't look bad. Thank you. 


In the commit message, you need to list functions being 
modified. See other commits messages for some examples.


I'll patch my patch :P 

+  ((eq type 'latex-fragment) +   (let ((beg 
(org-element-property :begin datum)) +	 (end 
(org-element-property :end datum))) +	 (list beg end 
(buffer-substring-no-properties beg end 


These are not correct buffer positions. BEG and END should be 
between "\(" and "\)" (or "$" and "$", or…). See, in the same 
function, how inline source blocks are handled.


I thought that too initially. The think is you actually want them 
in the LaTeX buffer so they get treated as mathematics instead of 
text. 

+(org-src--edit-element + context + 
(org-src--construct-edit-buffer-name (buffer-name) "LaTeX 
fragment") + (org-src-get-lang-mode "latex") + t) + 
t)) 


You also need to put read-only property on fragment markers, and 
remove any blank line as the final step. See 
`org-edit-footnote-reference'. 


I'll take a look :)

 	 (pcase (org-element-type context) (`footnote-reference 
 (org-edit-footnote-reference)) (`inline-src-block 
 (org-edit-inline-src-code)) 
+	   (`latex-fragment (org-edit-latex-fragment)) 


This line is perfect ;)


I must have had great inspiration for it ;-)

Regards,

Timothy.

Re: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


akater  writes:

> * Summary
> I have a patch that allows to put trace output and error output into
> corresponding Org buffer. Current behaviour with outputs being splitted
> so that they go to different buffers (Org buffer, REPL), is arbitrary
> and inconvenient. The patch ensures backwards compatibility. I thus
> believe merging the patch would be a clear improvement. I use the
> proposed features daily (trace, mostly). Note however that the patch
> can't be merged right away; see [[Caveats]].
>
> Contents of output streams not specified in =:results= is always emitted
> to REPL buffer.
>
> * Examples
> I'll give here some examples of what's possible with the patch applied
> that is not possible currently.
>
> ** Output of ~time~
> #+begin_src lisp :results trace
> (time 0)
> #+end_src
>
> #+RESULTS:
> : Evaluation took:
> :   0.000 seconds of real time
> :   0.04 seconds of total run time (0.04 user, 0.00 system)
> :   100.00% CPU
> :   420 processor cycles
> :   0 bytes consed
> :   
>
> ** Traces
> #+begin_src lisp :results trace :wrap example lisp
> (defun memq (item list) (or (eq item (car list)) (memq item (cdr list
> (trace memq)
> (memq 'e '(a b c d e f))
> #+end_src
>
> #+RESULTS:
> #+begin_example lisp
>   0: (MEMQ E (B C D E F))
> 1: (MEMQ E (C D E F))
>   2: (MEMQ E (D E F))
> 3: (MEMQ E (E F))
> 3: MEMQ returned T
>   2: MEMQ returned T
> 1: MEMQ returned T
>   0: MEMQ returned T
> #+end_example
>
> ** Ignored errors
> #+begin_src lisp :results errors :wrap example lisp
> (ignore-errors (/ 1 0))
> #+end_src
>
> #+RESULTS:
> #+begin_example lisp
> ; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/"))
> ; (/ 1 0)
> ; 
> ; caught STYLE-WARNING:
> ;   Lisp error during constant folding:
> ;   arithmetic error DIVISION-BY-ZERO signalled
> ;   Operation was (/ 1 0).
> ; 
> ; compilation unit finished
> ;   caught 1 STYLE-WARNING condition
> #+end_example
>
> ** A combo
> #+begin_src lisp :results errors trace output :wrap example lisp
> (progn (time 0) (ignore-errors (/ 1 0)) (princ "wow"))
> #+end_src
>
> #+RESULTS:
> #+begin_example lisp
> ; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/"))
> ; (/ 1 0)
> ; 
> ; caught STYLE-WARNING:
> ;   Lisp error during constant folding:
> ;   arithmetic error DIVISION-BY-ZERO signalled
> ;   Operation was (/ 1 0).
> ; 
> ; compilation unit finished
> ;   caught 1 STYLE-WARNING condition
>
> Evaluation took:
>   0.000 seconds of real time
>   0.04 seconds of total run time (0.04 user, 0.00 system)
>   100.00% CPU
>   420 processor cycles
>   0 bytes consed
>   
>
> wow
> #+end_example

This looks really a great feature!!!

>
> * Caveats
> This improvement requires a change in SLIME code. One of SLIME
> maintaners agreed to merge it but SLIME and Org would need to
> synchronise their updates, and I'm not sure how to approach this.
>
> Corresponding patch to SLIME changes the interface of
> ~swank:eval-and-grab-output~. As implemented,
> ~swank:eval-and-grab-output~ makes its users choose between values and
> output by means of ~car~ and ~cadr~; preserving the compatibility by
> extending the current behaviour would make its users refer to various
> outputs by their positions which is a very bad idea. I employed alist
> instead. However, merging will break =ob-lisp= completely for those who
> use vcs Org but a stable SLIME.
>
> The change to SLIME may also affect ~org-babel-execute:clojure~ but I
> have no idea why Clojure would use SLIME and whether it actually does
> use it. Anyway, I will be able to provide a patch for it that would
> ensure backwards compatibility.
>
> * Some Details
> ** Syntax
> At least one function needs to be changed, namely
> ~org-babel-execute:lisp~.
>
> We preserve the current behaviour, i.e. =:results output= behaves as it
> used to. Preserving compatibility requires patching
> ~org-babel-result-cond~ so that it does not try to vectorise output from
> =:result trace=, =:result errors=.
>
> We could avoid this by requiring the =output= parameter all the time, so
> that user would have to write something like =:results trace output= or
> =:results output trace standard=. While the former is neat, the latter
> is not. Also, the notion “error output stream” makes sense not only for
> Common Lisp. Thus, adding =trace= and =errors= exceptional cases to
> ~org-babel-result-cond~ looks acceptable to me.
>
> ** (suggestion) Multi-block return
> Overall, I believe it would be best to embrace full potential of Org
> features and implement multi-block results as default for Common Lisp
> evaluation in Org, like in the following example:
>
> #+begin_src lisp
> (progn (time 0) (ignore-errors (/ 1 0)) (princ "wow") t)
> #+end_src
>
> #+RESULTS:
> #+begin_values lisp
> T
> #+end_values
> #+begin_errors lisp
> ; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/"))
> ; (/ 1 0)
> ; 
> ; caught STYLE-WARNING:
> 

Re: [PATCH] make org-attach-url download function as an option

[stardiviner]

Bastien  writes:

> Hi,
>
> stardiviner  writes:
>
>> I found when network is bad and slow, or the download file is big, the
>> org-attach-url will suspend Emacs for a long time. User might have to cancel
>> downloading, and start again later.
>
> Indeed, this might be annoying.  At the same time, it is not
> unreasonable to expect the user to know what size is the contents he
> is willing to attach to an Org node.

It's not the URL file size problem, sometime network is bad. I meet some
situations like downloading 1M file might use 5 minutes. Not 1M file or 1G file
difference.

>
>> I hope to make "org-attach-url" download file asynchronously. But function
>> org-attach-attach hardcoded this function for 'url method. Here is a patch to
>> make it into an option.
>
> (FWIW, I could not find the patch.)

Aha, I forgot the patch. I attached now. The patch does not provide an async
function to download. Just provide an easy way for user to use other async
functions.

>
> I think you are on the right track when trying to enhance the 'url
> package.  Maybe url-copy-file should be asynchronous and url could
> provide url-copy-file-synchronously (to mimic the url-retrieve and
> url-retrieve-synchronously pair)?

Actually I did check out url-copy-file-synchronously source code, try to mimic
an async version function. But seems I can't implement it. I will post an email
to Emacs-dev mailing list whether this can be improved.

>
> Until Emacs has a function to copy a URL's contents asynchronously,
> I'd rather not add this functionality in Org.

Emacs async functionality is always bad. Waiting for Emacs get better async
support might need a very long time.

I still think simply provide an simple entry for user to change downloading
function is a simpler option. WDYT?

-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
From 61e26e148e68deb03f26dddb2a88beae5b6869f7 Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Wed, 29 Apr 2020 21:38:34 +0800
Subject: [PATCH] lisp/org-attach.el: support custom url file downloading
 function

lisp/org-attach.el (org-attach-url-function): make download function as
a defcustom option. So that user can use async function or other
functions instead.
---
 lisp/org-attach.el | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 57d1360fc..e33551f40 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -110,6 +110,12 @@ (defcustom org-attach-method 'cp
 	  (const :tag "Hard Link" ln)
 	  (const :tag "Symbol Link" lns)))
 
+(defcustom org-attach-url-function 'url-copy-file
+  "The download file function to use in org-attach-url."
+  :type '(choice (const 'url-copy-file))
+  :safe #'functionp
+  :group 'org-attach)
+
 (defcustom org-attach-expert nil
   "Non-nil means do not show the splash buffer with the attach dispatcher."
   :group 'org-attach
@@ -504,7 +510,7 @@ (defun org-attach-attach (file  visit-dir method)
((eq method 'cp) (copy-file file attach-file))
((eq method 'ln) (add-name-to-file file attach-file))
((eq method 'lns) (make-symbolic-link file attach-file))
-   ((eq method 'url) (url-copy-file file attach-file)))
+   ((eq method 'url) (apply org-attach-url-function file (list attach-file
   (run-hook-with-args 'org-attach-after-change-hook attach-dir)
   (org-attach-tag)
   (cond ((eq org-attach-store-link-p 'attached)
-- 
2.26.2



signature.asc
Description: PGP signature

Re: (org-cycle) in new plain list items

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> I'm looking into it.

Fixed. Thank you.

Re: Improving Org Mode for VSCode - Thinking Aloud

[rey-coyrehourcq]

Hi,

Really cool discussion here.

My two cents, Jupyter & Kernel on various langage, which have a very
large community, could be an interesting backend for org-babel on
VSCode or anyeditoryouwantusehere. 

Lot of things start to appear to collaborate online around
online/scientific cnotebook/literate programing this last year, and that 
continue, for example i discover recently :
Stencila : https://github.com/stencila=

org-babel / org-mode outside of emacs has a great potential to lead an
alternative to other markdown (RStudio / Jupyter) solution.

Best regards

Le dimanche 24 mai 2020 à 06:06 -0700, Jack Kamm a écrit :
> It would be very good indeed for org-babel if it could be ported to
> other editors. One of the biggest drawbacks of org-babel notebooks is
> that I can't collaborate with my colleagues on them, since I can't
> expect them to use Emacs.
> 
> Aside from VSCode, I think RStudio would be an excellent target for a
> few reasons:
> 
> - Literate programming is already popular among R users (see also:
>   knitr, sweave, Rmarkdown)
> - There is a strong ob-R community here
> - There are some prominent Emacs users among the Rstudio developers
>   (e.g. Lionel Henry, who I think is both an Rstudio and ESS
> developer)
> 
> However, this would be a massive undertaking, and ultimately would
> need
> a volunteer to step up to the plate. I don't have any bandwidth to do
> this in the foreseeable future but dream of working on it one day.
> The
> biggest downside -- it would require spending considerable time
> outside
> Emacs!
> 
-- 


Sébastien Rey-Coyrehourcq
Research Engineer UMR IDEES
02.35.14.69.30

{Stronger security for your email, follow EFF tutorial : 
https://ssd.eff.org/}




signature.asc
Description: This is a digitally signed message part

Re: [PATCH] Fix `org-babel-detangle' handling of false positives

[Kyle Meyer]

Kevin Foley writes:

> Kyle Meyer  writes:
>
>> Kevin, could you look into updating the test to avoid changing the repo
>> state?
>
> Sorry about that.  Do you have any suggestions on how to avoid changing
> the state or any examples of similar tests?
>
> I tried the following to replace the file with it's original contents
> but it doesn't seem to be working as I intend.  I also worry it's a
> convoluted approach and there may be a simpler way.

Thanks for taking a look.  The dirty working tree state happens when
running all the ob-tangle tests but not when running just the test you
added [*].  That makes me think the core issue is that the change from
your test stays around to be save by another test.  So I suspect you can
avoid the dirty state by just wrapping the test in unwind-protect,
making sure to kill the Org buffer before detangle-false-positive exits.

[*] Specifically, running

  make BTEST_RE='ob-tangle' test-dirty

versus

  make BTEST_RE='detangle' test-dirty

RE: emacs + org-mode in virtual machine/docker/...

[Nick Daly]

John Kitchin writes:
> Has anyone had any success in creating or using any kind of virtual
> machine that can work across platforms to run emacs+org-mode?

Yes, just this spring.  I was trying to design an experiment that
could be replicated and expanded by any citizen scientist, with
minimal effort and interference.  I didn't use docker, but instead
Propellor to produce a bootable disk image that can boot from
removable media or be launched in a VM.

https://gitlab.com/nickdaly/cs790-p1

$ make diskimage

The disk image can be reproduced from inside the VM, if necessary,
allowing anyone to customize and extend the experiment.  Additionally,
the =.gitlab-ci= file ensures that the experiment's data are
reevaluated and the paper republished every time the experimental data
are updated:

- The paper :: https://nickdaly.gitlab.io/cs790-p1/notes.pdf

- The full set of experimental notes :: https://nickdaly.gitlab.io/cs790-p1

Thanks,
Nick

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Hello,

Timothy  writes:

> Well that didn't quite work as intended. Here's a take two.

This doesn't look bad. Thank you.

> From 379e23545d7e55766e48b50514bd797bdf691a40 Mon Sep 17 00:00:00 2001
> From: TEC 
> Date: Sun, 24 May 2020 23:35:33 +0800
> Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments

In the commit message, you need to list functions being modified. See
other commits messages for some examples.

> +  ((eq type 'latex-fragment)
> +   (let ((beg (org-element-property :begin datum))
> +  (end (org-element-property :end datum)))
> +  (list beg end (buffer-substring-no-properties beg end

These are not correct buffer positions. BEG and END should be between
"\(" and "\)" (or "$" and "$", or…). See, in the same function, how
inline source blocks are handled.

> +(pp (org-element-property :contents-begin context))

It is a left-over.

> +(org-src--edit-element
> + context
> + (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
> + (org-src-get-lang-mode "latex")
> + t)
> +  t))

You also need to put read-only property on fragment markers, and remove
any blank line as the final step. See `org-edit-footnote-reference'.

>(pcase (org-element-type context)
>  (`footnote-reference (org-edit-footnote-reference))
>  (`inline-src-block (org-edit-inline-src-code))
> +(`latex-fragment (org-edit-latex-fragment))

This line is perfect ;)

Regards,

-- 
Nicolas Goaziou

Re: (org-cycle) in new plain list items

[Nicolas Goaziou]

Hello,

lamagl...@posteo.net writes:

> Sorry, again. I am talking about "nested" plain lists:
>
>> - "Parent" level
>> - Initial level for new item
>> -
>  At this point I created the empty item with M-RET. If I then press TAB,
> it demotes this item, which is also mentioned here:
> https://orgmode.org/org.html#Plain-Lists [1].
>
>> - "Parent" level
>> - Initial level for new item
>> -
>  So far, so good. But if I then press TAB again, we go back to this: 
>
>> - "Parent" level
>> - Initial level for new item
>> -
>  Whereas I would expect it to move the item to this position: 
>
>> - "Parent" level
>> - Initial level for new item
>> -

>  If it would do this, it would behave analogous to how it is implemented
> for headings, as described at
> https://orgmode.org/manual/Structure-Editing.html#Structure-Editing
> [2]:

I'm looking into it.

Regards,

-- 
Nicolas Goaziou

Re: [PATCH] Fix `org-babel-detangle' handling of false positives

[Kevin Foley]

Kyle Meyer  writes:

> Kevin, could you look into updating the test to avoid changing the repo
> state?

Sorry about that.  Do you have any suggestions on how to avoid changing
the state or any examples of similar tests?

I tried the following to replace the file with it's original contents
but it doesn't seem to be working as I intend.  I also worry it's a
convoluted approach and there may be a simpler way.

diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index ed75e6ca4..a91bd3446 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -384,12 +384,19 @@ (ert-deftest ob-tangle/commented-src-blocks ()

 (ert-deftest ob-tangle/detangle-false-positive ()
   "Test handling of false positive link during detangle."
-  (org-test-in-example-file (expand-file-name "babel.el" org-test-example-dir)
-(org-babel-detangle)
-(org-test-at-id "73115FB0-6565-442B-BB95-50195A499EF4"
-(org-babel-next-src-block)
-(should (equal (string-trim (org-element-property :value 
(org-element-at-point)))
-  ";; detangle changes")
+  (let* ((babel-org-file (expand-file-name "babel.org" org-test-example-dir))
+(orig-file-buffer
+ (get-buffer-create " bable-org")))
+(with-current-buffer orig-file-buffer (insert-file-contents 
babel-org-file))
+(org-test-in-example-file (expand-file-name "babel.el" 
org-test-example-dir)
+  (org-babel-detangle)
+  (org-test-at-id "73115FB0-6565-442B-BB95-50195A499EF4"
+   (org-babel-next-src-block)
+   (should (equal (string-trim (org-element-property :value 
(org-element-at-point)))
+  ";; detangle changes"
+(with-current-buffer orig-file-buffer
+  (kill-buffer (get-file-buffer babel-org-file))
+  (write-region (point-min) (point-max) babel-org-file

 (provide 'test-ob-tangle)


Thanks,
Kevin

Re: Bug: When "Org Hierarchical Todo Statistics" set to nil, DONE items diasppear from agenda filtered by top headline [9.3.6 (9.3.6-25-g685b2c-elpa @ /home/william/.emacs.d/elpa/org-20200316/)]

[William Horne]

Hi Bastien,

Thank you for your response. This still happens for me on the version built
from the org-mode.git repository.

Here is a test .org file (also attached):


* TODO [0/4] Project 1
** Category 1
*** TODO Task 1
*** TODO Task 2
** Category 2
*** TODO Task 3
*** TODO Task 4
* TODO [0/4] Project 2
** Category 3
*** TODO Task 5
*** TODO Task 6
** Category 4
*** TODO Task 7
*** TODO Task 8


Here are the steps I followed (using emacs -q) to reproduce the issue:

1. emacs -q test.org
2. M-x, customize variable
3. org-hierarchical-todo-statistics
4. Toggle --> off,
5. State --> 0, "Set for current session"
6. back to test.org
7. M-x, org-agenda
8. < (restricted to buffer)
9. t "List of all TODO entries"
10. place cursor box on "Project 1" line
11. ^ ("org-agenda-filter-by-top-headline") ("Project 2" and descendants
disappear)
12. cursor box over "Task 1"
13. t (mark "Task 1" DONE)

This makes "Task 1" disappear from the agenda on my machine. The same
happens when I mark "Task 2" as done. Pressing "g" makes "Project 1" and
all remaining descendant tasks disappear.

Please let me know if I can provide any more information.

Will

On Sun, May 24, 2020 at 7:03 AM Bastien  wrote:

> Hi William,
>
> William Horne  writes:
>
> > Unfortunately, it appears that doing both at once triggers the
> > following behavior: with Org Hierarchical Todo Statistics set to
> > nil, marking an item DONE in the agenda while it is filtered by top
> > headline makes it disappear from the agenda, leave a blank line in
> > its place, and become irretrievable through undo.
>
> thanks for the detailed report.  I tried to reproduce the issue with
> an .org file I wrote, but I could not reproduce the problem.
>
> Do you still have this issue with latest Org?
>
> If so, can you provide a minimal .org file to let us reproduce the
> problem with emacs -q?
>
> Thanks,
>
> --
>  Bastien
>


test.org
Description: Binary data

Re: Org-agenda ignores archive tag set by "#+FILETAGS: ARCHIVE"

[Kyle Meyer]

Bastien writes:

> George Sokolsky  writes:
>
>> I have .org files with  "#+FILETAGS: ARCHIVE" headers.
>
> Shouldn't it be "#+FILETAGS: :ARCHIVE:" instead? 
>
> (Note the columns.)

Despite being the documented form, org-set-regexps-and-options will
handle entries "tag1 [tag2 ...]" as well:

(cl-mapcan (lambda (value)
 (cl-mapcan
  (lambda (k) (org-split-string k ":"))
  (split-string value)))
   (cdr (assoc "FILETAGS" alist)))

>> I want items from these .org files to be hidden by default from results
>> of "org-agenda" -> "s Search for keywords" by default.
>>
>> This is not the case, unfortunately.
>
> Can you be so kind as to test with latest Org from maint or master?

Earlier this week I applied the patch from a sibling message of this
thread (5e2490bdf), so maint and master no longer behave as initially
reported (hopefully :>).

Re: [Patch] Document org-capture-templates entry type default strings

[Kyle Meyer]

Bastien writes:

> No Wayman  writes:
>
>> I've included the default entry type strings for each entry type in
>> org-capture-tempalte's docstring.
>
> Thanks for the patch.  The lines are wrapped and it is not easy to
> read it in my client.  Can you resend it as an attachement and update
> it as a proper patch, with a changelog entry in the commit message?

This is the same patch as the one at
.  The In-reply-to
was unintentionally dropped.

Re: [PATCH] Fix `org-babel-detangle' handling of false positives

[Kyle Meyer]

Hi Kevin and Bastien,

This change (010d1e3b6) needs a follow-up patch.  Running the tests now
leaves the working tree dirty:

diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index b0942800a..e95a65b85 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -499,5 +499,5 @@ ** linked content to detangle
 :ID:   73115FB0-6565-442B-BB95-50195A499EF4
 :END:
 #+begin_src emacs-lisp :tangle yes :comments link
-  ;; detangle
+  ;; detangle changes
 #+end_src

Kevin, could you look into updating the test to avoid changing the repo
state?

Thanks.

Clocktable billing rules

[Russell Adams]

This came up in IRC. Is there a way to make clock tables follow billing rules?
For example, only billing whole hours, and maybe weekend items are a 4 hour
minimum?

I think it's too much to ask. ;]

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: [PATCH] ob-core: Display warning on failure to read results

[Kyle Meyer]

Kyle Meyer writes:

> Subject: [PATCH] ob-core: Display warning on failure to read results

Applied to master (14878f3f9).

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

> <#part type=“text/x-patch”
> filename=“home/tec.emacs.d/.local/straight/repos/org-mode/0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch”
>  disposition=attachment>
> <#/part>

Well that didn't quite work as intended. Here's a take two.

0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch
Description: Binary data

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

>From 379e23545d7e55766e48b50514bd797bdf691a40 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments

---
 lisp/org-src.el | 19 +++
 lisp/org.el |  1 +
 2 files changed, 20 insertions(+)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index c9eef744e..d648ce2c9 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -363,6 +363,10 @@ where BEG and END are buffer positions and CONTENTS is a string."
 	 (end (progn (goto-char (org-element-property :end datum))
 			 (search-backward "}" (line-beginning-position) t
 	 (list beg end (buffer-substring-no-properties beg end
+  ((eq type 'latex-fragment)
+   (let ((beg (org-element-property :begin datum))
+	 (end (org-element-property :end datum)))
+	 (list beg end (buffer-substring-no-properties beg end
   ((org-element-property :contents-begin datum)
(let ((beg (org-element-property :contents-begin datum))
 	 (end (org-element-property :contents-end datum)))
@@ -959,6 +963,21 @@ Throw an error when not at such a table."
 (table-recognize)
 t))
 
+(defun org-edit-latex-fragment ()
+  "Edit LaTeX fragment at point."
+  (interactive)
+  (let ((context (org-element-context)))
+(unless (and (eq (org-element-type context) 'latex-fragment)
+		 (org-src--on-datum-p context))
+  (user-error "Not on a LaTeX fragment"))
+(pp (org-element-property :contents-begin context))
+(org-src--edit-element
+ context
+ (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
+ (org-src-get-lang-mode "latex")
+ t)
+  t))
+
 (defun org-edit-latex-environment ()
   "Edit LaTeX environment at point.
 \\
diff --git a/lisp/org.el b/lisp/org.el
index 40c3c46b9..0808fc210 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17347,6 +17347,7 @@ Otherwise, return a user error."
 	 (pcase (org-element-type context)
 	   (`footnote-reference (org-edit-footnote-reference))
 	   (`inline-src-block (org-edit-inline-src-code))
+	   (`latex-fragment (org-edit-latex-fragment))
 	   (`timestamp (if (eq 'inactive (org-element-property :type context))
 			   (call-interactively #'org-time-stamp-inactive)
 			 (call-interactively #'org-time-stamp)))
-- 
2.26.2

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

Bastien  writes: 

I hope you will have time to move forward with sending patches 
so that we can discuss the feature proposals against something 
we can actually test. 


Well, I'm currently having a look at patching this, so this looks 
hopeful :)


I think I've got a mostly-functional `org-edit-latex-fragment', 
I'm just wrangling with `org-src--contents-area' complaining 
"Unsupported element or object: latex-fragment" at the moment.
   
I hope to have more soon!

Re: Bug: ob-python mangles multiline :var values [9.3.6 (release_9.3.6-397-ga089600)]

[Jack Kamm]

Hello,

Thanks for reporting. I've just fixed this issue in master (commit
6149b6cb6).

The problem was that ob-python adds tab indentation to the code body
before putting it inside a main() function, which adds spurious
indentation to multiline strings passed through :var.

I fixed the issue by moving variable assignment from the code body to
the code preamble, which is executed outside the main() function.

Best,
Jack

Štěpán Němec  writes:

> Recipe:
> ---
>
> emacs -Q
> M-x load-library RET ob-python RET
> M-x org-mode RET
>
> #+begin_src python :var text="a\nb\nc"
> return text
> #+end_src
>
> #+RESULTS:
> : a
> : b
> : c
>
>
> Commentary:
> ---
>
> ob-python seems to prepend a TAB character to every line except for the
> first one.
>
> Emacs  : GNU Emacs 28.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 
> 3.24.14, cairo version 1.17.3)
>  of 2020-03-11
> Package: Org mode version 9.3.6 (release_9.3.6-397-ga08960 @ 
> /home/stepnem/.emacs.d/lib/org/lisp/)

bug#36228: closed (Re: bug#36228: org agenda tags-todo time-zone bug/inconsistency)

[Gary Fredericks]

I agree, I can no longer reproduce it, even though we're in the same phase
of daylight savings time as when I originally reported it.

Thanks!

Gary Fredericks

Re: Bug: lisp error on user error [9.3.6 (9.3.6-43-gc77edd-elpa @ /home/minshall/.emacs.d/elpa/org-20200413/)]

[Bastien]

Hi Greg,

Greg Minshall  writes:

> hi.  the following example should possibly result in an error message,
> but actually causes a lisp error/backtrace.  i have a code block with
> ":results vertatim :colnames yes", and am returning a simple character
> string (so, no headers -- tsk, tsk, a user error).  this happens with
> 'emacs -Q'.  if either the ":results verbatim" or the ":colnames yes" is
> left out, i get no error.  below is a sample file.

thanks for reporting this.  I've pushed a quick fix in master so that
it now displays an error as the output and does not choke at the user
as it did before.

Best,

-- 
 Bastien

Re: [PATCH] make org-attach-url download function as an option

[Bastien]

Hi,

stardiviner  writes:

> I found when network is bad and slow, or the download file is big, the
> org-attach-url will suspend Emacs for a long time. User might have to cancel
> downloading, and start again later.

Indeed, this might be annoying.  At the same time, it is not
unreasonable to expect the user to know what size is the contents he
is willing to attach to an Org node.

> I hope to make "org-attach-url" download file asynchronously. But function
> org-attach-attach hardcoded this function for 'url method. Here is a patch to
> make it into an option.

(FWIW, I could not find the patch.)

I think you are on the right track when trying to enhance the 'url
package.  Maybe url-copy-file should be asynchronous and url could
provide url-copy-file-synchronously (to mimic the url-retrieve and
url-retrieve-synchronously pair)?

Until Emacs has a function to copy a URL's contents asynchronously,
I'd rather not add this functionality in Org.

-- 
 Bastien

Re: (org-cycle) in new plain list items

[lamaglama]

 

Sorry for being unclear, I'll try to rephrase what I am talking about.

Bastien wrote:
> So I guess you have (setq org-cycle-include-plain-lists nil), right?

It is set to integrate, but I tested it and it does not seem to matter.

> I'm not sure what "move to the parent level" really means here.

Sorry, again. I am talking about "nested" plain lists:

> - "Parent" level
> - Initial level for new item
> -
 At this point I created the empty item with M-RET. If I then press TAB,
it demotes this item, which is also mentioned here:
https://orgmode.org/org.html#Plain-Lists [1].

> - "Parent" level
> - Initial level for new item
> -
 So far, so good. But if I then press TAB again, we go back to this: 

> - "Parent" level
> - Initial level for new item
> -
 Whereas I would expect it to move the item to this position: 

> - "Parent" level
> - Initial level for new item
> -
 If it would do this, it would behave analogous to how it is implemented
for headings, as described at
https://orgmode.org/manual/Structure-Editing.html#Structure-Editing [2]:

> In a new entry with no text yet, the first TAB demotes the entry to become a 
> child of the previous one. The next TAB makes it a parent, and so on, all the 
> way to top level. Yet another TAB, and you are back to the initial level.
 I am using Emacs 26.3 on Windows and this behaviour replicated on a
clean install.

Thank you for your time! 

Links:
--
[1] https://orgmode.org/org.html#Plain-Lists
[2] https://orgmode.org/manual/Structure-Editing.html#Structure-Editing

Re: [PATCH] Fix `org-babel-detangle' handling of false positives

[Bastien]

Hi Kevin,

I was able to apply the patch, I just did so against master.

I also added you to the list of contributors here:
https://orgmode.org/worg/org-contribute.html

Thanks a lot!

-- 
 Bastien

Re: Clock connection between the files

[Vladimir Nikishkin]

I don't remember any more how this worked out, sorry.

I only remember that #+latex_header, if set in a wrong way, breaks almost
everything. One of the things it's breaking is C-c C-j, but it actually
breaks more.

Moreover, I had both files in the agenda list, so this may be a potential
"mis-coupling".

But I sent faithfully reenact the setup of March.

Sorry

Bastien  於 2020年5月24日 週日 19:54 寫道：

> Hi Vladimir,
>
> Vladimir Nikishkin  writes:
>
> > How come org knows the connection between the first and the second
> > file? There are not any references to the second file in the first one
> > whatsoever.
>
> I cannot reproduce the problem.  Can you reproduce it (without adding
> that much contents to the second file)?  Otherwise I don't see where
> the error can come from.
>
> Thanks,
>
> --
>  Bastien
>

Re: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer

[Bastien]

Hi,

akater  writes:

> I have a patch that allows to put trace output and error output into
> corresponding Org buffer. 

Can you share the patch (as an attachment)?

Does it add a functionality just for one ob-* library or for babel
evaluation in general?

> Current behaviour with outputs being splitted
> so that they go to different buffers (Org buffer, REPL), is arbitrary
> and inconvenient. The patch ensures backwards compatibility. I thus
> believe merging the patch would be a clear improvement. I use the
> proposed features daily (trace, mostly). Note however that the patch
> can't be merged right away; see [[Caveats]].

Can the patch be made so that the ob-* library is still compatible
with previous versions of slime?

If the patch is just for one babel library and completely depends on 
a version of slime that does not exist yet, perhaps it is a good idea
to publish your modified version of that library, test the proposed
feature with your users and see what can be added to Org's core later
on?

Don't hesitate to send an update on this.

Thanks,

-- 
 Bastien

Re: Bug: org-agenda-refile does not update CATEGORY [9.1.9 (release_9.1.9-65-g5e4542 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Bastien]

Hi Kent,

Kent Primrose  writes:

> org-agenda-prefix-format uses %T to show the CATEGORY or filename.
> When
>
> refiling via org-agenda-refile, the CATEGORY (or filename) is not
>
> changed. The original category (such as "CAP" for items from
>
> capture.org) remains. This also remains if I regenerate the org
> agenda,
>
> and even if I kill the org agenda buffer and regenerate. On
> restarting
>
> emacs, the correct CATEGORY information is displayed in the org
> agenda.

I cound not reproduce this problem.  

Can you first try to download and install the latest version of Org
and see if your problem persists?   If so, can you send a minimal
example and step-by-step recipe explaining how to reproduce it?

Thanks a lot,

-- 
 Bastien

Re: [Patch] Document org-capture-templates entry type default strings

[Bastien]

Hi,

No Wayman  writes:

> I've included the default entry type strings for each entry type in
> org-capture-tempalte's docstring.

Thanks for the patch.  The lines are wrapped and it is not easy to
read it in my client.  Can you resend it as an attachement and update
it as a proper patch, with a changelog entry in the commit message?

Thanks,

-- 
 Bastien

Re: wip-cite status question and feedback

[Bruce D'Arcus]

Hi Bastian,


On Sun, May 24, 2020 at 8:12 AM Bastien  wrote:
>
> Hi Bruce,
>
> "Bruce D'Arcus"  writes:
>
> > I'm not sure of the value of this sort of question thrown in the
> > middle of a long-running, many year, conversation. You seem to assume
> > nobody considered this.
>
> Well, this sounded a bit harsh, problably more than what was intended.

Yes, probably true.

I was trying to be direct, to avoid a potentially long-winded diversion.

But it was a bit harsh. Sorry Gustav.

> > But to answer anyway ...
>
> And your answer was precisely what I was (also) looking for, so thanks
> for it.  I haven't followed nor helped developments in this area but I
> hope this can settle down and be widely available.

Indeed; thanks!

Bruce

Re: Improving Org Mode for VSCode - Thinking Aloud

[Fabrice Popineau]

Le dim. 24 mai 2020 à 15:07, Jack Kamm  a écrit :

> It would be very good indeed for org-babel if it could be ported to
> other editors. One of the biggest drawbacks of org-babel notebooks is
> that I can't collaborate with my colleagues on them, since I can't
> expect them to use Emacs.


+1000 on this one !

Fabrice

Re: Improving Org Mode for VSCode - Thinking Aloud

[Jack Kamm]

It would be very good indeed for org-babel if it could be ported to
other editors. One of the biggest drawbacks of org-babel notebooks is
that I can't collaborate with my colleagues on them, since I can't
expect them to use Emacs.

Aside from VSCode, I think RStudio would be an excellent target for a
few reasons:

- Literate programming is already popular among R users (see also:
  knitr, sweave, Rmarkdown)
- There is a strong ob-R community here
- There are some prominent Emacs users among the Rstudio developers
  (e.g. Lionel Henry, who I think is both an Rstudio and ESS developer)

However, this would be a massive undertaking, and ultimately would need
a volunteer to step up to the plate. I don't have any bandwidth to do
this in the foreseeable future but dream of working on it one day. The
biggest downside -- it would require spending considerable time outside
Emacs!

Re: Improving Org Mode for VSCode - Thinking Aloud

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Bastien  writes:

> Hi,
>
> stardiviner  writes:
>
>> And I really don't think suggesting improvement of Org Mode on VS Code is an
>> good idea here.
>
> This list is both about Org as a set of tools for GNU Emacs and Org as
> a text format used for .org files.
>
> So any topic that is relevant to either Org as an Emacs mode or Org as
> a text format is relevant here.
>
> This also mean that, yes, our focus is not on discussing how the org
> format is supported on *any* tools.  I don't think we should forbid
> such discussions, it's just that they will be more effective when
> brought on these other tools forums.

Sounds reasonable.

- -- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7KaxYUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsNxhwgAlacQmq8LfixBW8PN2fFqXsD/Hmw2
TwT5+8aoJKTgOtaD1q5ewzff9z3Utlt8Y+ufUJ/nUk313SuXZTEkjXt+H7FlvG+4
grskFve6OYbaY+XH2iXyHEn2lONP2ZSfvlSa+Kiww/odlwSlr5jKcj1WfKBhCWtu
XZEM2b20bgz4YrgHm+sZehKWwX8N5SLZsgnmv2O1WE4uAhBRHySGJXPJdCIg+uPY
2JzegcU590YGTwp5Qnt1H6jUA9AfIzA1xQkhUuhrWe1UVVHomECu2pY/49JC0dlj
YBXJM44r5ky5geBsul3mer6H0tmuX+Fm5h+Q/u/3NEbc4WvvsXci3mKztw==
=glLj
-END PGP SIGNATURE-

Re: Customizable fixed indentation column

[Panagiotis Vlantis]

Hi Bastien,

Completely understandable. Thanks for taking the time to consider this 
in the first place. I hope we get to pick this topic up again in the 
near future.


Best regards to all,
Panagiotis


On 5/24/20 1:55 PM, Bastien wrote:

Hi Panagiotis,

thanks for this proposal.

I don't have a strong opinion (yet) on whether we should allow to
indent to a custom column by setting org-adapt-indentation to an
integer.  My gut feeling for now is that this is too much, but I
don't want to dismiss this possibility completely.

That said, the new customization values for org-adapt-indentation
have not yet been released, so I suggest continuing the discussion
for after 9.4 has been released and for after org-adapt-indentation
has been more widely used in its current (from master) state.

Thanks,

Re: Replace Org's C-TAB with C-M-TAB - objection?

[Joost Kremers]

On Sun, May 24 2020, stardiviner wrote:

Bastien  writes:
C-TAB in Org is bound to `org-force-cycle-archived' to allow to 
cycle

through archived subtrees.

In the Emacs tab-bar mode, it is now bound to `tab-next', which 
needs

to work globally.

So Org's binding and tab-bar's one are in conflict, as reported 
here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41325

I suggest binding `org-force-cycle-archived' to C-M-TAB: any 
objection?


Thanks,


I object this change. Emacs tab-bar is not enabled by default. 
When conflict,
user can customize keybinding. I don't think it's very necessary 
to change.


I would support the change, since both Org mode and tab-bar-mode 
are part of core Emacs and I doubt it'll be clear to new users 
coming to Emacs why these conflicting key bindings exist. Instead, 
they'll be annoyed that they cannot C-TAB out of the Org buffer 
and their impression of Emacs (not just Org mode or tab-bar-mode) 
will suffer. Ever more so because it's probably not immediately 
obvious to new users how C-TAB is different from just TAB: they 
both open the subtree at point.


I've been using C-TAB for a long time to switch buffers (albeit 
not with tab-bar-mode), and it's always annoying when some mode 
usurps (from my perspective) this keybinding. Now, I'm familiar 
with Emacs and the relative independence and freedom that 
individual packages have, plus C-TAB is a personal keybinding, so 
I know this sort of thing may happen and I know how to resolve it. 
For a new user, that won't be so obvious. For them, this will 
simply look like a badly designed UI.


So I think the general argument for habit-breaking UI changes 
applies: it creates a more consistent UI, which means it's easier 
on new users and more in line with what they expect. For existing 
users that want the old behaviour back, it's a simple 
configuration in their init.el.


--
Joost Kremers
Life has its moments

Re: [PATCH] Fix `org-babel-detangle' handling of false positives

[Kevin Foley]

Hi Bastien,

Bastien  writes:

> I tried to apply your patch but I was not able to apply it, perhaps
> just a problem with extracting it from your email.
>
> Can you send an (perhaps updated) version as an attachment?

What issue did you have?

I was able to download and apply the original patch to the latest commit
on master (701c7bed) without any issues/conflicts using =git am --
=.  I'm new to patch based development so I may be
missing something.

I've tried recreating the patch and attaching to this message, hopefully
that resolves it.  I've also attached it as "text/x-patch" instead of
"text/plain" which I used last time, I'm not sure if that causes issues
or if one is preferred.

>From eae83992e0c671d0162ba60f567629138ecc0074 Mon Sep 17 00:00:00 2001
From: "Kevin J. Foley" 
Date: Tue, 28 Jan 2020 17:51:29 -0500
Subject: [PATCH] Fix `org-babel-detangle' handling of false positives

* lisp/ob-tangle.el (org-babel-detangle): Handle false positive
matches of `org-link-bracket-re'

* testing/examples/babel.el: New file for babel detangle false
positive test

* testing/examples/babel.org (detangle): Add detangle/false positive
example

* testing/lisp/test-ob-tangle.el (ob-tangle/detangle-false-positive):
Add test for detangle false positive
---
 lisp/ob-tangle.el  | 18 ++
 testing/examples/babel.el  |  5 +
 testing/examples/babel.org | 13 +
 testing/lisp/test-ob-tangle.el | 11 +++
 4 files changed, 39 insertions(+), 8 deletions(-)
 create mode 100644 testing/examples/babel.el

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 8fd407478..4fe444532 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -516,14 +516,16 @@ (defun org-babel-detangle ( source-code-file)
 (goto-char (point-min))
 (let ((counter 0) new-body end)
   (while (re-search-forward org-link-bracket-re nil t)
-(when (re-search-forward
-	   (concat " " (regexp-quote (match-string 2)) " ends here"))
-  (setq end (match-end 0))
-  (forward-line -1)
-  (save-excursion
-	(when (setq new-body (org-babel-tangle-jump-to-org))
-	  (org-babel-update-block-body new-body)))
-  (setq counter (+ 1 counter)))
+(if (and (match-string 2)
+		 (re-search-forward
+		  (concat " " (regexp-quote (match-string 2)) " ends here") nil t))
+	(progn (setq end (match-end 0))
+		   (forward-line -1)
+		   (save-excursion
+		 (when (setq new-body (org-babel-tangle-jump-to-org))
+		   (org-babel-update-block-body new-body)))
+		   (setq counter (+ 1 counter)))
+	  (setq end (point)))
 (goto-char end))
   (prog1 counter (message "Detangled %d code blocks" counter)
 
diff --git a/testing/examples/babel.el b/testing/examples/babel.el
new file mode 100644
index 0..a7bb0ccf5
--- /dev/null
+++ b/testing/examples/babel.el
@@ -0,0 +1,5 @@
+(string-match-p "^#[[:digit:]]+$" "#123")
+
+;; [[id:73115FB0-6565-442B-BB95-50195A499EF4][detangle:1]]
+;; detangle changes
+;; linked content to detangle:1 ends here
diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index c889d5d92..b0942800a 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -488,3 +488,16 @@ nil
 #+BEGIN_SRC emacs-lisp :output-dir xxx :file foo.bar
 nil
 #+END_SRC
+* detangle
+** false positive
+The =[[= causes a false positive which ~org-babel-detangle~ should handle properly
+#+begin_src emacs-lisp :tangle yes
+(string-match-p "^#[[:digit:]]+$" "#123")
+#+end_src
+** linked content to detangle
+:PROPERTIES:
+:ID:   73115FB0-6565-442B-BB95-50195A499EF4
+:END:
+#+begin_src emacs-lisp :tangle yes :comments link
+  ;; detangle
+#+end_src
diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index 301f7aff7..ed75e6ca4 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -25,6 +25,8 @@
 
 ;;; Code:
 
+(require 'subr-x)
+
 ;; TODO
 ;; (ert-deftest ob-tangle/noweb-on-tangle ()
 ;;   "Noweb header arguments tangle correctly.
@@ -380,6 +382,15 @@ (ert-deftest ob-tangle/commented-src-blocks ()
 		(org-split-string (buffer-string
 	  (delete-file file))
 
+(ert-deftest ob-tangle/detangle-false-positive ()
+  "Test handling of false positive link during detangle."
+  (org-test-in-example-file (expand-file-name "babel.el" org-test-example-dir)
+(org-babel-detangle)
+(org-test-at-id "73115FB0-6565-442B-BB95-50195A499EF4"
+(org-babel-next-src-block)
+(should (equal (string-trim (org-element-property :value (org-element-at-point)))
+		   ";; detangle changes")
+
 (provide 'test-ob-tangle)
 
 ;;; test-ob-tangle.el ends here
-- 
2.19.0


Thanks,
Kevin

Re: Bug: org-agenda-finalize throws args-out-of-range [9.3.6 (9.3.6-19-gf360f9-elpaplus @ /home/nivekuil/.emacs.d/elpa/org-plus-contrib-20200302/)]

[Bastien]

Hi Kevin,

Kevin Liu  writes:

> This bit in org-agenda-finalize:
>
> (save-excursion
> (while (org-activate-links (point-max))
>   (add-text-properties (match-beginning 0) (match-end 0)
>'(face org-link
>
> Will throw an error at add-text-properties:
>
> Debugger entered--Lisp error: (args-out-of-range 0 2)
>   add-text-properties(0 2 (face org-link))
>   org-agenda-finalize()
>   org-agenda-list(nil)
>   funcall-interactively(org-agenda-list nil)
>   call-interactively(org-agenda-list)
>   org-agenda(nil)
>   funcall-interactively(org-agenda nil)
>   call-interactively(org-agenda nil nil)
>   command-execute(org-agenda)

FWIW I could not reproduce this bug but the code was wrong indeed, I
removed the redundant call to `add-text-properties' in maint.

I hope it fixed the problem you had, thanks for reporting it.

Best,

-- 
 Bastien

Re: wip-cite status question and feedback

[Bastien]

Hi Bruce,

"Bruce D'Arcus"  writes:

> I'm not sure of the value of this sort of question thrown in the
> middle of a long-running, many year, conversation. You seem to assume
> nobody considered this.

Well, this sounded a bit harsh, problably more than what was intended.

> But to answer anyway ...

And your answer was precisely what I was (also) looking for, so thanks
for it.  I haven't followed nor helped developments in this area but I
hope this can settle down and be widely available.

Best,

-- 
 Bastien

Re: yhetil.org/orgmode now supports searching by Gmane ID

[Bastien]

Hi Kyle,

Kyle Meyer  writes:

>> Let me how I can help with this.
>
> Making it available at orgmode.org sounds fine to me.  My preference
> would be for the orgmode.org server to host an actual mirror of the
> archive.  This wouldn't involve setting up incoming mail on the server;
> getting new messages would be a "git fetch && public-inbox-index".
> Hopefully setting things up would be pretty painless given that I
> already have a working setup.

Great, thanks -- can you send me the instructions in private on how to
set up a mirror on orgmode.org?

-- 
 Bastien

Re: Bug: When "Org Hierarchical Todo Statistics" set to nil, DONE items diasppear from agenda filtered by top headline [9.3.6 (9.3.6-25-g685b2c-elpa @ /home/william/.emacs.d/elpa/org-20200316/)]

[Bastien]

Hi William,

William Horne  writes:

> Unfortunately, it appears that doing both at once triggers the
> following behavior: with Org Hierarchical Todo Statistics set to
> nil, marking an item DONE in the agenda while it is filtered by top
> headline makes it disappear from the agenda, leave a blank line in
> its place, and become irretrievable through undo.

thanks for the detailed report.  I tried to reproduce the issue with
an .org file I wrote, but I could not reproduce the problem.

Do you still have this issue with latest Org?

If so, can you provide a minimal .org file to let us reproduce the
problem with emacs -q?

Thanks,

-- 
 Bastien

Re: Clock connection between the files

[Bastien]

Hi Vladimir,

Vladimir Nikishkin  writes:

> How come org knows the connection between the first and the second
> file? There are not any references to the second file in the first one
> whatsoever.

I cannot reproduce the problem.  Can you reproduce it (without adding
that much contents to the second file)?  Otherwise I don't see where
the error can come from.

Thanks,

-- 
 Bastien

Re: org-agenda-sorting-strategy's sorting of deadline and schedule is opposed

[Bastien]

Hi,

stardiviner  writes:

> org-agenda-sorting-strategy bug? Cannot list deadline items before scheduled 
> items.
>
> With the following:
>
> #+begin_src emacs-lisp
> (setq org-agenda-sorting-strategy
>   '((agenda time-up deadline-up scheduled-down ts-up habit-down 
> priority-down category-keep)
> (todo priority-down category-keep)
> (tags priority-down category-keep)
> (search category-keep))
>   org-agenda-sorting-strategy-selected
>   '(time-up priority-down deadline-up scheduled-down ts-up habit-down 
> category-keep))
> #+end_src
>
> The time-up is correctly shown first; however, all scheduled items are shown
> next as opposed to all deadline items (the order should be the other way
> around).

Can you provide a more minimal configuration example, with the order
expected and the order you get?

As said in the reddit thread, the output of complex sorting strategies
can be confusing, so being minimal here is the way to go.

Thanks,

-- 
 Bastien

Re: [QUESTION] What's the ":desk" link parameter?

[Ihor Radchenko]

> thanks for the patch.  I assume you are submitting it against master,
> am I right?

The patch is against commit 2e96dc639. 

> From reading this, I don't see what bug it fixes, what problem it
> solves or what real user need it responds to, but maybe I lost part
> of the context.  Can you explain why this should be applied?

It does not fix any bug. Rather adds a new feature [1]. Currently, org
provides org-link-make-description-function as user customisation to
compute default link description. The patch provides a way to set such
description functions on per link type basis (via :description link
parameter). Using link parameters looks natural for me since similar
customisation is already done in :follow and :store link parameters.

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2019-08/msg00013.html

Best,
Ihor

Bastien  writes:

> Hi Ihor,
>
> thanks for the patch.  I assume you are submitting it against master,
> am I right?
>
> Ihor Radchenko  writes:
>
>> +`:description'
>> +
>> +  Function to use for generating link descriptions from links.  This
>> +  function must take two parameters: the first one is the link, the
>> +  second one is the description generated by `org-insert-link'.  The
>> +  function should return the description to use.
>
> From reading this, I don't see what bug it fixes, what problem it
> solves or what real user need it responds to, but maybe I lost part
> of the context.  Can you explain why this should be applied?
>
> Thanks,
>
> -- 
>  Bastien

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

Re: Improving Org Mode for VSCode - Thinking Aloud

[Bastien]

Hi Tim,

Tim Cross  writes:

> Probably the best assistance org-mode can provide would be definitive
> and current documentation on the markup syntax and APIs for babel and
> export.

Agreed -- help is always welcome on this.

Thanks!

-- 
 Bastien

Re: Improving Org Mode for VSCode - Thinking Aloud

[Bastien]

Hi,

stardiviner  writes:

> And I really don't think suggesting improvement of Org Mode on VS Code is an
> good idea here.

This list is both about Org as a set of tools for GNU Emacs and Org as
a text format used for .org files.

So any topic that is relevant to either Org as an Emacs mode or Org as
a text format is relevant here.

This also mean that, yes, our focus is not on discussing how the org
format is supported on *any* tools.  I don't think we should forbid
such discussions, it's just that they will be more effective when
brought on these other tools forums.

-- 
 Bastien

Re: [QUESTION] What's the ":desk" link parameter?

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Ihor Radchenko  writes:

>> I remember I found this code on emacs.stackexchange.com website.
>>
>> I did a Google search now, I found someone indeed proposed this feature. 
>> Here is
>> the email archive:
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2019-08/msg00013.html
>>
>> I saw this thread is stopped. Seems no patch provided. Does anyone want to 
>> implement it?
>
> See the attached.
>
> Best,
> Ihor
>

This is great. Nicolas, can you review this patch? If ok, I hope this new
feature can be added. WDYT?

>
>
> stardiviner  writes:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>>
>> John Kitchin  writes:
>>
>>> Where did you find that code?  I recall this was some kind of prototype
>>> code, and maybe it never got fully developed. I think desk was shorthand
>>> for description.
>>
>> I remember I found this code on emacs.stackexchange.com website.
>>
>> I did a Google search now, I found someone indeed proposed this feature. 
>> Here is
>> the email archive:
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2019-08/msg00013.html
>>
>> I saw this thread is stopped. Seems no patch provided. Does anyone want to 
>> implement it?
>>
>>>
>>> On Sat, May 23, 2020 at 8:24 AM stardiviner  wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256


 I found some examples setting org-link-parameters with ":desk", like this:

 #+begin_src emacs-lisp
 (defun org-id-link-desk (link desk)
   "Description function for id: link."
   (let ((id (cadr (split-string link ":"
 (org-with-point-at (org-id-find id 'marker)
   (s-join "/" (org-get-outline-path 'with-self)

 (org-link-set-parameters "id" :desk #'org-id-link-desk)
 #+end_src

 But I have not found any mention in help of variable
 ~org-link-parameters~. Also I
 checked org mode source code by search, no matching of ":desk" found. Did
 I miss
 something?

 - --
 [ stardiviner ]
I try to make every word tell the meaning that I want to express.

Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

 -BEGIN PGP SIGNATURE-

 iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7JFckUHG51bWJjaGls
 ZEBnbWFpbC5jb20ACgkQG13xyVromsONBggAy0z465LkTx1EYBo4GWZdObWXct8O
 Fjz24HGzin/ffISIhytm0r4w5GE2Rb2/m+BwAsfHEDDvLu1mwU3HvLugXmIk0OUA
 u9qRLHJ4Po1/Y1CRR0o/OHHnbTjhA/7ppljRcN0klwd6J0PDrSE3K/XOhV94xyfK
 k0fUBhtQeTdW/uzx49hs14QlNQ5i6+HJWd1g/viXI+v0EIYJDV3PLwS6CFJWnvo3
 Yi210RM87uKi8vWFcFP7fEW2dYDV5MRsKmQ8v9AKLcCW9+T6Zq3tI7Srxn7ZwFsQ
 mFxZdLFyDlQq0M4VG0WL/epwr0f4B2SUZ3BcOEYrwv7N+7sfMN2cCWI8jQ==
 =8aOD
 -END PGP SIGNATURE-

 --
>>> John
>>>
>>> ---
>>> Professor John Kitchin
>>> Doherty Hall A207F
>>> Department of Chemical Engineering
>>> Carnegie Mellon University
>>> Pittsburgh, PA 15213
>>> 412-268-7803
>>> @johnkitchin
>>> http://kitchingroup.cheme.cmu.edu
>>
>>
>> - -- 
>> [ stardiviner ]
>>I try to make every word tell the meaning that I want to express.
>>
>>Blog: https://stardiviner.github.io/
>>IRC(freenode): stardiviner, Matrix: stardiviner
>>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>>   
>> -BEGIN PGP SIGNATURE-
>>
>> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7JtzoUHG51bWJjaGls
>> ZEBnbWFpbC5jb20ACgkQG13xyVromsMC4wf+Nzj7X+SDnSaYoFYWvdx/r0PtSbyJ
>> u4fmiT5TlWYJvx6+S9HVxTSmvR7QEdxWFTLU0zkVFAmuhFIehIDoQpCzunwCGKfl
>> Onn+TLwqm8UaeDS1GXs0yhRLRAgsDqM+jdd7+IKccljRonM1RVYDjFjfdXvh9U9h
>> mDU78HGL/yGg6rzlIHlzh+s0bvkM0xgmivI7zWmk1BF8PQofXcVzdGn3aWFz3rNN
>> clEgmCtOX/t7gRzn8H8Ydq+vg+J15OliNjWBRZ1Op26msaOYe+nly8tGAbfwqDgB
>> SSC4vi42vUbvVNzpjYfR6byqQ4RDxI8th66NJ6yuk0hkCnTHe69h1gQuqw==
>> =Q210
>> -END PGP SIGNATURE-
>>


- -- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7KVpYUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsMKtAgAn/ZdO3hWa60Rt4jvyA4xxJnWV8n4
oqva8Psq3NJNswpiruUoEOWV2OftQxe8HmyKHlAdOAnmpoIfLV21vp7YE85T8OBj
zpIOziQJdoMw/5KYImVRRZwwtpZ5nBdur90WO6vhhbhtCXnfGKBv1sQ0oXDHaxsq
TFWkt1Adqgc40xCAgSuaRoXq5k15kt4IvFYlwLfNybK57GcSxOCJUUQvfjaBPLEr
j9N6ZhgaJMHWdTPFunez1z+2XpJKI4i1W2JcOdaqT6CA5sgRFbEFUdsfIipuJi0v
Wq2O2sao7L2L/uzIKmEZavNgEWi7ohjcuKldMu65pA9gXgD6zUrmodUq+A==
=Ymys
-END PGP SIGNATURE-

Re: (org-cycle) in new plain list items

[Bastien]

Hi,

lamagl...@posteo.net writes:

> It is a minor thing, but it sort of bugs me:
>
> When I press  in a new plain list item it demotes it, as it
> should. 

So I guess you have (setq org-cycle-include-plain-lists nil), right?

> But when I press  again, it does not move to the parent
> level, like a new headline would. 

I'm not sure what "move to the parent level" really means here.

> Rather, it goes to the initial level
> first, before moving on to the parent levels.
>
> Is this intended behaviour?

Sorry I cannot figure out what the problem is.  Can you give a more
actionable example, along with relevant parts of your configuration
and Org/Emacs versions?

Thanks, 

-- 
 Bastien

Re: Replace Org's C-TAB with C-M-TAB - objection?

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Bastien  writes:

> Hi all,
>
> C-TAB in Org is bound to `org-force-cycle-archived' to allow to cycle
> through archived subtrees.
>
> In the Emacs tab-bar mode, it is now bound to `tab-next', which needs
> to work globally.
>
> So Org's binding and tab-bar's one are in conflict, as reported here:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41325
>
> I suggest binding `org-force-cycle-archived' to C-M-TAB: any objection?
>
> Thanks,

I object this change. Emacs tab-bar is not enabled by default. When conflict,
user can customize keybinding. I don't think it's very necessary to change.

- -- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7KVPcUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsNH7gf+NdaEwp1Up/jxbebM65JcBky/Cu6I
9rFQvFOzQ/dIQDb6IpMzOqJta8AwPIXL5tXebs4Af16D8kO5fL+q/noUoxBE7IUA
CQiGlAW3HAeIPFomnkLwSubctfbORJhwmVPoKoNkVoH98eTwuAXQVORzwDpaU7/2
NasQO6KJ1VJ48v8ipXamVO/KcDIYl4zRv5inXcpsigIpXMQ1tkeNAZUB6thaH1xz
3lDy5nSBozfrDZXq8maYV+Oa5cklR6OuNN+0VHk7HBci5vlKHAuMygLXL7M2ftIZ
HkOs56aSlKwql7BzNUnkJuGx5KQVizG6cQy9ide9rjWwf5iZPn6mR8jIbg==
=JWH3
-END PGP SIGNATURE-

Re: [QUESTION] What's the ":desk" link parameter?

[Bastien]

Hi Ihor,

thanks for the patch.  I assume you are submitting it against master,
am I right?

Ihor Radchenko  writes:

> +`:description'
> +
> +  Function to use for generating link descriptions from links.  This
> +  function must take two parameters: the first one is the link, the
> +  second one is the description generated by `org-insert-link'.  The
> +  function should return the description to use.

>From reading this, I don't see what bug it fixes, what problem it
solves or what real user need it responds to, but maybe I lost part
of the context.  Can you explain why this should be applied?

Thanks,

-- 
 Bastien

Re: Org-agenda ignores archive tag set by "#+FILETAGS: ARCHIVE"

[Bastien]

Hi George,

George Sokolsky  writes:

> I have .org files with  "#+FILETAGS: ARCHIVE" headers.

Shouldn't it be "#+FILETAGS: :ARCHIVE:" instead? 

(Note the columns.)

> I want items from these .org files to be hidden by default from results
> of "org-agenda" -> "s Search for keywords" by default.
>
> This is not the case, unfortunately.

Can you be so kind as to test with latest Org from maint or master?

Thanks,

-- 
 Bastien

Re: Customizable fixed indentation column

[Bastien]

Hi Panagiotis,

thanks for this proposal.

I don't have a strong opinion (yet) on whether we should allow to
indent to a custom column by setting org-adapt-indentation to an
integer.  My gut feeling for now is that this is too much, but I 
don't want to dismiss this possibility completely.

That said, the new customization values for org-adapt-indentation
have not yet been released, so I suggest continuing the discussion
for after 9.4 has been released and for after org-adapt-indentation
has been more widely used in its current (from master) state.

Thanks,

-- 
 Bastien

Re: emacs + org-mode in virtual machine/docker/...

[Olivier Berger]

Hi.

On 24/05/2020 11:03, Jens Lechtenboerger wrote:

On 2020-05-23, Olivier Berger wrote:


Hi.

This looks quite similar to my approach to producing course material,
which is documented here : https://olberger.gitlab.io/org-teaching
including the use of Docker (see
https://gitlab.com/olberger/docker-org-teaching-export/ )


Indeed, the philosophy of using the right source format is the same.
Thanks for the pointer.

What I see as differences: Emacs-reveal embeds plugins for audio and
quizzes to create what I hope to be material for asynchronous
learning (particularly useful in Corona times but preferable to
lecturing in “normal” years as well).  It supports a bibliography
slide and focuses on Free and Open Educational Resources with
simplified (in my view) treatment of license information.



I'll have to investigate when time permits. Thanks for these details.


Do you share your teaching material for “Web architecture and
applications (CSC4101)”?



I don't advertize it outside of my classes. But you may find it online 
if you're looking for "accueil du cours CSC4101" in a search engine... 
and know how to read french ;)


Unfortunately some contents included/reused have a dubious copyright 
status, which prevents me from publishing it in a more public way, so 
I'm sticking to a class perimeter (slightly extended) now, to keep in 
the safe side, and given current time/effort available.


Hope this gives you an interesting example though ;)

Best regards,

--
Olivier

Re: emacs + org-mode in virtual machine/docker/...

[Jens Lechtenboerger]

On 2020-05-23, Olivier Berger wrote:

> Hi.
>
> This looks quite similar to my approach to producing course material,
> which is documented here : https://olberger.gitlab.io/org-teaching
> including the use of Docker (see
> https://gitlab.com/olberger/docker-org-teaching-export/ )

Indeed, the philosophy of using the right source format is the same.
Thanks for the pointer.

What I see as differences: Emacs-reveal embeds plugins for audio and
quizzes to create what I hope to be material for asynchronous
learning (particularly useful in Corona times but preferable to
lecturing in “normal” years as well).  It supports a bibliography
slide and focuses on Free and Open Educational Resources with
simplified (in my view) treatment of license information.

Do you share your teaching material for “Web architecture and
applications (CSC4101)”?

Best wishes
Jens

Replace Org's C-TAB with C-M-TAB - objection?

[Bastien]

Hi all,

C-TAB in Org is bound to `org-force-cycle-archived' to allow to cycle
through archived subtrees.

In the Emacs tab-bar mode, it is now bound to `tab-next', which needs
to work globally.

So Org's binding and tab-bar's one are in conflict, as reported here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41325

I suggest binding `org-force-cycle-archived' to C-M-TAB: any objection?

Thanks,

-- 
 Bastien

bug#36228: org agenda tags-todo time-zone bug/inconsistency

[Bastien]

Hi Gary,

Gary Fredericks  writes:

> I use a (tags-todo "SCHEDULED<\"\"" ()) portion of my org agenda
> to suppress scheduled agenda items until their scheduled timestamp
> has passed. In more recent commits of emacs I've found this to be an
> hour off (possibly due to daylight savings time), in a way that's not
> just wrong but also inconsistent with the time shown by the calendar
> agenda (so it's probably not related to a more global timezone
> configuration).

I tried to reproduce this bug with latest Org mode version 9.3.6 and
GNU Emacs 28.0.50 and I could not reproduce it.

I am closing this bug report -- please feel free to reopen it if you
still hit this bug.

Thanks,

-- 
 Bastien

bug#34891: 25.2; ORG-PUBLISH-FIND-DATE should not use Creation/Publish date (#+DATE:) in file as a modification timestamp.

[Bastien]

Hi David,

after Nicolas' answer, I don't see the bug in here, so I am closing
this bug report.

If you think there is still something wrong, please test with latest
Org and report it again on emacs-orgmode@gnu.org.

Thanks,

-- 
 Bastien

bug#34977: org-edit-src-code undesirable behaviour

[Bastien]

Hi,

Nicolas Goaziou  writes:

> I cannot reproduce any of these observations. Could you check that no
> other function is interfering?

Well, I tried and could not reproduce this either.

I am closing the bug report.

-- 
 Bastien

Re: org-clip-link should be included in core

[Adam Porter]

On Sat, May 23, 2020 at 10:14 AM Bastien  wrote:

> So IIUC the need is to easily remove the link part of a link.
>
> I pushed a change to make this easier.  Now you can hit `C-c C-l' on
> a link, empty the link part, keep the description and RET to get only
> the description inserted as non-link text.
>
> Let me know if this seems okay for you.
>
> I'm copying Adam as he may comment on that too.

That seems like an elegant solution.  Thanks, Bastien.

bug#15598: 24.3.50; documentation: org-mode calendar interaction

[Bastien]

Hi Joe,

Joe Corneli  writes:

> The org-mode manual (8.2.1 The date/time prompt) documents this keyboard
> command for selecting dates for scheduling using the calendar:
>
> S-/ One day forward/backward.
>
> However, the documentation string for `org-schedule' (which is the
> command that pops up the calendar) doesn't talk about this at all:

thanks for the report and sorry for the delay (...).

I've update the docstrings here:
https://code.orgmode.org/bzg/org-mode/commit/701c7bed94

Best,

-- 
 Bastien

bug#32722: [O] bug#32722: bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

[Bastien]

AFAICT the issues raised in this thread have been solved, so I am
closing this bug report now.

Org-mode does not encourage users to use GitHub for hosting their
source code, nor does it encourage them to use non-free javascript
by browsing GitHub's page.

Some files in Org still contain references to links starting with
http://github.com but users can use M-x eww on these links and still
get the correct instructions on how to clone the Git repository.

The htmlize/htmlfontify discussion can continue in this report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7506

If anyone think there are things we can still fix in this area,
please reopen this bug report with suggestions on what to fix and
how to fix it.

Thanks!

-- 
 Bastien

bug#33521: 26.1; org html export fails to recorgnize image urls with query parameters

[Bastien]

Hi Ernesto,

I tried exporting a simple .org file with this contents:

  * Some pictures
  
  https://travis-ci.org/erjoalgo/emacs-buttons.svg?branch=master
  
  https://travis-ci.org/erjoalgo/emacs-buttons.png?branch=master
  
  * More pictures
  
  [[https://travis-ci.org/erjoalgo/emacs-buttons.svg?branch=master]]
  
  [[https://travis-ci.org/erjoalgo/emacs-buttons.png?branch=master]]

And all pictures are exporting fine with latest Org.

Also see Nicolas' suggestion to customize org-html-inline-image-rules
if that helps.

I'm closing this bug report now, feel free to reopen it if needed.

Best,

-- 
 Bastien

bug#41325: 27.0.91; org-mode key binding conflicts with tab-bar-mode

[Bastien]

Hi Juri,

Juri Linkov  writes:

>>> Indeed, it seems C-TAB is a less frequently used keybinding in org-mode,
>>> so it could be disabled by org-mode when tab-bar-mode is active.
>>
>> Personally, I never use it.  But it's likely that other users will have
>> a very different experience.
>>
>> Maybe we should contact the org-mode developers to hear what they think
>> about changing the key binding?
>
> I thought that org-mode developers read this bug list?

FWIW, I do read this list in my free time.  If something requires an
urgent attention, don't hesitate to CC my email address of course.

Thanks,

-- 
 Bastien

bug#41325: 27.0.91; org-mode key binding conflicts with tab-bar-mode

[Bastien]

Hi,

Thanks for the report, this should indeed be fixed.

I suggest that Org binds C-M-TAB instead of C-TAB.

I will bring this suggestion to the orgmode list.

-- 
 Bastien

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Bastien]

Nicolas Goaziou  writes:

> Kévin Le Gouguec  writes:
>
>>> (I hope I got that right.)
>
> LGTM. I applied the patch on your behalf.
>
> Now Org has future-proof support for Electric indent mode.

Thanks to both of you for this welcome improvement!

-- 
 Bastien