Re: Need for dedicated kinds of paragraphs

2022-10-17 Thread Sébastien Miquel

Hi,

Damien Cassou writes:

I'm implementing an odt-based exporter for a French magazine named
GNU/Linux Magazine.  This magazine defines several kinds of boxes, which
are small paragraphs of a certain type among "Default", "Attention",
"Warning" and "PAO". When published, the magazine will change the
background of these boxes depending on the type (e.g., using red color
for warning boxes).

I'm not sure what kind of markup to use nor how to transcode that
markup. I tried with:

 #+BOX: attention
 This text will appear with a red background

Does that make sense? Do you have a better suggestion?


I think special blocks are a good fit for this purpose.

--
Sébastien Miquel



Re: Support for tagging (special) blocks

2022-10-04 Thread Sébastien Miquel

Hi,

Ihor Radchenko writes:

Thanks for the clarification!
I did not mean to reduce the font size in affiliated keywords.
I was referring to replacing the display of affiliated keywords:

#+name: A classic
#+tag: easy

will be displayed by Emacs as

#+... A classic :easy:

The underlying text will not be changed.
The hidden parts will be revealed upon cursor entering the affiliated
keywords.


Perhaps something like
#+... name: A classic tag: easy
might be used for any kind of keyword. That'd be quite the trick.

It would certainly improve the situation when an element has several
keywords, but I'm not sure how common that is.

I'll look into implementing such #+name and #+tag keywords, when I
have the time.

On an unrelated note, how is your work on revamping org's
fontification going, if I may ask ? I had had a look at your repo, but
since adapting my configuration would have required some effort I did
not try it.

--
Sébastien Miquel



Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks

2022-10-04 Thread Sébastien Miquel



Ihor Radchenko writes:

See the attached.
I am not sure if we really need the variable.
AFAIU, acting natively was the default in the past for M-q with no
region selection. Then, I "fixed" some bug report in 05ee1e6ee06db and
introduced the bug herein.


You're right, I had not realised org-fill-element already acted natively.

Your patch looks and tests good to me.

--
Sébastien Miquel




Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks

2022-10-03 Thread Sébastien Miquel

Hi,

Ihor Radchenko writes:

I am still getting the described behaviour.
However, it does not happen in Org mode itself.
`fill-paragraph' in emacs-lisp-mode does exactly the observed behaviour.

Try
1. emacs -Q
2. insert
;; A comment
(+ 2 2)
3. M-h M-q

Is it emacs-lisp-mode bug? Or is it illegal to fill-region in source
code buffers?


I think the original report is about M-q, not M-h M-q. M-q behaves as 
expected in emacs-lisp-mode.


Currently, org-fill-paragraph will not work properly when called inside 
src blocks. This can be easily fixed, but probably requires yet another 
org-fill-paragraph-act-natively variable.


--
Sébastien Miquel




Re: Support for tagging (special) blocks

2022-09-03 Thread Sébastien Miquel



Ihor Radchenko writes:
>>   >> On a slightly related note, I find it quite unfortunate that one
>>   >> presently cannot make use of the #+begin_ line of special blocks to
>>   >> set some kind of optional title instead of using #+name or
>>   >> #+attr_latex. That's a lot of wasted real estate.
>>   >
>>   > Yes, but we do not want to overcomplicate Org syntax. Affiliated
>>   > keywords are universal across multiple element types. Adding a
>>   > specialized syntax for src blocks will make things complex 
technically

>>   > and create duplicate code.
>>   >
>>   > We can alter the fontification to compact the screen space 
though. Will

>>   > it suffice?
>>   >
>>
>> I don't see any possible compactification that doesn't hinder
>> readability. From my perspective, it is important that the type of the
>> special block, its title, and its tags are readable.
> I feel that I either misunderstand you here or in the previous message.

To clarify, here are the two alternatives I have in mind.

#+tag: easy
#+attr_latex: A classic
#+begin_exercice
Find a necessary and sufficient condition on $N$ and $P$ for $P = NP$
to hold.
#+end_exercice

#+begin_exercice A classic  :easy:
Find a necessary and sufficient condition on $N$ and $P$ for $P = NP$
to hold.
#+end_exercice

In my first message, I argue that wasting two lines of my screen
hinders reading and navigating the whole org file.

I'm not sure what fontification trick you had in mind to compact the
space, but if you were thinking of making the meta lines smaller, by
say 50%, I argue in my second message that this hinders the
readability of this single exercice. The first three lines each
contain information that is important to me when I browse the file (as
opposed to information that's only relevant for org export).

The only line that contains no content information is the #+end_exercice
line, which is only here for the org parser.


--
Sébastien Miquel



Re: Support for tagging (special) blocks

2022-09-02 Thread Sébastien Miquel



Ihor Radchenko writes:
> Sébastien Miquel  writes:
>
>> Ihor Radchenko writes:
>>   > They do not. Tags are only considered inside headlines. Trying 
to allow
>>   > tags outside headlines will require major changes across the 
whole Org

>>   > codebase and will still make things incompatible with third party
>>   > packages, like org-ql. Not to mention the whole new concept for 
block

>>   > syntax.
>>
>> Tags on block do not need to have the same support as headlines tags.
>> I'm not suggesting they should interact with the agenda or whatnot.
>> Support could be behind a user option, and consist only of say easy
>> tag edition, and `#+exclude_tags:` support. With that scope, the
>> implementation should be fairly simple. As for third party packages,
>> it is up to them whether to extend their features to tagged blocks ;
>> in some case it might not make sense.
>
> We already have ":exports none" header argument.

For src block yes, but not for special blocks.

To explain where I'm coming from : I write mathematical content
categorized using special blocks, such as theorems, exercices, proofs,
personnal notes, etc. Then from a single org file, I export several
pdf files, filtering the content according to the types and tags of
special blocks : for example, to exclude some proofs, or exercices
that are too hard.

>
>>   > If one wants to add "tags" or other keywords associated with 
blocks or
>>   > other Org elements, the right tool to use is affiliated 
keywords. But

>>   > note that Org search infrastructure is tailored towards searching
>>   > headlines.
>>
>> Two inconvenients with using affiliated keywords.
>>1. There would be no uniform treatment with headline tags. In my use,
>>   I have the same tags on headline and blocks, and I filter the
>>   export according to them with #+exclude_tags.
>
> Affiliated keywords are indeed not uniform with headlines. But they are
> uniform with everything else. Paragraphs can have affiliated keywords.
> Or other blocks. Or lists. Or tables...

That's indeed a good point. In fact, I had been wondering recently how
I could tag a single list item, but I guess affiliated keywords still
can't do that.

>
>>2. They waste too much space. Say I have some 20 short exercices
>>   (represented by special blocks). Since I dot not display the
>>   #+end_ line, each of them takes 2 or 3 lines in my screen. If I
>>   want to tag those using affiliated keywords that makes for a 50%
>>   or 33% size increase, with very poor readability.
>
>> On a slightly related note, I find it quite unfortunate that one
>> presently cannot make use of the #+begin_ line of special blocks to
>> set some kind of optional title instead of using #+name or
>> #+attr_latex. That's a lot of wasted real estate.
>
> Yes, but we do not want to overcomplicate Org syntax. Affiliated
> keywords are universal across multiple element types. Adding a
> specialized syntax for src blocks will make things complex technically
> and create duplicate code.
>
> We can alter the fontification to compact the screen space though. Will
> it suffice?
>

I don't see any possible compactification that doesn't hinder
readability. From my perspective, it is important that the type of the
special block, its title, and its tags are readable.

One thing that org can do in that regard is hide the #+end_ line. For
special blocks, a requirement is that the org-block face should apply
to them too, to see where the block ends.


--
Sébastien Miquel



Re: Support for tagging (special) blocks

2022-09-01 Thread Sébastien Miquel

Hi,

Ihor Radchenko writes:
> They do not. Tags are only considered inside headlines. Trying to allow
> tags outside headlines will require major changes across the whole Org
> codebase and will still make things incompatible with third party
> packages, like org-ql. Not to mention the whole new concept for block
> syntax.

Tags on block do not need to have the same support as headlines tags.
I'm not suggesting they should interact with the agenda or whatnot.
Support could be behind a user option, and consist only of say easy
tag edition, and `#+exclude_tags:` support. With that scope, the
implementation should be fairly simple. As for third party packages,
it is up to them whether to extend their features to tagged blocks ;
in some case it might not make sense.

> If one wants to add "tags" or other keywords associated with blocks or
> other Org elements, the right tool to use is affiliated keywords. But
> note that Org search infrastructure is tailored towards searching
> headlines.

Two inconvenients with using affiliated keywords.
 1. There would be no uniform treatment with headline tags. In my use,
I have the same tags on headline and blocks, and I filter the
export according to them with #+exclude_tags.
 2. They waste too much space. Say I have some 20 short exercices
(represented by special blocks). Since I dot not display the
#+end_ line, each of them takes 2 or 3 lines in my screen. If I
want to tag those using affiliated keywords that makes for a 50%
or 33% size increase, with very poor readability.

On a slightly related note, I find it quite unfortunate that one
presently cannot make use of the #+begin_ line of special blocks to
set some kind of optional title instead of using #+name or
#+attr_latex. That's a lot of wasted real estate.


--
Sébastien Miquel



Support for tagging (special) blocks

2022-08-31 Thread Sébastien Miquel

Hi,

I've been using tags on special blocks, src blocks and other, for two
purposes:

 1. to control which blocks get exported, using the `#+exclude_tags`
property.
 2. to fine tune the export, according to tags, of special blocks such as
#+BEGIN_exercice:hard:
…
#+END_exercice

Does anyone think this is useful and might warrant adding support for ?

--
Sébastien Miquel



Re: [PATCH] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)

2022-08-29 Thread Sébastien Miquel

Hi Ihor,

I've implemented this proposal in the patch attached.

Does it look good to you ?

--
Sébastien MiquelFrom b1b783dc80821b07937ac4211ec28df8726fff1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sat, 13 Aug 2022 20:49:27 +0200
Subject: [PATCH] New babel syntax to pass src block contents as argument

* lisp/ob-ref.el (org-babel-ref-resolve): Add support for
`named-block[]' syntax, resolving to the contents of a named-block.
* lisp/ob-core.el (org-babel-read-element): Read a code block into its
contents, like other blocks.
* testing/listp/test-ob.el (test-ob/block-content-resolution): Test
block content resolution.
* doc/org-manual.org: Document syntax.
* etc/ORG-NEWS: Document syntax.
---
 doc/org-manual.org  |  7 ---
 etc/ORG-NEWS|  5 +
 lisp/ob-core.el |  2 +-
 lisp/ob-ref.el  | 10 ++
 testing/lisp/test-ob.el | 15 +++
 5 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 57a57a6fe..794682b49 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17505,9 +17505,10 @@ a colon, for example: =:var table=other-file.org:example-table=.
   : 4
   #+end_example
 
-- literal example ::
+- literal example, or code block contents ::
 
-  A literal example block named with a =NAME= keyword.
+  A code block or literal example block named with a =NAME= keyword,
+  followed by brackets (optional for example blocks).
 
   #+begin_example
   ,#+NAME: literal-example
@@ -17517,7 +17518,7 @@ a colon, for example: =:var table=other-file.org:example-table=.
   ,#+END_EXAMPLE
 
   ,#+NAME: read-literal-example
-  ,#+BEGIN_SRC emacs-lisp :var x=literal-example
+  ,#+BEGIN_SRC emacs-lisp :var x=literal-example[]
 (concatenate #'string x " for you.")
   ,#+END_SRC
 
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 7dae03dc6..d6d99a64b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -288,6 +288,11 @@ The =org-md-toplevel-hlevel= customization variable sets the heading
 level used for top level headings, much like how
 =org-html-toplevel-hlevel= sets the heading level used for top level
 headings in HTML export.
+*** Babel: new syntax to pass the contents of a src block as argument
+
+Use the header argument =:var x=code-block[]= or
+: #+CALL: fn(x=code-block[])
+to pass the contents of a named code block as a string argument.
 
 ** New options
 *** A new custom setting =org-hide-drawer-startup= to control initial folding state of drawers
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 68dd5557c..c52ef9ed6 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2156,7 +2156,7 @@ Return nil if ELEMENT cannot be read."
 	(or (org-babel--string-to-number v) v)))
  (`table (org-babel-read-table))
  (`plain-list (org-babel-read-list))
- (`example-block
+ ((or `example-block `src-block)
   (let ((v (org-element-property :value element)))
 	(if (or org-src-preserve-indentation
 		(org-element-property :preserve-indent element))
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index 87a7ccf63..ee2745e09 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -124,12 +124,14 @@ Emacs Lisp representation of the value of the variable."
   (save-excursion
 	(let ((case-fold-search t)
 	  args new-refere new-header-args new-referent split-file split-ref
-	  index)
+	  index contents)
 	  ;; if ref is indexed grab the indices -- beware nested indices
-	  (when (and (string-match "\\[\\([^\\[]+\\)\\]$" ref)
+	  (when (and (string-match "\\[\\([^\\[]*\\)\\]$" ref)
 		 (let ((str (substring ref 0 (match-beginning 0
 		   (= (cl-count ?\( str) (cl-count ?\) str
-	(setq index (match-string 1 ref))
+(if (> (length (match-string 1 ref)) 0)
+	(setq index (match-string 1 ref))
+  (setq contents t))
 	(setq ref (substring ref 0 (match-beginning 0
 	  ;; assign any arguments to pass to source block
 	  (when (string-match
@@ -171,7 +173,7 @@ Emacs Lisp representation of the value of the variable."
 (throw :found
    (org-babel-execute-src-block
 	nil (org-babel-lob-get-info e) params)))
-			   (`src-block
+			   ((and `src-block (guard (not contents)))
 (throw :found
    (org-babel-execute-src-block
 	nil nil
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index a62bd56bf..c944ccd39 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -178,6 +178,21 @@ should still return the link."
 			(point-at-bol)
 			(point-at-eol))
 
+(ert-deftest test-ob/block-content-resolution ()
+  "Test block content resolution."
+  (org-test-with-temp-text-in-file "
+
+#+name: four
+#+begin_src emacs-lisp
+  (list 1 2 3 4)
+#+end_src
+
+#+begin_src emacs-lisp :var four=four[]
+  (length (eval (car (read-from-string four
+#+end_src"
+   (org-babel-next-src-block 2)
+   (should 

Re: [PATCH] org-babel: Do not echo output of resolved noweb references

2022-07-21 Thread Sébastien Miquel



Hi,

Ihor Radchenko writes:
> Let me know if you see any potential issues with the proposed change.

Thanks for looking into this. I think the change looks right, though I
am no great user of org-babel and its header arguments.

Regards,

--
Sébastien Miquel



Re: [PATCH] lisp/org.el: Fix `org-fill-paragraph' in lists when `mark-active'

2022-07-19 Thread Sébastien Miquel



Hi,

Renato Ferreira writes:
> Go to start of list, `org-mark-element`, then `org-fill-paragraph`. 
The first item does not get filled.


This should be fixed on main. If not, please say so.

I'm removing this from updates.orgmode.org:
Canceled.

--
Sébastien Miquel



Re: bug#52771: 29.0.50; org-fill-paragraph does not work for several plain lists

2022-07-19 Thread Sébastien Miquel




Kyle Meyer writes:
> Rudolf Adamkovič writes:
>
>> Reproduction steps:
>>
>> 1. start "emacs -Q"
>> 2. type "C-x C-f" and "test.org" and RET   
>> 3. type the following:
>>
>> - one
>>   two
>>
>> - three
>>   four
>>
>> 4. mark all with "C-x h"
>> 5. type "M-q" to fill
>>
>> Actual:
>>
>> - one
>>   two
>>
>> - three four
>>
>> Expected:
>>
>> - one two
>>
>> - three four

This is fixed on main.

Marking it as resolved on updates.orgmode.org:
Fixed.

--
Sébastien Miquel



Re: [FR] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)

2022-07-17 Thread Sébastien Miquel



Hi,

Ihor Radchenko writes:
> Hmm. You are right. I missed "optionally".
>
> Still, I find this idea as the best solution for people who want to
> process the source block text during noweb expansion.
>
> Alternative ideas are welcome though. I'd prefer to avoid breaking
> change if we can find an equally simple syntax alternative to assign
> source block code to a variable.

The uses are maybe too niche to warrant the breaking change. A syntax
extension like
 : var=block-id[]
seems possible, even though brackets are already overloaded.

One alternative is to only allow the syntax inside noweb brackets
instead of generic variable arguments. I assume there'd be much less
breakage. It would also makes sense to allow noweb references instead
of block ids. We'd add support for
 : <>
and <> would also insert the contents as a
by-product.

Do you have any example of use in mind, beyond my original one ?

Regards,

--
Sébastien Miquel



Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]

2022-07-04 Thread Sébastien Miquel

Marking this as resolved on updates.orgmode.org, 2nd try.

|Fixed.|

--
Sébastien Miquel


Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]

2022-07-04 Thread Sébastien Miquel

Marking this as resolved on updates.orgmode.org.

|Fixed.|

--
Sébastien Miquel


Re: [PATCH] org.el (org-latex-preview): With an active region, act on it

2022-07-04 Thread Sébastien Miquel

Marking this as resolved on updates.orgmode.org.

Applied.

--
Sébastien Miquel




Re: [PATCH] org.el: Fix the filling of regions containing lists

2022-07-04 Thread Sébastien Miquel

Applied, as 4e4250061.

Took a little while :P

--
Sébastien Miquel




Re: [PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before PACKAGES

2022-06-17 Thread Sébastien Miquel

Ihor Radchenko writes:

Thanks for the clarification! Now, your patch makes much more sense. Can
you update the commit message explaining the above shortly and linking
to this thread?


See attached.

Thanks,

--
Sébastien Miquel
From 72742cab341f66525e0acb0b92de65fb6d24c27f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 13 Jun 2022 11:04:34 +0200
Subject: [PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before
 PACKAGES

* lisp/org.el (org-format-latex-header): put DEFAULT-PACKAGES before
PACKAGES, as per org-latex-packages-alist's documentation.

`org-format-latex-header' is mostly used to generate in-buffer images
from LaTeX fragments. For LaTeX document export, the header is
generated by `org-splice-latex-header' ond `org-latex-classes' instead
and the default and documented behaviour is to insert DEFAULT-PACKAGES
before PACKAGES.

See also
https://list.orgmode.org/877d5gg5rt.fsf@localhost/T/#m2ad2f3b1509e1af72016e8e6fad3557ff3083046
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 95dff27ad..0acfa4846 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3248,8 +3248,8 @@ images at the same place."
 
 (defcustom org-format-latex-header "\\documentclass{article}
 \\usepackage[usenames]{color}
-\[PACKAGES]
 \[DEFAULT-PACKAGES]
+\[PACKAGES]
 \\pagestyle{empty} % do not remove
 % The settings below are copied from fullpage.sty
 \\setlength{\\textwidth}{\\paperwidth}
-- 
2.36.1



Re: [PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before PACKAGES

2022-06-14 Thread Sébastien Miquel

Hi,

Ihor Radchenko writes:

We actually have 2 options here:
1. Change the docstring
2. Change the template

Can moving [PACKAGES] up break the existing configs? It might.
I am inclined to change the docstring instead.


Thanks for having a look at this.

It makes more sense for a package in PACKAGES to depend on a
DEFAULT-PACKAGE than vice versa.

=org-latex-packages-alist= and =org-latex-classes=' are two important
docstrings. People are likely to have crafted their configuration by
reading these documentation.

I've also just checked that by default, for document export,
DEFAULT-PACKAGES are inserted before PACKAGES --- the default
templates from =org-latex-classes= do not include =DEFAULT-PACKAGES=
nor =PACKAGES=, and in this case, =org-splice-latex-header= adds both
default packages and packages at the end, with default packages coming
first.

=org-format-latex-header= is only used to generate images for preview,
and in some cases by ob-latex to compile a document from a LaTeX src
block.

Regards,

--
Sébastien Miquel




[PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before PACKAGES

2022-06-13 Thread Sébastien Miquel

Hi,

The attached patch puts DEFAULT-PACKAGES before PACKAGES in 
org-format-latex-header, as per org-latex-packages-alist's and 
org-latex-classes' documentations.


Regards,

--
Sébastien Miquel
From 983e35f19371e3ea85ed28bd46f36ea5a52a3950 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 13 Jun 2022 11:04:34 +0200
Subject: [PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before
 PACKAGES

* lisp/org.el (org-format-latex-header): put DEFAULT-PACKAGES before
PACKAGES, as per org-latex-packages-alist's documentation.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 95dff27ad..0acfa4846 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3248,8 +3248,8 @@ images at the same place."
 
 (defcustom org-format-latex-header "\\documentclass{article}
 \\usepackage[usenames]{color}
-\[PACKAGES]
 \[DEFAULT-PACKAGES]
+\[PACKAGES]
 \\pagestyle{empty} % do not remove
 % The settings below are copied from fullpage.sty
 \\setlength{\\textwidth}{\\paperwidth}
-- 
2.36.1



Re: [PATCH] org.el (org-latex-preview): With an active region, act on it

2022-06-10 Thread Sébastien Miquel

Hi,

Daniel Fleischer writes:

Hi Miquel, thanks for the patch! It's useful and works nicely - both in
creating and removing the previews. Let's give it a couple more days for
feedback and then feel free to merge the patch.


Thanks for your comment and testing this.

Note that I do not have merge access to the repository.

Regards,

--
Sébastien Miquel




[PATCH] org.el (org-latex-preview): With an active region, act on it

2022-06-08 Thread Sébastien Miquel

Hi,

The attached patch modifies org-latex-preview to display all images of 
latex fragments in a region, when one is active.


Using prefix arguments it is already possible to display all images in 
the buffer, or in the current section, but I find it often too slow and 
unnecessary. Regards,


--
Sébastien Miquel
From 2c9b72731247620dea2aed96a0a83385472e29cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Wed, 8 Jun 2022 13:11:12 +0200
Subject: [PATCH] org.el (org-latex-preview): With an active region, act on it

* lisp/org.el (org-latex-preview): With an active region, display
images for all fragments in the region. With universal prefix
argument, remove all images in the region.
---
 lisp/org.el | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 95dff27ad..07f481647 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15307,7 +15307,8 @@ BEG and END are buffer positions."
 If the cursor is on a LaTeX fragment, create the image and
 overlay it over the source code, if there is none.  Remove it
 otherwise.  If there is no fragment at point, display images for
-all fragments in the current section.
+all fragments in the current section.  With an active region,
+display images for all fragments in the region.

 With a `\\[universal-argument]' prefix argument ARG, clear images \
 for all fragments
@@ -15335,10 +15336,18 @@ fragments in the buffer."
;; Clear current section.
((equal arg '(4))
 (org-clear-latex-preview
- (if (org-before-first-heading-p) (point-min)
-   (save-excursion
-	 (org-with-limited-levels (org-back-to-heading t) (point
- (org-with-limited-levels (org-entry-end-position
+ (if (use-region-p)
+ (region-beginning)
+   (if (org-before-first-heading-p) (point-min)
+ (save-excursion
+	   (org-with-limited-levels (org-back-to-heading t) (point)
+ (if (use-region-p)
+ (region-end)
+   (org-with-limited-levels (org-entry-end-position)
+   ((use-region-p)
+(message "Creating LaTeX previews in region...")
+(org--latex-preview-region (region-beginning) (region-end))
+(message "Creating LaTeX previews in region... done."))
;; Toggle preview on LaTeX code at point.
((let ((datum (org-element-context)))
   (and (memq (org-element-type datum) '(latex-environment latex-fragment))
-- 
2.36.1


Re: [PATCH] lisp/org.el: Fix `org-fill-paragraph' in lists when `mark-active'

2022-05-31 Thread Sébastien Miquel

Hi,

Renato Ferreira writes:

I stumbled upon a bug introduced by it: filling lists with active region.

# MRE:

Go to start of list, `org-mark-element`, then `org-fill-paragraph`. The first 
item does not get filled.

```org
* This is a test

- Aliquam erat volutpat.  Nunc eleifend leo vitae magna.  In id erat non orci 
commodo lobortis.  Proin neque massa, cursus ut, gravida ut, lobortis eget, 
lacus.  Sed diam.  Praesent fermentum tempor.
- Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit 
tempor tellus.  Donec pretium posuere tellus. Proin quam nisl, tincidunt et, 
mattis eget, convallis nec, purus. Cum sociis natoque.
- Aliquam erat volutpat.  Nunc eleifend leo vitae magna.  In id erat non orci 
commodo lobortis.  Proin neque massa, cursus ut, gravida ut, lobortis eget, 
lacus.  Sed diam.  Praesent fermentum tempor tellus.
```

See also
https://list.orgmode.org/041ca43d-2efb-db1e-76ab-7c15af088...@posteo.eu/
where I submitted a different patch that fixes this issue (I think) and
a couple of others.

Regards,

--
Sébastien Miquel




Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments

2022-05-31 Thread Sébastien Miquel

Hi,

Ihor Radchenko writes:

Can you provide more concrete examples?


Some drawbacks:
   + doesn't work for all languages (does work for LaTeX)

Which languages do not work?

Most languages do not work. Using your proposed solution, what I'm
trying to do is

#+name:javascript-header
#+begin_src javascript :tangle no
some javascript, with \ and " to be escaped
#+end_src

#+name: string-escape
#+begin_src emacs-lisp :var str="" :tangle no
(prin1-to-string (string-trim-right str))
#+end_src

#+begin_src emacs-lisp :noweb yes :tangle yes
(setq javascript-header <>)
#+end_src

If you replace javascript with latex, it happens to work, because when
org executes a latex block, it prints its content.

The goal is to tangle to some lisp code whose purpose is to generate
LaTeX/javascript code. Quite niche admittedly, though as you showed,
it could also be used to string-escape documentation.


   + the tangle gets very noisy: not only are the result of execution
     printed in the echo buffer, but emacs visits the tangling buffer
     and moves the point to each block.
     Perhaps this is a bug that can be fixed.

Did you try to play with :results header argument to disable messages?
What exactly went unexpected?


I did. I might have missed something, but no combination of :results
argument to both the latex block and the string-escape block silences
the tangle (except for :results none, which doesn't tangle the content
of the block). During tangle, the contents of the latex block are
displayed (shortly) in the echo buffer (check *Messages*), and the
point very briefly moves to the latex block. This isn't very
noticeable with a single block.

   + src block execution also resets the noweb cache, slowing down
     tangle, though I have not tried to measure the effect.

I am not sure what you are referring to here. Can you elaborate?


Lines 2892-2893 of (my) ob-core.el, in org-babel-expand-noweb-references:


         ;; Evaluation can potentially modify the buffer
         ;; and invalidate the cache: reset it.


Regards,

--
Sébastien Miquel


Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments

2022-05-30 Thread Sébastien Miquel

Hi,

Ihor Radchenko writes:

Thinking about the whole idea of :noweb-trans more, I see little benefit
compared to something like:

#+name: documentation
This is a sample function documentation.
Because there are "quotes", it must be escaped and cannot be directly
used as noweb-reference.

#+name: doc-escape
#+begin_src emacs-lisp :var str="" :tangle no
(prin1-to-string (string-trim-right str))
#+end_src

#+begin_src emacs-lisp :tangle yes
(defun test ()
<>
t)
#+end_src

I had converted my uses (tangling code, not text/documentation) to
this but I ended up reverting.

Some drawbacks:
 + doesn't work for all languages (does work for LaTeX)
 + the tangle gets very noisy: not only are the result of execution
   printed in the echo buffer, but emacs visits the tangling buffer
   and moves the point to each block.
   Perhaps this is a bug that can be fixed.
 + src block execution also resets the noweb cache, slowing down
   tangle, though I have not tried to measure the effect.

As stated in the OP, I find it unfortunate that org does not provide
any way to tangle the content of a src block to a string representing
this code. If anyone shows any interest, I've provided two possible
implementations in this thread, that I can rebase.

Regards,

--
Sébastien Miquel




Re: [PATCH] New LaTeX code export option: engraved

2022-05-10 Thread Sébastien Miquel

Hi,

Timothy writes:

  2. `minted` supports a `mathescape` option to render math content
     inside code. `fvextra` supports the same option, but maths
     characters are escaped by engrave-faces-latex-face-mapper.

I’l also take a look at this:)

Implemented in engrave-faces-latex, but not worked into ox-html yet. If you
could check it out on the engrave-faces-latex side and check it’s behaving
sanely, that would be helpful.


I've tried it, and mathescape works, thanks !

--
Sébastien Miquel


Re: [PATCH] New LaTeX code export option: engraved

2022-05-09 Thread Sébastien Miquel

Hi Timothy,

I'm quite exited and impressed to see this alternative to minted,
thank you.

I haven't been able to test your patches to org, but I have tried
engrave-faces.el. Here's a couple issues I've run into.

 1. engrave-faces-generate-preset generates emacs colors such as
    `:foreground "grey70"` which are not supported by
    engrave-faces-latex-gen-preamble-line and co.
 2. `minted` supports a `mathescape` option to render math content
    inside code. `fvextra` supports the same option, but maths
    characters are escaped by engrave-faces-latex-face-mapper.

Regards,

--
Sébastien Miquel




Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments

2022-04-30 Thread Sébastien Miquel


Ihor Radchenko writes:

#+name: documentation
This is a sample function documentation.
Because there are "quotes", it must be escaped and cannot be directly
used as noweb-reference.

#+name: doc-escape
#+begin_src emacs-lisp :var str="" :tangle no
(prin1-to-string (string-trim-right str))
#+end_src

#+begin_src emacs-lisp :tangle yes
(defun test ()
<>
t)
#+end_src


Nice ! Quite obscure and brittle (doesn't work if documentation is a 
text src block) but I can use it nonetheless.


Other than :noweb-trans, the patch looks good for me. 
Here's a patch with only the :noweb-prefix part. If applied, we can mark 
this thread resolved.


Thanks,

--
Sébastien Miquel
From 3fc3c3557b27026e2cfdb2a1973921c1baf3758a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 6 Sep 2021 18:45:42 +0200
Subject: [PATCH] ob-core.el: Add `:noweb-prefix` babel header argument

* lisp/ob-core.el (org-babel-expand-noweb-references): Add support for
`noweb-prefix' header argument, to not repeat the prefix characters
when expanding a noweb reference.
(org-babel-common-header-args-w-values):
(org-babel-safe-header-args): Add `noweb-prefix' value.
* doc/org-manual.org: Document `noweb-prefix' babel header argument.
* etc/ORG-NEWS: Document `:noweb-prefix'.
---
 doc/org-manual.org | 17 +
 etc/ORG-NEWS   |  6 +-
 lisp/ob-core.el| 17 -
 3 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6768ca98d..c9c1c1298 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18760,6 +18760,23 @@ else:
 print('do things when false')
 #+end_example
 
+This prefix behavior can be turned off in a block by setting the
+=noweb-prefix= header argument to =no=, as in:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb-prefix no
+  (setq example-data "<>")
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+which expands to:
+
+#+begin_example
+(setq example-data "this is the
+multi-line body of example")
+#+end_example
+
 When in doubt about the outcome of a source code block expansion, you
 can preview the results with the following command:
 
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 2b539d305..1e8558c7b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -150,7 +150,7 @@ The entry points are ~org-persist-register~, ~org-persist-unregister~,
 ~org-persist-read~, and ~org-persist-read-all~.  Storing circular
 structures is supported.  Storing references between different
 variables is also supported (see =:inherit= key in
-~org-persist-register~).  
+~org-persist-register~).
 
 The library permits storing buffer-local variables.  Such variables
 are linked to the buffer text, file =inode=, and file path.
@@ -175,6 +175,10 @@ the =compact-itemx= export option, or globally using the
 Items in a description list that begin with =Function:=, =Variable:=
 or certain related prefixes are converted using Texinfo definition
 commands.
+*** New =:noweb-prefix= babel header argument
+
+=:noweb-prefix= can be set to =no= to prevent the prefix characters
+from being repeated when expanding a multiline noweb reference.
 
 ** New functions and changes in function arguments
 
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 65907..09d6adfe0 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -413,6 +413,7 @@ then run `org-babel-switch-to-session'."
 (noweb	. ((yes no tangle no-export strip-export)))
 (noweb-ref	. :any)
 (noweb-sep  . :any)
+(noweb-prefix . ((no yes)))
 (output-dir . :any)
 (padline	. ((yes no)))
 (post   . :any)
@@ -438,8 +439,8 @@ specific header arguments as well.")
 
 (defconst org-babel-safe-header-args
   '(:cache :colnames :comments :exports :epilogue :hlines :noeval
-	   :noweb :noweb-ref :noweb-sep :padline :prologue :rownames
-	   :sep :session :tangle :wrap
+	   :noweb :noweb-ref :noweb-sep :noweb-prefix :padline
+   :prologue :rownames :sep :session :tangle :wrap
 	   (:eval . ("never" "query"))
 	   (:results . (lambda (str) (not (string-match "file" str)
   "A list of safe header arguments for babel source blocks.
@@ -2827,6 +2828,10 @@ block but are passed literally to the \"example-block\"."
  (lang (nth 0 info))
  (body (nth 1 info))
 	 (comment (string= "noweb" (cdr (assq :comments (nth 2 info)
+ (noweb-prefix (let ((v (assq :noweb-prefix (nth 2 info
+ (or (not v)
+ (and (org-not-nil (cdr v))
+  (not (equal (cdr v) "no"))
 	 (noweb-re (format "\\(.*?\\)\\(%s\\)"
 			   (with-current-buffer parent-buffer
 			 (org-babel-noweb-wrap
@@ -2923,9 +2928,11 @@ block but are passed literally to the \"example-block\"."
 			(push info (gethash ref cache))
 		 (funcall 

Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments

2022-04-29 Thread Sébastien Miquel

Hi,

Ihor Radchenko writes:

prin1-to-string is too specific and only solves a single use-case.

prin1-to-string is actually universal in a way, since any other
manipulation can then be achieved with

: (setq var (do-something <>))

at least as long as you're tangling to a programming language, that
can read lisp strings.

Consider the following example:

#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no :noweb-trans 
prin1-to-string
<>
(setq latex-header <>)
#+END_SRC

There are two noweb references here. Setting source block-wide
:noweb-trans is not helpful because the first reference will be
incorrectly filtered through prin1-to-string.

Indeed. Originally I had thought of adding a new syntax <<"nw">> to
insert a string representation. I've attached a new patch, that does
this instead of introducing :noweb-trans. Now that I think of the
universality of prin1-to-string, I actually like it slightly better
than :noweb-trans. It would break existing "nw"-like noweb references.

Of course, one can work around this easily enough by using two blocks.

I'd rather introduce a new syntax to transform the noweb reference
inline. Something like

#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no
<>
(setq latex-header <<(prin1-to-string nw)>>)
#+END_SRC

You'd need to only allow a single function call with only one
argument, or use something like <<(prin1-to-string <>)>>. The
change would be much more complex than what I propose, for maybe
little benefit.

[...]

This sounds a bit confusing. I would also add an example where it is
useful to set :noweb-prefix to no.


I've added such an example in the revised patch attached.

Thanks for the feedback.

Regards,

--
Sébastien Miquel
From 99d043b9d837a2658e60fb4b4913454d9566519b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 6 Sep 2021 18:45:42 +0200
Subject: [PATCH] ob-core.el: Add `:noweb-prefix`, `:noweb-trans` babel header
 arguments

* lisp/ob-core.el (org-babel-expand-noweb-references): Add support for
`noweb-prefix' header argument, to not repeat the prefix characters
when expanding a noweb reference. Add support for `noweb-trans' header
argument, to apply a function to the noweb content upon
expansion.
(org-babel-common-header-args-w-values):
(org-babel-safe-header-args): Add `noweb-prefix' and `noweb-trans' values.
* doc/org-manual.org: Document `noweb-prefix' and `noweb-trans' babel header
arguments.
* etc/ORG-NEWS: Document `:noweb-prefix' and `:noweb-trans'.
---
 doc/org-manual.org | 42 ++
 etc/ORG-NEWS   | 10 +-
 lisp/ob-core.el| 26 --
 3 files changed, 71 insertions(+), 7 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6768ca98d..5ef8e2f8b 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18760,6 +18760,48 @@ else:
 print('do things when false')
 #+end_example
 
+This prefix behavior can be turned off in a block by setting the
+=noweb-prefix= header argument to =no=, as in:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb-prefix no
+  (setq example-data "<>")
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+which expands to:
+
+#+begin_example
+(setq example-data "this is the
+multi-line body of example")
+#+end_example
+
+The header argument =noweb-trans= can be set to =prin1-to-string= to
+insert a lisp string representing the content of the referenced src
+block. With:
+
+#+begin_example
+,#+NAME: latex-header
+,#+BEGIN_SRC latex
+  \usepackage{amsmath}
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+this code block:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb yes :noweb-trans prin1-to-string
+  (setq header <>)
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+expands to:
+
+: (setq header "\\usepackage{amsmath}")
+
 When in doubt about the outcome of a source code block expansion, you
 can preview the results with the following command:
 
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 2b539d305..70f7606db 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -150,7 +150,7 @@ The entry points are ~org-persist-register~, ~org-persist-unregister~,
 ~org-persist-read~, and ~org-persist-read-all~.  Storing circular
 structures is supported.  Storing references between different
 variables is also supported (see =:inherit= key in
-~org-persist-register~).  
+~org-persist-register~).
 
 The library permits storing buffer-local variables.  Such variables
 are linked to the buffer text, file =inode=, and file path.
@@ -175,6 +175,14 @@ the =compact-itemx= export option, or globally using the
 Items in a description list that begin with =Function:=, =Variable:=
 or certain related prefixes are converted using Texinfo definition
 commands.
+*** New =:noweb-prefix= and =:noweb-trans= babel header arguments
+
+=:noweb-prefix= can be set to =no= to preve

Re: Bug: asynchronous export (org-mode 9.4.4, emacs 27.2)

2022-03-08 Thread Sébastien Miquel

M. Pger writes:
Thx for your answer. I've just upgraded org-mode (elpa way) and I am 
now using version 9.5.2.


Version 9.5.2 should indeed contain the fix I had in mind :

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c91271297dbbfc831874d7880343603881bdac9c


Unfortunately this does not work, I still end up with:

Invalid read syntax: "#"

Can you check that the right version of org-mode is picked-up, with
`describe-function` `org-latex-export-to-pdf`, find the function
definition by following the `ox-latex.el` link, and check that the
source contains the linked patch ?
I would like to try the alternative, i.e. disabling native-comp (for 
the export function I guess). Would you mind telling me how to do that?


`describe-function` should also tell you whether the function is
native compiled. If it is, you can temporarily 'uncompile' by
evaluating its source code. By disabling native compilation I meant as
a compile flag, if you've built emacs from source. I cannot find an
easy way to prevent native compilation of a single package/function.

--
Sébastien Miquel


Re: Bug: asynchronous export (org-mode 9.4.4, emacs 27.2)

2022-03-08 Thread Sébastien Miquel

Hi,

M. Pger writes:
When trying to asynchronously export, I get the following error: 
"Process `org-export-process'exited abnormally".


The *Org Export Process* buffer gives the following: Invalid read 
syntax: "#".


A similar issue was fixed in master. Try the latest version of org-mode.

Alternatively, disabling native-comp should also fix this.

Regards,

--
Sébastien Miquel


Re: Root heading when exporting sub-trees

2022-02-15 Thread Sébastien Miquel

Hi,

Michael Dauer writes:
When I export a subtree I normally want to produce a document for the 
topic of the subtree. So I would expect that the contents of the 
subtree would be exported with the heading as title (and maybe file 
name) and the children promoted to level 1.


This is the expected behaviour (except for the file name), and what I
get when I run C-c C-e C-s l o.


What I receive is something like this:
[...]
The whole first level of this outline is pointless.


Looking at the code, I don't understand how you can get this outcome.

Regards,

--
Sébastien Miquel




Re: [PATCH] Add support for $…$ latex fragments followed by a dash

2022-01-27 Thread Sébastien Miquel

Hi,

Ihor Radchenko writes:

We can theoretically make a change to support "-", but then it will be
logical to support $i$th as well. (If we don't some users will still be
confused after trying to write $i$th and then not getting the expected
results).


I disagree.
 1. The $…$- pattern is also used for other common constructions, such
    as $n$-dimensional, $K$-lipschitz, etc. As for $n$−th vs $n$th, both
    are commonly used. In french, $n$− is the correct one.
 2. It does not logically follow that we should support $i$th as well,
    since, as you point out, it'd be impossible. One argument for the
    patch is that is it very simple.
 3. The $n$th construction failing is not as confusing. One
    understands quickly what the limitation is, and several
    workarounds are available, whereas there's no good reason for the
    $n$− limitation, and it's harder to think of a workaround.

I should mention that the zero-width space character can be used to
work around both limitations.


Given the raised concerns, may we solve the issue with too verbose
\(...\) unambiguous syntax using the following approach:
1. Fontify \(...\) replacing the brackets with a single character. For
example:

   \(...\) -> ⁅...⁆

2. Provide convenient way to input \(\) brackets through
electric-pair-mode or trough org-cdlatex-mode.

If the $…$ syntax were to be deprecated, this would be a nice
addition, indeed. As a user, I find it quite satisfactory (with some
added utility to easily switch between the \(…\) and \[…\] syntax).
Some possible drawbacks :
 - are the display hacks scalable in a large document, with many LaTeX
   snippets ?
 - this feature may still be hard to discover, turn on and use by
   users more concerned with mathematical content and less familiar
   with emacs features such as fontification, automatic insertion of
   complex delimiters and whatnot.
 - hiding the syntax feels a bit weird, although it is already
   done with emphasis markers.

With respect to the possible deprecation of the $…$ syntax, the
drawbacks and complexity of this alternative should be weighted
against those of the current $…$ syntax, but no one has really spelled
out what the latter are. We're trading complexity here for complexity
there, fixing the false positives (but how common are they ?) and the
false negatives (which can be an annoyance while writing a snippet).

Thank you for bringing this up,

Regards,

--
Sébastien Miquel




Re: [PATCH] Add support for $…$ latex fragments followed by a dash

2022-01-27 Thread Sébastien Miquel

Hi,

Tom Gillespie writes:

The change is local and minor.

We can't know that.

I meant that the change to the syntax would be minor and local, with
respect to the linked syntax document.


#+begin_src org
I spent $20 on food and was paid$-10 dollars by friends so
I am down $10.
#+end_src
[...]
#+begin_src org
Text a $A_BASH_VAR
Text b some-$-lisp-var
#+end_src

The proposed change would break any file with a pattern like
this.

As you say, your first example is a typo. As for the second example,
it's a very uncommon pattern, and if such variable names occur in a
document, they should either be inside src blocks, or inside verbatim
or code markers. In both case, there's no breakage with respect to
parsing, export and tangling. The fontification may fail though. It
wont fail if your src blocks are fontified natively, and the
fontification of $…$ can be globally disabled.


We have no way of seeing every org file that users have
written so we don't know the extent of the impact, and thus
have to assume that there would be some impact. Making
such a change with an unknown blast radius in the midst of
considering removing support for that syntax altogether is
inviting disaster.

We can make an educated guess. It is quite likely that this change
will fix more documents than it breaks. Hardly a disaster.

Regards,

--
Sébastien Miquel




Re: [PATCH] Add support for $…$ latex fragments followed by a dash

2022-01-26 Thread Sébastien Miquel

Hi,

Tom Gillespie writes:

Unfortunately this falls into the realm of changes to syntax. The current
behavior is not a bug and is working as specified because hyphen minus
(U+002D) does not count as punctuation for the purposes of org syntax.
We should specify which chars count as punctuation in the syntax doc.
As noted by Eric \(\) has no such restrictions.

Fromhttps://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments

POST is any punctuation (including parentheses and quotes) or space character, 
or the end of line.


With this patch, I also propose to change the specification
accordingly. The change is local and minor.

Regards,

--
Sébastien Miquel


Re: Poor org-babel-tangle-file performance with more than 100 trivial noweb-references

2022-01-25 Thread Sébastien Miquel

Hi,

pareto optimal writes:
Using =emacs -Q= to tangle org files with more than over 100 
noweb-refs gets slow fast.

I can reproduce the slow down with my config. The culprit is
~org-element--cache-verify-element~. Significantly decreasing
=org-element--cache-self-verify-frequency= yields a 5x speedup.

Perhaps the frequency of the second
: (< (random 1000) (* 1000 org-element--cache-self-verify-frequency))
call in ~org-element--cache-verify-element~ should be decreased.

Regards,

--
Sébastien Miquel


Re: [PATCH] Add support for $…$ latex fragments followed by a dash

2022-01-25 Thread Sébastien Miquel

Hi,

Eric S Fraga writes:

But is not necessary (and further complicates the issue of support $...$
in org as recently discussed on this list) as you can simply type
\(n\)-th?


What complication are you referring to, precisely ?

The patch is fairly trivial, and a similar extension was already
implemented by Nicolas in 2017[1]. Yes, the $…$ syntax is redundant,
but I do not think it follows that this change is unnecessary.

This patch should have no bearing on the possible deprecation of the
$…$ syntax.

[1]: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c0369a798470763f8f3c69cf2079c3a194635feb


Regards,

--
Sébastien Miquel




[PATCH] Add support for $…$ latex fragments followed by a dash

2022-01-24 Thread Sébastien Miquel

Hi,

The attached patch adds support for $…$ latex fragments followed by a
dash, such as $n$-th.

This pattern is quite common, and the issue was mentionned by Rudolf
Adamkovič, here: https://list.orgmode.org/m2mtjvefrf@me.com/.

This extension of the syntax doesn't conflict with the use of $'s in
table formulas, or for currency, AFAICT.

Regards,

--
Sébastien Miquel
From b023fff129a5cc3b1f12b9f170f2e018dc34d237 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sun, 23 Jan 2022 13:28:03 +0100
Subject: [PATCH] =?UTF-8?q?org-element:=20Support=20$=E2=80=A6$=20LaTeX=20?=
 =?UTF-8?q?fragments=20followed=20by=20a=20dash?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-element.el (org-element-latex-fragment-parser):
* lisp/org.el (org-latex-regexps): Allow a dash right after a
$…$ fragment.
* testing/lisp/test-org-element.el (test-org-element/latex-fragment-parser):
Add test.

Allows such uses as `$n$-th' or `$n$-dimensional'.
---
 lisp/org-element.el  | 2 +-
 lisp/org.el  | 4 ++--
 testing/lisp/test-org-element.el | 4 
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index b82475a14..40a604578 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3416,7 +3416,7 @@ Assume point is at the beginning of the LaTeX fragment."
 		 (not (memq (char-before (match-beginning 0))
 '(?\s ?\t ?\n ?, ?.)))
 		 (looking-at-p
-		  "\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)")
+		  "\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|-\\|$\\)")
 		 (point)
 	 (post-blank
 	  (if (not after-fragment) (throw 'no-object nil)
diff --git a/lisp/org.el b/lisp/org.el
index 2d439cd05..3a164ee77 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -629,8 +629,8 @@ An entry can be toggled between COMMENT and normal with
   '(("begin" "^[ \t]*\\(begin{\\([a-zA-Z0-9\\*]+\\)[^\000]+?end{\\2}\\)" 1 t)
 ;; ("$" "\\([ \t(]\\|^\\)\\(\\(\\([$]\\)\\([^ \t\n,.$].*?\\(\n.*?\\)\\{0,5\\}[^ \t\n,.$]\\)\\4\\)\\)\\([ \t.,?;:'\")]\\|$\\)" 2 nil)
 ;; \000 in the following regex is needed for org-inside-LaTeX-fragment-p
-("$1" "\\([^$]\\|^\\)\\(\\$[^ \t\r\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|$\\)" 2 nil)
-("$"  "\\([^$]\\|^\\)\\(\\(\\$\\([^ \t\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^ \t\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|$\\)" 2 nil)
+("$1" "\\([^$]\\|^\\)\\(\\$[^ \t\r\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|-\\|$\\)" 2 nil)
+("$"  "\\([^$]\\|^\\)\\(\\(\\$\\([^ \t\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^ \t\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|-\\|$\\)" 2 nil)
 ("\\(" "([^\000]*?)" 0 nil)
 ("\\[" "\\[[^\000]*?\\]" 0 nil)
 ("$$" "\\$\\$[^\000]*?\\$\\$" 0 nil))
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 6d7376a96..2055e3a7b 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -1776,6 +1776,10 @@ e^{i\\pi}+1=0
(eq 'latex-fragment
(org-test-with-temp-text "$a$'"
 	 (org-element-type (org-element-context)
+  (should
+   (eq 'latex-fragment
+   (org-test-with-temp-text "$a$-"
+	 (org-element-type (org-element-context)
   ;; Test forbidden characters inside $...$.
   (should-not
(eq 'latex-fragment
-- 
2.34.1



Re: Depreciating TeX-style LaTeX fragments (was: Org Syntax Specification)

2022-01-16 Thread Sébastien Miquel

Hi,

With respect to readability, I only mean to point out that the $…$
syntax is one less character, and that the \(\) characters are quite
overloaded.

this is a good opportunity to point out that $/$$ are very much second 
class citizens in LaTeX now, no matter what you may see in old documents. 



The posts that you quote are 10 years old. As per [0] (2020), there
will be no LaTeX3. Nor is it only old documents that use the $…$
syntax : looking for learning ressources (see [1]), everything that I
find uses it. That includes The Not So Short Introduction to LaTeX [2]
(2021) and https://en.wikibooks.org/wiki/LaTeX/Mathematics.

Although I have no evidence of this, my expectation is that the
majority of tex users use the $…$ syntax (it is in fact widely used
outside of tex: in most markdown flavors and texmacs for example). I
also expect that a significant proportion of tex users are not aware
of the \(…\) syntax. I think here of users that are less tech literate
than most of this mailing list.

Regards,

[0]: 
https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf
[1]: 
https://tex.stackexchange.com/questions/11/what-are-good-learning-resources-for-a-latex-beginner

[2]: https://ctan.tetaneutral.net/info/lshort/english/lshort.pdf

--
Sébastien Miquel




Re: Org Syntax Specification

2022-01-15 Thread Sébastien Miquel

Hi,

The new document seems much clearer. It makes a nice complement to the
manual and we should definitely lose the (draft). Thank you Timothy
for the work.

Lastly, having spent a while looking at the syntax, I’m wondering if 
we should take this opportunity to mark some of the syntactic elements 
we’ve become less happy with as *(depreciated)*. I’m specifically 
thinking of the TeX-style LaTeX fragments which have been a bit of a 
pain. To quote Nicolas in org-syntax.org:


It would introduce incompatibilities with previous Org versions,
but support for |$...$| (and for symmetry, |$$...$$|) constructs
ought to be removed.

They are slow to parse, fragile, redundant and imply false
positives. — ngz



This quote has been mentioned a few times lately, and no one has yet
spoken in favor of the $…$ syntax, so I'll have a quick go.

It is easier to use, easier to read and more commonly used (and known)
in tex documents (a quick web search for sample tex documents confirms
the latter). Removing this syntax would make org slightly harder to
pick up, with respect to writing scientific documents.

As for the listed shortcomings, I don't think we know whether its
slowness is significant and false positives can be avoided by using
the \dollar entity (possibly ?). In my own use, the only usability
issue I can think of is false negatives while writing : inserting a
space or other such characters at the end of a snippet removes the
fontification (I solve this by modifying the fontification regexps).

Regards,

--
Sébastien Miquel


[PATCH] Add :noweb-prefix and :noweb-trans babel header arguments

2022-01-15 Thread Sébastien Miquel

Hi,

The attached patch adds support for two new babel header arguments:
=:noweb-prefix= and =:noweb-trans=.

=:noweb-prefix= can be set to =no= to disable the noweb prefix
behaviour, where prefix characters are repeated when expanding a
multiline noweb reference.

=:noweb-trans= can be set to =prin1-to-string= to insert a lisp string
representing the content of the referenced src block.

The goal is to allow one to use, say, a LaTeX src block to represent
some LaTeX snippet to be tangled into a string in some lisp (or other)
code. This isn't possible currently, and one has to manually string
escape the LaTeX code.

As an example, the following two blocks

#+BEGIN_SRC LaTeX :tangle no :noweb-ref nw
\usepackage{…}
\usepackage{…}
#+END_SRC

#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no 
:noweb-trans prin1-to-string

(setq latex-header <>)
#+END_SRC

would tangle to

#+BEGIN_SRC emacs-lisp
(setq latex-header "\\usepackage{…}
\\usepackage{…}")
#+END_SRC

I've left undocumented the possibility of setting =:noweb-trans= to
another function. I wonder if anyone can think of some other use.

Regards,

--
Sébastien Miquel
From 66f271225767d07e12bcc73a1ddbadf038d245fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 6 Sep 2021 18:45:42 +0200
Subject: [PATCH] ob-core.el: Add `:noweb-prefix`, `:noweb-trans` babel header
 arguments

* lisp/ob-core.el (org-babel-expand-noweb-references): Add support for
`noweb-prefix' header argument, to not repeat the prefix characters
when expanding a noweb reference. Add support for `noweb-trans' header
argument, to apply a function to the noweb content upon
expansion.
(org-babel-common-header-args-w-values):
(org-babel-safe-header-args): Add `noweb-prefix' and `noweb-trans' values.
* doc/org-manual.org: Document `noweb-prefix' and `noweb-trans' babel header
arguments.
* etc/NEWS: Document `:noweb-prefix' and `:noweb-trans'.
---
 doc/org-manual.org | 34 ++
 etc/ORG-NEWS   |  9 +
 lisp/ob-core.el| 26 --
 3 files changed, 59 insertions(+), 10 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b4c20f252..d7b1c4203 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18554,10 +18554,11 @@ Note that the expansion now contains the results of the code block
 : 100
 
 Noweb insertions honor prefix characters that appear before the noweb
-syntax reference.  This behavior is illustrated in the following
-example.  Because the =<>= noweb reference appears behind the
-SQL comment syntax, each line of the expanded noweb reference is
-commented.  With:
+syntax reference. This behavior can be turned off by setting the
+=noweb-prefix= header argument to =no= and is illustrated in the
+following example. Because the =<>= noweb reference appears
+behind the SQL comment syntax, each line of the expanded noweb
+reference is commented. With:
 
 #+begin_example
 ,#+NAME: example
@@ -18626,6 +18627,31 @@ else:
 print('do things when false')
 #+end_example
 
+The header argument =noweb-trans= can be set to =prin1-to-string= to
+insert a lisp string representing the content of the referenced src
+block. With:
+
+#+begin_example
+,#+NAME: latex-header
+,#+BEGIN_SRC latex
+  \usepackage{amsmath}
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+this code block:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb yes
+  (setq header <>)
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+expands to:
+
+: (setq header "\\usepackage{amsmath}")
+
 When in doubt about the outcome of a source code block expansion, you
 can preview the results with the following command:
 
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 335db4139..6fa808645 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -63,6 +63,15 @@ list of various table options (between brackets in LaTeX export),
 since certain tabular environments, such as longtblr of the
 tabularray LaTeX package, provides this structure.
 
+*** New =:noweb-prefix= and =:noweb-trans= babel header arguments
+
+=:noweb-prefix= can be set to =no= to prevent the prefix characters
+from being repeated when expanding a multiline noweb reference.
+
+=:noweb-trans= can be set to =prin1-to-string=. Noweb reference
+therein will be expanded to an elisp string representation of their
+content.
+
 ** New functions and changes in function arguments
 
 *** New function ~org-element-cache-map~ for quick mapping across Org elements
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 239a57f96..1d5d1bedc 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -411,6 +411,8 @@ then run `org-babel-switch-to-session'."
 (noweb	. ((yes no tangle no-export strip-export)))
 (noweb-ref	. :any)
 (noweb-sep  . :any)
+(noweb-prefix . ((no yes)))
+(noweb-trans  . ((prin1-to-string)))
 (output-dir . :any)
 (padline	. ((yes no)))
 (post   . :any)
@@ -436,9 +438,10 @@ specific h

Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks

2022-01-11 Thread Sébastien Miquel

Fabio Natali writes:

Thanks for getting back to me and thank you very much for the code
snippet, which I think I'm going to integrate in my configuration.


Thank you for the report. With regard to the snippet, It seems the
advice function needs ~( justify region)~ as arguments rather
than ().


I'd be curious to hear from other fellow Org Moders. If this is a
relatively common problem and there's interest around it, maybe we could
think of a fix directly in the code base.

The best way to get it done is to post a patch to the list. If it
doesn't break a legitimate existing behaviour, It should get applied.
I'll probably do so eventually, or you could, if you feel so inclined.
Perhaps one difficulty is to deal with the case where the org-babel
call errors out, say if there's no mode to edit the src code in.

--
Sébastien Miquel




Re: [PATCH] Bug: Incorrect indentation in Org Babel list output with multiline text [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

2022-01-11 Thread Sébastien Miquel

Hi,

Vikas Kumar writes:

Here is a patch with the fix.

Thank you for the patch.

I'm just adding the [PATCH] cookie, so that this shows up on 
https://updates.orgmode.org/.


A maintainer will eventually get back to you, but it may take a while 
(couple of months at most).


Regards,

--
Sébastien Miquel




Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks

2022-01-10 Thread Sébastien Miquel

Hi,

Fabio Natali writes:

Is there anything obvious that you think I'm missing here? Is anyone
able to replicate the above behaviour and, if so, do you also find it
slightly problematic? Any thoughts and feedback on the above will be
greatly appreciated.:)


It's not just you. I think org-fill-paragraph should try to act
natively if called from inside a src block.

As it happens, I've recently added the following advice to my init
file.

(defun my-org-fill-paragraph-natively-maybe ()
  (let* ((element (save-excursion (beginning-of-line) 
(org-element-at-point-no-context)))

 (type (org-element-type element)))
    (if (and (eq type 'src-block)
 (> (line-beginning-position)
    (org-element-property :post-affiliated element))
 (< (line-beginning-position)
    (org-with-point-at (org-element-property :end element)
  (skip-chars-backward " \t\n")
  (line-beginning-position
    (progn
  (org-babel-do-in-edit-buffer (fill-paragraph))
  nil) t)))
(advice-add 'org-fill-paragraph :before-while 
#'my-org-fill-paragraph-natively-maybe)


Regards,

--
Sébastien Miquel




Re: bug#52771: 29.0.50; org-fill-paragraph does not work for several plain lists

2021-12-31 Thread Sébastien Miquel

Hi,

Kyle Meyer writes:

Rudolf Adamkovič writes:


Reproduction steps:

1. start "emacs -Q"
2. type "C-x C-f" and "test.org" and RET
3. type the following:

- one

  two

- three
  four

4. mark all with "C-x h"
5. type "M-q" to fill

Actual:

- one
  two

- three four

Expected:

- one two

- three four


Note that this issue is fixed by the patch proposed at

https://list.orgmode.org/041ca43d-2efb-db1e-76ab-7c15af088...@posteo.eu/

Regards,

--
Sébastien Miquel


Re: Patch to align baseline of latex fragments and surrounding text

2021-12-10 Thread Sébastien Miquel

Matt Huszagh writes:

I couldn't get ~org--match-text-baseline-ascent~ to compute the
ascent : the ~xml-get-attribute~ call returns
   : ("-16.945024" "12.153473" "16.148855" "8.064997")
which gives an ascent < -100, and the code then defaults to 'center.

I'd need to know more about your setup for generating latex
fragments. Did you follow all the directions in
org--match-text-baseline-ascent? How is your org-format-latex-header
set? In particular, are you using \documentclass[preview]{standalone}?
If you can provide me with the TeX file used to generate the fragment,
as well as the SVG file you get as a result, that would be helpful too.

My mistake. For some reason, I had thought that
=\documentclass[preview]{standalone}= was used by default for LaTeX
previews. Setting it as described in your patch, it now works
properly, even with the default value of =dvisvgm=.


If there are no drawbacks, perhaps this behaviour should be the
default. Otherwise, it should at least be easier to toggle.

I didn't attempt to make this the default because it requires a specific
setup, which is also different from the current default setup in other
respects. Most importantly, it requires using the standalone document
class, though I believe article is used at the moment.


To make this behavior easier to toggle, you could
 1. Change the default value of =org-format-latex-header=. The
    =standalone= class makes sense, but I don't know if that might
    break things.
 2. Specify the =:latex-header= of the default =dvisvgm= option. Same
    caveat applies.
 3. Add a =dvisvgm-with-ascent= option to the default value of
    =org-preview-latex-process-alist=.

Instead of the new variable =org-latex-fragment-overlay-ascent=,
perhaps the function used to compute the ascent could be provided as
another property, such as =:ascent=, added to the relevant options in
=org-preview-latex-process-alist=. It seems to make more sense since
it only applies to svg output, and it makes it easier to have this
behavior as default. It would require =org--make-preview-overlay= to
take the ascent as an additional argument.

Please note that I am not a maintainer, these are just a few thoughts.
I do hope your work can be applied and that LaTeX fragments can be
properly aligned by default.

You should add [PATCH] to the subject of your mail, so that it gets
listed at https://updates.orgmode.org/ and not forgotten. A maintainer
will reply eventually, but it might take up to a few months.

Regards,

--
Sébastien Miquel




Re: Patch to align baseline of latex fragments and surrounding text

2021-12-09 Thread Sébastien Miquel

Hi,

Matt Huszagh writes:

I feel that maybe it would be useful to attach screenshots to show the
improvement from this patch? Anyway, I've attached two images: one with
the correct baseline alignment to surrounding text and the other with
the current, incorrect, baseline alignment.

I think a lot of people would like this functionality. It looks much
better than the current behavior.

This looks great indeed but I've failed to reproduce in my
environment.

I couldn't get ~org--match-text-baseline-ascent~ to compute the
ascent : the ~xml-get-attribute~ call returns
 : ("-16.945024" "12.153473" "16.148855" "8.064997")
which gives an ascent < -100, and the code then defaults to 'center.

The options described in your =my-dvisvgm= seem outdated, you can
check the latest default value of =dvisvgm= : =use-xcolor= is
deprecated and a =:image-size-adjust= property is provided for the
images to be sized properly. Are the arguments =--no-fonts= and
=--exact-bbox= necessary ?

If there are no drawbacks, perhaps this behaviour should be the
default. Otherwise, it should at least be easier to toggle.

Can something similar be done with =dvipng= ?

Regards,

--
Sébastien Miquel




Re: [PATCH] org-src.el: add option `org-src-native-defun-movements'

2021-12-03 Thread Sébastien Miquel

Hi,

Thank you for having a look.

Tim Cross writes:

This also seems like an edge case and I'm not convinced yet another
option is justified. Why have eilisp in org blocks rather than an
emacs-lisp block?


By org src blocks I meant an org emacs-lisp src block. The point of
the patch is to be able to eval-defun some lisp code in an emacs-lisp
src block from the org-buffer.


As this is a breaking change, it should not be on by default.

Currently eval-defun errors out, and fixing that will break things
sooner or later, I think.

I do not mind updating the patch to set the new option to nil by
default, although I'll wait for a second opinion on this.

Regards,

--
Sébastien Miquel




[PATCH] org-src.el: add option `org-src-native-defun-movements'

2021-12-03 Thread Sébastien Miquel

Hi,

The attached patch adds a new option ~org-src-native-defun-movements~
that makes ~beginning-of-defun~, ~end-of-defun~ and ~eval-defun~ work
natively when called from inside an org src block : those functions
are called from an org src edit buffer, in the appropriate language
mode. Without this patch, calling =eval-defun= on elisp code fails.

With this option set to t by default, this is a breaking change. To
get to the beginning/end of a src block you'd have to call
~org-backward-element~ or ~org-forward-element~ directly, instead of
~beginning-of-defun~. Or you could disable the new behaviour by
setting ~org-src-native-defun-movements~ to nil.

Regards,

--
Sébastien Miquel
From 51675d8bbea54db7daf3dcc88a77ccad5174854f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Fri, 27 Aug 2021 21:41:29 +0200
Subject: [PATCH] org-src.el: add option `org-src-native-defun-movements'

* lisp/org-src.el (org-src-native-defun-movements): New option. If t,
`beginning-of-defun', `end-of-defun' and `eval-defun' act natively
when called from inside a src block.
(org-beginning-of-defun):
(org-end-of-defun): New functions.  If
`org-src-native-defun-movements' is t and point is in a src block,
call `beginning-of-defun' or `end-of-defun' from the src edit buffer.

The main goal is to make `eval-defun' work from the org buffer. For
this to work, if point is at the beginning of an #+end_src line,
`org-beginning-of-defun' has to work natively.  To get to the
beginning of the src block, call `org-backward-element` instead.
---
 etc/ORG-NEWS| 20 ++
 lisp/org-src.el |  7 +++
 lisp/org.el | 54 ++---
 3 files changed, 74 insertions(+), 7 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index eb5a5d40d..379870d44 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -60,6 +60,26 @@ list of various table options (between brackets in LaTeX export),
 since certain tabular environments, such as longtblr of the
 tabularray LaTeX package, provides this structure.
 
+*** ~beginning-of-defun~ and ~eval-defun~ now work natively in src blocks
+
+To get to the beginning or end of a src block, use
+~org-backward-element~ and ~org-forward-element~ instead, or disable
+this new behaviour by setting ~org-src-native-defun-movements~ to nil.
+
+** New options
+
+*** New option =org-src-native-defun-movements=
+
+This option, t by default, makes ~beginning-of-defun~, ~end-of-defun~
+and ~eval-defun~ work natively inside src blocks : the corresponding
+function is called from an org src block edit buffer in the language
+specific mode.
+
+For ~eval-defun~ to work natively from the org buffer, if point is at
+the beginning of an #+end_src line, `org-beginning-of-defun` will work
+natively as well.  To get to the beginning of the src block, call
+`org-backward-element` instead.
+
 ** New functions and changes in function arguments
 
 *** New function ~org-element-cache-map~ for quick mapping across Org elements
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 46fed052d..8feced080 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -246,6 +246,13 @@ green, respectability.
   :package-version '(Org . "9.4")
   :group 'org-babel)
 
+(defcustom org-src-native-defun-movements t
+  "If non-nil, the effect of `beginning-of-defun' and
+`end-of-defun' in a code block is as if they were issued in the
+language major mode buffer."
+  :type 'boolean
+  :package-version '(Org . "9.6")
+  :group 'org-babel)
 
 
 ;;; Internal functions and variables
diff --git a/lisp/org.el b/lisp/org.el
index ec59ddf44..1ff0d6f87 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4892,13 +4892,8 @@ The following commands are available:
  org-element-use-cache)
 (org-persist-read 'org-element--cache (current-buffer)))
   ;; Beginning/end of defun
-  (setq-local beginning-of-defun-function 'org-backward-element)
-  (setq-local end-of-defun-function
-	  (lambda ()
-		(if (not (org-at-heading-p))
-		(org-forward-element)
-		  (org-forward-element)
-		  (forward-char -1
+  (setq-local beginning-of-defun-function 'org-beginning-of-defun)
+  (setq-local end-of-defun-function 'org-end-of-defun)
   ;; Next error for sparse trees
   (setq-local next-error-function 'org-occur-next-match)
   ;; Make commit log messages from Org documents easier.
@@ -21525,6 +21520,51 @@ Move to the previous element at the same level, when possible."
 			   (<= (org-element-property :end prev) beg))
 		 (goto-char (org-element-property :begin prev)))
 
+(defun org-beginning-of-defun ()
+  "If point is in a src block and `org-src-native-defun-movements'
+is non-nil, call `beginning-of-defun' in the src block edit
+buffer, otherwise call `org-backward-element'."
+  (interactive)
+  (if (and org-src-native-defun-movements
+   (let* ((element (save-excursion (beginning-of-line)
+ 

Re: [patch] fix ox-latex async export bug

2021-11-30 Thread Sébastien Miquel

Hi,

Rasmus Pank Roulund writes:

This is most likely due to native compilation which compiles the
unquoted lambda. Once compiled, it (presumably) fails to be passed to
the external emacs process.

Ah, interesting.  Is this a bug or a feature?


I think the bug's with org-mode. As I explain elsewhere in the thread,
this lambda is to be treated as data, and written to a file to be
executed by the external emacs instance. It should always have been
quoted (naming it happens to work also).

Regards,

--
Sébastien Miquel


[PATCH] org.el: Fix the filling of regions containing lists

2021-11-30 Thread Sébastien Miquel

Hi,

The attached patch fixes the following issues with the functions
=fill-region= and =fill-paragraph=, when called with an active region
containing a list.

In the examples, replace 'long line' by long lines to be filled.

 + Calling =fill-region= on a region which contains a list with single
   line items (such as the one below) breaks the list structure.
   - long line
   - long line
 + Calling =fill-region= on a region with a list such as the one below
   doesn't fill the list
   - short line
 short line
   - short line
 short line
 + Calling =fill-paragraph= on a region containing a list such as the
   one below doesn't fill the first item
   - long line
   - long line
   - long line
 + Calling =fill-paragraph= on a region containing a list such as the
   one below doesn't fill the list
   - long line
   - long line
   - short line

Regards,

--
Sébastien Miquel
From 6c60e8e43e39074fa87da2f0ed272a69a6793862 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sat, 6 Nov 2021 22:41:20 +0100
Subject: [PATCH] org.el: Fix the filling of regions containing lists

* lisp/org.el (org-setup-filling): Set fill-forward-paragraph-function.
(org--single-lines-list-is-paragraph): New internal variable. Whether
a list with single lines items should be considered a single
paragraph.
(org--paragraph-at-point): use org--single-lines-list-is-paragraph.
(org-fill-paragraph): When an active region contains a list ensure
every item get filled.
* testing/lisp/test-org.el (test-org/fill-paragraph):
(test-org/fill-region): Test behaviour of fill-paragraph and
fill-region with an active region containing a list.

When filling paragraphs in a region, do not treat a list with single
lines items as a single paragraph.
---
 lisp/org.el  | 19 +++
 testing/lisp/test-org.el | 41 
 2 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 025513e7a..17046f391 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19629,6 +19629,8 @@ assumed to be significant there."
 ;; `org-setup-filling' installs filling and auto-filling related
 ;; variables during `org-mode' initialization.
 
+(defvar org--single-lines-list-is-paragraph) ; defined later
+
 (defun org-setup-filling ()
   (require 'org-element)
   ;; Prevent auto-fill from inserting unwanted new items.
@@ -19644,6 +19646,10 @@ assumed to be significant there."
 (setq-local paragraph-start paragraph-ending)
 (setq-local paragraph-separate paragraph-ending))
   (setq-local fill-paragraph-function 'org-fill-paragraph)
+  (setq-local fill-forward-paragraph-function
+  (lambda ( arg)
+(let ((org--single-lines-list-is-paragraph nil))
+  (org-forward-paragraph arg
   (setq-local auto-fill-inhibit-regexp nil)
   (setq-local adaptive-fill-function 'org-adaptive-fill-function)
   (setq-local normal-auto-fill-function 'org-auto-fill-function)
@@ -19873,9 +19879,11 @@ filling the current element."
 	(progn
 	  (goto-char (region-end))
 	  (skip-chars-backward " \t\n")
-	  (while (> (point) start)
-		(org-fill-element justify)
-		(org-backward-paragraph)))
+	  (let ((org--single-lines-list-is-paragraph nil))
+(while (> (point) start)
+		  (org-fill-element justify)
+		  (org-backward-paragraph)
+  (skip-chars-backward " \t\n"
 	  (goto-char origin)
 	  (set-marker origin nil
  (t
@@ -21218,6 +21226,9 @@ It also provides the following special moves for convenience:
 ;; Return moves left.
 arg))
 
+(defvar org--single-lines-list-is-paragraph t
+  "Treat plain lists with an item every line as a whole paragraph")
+
 (defun org--paragraph-at-point ()
   "Return paragraph, or equivalent, element at point.
 
@@ -21279,7 +21290,7 @@ Function may return a real element, or a pseudo-element with type
 	  (while (memq (org-element-type (org-element-property :parent l))
 			   '(item plain-list))
 		(setq l (org-element-property :parent l)))
-	  (and l
+	  (and l org--single-lines-list-is-paragraph
 		   (org-with-point-at (org-element-property :post-affiliated l)
 		 (forward-line (length (org-element-property :structure l)))
 		 (= (point) (org-element-property :contents-end l)))
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 056ea7d87..4375456da 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -765,8 +765,49 @@
 	  (push-mark (point) t t)
 	  (goto-char (point-max))
 	  (call-interactively #'org-fill-paragraph)
+	  (buffer-string)
+  ;; Fill every list item in a region
+  (should
+   (equal "\n- 2345678\n  9\n- 2345678\n  9"
+	  (org-test-with-temp-text "\n- 2345678 9\n- 2345678 9"
+	(let ((fill-column 10))
+	  (transient-mark-mode 1)
+	  (push-mark (point-min) t t)
+	  

Re: [PATCH] Fontification for inline src blocks

2021-11-30 Thread Sébastien Miquel

Hi,

Timothy writes:

Pushed .


Sorry for the late reply, but isn't there a =message= call leftover from 
debugging ?


Regards,

--
Sébastien Miquel




Re: [patch] fix ox-latex async export bug

2021-11-30 Thread Sébastien Miquel

Hi,

Nicolas Goaziou writes:

This is not really the same fix.


Indeed, but I tested it and it does work.


You're quoting a lambda, which should
not be required if the problem disappeared. IOW, the true fix probably
belong in the `org-export-async-start' function.


What happens is as follows
 1. This lambda is passed as the =post-process= variable of
    =org-export-to-file=.
 2. Which converts it to code using =`(funcall ',post-process)=
 3. Which =org-export-async-start= writes to a file, to be executed by
    the external emacs process.

I think native compilation compiles the lamdba in
=org-latex-export-to-pdf= and that there is no way to get back this
original lambda (the code) from within =org-export-to-file= or
=org-export-async-start=. Quoting the lambda prevents this
compilation.

My understanding of elisp and the native compilation business is quite
superficial, so this may be wrong.

Regards,

--
Sébastien Miquel




Re: [patch] fix ox-latex async export bug

2021-11-29 Thread Sébastien Miquel

Hi,

Nicolas Goaziou writes:

I don’t really understand why this bug happens to be honest.

The patch is already an improvement, but the beast is still lurking,
indeed.

This is most likely due to native compilation which compiles the
unquoted lambda. Once compiled, it (presumably) fails to be passed to
the external emacs process.

Attached is a patch that applies the same fix where affected.

Regards,

--
Sébastien Miquel
From 35ae093113d9a04a99b55f0747848b373a7463f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 29 Nov 2021 09:54:33 +0100
Subject: [PATCH] ox: Fix async export with native compilation

* lisp/ox-beamer.el (org-beamer-export-to-pdf):
* lisp/ox-icalendar.el (org-icalendar-export-to-ics):
* lisp/ox-koma-letter.el (org-koma-letter-export-to-pdf):
* lisp/ox-man.el (org-man-export-to-pdf):
* lisp/ox-texinfo.el (org-texinfo-export-to-info): Quote lambda.

Quote or name lambdas to prevent their compilation into anonymous
functions which cannot be passed to the external async emacs process.
---
 lisp/ox-beamer.el  | 2 +-
 lisp/ox-icalendar.el   | 4 ++--
 lisp/ox-koma-letter.el | 2 +-
 lisp/ox-man.el | 2 +-
 lisp/ox-texinfo.el | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index c9a67f891..3bfcd01d4 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -1059,7 +1059,7 @@ Return PDF file's name."
   (let ((file (org-export-output-file-name ".tex" subtreep)))
 (org-export-to-file 'beamer file
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-latex-compile file)
+  #'org-latex-compile)))
 
 ;;;###autoload
 (defun org-beamer-select-environment ()
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 0a682c7c8..68c5679ea 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -888,8 +888,8 @@ Return ICS file name."
 (org-export-to-file 'icalendar outfile
   async subtreep visible-only body-only
   '(:ascii-charset utf-8 :ascii-links-to-notes nil)
-  (lambda (file)
-	(run-hook-with-args 'org-icalendar-after-save-hook file) nil
+  '(lambda (file)
+	 (run-hook-with-args 'org-icalendar-after-save-hook file) nil
 
 ;;;###autoload
 (defun org-icalendar-export-agenda-files ( async)
diff --git a/lisp/ox-koma-letter.el b/lisp/ox-koma-letter.el
index 6a895a6a2..978e4e41f 100644
--- a/lisp/ox-koma-letter.el
+++ b/lisp/ox-koma-letter.el
@@ -982,7 +982,7 @@ Return PDF file's name."
 (org-koma-letter-special-contents))
 (org-export-to-file 'koma-letter file
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-latex-compile file)
+  #'org-latex-compile)))
 
 
 (provide 'ox-koma-letter)
diff --git a/lisp/ox-man.el b/lisp/ox-man.el
index 6d3476cda..9a1f00f35 100644
--- a/lisp/ox-man.el
+++ b/lisp/ox-man.el
@@ -1117,7 +1117,7 @@ Return PDF file's name."
   (let ((outfile (org-export-output-file-name ".man" subtreep)))
 (org-export-to-file 'man outfile
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-latex-compile file)
+  #'org-latex-compile)))
 
 (defun org-man-compile (file)
   "Compile a Groff file.
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index b0125894a..734c8a4f3 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -1701,7 +1701,7 @@ Return INFO file's name."
 	(org-export-coding-system org-texinfo-coding-system))
 (org-export-to-file 'texinfo outfile
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-texinfo-compile file)
+  #'org-texinfo-compile)))
 
 ;;;###autoload
 (defun org-texinfo-publish-to-texinfo (plist filename pub-dir)
-- 
2.34.1



[BUG] org-element-at-point returns wrong element

2021-11-03 Thread Sébastien Miquel

Hi,

With point at the bol of the empty line after the keyword and before
the heading at the end of this mail, =org-element-at-point= returns
the headline element. It used to (a month ago, before all the caching)
return the keyword.

This breaks =org-element-context= which errors out when called from
the same point.

Regards,

#+LATEX_CLASS: my-class

* Head1

* Head2

--
Sébastien Miquel




[PATCH] org.el (org-display-inline-image--width): Small fix

2021-10-23 Thread Sébastien Miquel

Hi,

The variable display-line-numbers-width is nil by default.

Regards,

--
Sébastien Miquel
From 2e306750caff0474aa9a6443c7d7eb68e3aca83b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sat, 23 Oct 2021 13:28:59 +0200
Subject: [PATCH] org.el (org-display-inline-image--width): Small fix

---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 474171b55..3140c4d1f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16867,7 +16867,7 @@ buffer boundaries with possible narrowing."
 (/ (or (and (bound-and-true-p visual-fill-column-mode)
 (or visual-fill-column-width auto-fill-function))
(when auto-fill-function fill-column)
-   (- (window-text-width) display-line-numbers-width))
+   (- (window-text-width) (or display-line-numbers-width 0)))
(float (window-total-width)
 width)))
((numberp org-image-actual-width)
-- 
2.33.1


Re: [PATCH] Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]

2021-09-30 Thread Sébastien Miquel

Hi Bastien,

Bastien writes:


Sébastien, have you been able to test this patch heavily and is it
still needed, or has it been made somehow irrelevant?  (I see it does
apply well on the bugfix branch, but not on main.)

Thanks for any feedback,

I've rebased the patch on main. It is still relevant (Ihor and I have 
provided

reproducers earlier in the thread).

I had done some testing, and some more recently. The patch only affects
latex-fragments and org entities to be edited which do not need to start 
at a
beginning of line (latex-fragments, inline src blocks, footnote 
definitions).


Regards,

--
Sébastien Miquel
From b80124aa6edbd3b6992817dd8c37253705c82ae3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 30 Aug 2021 23:18:41 +0200
Subject: [PATCH] org-src.el: Fix special editing of LaTeX fragments

* lisp/org-macs.el (org-do-remove-indentation): Add optional argument
to skip the first line.
* lisp/org-src.el (org-src--coordinates): Fix coordinates for inline
LaTeX fragments.
(org-src--contents-for-write-back): Do not indent first line for LaTeX
fragments.
(org-src--edit-element): Compute block-indentation according to parent
for LaTeX fragments.  Skip first line when removing common indentation
for LaTeX fragments.
---
 lisp/org-macs.el |  9 ++---
 lisp/org-src.el  | 18 ++
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index bf1340b0a..1ef89a04d 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -326,17 +326,19 @@ it for output."
 
 ;;; Indentation

-(defun org-do-remove-indentation ( n)
+(defun org-do-remove-indentation ( n skip-fl)
   "Remove the maximum common indentation from the buffer.
 When optional argument N is a positive integer, remove exactly
-that much characters from indentation, if possible.  Return nil
-if it fails."
+that much characters from indentation, if possible.  When
+optional argument SKIP-FL is non-nil, skip the first
+line.  Return nil if it fails."
   (catch :exit
 (goto-char (point-min))
 ;; Find maximum common indentation, if not specified.
 (let ((n (or n
 		 (let ((min-ind (point-max)))
 		   (save-excursion
+ (when skip-fl (forward-line))
 		 (while (re-search-forward "^[ \t]*\\S-" nil t)
 		   (let ((ind (current-indentation)))
 			 (if (zerop ind) (throw :exit nil)
@@ -344,6 +346,7 @@ if it fails."
 		   min-ind
   (if (zerop n) (throw :exit nil)
 	;; Remove exactly N indentation, but give up if not possible.
+(when skip-fl (forward-line))
 	(while (not (eobp))
 	  (let ((ind (progn (skip-chars-forward " \t") (current-column
 	(cond ((eolp) (delete-region (line-beginning-position) (point)))
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 3b25fad60..d78f46186 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -327,7 +327,8 @@ a cons cell (LINE . COLUMN) or symbol `end'.  See also
   (if (>= pos end) 'end
 (org-with-wide-buffer
  (goto-char (max beg pos))
- (cons (count-lines beg (line-beginning-position))
+ (cons (count-lines (save-excursion (goto-char beg) (line-beginning-position))
+(line-beginning-position))
 	   ;; Column is relative to the end of line to avoid problems of
 	   ;; comma escaping or colons appended in front of the line.
 	   (- (point) (min end (line-end-position)))
@@ -445,6 +446,7 @@ Assume point is in the corresponding edit buffer."
 		  org-src--content-indentation
 		0
 	(use-tabs? (and (> org-src--tab-width 0) t))
+(preserve-fl (eq org-src--source-type 'latex-fragment))
 	(source-tab-width org-src--tab-width)
 	(contents (org-with-wide-buffer
(let ((eol (line-end-position)))
@@ -466,7 +468,8 @@ Assume point is in the corresponding edit buffer."
   ;; Add INDENTATION-OFFSET to every line in buffer,
   ;; unless indentation is meant to be preserved.
   (when (> indentation-offset 0)
-	(while (not (eobp))
+	(when preserve-fl (forward-line))
+(while (not (eobp))
 	  (skip-chars-forward " \t")
   (when (or (not (eolp))   ; not a blank line
 (and (eq (point) (marker-position marker)) ; current line
@@ -518,7 +521,13 @@ Leave point in edit buffer."
 	 (source-tab-width (if indent-tabs-mode tab-width 0))
 	 (type (org-element-type datum))
 	 (block-ind (org-with-point-at (org-element-property :begin datum)
-			  (current-indentation)))
+  (cond
+   ((save-excursion (skip-chars-backward " \t") (bolp))
+			(current-indentation))
+   ((org-element-property :parent datum)
+(org--get-expected-indentation
+ (org-element-property :parent datum) nil))
+   (t (current-indenta

Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.con

2021-09-20 Thread Sébastien Miquel

Hi,

Mohsin Kaleem writes:

Hi, just following up. This is still an issue.


I can confirm this. I've run into the same issue and fix.

Are you using native compilation ? I think this must be the cause, 
though no one

else could reproduce. If I byte compile the function instead, things work.

Regards,

--
Sébastien Miquel




[PATCH] Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]

2021-08-31 Thread Sébastien Miquel

Hi,

Ihor Radchenko writes:

Dávid Jakab  writes:

When using org-edit-special to edit inline latex, i.e., equations
between \( and \), in an org-mode buffer, a number of
spaces may get inserted before \( after the latex editing minibuffer is
closed.

The attached patch fixes this as well as a couple other issues with special
editing of latex fragments :
 + the coordinates computation was wrong, so point position inside fragment
   isn't preserved when calling ~org-edit-special~ from an inline fragment.
 + common leading indentation wasn't getting trimmed when editing a 
multiline

   fragment inside an org list such as
   $$abc
   def$$

Thanks for reporting and confirming.

Regards,

--
Sébastien Miquel

>From 5c3254d42e3d359021d41dae9a0549244e6fddff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 30 Aug 2021 23:18:41 +0200
Subject: [PATCH] org-src.el: Fix special editing of LaTeX fragments

* lisp/org-macs.el (org-do-remove-indentation): Add optional argument
to skip the first line.
* lisp/org-src.el (org-src--coordinates): Fix coordinates for inline
LaTeX fragments.
(org-src--contents-for-write-back): Do not indent first line for LaTeX
fragments.
(org-src--edit-element): Compute block-indentation according to parent
for LaTeX fragments.  Skip first line when removing common indentation
for LaTeX fragments.
---
 lisp/org-macs.el |  9 ++---
 lisp/org-src.el  | 18 ++
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 77458db96..5c90c92f6 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -326,17 +326,19 @@ it for output."
 
 ;;; Indentation
 
-(defun org-do-remove-indentation ( n)
+(defun org-do-remove-indentation ( n skip-fl)
   "Remove the maximum common indentation from the buffer.
 When optional argument N is a positive integer, remove exactly
-that much characters from indentation, if possible.  Return nil
-if it fails."
+that much characters from indentation, if possible.  When
+optional argument SKIP-FL is non-nil, skip the first
+line.  Return nil if it fails."
   (catch :exit
 (goto-char (point-min))
 ;; Find maximum common indentation, if not specified.
 (let ((n (or n
 		 (let ((min-ind (point-max)))
 		   (save-excursion
+ (when skip-fl (forward-line))
 		 (while (re-search-forward "^[ \t]*\\S-" nil t)
 		   (let ((ind (current-indentation)))
 			 (if (zerop ind) (throw :exit nil)
@@ -344,6 +346,7 @@ if it fails."
 		   min-ind
   (if (zerop n) (throw :exit nil)
 	;; Remove exactly N indentation, but give up if not possible.
+(when skip-fl (forward-line))
 	(while (not (eobp))
 	  (let ((ind (progn (skip-chars-forward " \t") (current-column
 	(cond ((eolp) (delete-region (line-beginning-position) (point)))
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 4698c6dd2..2e72b1755 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -324,7 +324,8 @@ a cons cell (LINE . COLUMN) or symbol `end'.  See also
   (if (>= pos end) 'end
 (org-with-wide-buffer
  (goto-char (max beg pos))
- (cons (count-lines beg (line-beginning-position))
+ (cons (count-lines (save-excursion (goto-char beg) (line-beginning-position))
+(line-beginning-position))
 	   ;; Column is relative to the end of line to avoid problems of
 	   ;; comma escaping or colons appended in front of the line.
 	   (- (point) (min end (line-end-position)))
@@ -442,6 +443,7 @@ Assume point is in the corresponding edit buffer."
 		  org-src--content-indentation
 		0
 	(use-tabs? (and (> org-src--tab-width 0) t))
+(preserve-fl (eq org-src--source-type 'latex-fragment))
 	(source-tab-width org-src--tab-width)
 	(contents (org-with-wide-buffer (buffer-string)))
 	(write-back org-src--allow-write-back))
@@ -456,7 +458,8 @@ Assume point is in the corresponding edit buffer."
   ;; Add INDENTATION-OFFSET to every line in buffer,
   ;; unless indentation is meant to be preserved.
   (when (> indentation-offset 0)
-	(while (not (eobp))
+	(when preserve-fl (forward-line))
+(while (not (eobp))
 	  (skip-chars-forward " \t")
 	  (let ((i (current-column)))
 	(delete-region (line-beginning-position) (point))
@@ -504,7 +507,13 @@ Leave point in edit buffer."
 	 (source-tab-width (if indent-tabs-mode tab-width 0))
 	 (type (org-element-type datum))
 	 (block-ind (org-with-point-at (org-element-property :begin datum)
-			  (current-indentation)))
+  (cond
+   ((save-excursion (skip-chars-backward " \t") (bolp))
+			(current-indentation))
+   ((org-element-property :parent datum)
+(org--get-expected-indentation
+ (org-element-property :parent datum) nil))
+

Re: Bug: [PATCH] Can't set background color of latex fragment

2021-08-29 Thread Sébastien Miquel

Sébastien Miquel writes:

Here's a patch that fixes this bug by calling `dvipng' with the `-bg
Transparent' argument only when no background color is set.


Setting X-Woof-Bug and X-Woof-Patch, as this doesn't show on 
https://updates.orgmode.org/


--
Sébastien Miquel




Re: [BUG] Async pdf export broken with native-comp

2021-07-16 Thread Sébastien Miquel

Hi,

Timothy writes:
> FWIW I use native-comp (with Doom + my config) and async PDF export
> works.

Would you mind checking that ~org-latex-export-to-pdf~ is native 
compiled, using

=describe-function= ?

I've updated to latest emacs master and I'm still hitting this issue,
although the steps to reproduce in my original mail are wrong :

 + with =emacs -q= async export fails, but for a different reason : I get a
   =wrong argument stringp, nil= error because ~user-init-file~ is nil 
inside

   ~org-export-async-start~.
 + The issue I described occurs when you use an empty init.el file and 
start

   =emacs=. Perhaps you need to make sure that ~org-latex-export-to-pdf~ is
   native compiled.

Regards,

--
Sébastien Miquel




[BUG] Async pdf export broken with native-comp

2021-07-15 Thread Sébastien Miquel

Hi,

The async pdf export functionality appears to be broken with latest org 
and a

recent emacs version compiled with native-comp enabled (I have not tested
without native-comp).

To reproduce:

 - use `emacs -q` and an empty init.el file (your init file gets picked 
up by

   the async emacs instance)
 - (setq org-export-async-debug t)
 - find any org file and hit =C-c C-e C-a C-l C-p= to export as pdf file.

The async process will exit abnormaly.

The issue stems from this line in `org-export-to-file`
 :   (ignore-errors (funcall ',post-process ,file))

In `org-latex-export-to-pdf`, this `post-process` is set to
 :   (lambda (file) (org-latex-compile file))

I think native-comp compiles this lambda, which messes things up.

As a fix, you can quote the lambda in `org-latex-export-to-pdf`
 :   '(lambda (file) (org-latex-compile file))

The same applies to other backends but I don't know if it's the right 
thing to do.


Regards,

--
Sébastien Miquel




Re: [PATCH] Do not throw error when parameter of :tangle is not a string

2021-07-08 Thread Sébastien Miquel

Hi,

Jacopo De Simoi writes:

  in the current master branch, if the parameter :tangle of a src block is not
a string, tangling fails by throwing  an error when calling `file-name-
directory'  This patch checks if the parameter is a string before calling
`file-name-directory'.

This makes construct such as :tangle (when condition-applies "filename") work
again (as they did a few versions ago…)

Thanks for the patch. It looks good to me (had to run `dos2unix' to apply).

To clarify, it fixes `:tangle (when condition-applies "filename")' when the
condition doesn't apply, such as `(when nil "filename")'.

Regards,

--
Sébastien Miquel




Re: Large source block causes org-mode to be unusable

2021-06-28 Thread Sébastien Miquel

Hi,

Léo Ackermann writes:

@EricSFrada, would you mind sharing your code for your proof sections ?

This functionality is now built-in: headings with an `ignore' tag do not get
exported (their contents do). For very large proof, this seems like the 
right

thing to do.

In small to moderate sized blocks, the delay can still be noticeable and 
ought

to be fixed. Attached is a patch that seems to resolve this issue. I haven't
noticed any drawbacks so far.

Regards,

--
Sébastien Miquel

>From d843bdc5887a6e50a57e349128ebbe032086dc17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sun, 27 Jun 2021 16:24:22 +0200
Subject: [PATCH] WIP : do not refontify special blocks

---
 lisp/org.el | 99 ++---
 1 file changed, 64 insertions(+), 35 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..9fd3f8514 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5265,22 +5265,32 @@ by a #."
   (org-fontify-meta-lines-and-blocks-1 limit)
 (error (message "Org mode fontification error in %S at %d"
 		(current-buffer)
-		(line-number-at-pos)
+		(line-number-at-pos
+  nil)
 
 (defun org-fontify-meta-lines-and-blocks-1 (limit)
   "Fontify #+ lines and blocks."
-  (let ((case-fold-search t))
-(when (re-search-forward
-	   (rx bol (group (zero-or-more (any " \t")) "#"
-			  (group (group (or (seq "+" (one-or-more (any "a-zA-Z")) (optional ":"))
-	(any " \t")
-	eol))
- (optional (group "_" (group (one-or-more (any "a-zA-Z"))
-			  (zero-or-more (any " \t"))
-			  (group (group (zero-or-more (not (any " \t\n"
- (zero-or-more (any " \t"))
- (group (zero-or-more any)
-	   limit t)
+  (let* ((case-fold-search t)
+ (fl-beg (point))
+ (fl-end limit)
+ (fbeg (when (and (> fl-beg (point-min))
+  (get-text-property (1- fl-beg) 'font-lock-multiline-block))
+ (or (previous-single-property-change
+  fl-beg 'font-lock-multiline-block)
+ (point-min)
+(when fbeg (goto-char fbeg))
+(while (and (< (point) limit)
+(re-search-forward
+	 (rx bol (group (zero-or-more (any " \t")) "#"
+			(group (group (or (seq "+" (one-or-more (any "a-zA-Z")) (optional ":"))
+	  (any " \t")
+	  eol))
+   (optional (group "_" (group (one-or-more (any "a-zA-Z"))
+			(zero-or-more (any " \t"))
+			(group (group (zero-or-more (not (any " \t\n"
+   (zero-or-more (any " \t"))
+   (group (zero-or-more any)
+	 limit t))
   (let ((beg (match-beginning 0))
 	(end-of-beginline (match-end 0))
 	;; Including \n at end of #+begin line will include \n
@@ -5318,7 +5328,7 @@ by a #."
 	  (remove-text-properties beg end-of-endline
   '(display t invisible t intangible t)))
 	(add-text-properties
-	 beg end-of-endline '(font-lock-fontified t font-lock-multiline t))
+	 beg end-of-endline '(font-lock-fontified t font-lock-multiline-block t))
 	(org-remove-flyspell-overlays-in beg bol-after-beginline)
 	(org-remove-flyspell-overlays-in nl-before-endline end-of-endline)
 	(cond
@@ -5327,7 +5337,8 @@ by a #."
 	  (add-text-properties bol-after-beginline block-end '(src-block t)))
 	 (quoting
 	  (add-text-properties
-	   bol-after-beginline beg-of-endline
+	   (max bol-after-beginline (or fl-beg bol-after-beginline))
+   (min beg-of-endline (or fl-end beg-of-endline))
 	   (list 'face
 		 (list :inherit
 			   (let ((face-name
@@ -5426,26 +5437,41 @@ by a #."
 	(add-text-properties closing-start end '(invisible t)))
 	  t)
 
-(defun org-fontify-extend-region (beg end _old-len)
-  (let ((begin-re "\\(\\[\\|\\(#\\+begin_\\|begin{\\)\\S-+\\)")
-	(end-re "\\(\\]\\|\\(#\\+end_\\|end{\\)\\S-+\\)")
-	(extend
- (lambda (r1 r2 dir)
-	   (let ((re (replace-regexp-in-string
-  "\\(begin\\|end\\)" r1
-		  (replace-regexp-in-string
-   "[][]" r2
-		   (match-string-no-properties 0)
-	 (re-search-forward (regexp-quote re) nil t dir)
-(save-match-data
-  (save-excursion
-	(goto-char beg)
-	(back-to-indentation)
-	(cond ((looking-at end-re)
-	   (cons (or (funcall extend "begin" "[" -1) beg) end))
-	  ((looking-at begin-re)
-	   (cons beg (or (funcall extend "end" "]" 1) end)))
-	  (t (cons beg end)))
+(defun org-fontify-extend-region (bego endo _old-len)
+  (let* ((beg bego) 

Re: [PATCH] extra space at the end of lines in source

2021-06-26 Thread Sébastien Miquel

Greg Minshall writes:

thanks.  my trivial test shows this works*except*  in the particular
case where, when closing the Org Src buffer, `point` is on an empty
line.  in this case, that one empty line is given extra spaces.
Yes, I was aware of this, but didn't think we could do better in this 
case. I've

thought about it some more, and came up with a solution.

Here's a new patch that's smarter about indenting the current line, and 
resolves

this remaining issue.

Regards,

--
Sébastien Miquel

>From 8c31e6b732a45c0ddbbf0a0db7a2cb4ef3af0414 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Wed, 23 Jun 2021 15:25:58 +0200
Subject: [PATCH] org-src.el: Do not indent blank lines, except current one

* lisp/org-src.el (org-src--contents-for-write-back): Do not indent blank lines, except for the
current line maybe.
(org-src--preserve-blank-line): New variable, whether to preserve
indentation of the current blank line.
(org-src--edit-element): Set `org-src--preserve-blank-line'.
* lisp/org.el (org-indent-line): When tab acts natively, do some
preindentation, which signals `org-src--edit-element' to
preserve the indentation of current blank line.

Removing all the whitespace was the original behaviour for all blank lines, before `857ae366b3`.
---
 lisp/org-src.el | 34 +++---
 lisp/org.el | 15 +++
 2 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 79f002e56..c6311adbb 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -299,6 +299,9 @@ is 0.")
   "File name associated to Org source buffer, or nil.")
 (put 'org-src-source-file-name 'permanent-local t)
 
+(defvar-local org-src--preserve-blank-line nil)
+(put 'org-src--preserve-blank-line 'permanent-local t)
+
 (defun org-src--construct-edit-buffer-name (org-buffer-name lang)
   "Construct the buffer name for a source editing buffer."
   (concat "*Org Src " org-buffer-name "[ " lang " ]*"))
@@ -443,14 +446,21 @@ Assume point is in the corresponding edit buffer."
 		0
 	(use-tabs? (and (> org-src--tab-width 0) t))
 	(source-tab-width org-src--tab-width)
-	(contents (org-with-wide-buffer (buffer-string)))
-	(write-back org-src--allow-write-back))
+	(contents (org-with-wide-buffer
+   (let ((eol (line-end-position)))
+ (list (buffer-substring (point-min) eol)
+   (buffer-substring eol (point-max))
+	(write-back org-src--allow-write-back)
+(preserve-blank-line org-src--preserve-blank-line)
+marker)
 (with-current-buffer write-back-buf
   ;; Reproduce indentation parameters from source buffer.
   (setq indent-tabs-mode use-tabs?)
   (when (> source-tab-width 0) (setq tab-width source-tab-width))
   ;; Apply WRITE-BACK function on edit buffer contents.
-  (insert (org-no-properties contents))
+  (insert (org-no-properties (car contents)))
+  (setq marker (point-marker))
+  (insert (org-no-properties (car (cdr contents
   (goto-char (point-min))
   (when (functionp write-back) (save-excursion (funcall write-back)))
   ;; Add INDENTATION-OFFSET to every line in buffer,
@@ -458,10 +468,14 @@ Assume point is in the corresponding edit buffer."
   (when (> indentation-offset 0)
 	(while (not (eobp))
 	  (skip-chars-forward " \t")
-	  (let ((i (current-column)))
-	(delete-region (line-beginning-position) (point))
-	(indent-to (+ i indentation-offset)))
-	  (forward-line))
+  (when (or (not (eolp))   ; not a blank line
+(and (eq (point) (marker-position marker)) ; current line
+ preserve-blank-line))
+	(let ((i (current-column)))
+	  (delete-region (line-beginning-position) (point))
+	  (indent-to (+ i indentation-offset
+	  (forward-line)))
+  (set-marker marker nil
 
 (defun org-src--edit-element
 (datum name  initialize write-back contents remote)
@@ -506,6 +520,11 @@ Leave point in edit buffer."
 	 (block-ind (org-with-point-at (org-element-property :begin datum)
 			  (current-indentation)))
 	 (content-ind org-edit-src-content-indentation)
+ (blank-line (save-excursion (beginning-of-line)
+ (looking-at-p "^[[:space:]]*$")))
+ (empty-line (and blank-line (looking-at-p "^$")))
+ (preserve-blank-line (or (and blank-line (not empty-line))
+  (and empty-line (= (+ block-ind content-ind) 0
 	 (preserve-ind
 	  (and (memq type '(example-block src-block))
 		   (or (org-element-property :preserve-indent datum)
@@ -554,6 +573,7 @@ Leave point in edit buffer."
 	(setq org-src--overlay overlay)
 	(setq org-src--allow-write-back write-back)
 	(setq org-src-sour

Re: [PATCH] extra space at the end of lines in source

2021-06-23 Thread Sébastien Miquel

Greg Minshall writes:

- the next time i open the Org Src buffer, whatever lint-like process is
   running for that language may complain about extra spaces at the end
   of a line.  (does that mean my experience is different from yours, or
   at least from your expectation?)
If I try your original examples with `emacs -q' I do not get extra 
whitespace in
the org src buffer. Those two spaces in the original org buffer -- that 
are due
to `org-edit-src-content-indentation' -- are removed in the org src 
buffer. If

you do not find it to be the case, then I'm missing something.

Anyway, here's a patch that cleans up blank lines, except the current 
one. It

preserves the fix for the original issue.

Can you try it out ?

Regards,

--
Sébastien Miquel

>From 405c2be7487c564e72a9f01a940f96dc19ff16ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Wed, 23 Jun 2021 15:25:58 +0200
Subject: [PATCH] org-src.el (org-src--contents-for-write-back): Do not indent
 blank lines

* lisp/org-src.el (org-src--contents-for-write-back): Do not indent
blank lines, except for the current line.

This was the original behaviour for all blank lines, before `857ae366b3`.
---
 lisp/org-src.el | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 79f002e56..faacb53e3 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -443,14 +443,20 @@ Assume point is in the corresponding edit buffer."
 		0
 	(use-tabs? (and (> org-src--tab-width 0) t))
 	(source-tab-width org-src--tab-width)
-	(contents (org-with-wide-buffer (buffer-string)))
-	(write-back org-src--allow-write-back))
+	(contents (org-with-wide-buffer
+   (let ((eol (progn (end-of-line) (point
+ (list (buffer-substring (point-min) eol)
+   (buffer-substring eol (point-max))
+	(write-back org-src--allow-write-back)
+marker)
 (with-current-buffer write-back-buf
   ;; Reproduce indentation parameters from source buffer.
   (setq indent-tabs-mode use-tabs?)
   (when (> source-tab-width 0) (setq tab-width source-tab-width))
   ;; Apply WRITE-BACK function on edit buffer contents.
-  (insert (org-no-properties contents))
+  (insert (org-no-properties (car contents)))
+  (setq marker (point-marker))
+  (insert (org-no-properties (car (cdr contents
   (goto-char (point-min))
   (when (functionp write-back) (save-excursion (funcall write-back)))
   ;; Add INDENTATION-OFFSET to every line in buffer,
@@ -458,10 +464,13 @@ Assume point is in the corresponding edit buffer."
   (when (> indentation-offset 0)
 	(while (not (eobp))
 	  (skip-chars-forward " \t")
-	  (let ((i (current-column)))
-	(delete-region (line-beginning-position) (point))
-	(indent-to (+ i indentation-offset)))
-	  (forward-line))
+  (when (or (not (eolp)) ; ignore blank lines
+(eq (point) (marker-position marker)))
+	(let ((i (current-column)))
+	  (delete-region (line-beginning-position) (point))
+	  (indent-to (+ i indentation-offset
+	  (forward-line)))
+  (set-marker marker nil
 
 (defun org-src--edit-element
 (datum name  initialize write-back contents remote)
-- 
2.32.0



Re: extra space at the end of lines in source

2021-06-22 Thread Sébastien Miquel
For the record, the original issue is that with 
`org-src-tab-acts-natively' set
to t (which is the new default) you couldn't use tab to indent an empty 
line, and

electric-indent-mode wouldn't work properly.

Greg Minshall writes:

i don't know what
would be involved to keep the fix for the original problem (which i was
also seeing), without adding these extra spaces.  but, i suspect it
would be worth it, if feasible.


I think the only way would be to change 
`org-src--contents-for-write-back' to

keep track of where the point was in the edit buffer, and clean up spaces in
other lines. Doesn't seem difficult ; maybe you could replace the 
`buffer-string`

call by two calls, to get the part before point and the one after, then work
with that.


it's long-term emacs behavior to eliminate spaces
at the end of lines, at least in programming modes.
As for the `org-src--content-indentation' spaces, they are quite 
peculiar. Note
that they are removed when you call =C-c '= and when you tangle (they 
should,
but I haven't tested it), so strictly speaking, they are removed in 
programming
modes. What if your org block itself is indented, do you also expect 
blank lines

to be entirely empty ?

As for additional indentation in a blank line, it will indeed never get 
cleaned

up by org, which isn't ideal. But then, spaces at the end of non blank lines
don't get cleaned up either (I think) and never were. It's up to the user to
remove them, in the appropriate language mode.

Despite these arguments, I have no opinion on the matter.

Regards,

--
Sébastien Miquel




Re: extra space at the end of lines in source

2021-06-22 Thread Sébastien Miquel

Hi Greg,

Greg Minshall writes:

hi.  i can't date it exactly, but in the last week or so, editing a
source buffer (with =C-c '=) adds spaces (to the "tab location") of
previously blank lines.


See https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00867.html

The goal of the change was to fix some (electric) indentation issues when
editing a src block directly.

As I write in the linked thread, setting `org-src--preserve-indentation' 
should

revert this behaviour.

Regards,

--
Sébastien Miquel




Re: org-edit-src-exit randomizes / mixes up code in source-buffer on exit

2021-06-22 Thread Sébastien Miquel

Hi,

This has been reported before.

There's a patch that fixes this here : 
https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg7.html


To fix this bug, you can can either apply this patch, downgrade org, or 
update emacs to 27.


Could anyone with commit access have a look and apply this patch to 
master ?


Regards,

--
Sébastien Miquel




Re: Large source block causes org-mode to be unusable

2021-06-21 Thread Sébastien Miquel

Hi Léo,

Léo Ackermann writes:
I am working in an org-file of reasonable size (<2000 lines): my first 
paper written in org-mode. Everything fine (and fast) until I started 
to add `#+BEGIN_proof / #+END_proof` within my .org to make my .pdf 
export prettier. This caused the editing of the proofs to be very 
slow: navigation within the proof is fast but adding/removing any char 
takes around 4s per char.
It seems that the fontify function is responsible for that (see 
screenshot). As far as I understand, this function tries to fontify 
the whole block as soon as a single char is modified. In my case, it 
then tries to fontify a whole proof (~4 pages in my .pdf, with many 
LaTeX formulas) several times per second...

You can try setting org-highlight-latex-and-related to '(latex) instead of
'(native).

Even with this setting, latex fontification in special blocks is slow. The
reason being that the whole block has the `font-lock-multiline' 
property, hence

every char insertion triggers refontification of the whole block.

In the function `org-do-latex-and-related', I commented out the second 
condition

of the `cond' form, which makes calls to `face-at-point'. This yields a
significant speedup, and was enough to make things bearable in my cases. 
You can

also try to simplify the latex regexp.

If you try these, I'd be interested to hear how much of an improvement 
theymake.


Regards,

--
Sébastien Miquel




Re: Default entry in org-src-block-faces

2021-06-19 Thread Sébastien Miquel

Hi,

Augusto Stoffel writes:

Would it make sense to allow a default entry (t FACE) in
`org-src-block-faces', to be applied to all src blocks without a more
specific entry in that alist?  There seems to be no other way to specify
a face to be applied to all src blocks, and only src blocks.


Makes sense to me.

I also wonder if there's any reason for the `org-block' face not to 
apply to "greater" blocks.


--
Sébastien Miquel




Re: An org-latex face

2021-06-01 Thread Sébastien Miquel

Sébastien Miquel writes:

There's already an `org-latex-and-relatex` regexp


I meant the `org-latex-and-related` face.

--
Sébastien Miquel




Re: [PATCH] source blocks mangled when edited

2021-06-01 Thread Sébastien Miquel

Michael Gauland writes:

This is all the*trace-output*  buffer shows:

==
1 -> (replace-buffer-contents #)
1 <- replace-buffer-contents: nil

Indeed, the `replace-buffer-contents` call is failing.

I've been able to reproduce with earlier versions of emacs 26.1. With
later versions of emacs 26, the problem goes away.

It seems earlier versions of `replace-buffer-contents` are not quite
reliable. It was patched prior to 27.1 and the new documentation
string makes some guarantees of correctness, so let's just change the
minimal version to 27.1.

Thank you for the report.

Regards,

--
Sébastien Miquel

X-Woof-Bug: confirmed

>From 8ebdbc5eca92de4429d3994a3663d8aa3b9877fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Tue, 1 Jun 2021 08:56:48 +0200
Subject: [PATCH] org-src.el: Use `replace-buffer-contents' only for emacs >=
 27

* lisp/org-src.el: Use `replace-buffer-contents' only for emacs >= 27.

It was introduced in emacs 26.1, but earlier versions made no
guarantees of correctness.
---
 lisp/org-src.el | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 79f002e56..4698c6dd2 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -1199,12 +1199,12 @@ Throw an error if there is no such buffer."
   ;; insert new contents.
   (delete-overlay overlay)
   (let ((expecting-bol (bolp)))
-	(if (version< emacs-version "26.1")
+	(if (version< emacs-version "27.1")
 	(progn (delete-region beg end)
 		   (insert (with-current-buffer write-back-buf (buffer-string
 	(save-restriction
 	  (narrow-to-region beg end)
-	  (replace-buffer-contents write-back-buf)
+	  (replace-buffer-contents write-back-buf 0.1 nil)
 	  (goto-char (point-max
 	(when (and expecting-bol (not (bolp))) (insert "\n")))
   (kill-buffer write-back-buf)
@@ -1246,13 +1246,13 @@ Throw an error if there is no such buffer."
(undo-boundary)
(goto-char beg)
(let ((expecting-bol (bolp)))
-	 (if (version< emacs-version "26.1")
+	 (if (version< emacs-version "27.1")
 	 (progn (delete-region beg end)
 		(insert (with-current-buffer write-back-buf
   (buffer-string
 	 (save-restriction
 	   (narrow-to-region beg end)
-	   (replace-buffer-contents write-back-buf)
+	   (replace-buffer-contents write-back-buf 0.1 nil)
 	   (goto-char (point-max
 	 (when (and expecting-bol (not (bolp))) (insert "\n")
 (when write-back-buf (kill-buffer write-back-buf))
-- 
2.31.1



Re: An org-latex face

2021-06-01 Thread Sébastien Miquel

Hi Léo,

Léo Ackermann writes:

When it comes to preview inline LaTeX fragments within org-mode, the 
org package applies the `org-block` face. It would be nice to *treat 
inline latex block specially*, to make integration of the those 
preview-block easier when surrounded by plaintext. This feature would 
allow to have a theme that highlight blocks (source code, examples) 
without the background artifact you can see in attachment when 
previewing latex fragments.

There's already an `org-latex-and-relatex` regexp, that will be used
if you set `org-highlight-latex-and-related` to `'(latex)` instead of
`'(native)`. The org-block face won't be applied anymore.

Regards,

--
Sébastien Miquel




Re: source blocks mangled when edited

2021-05-31 Thread Sébastien Miquel

Michael Gauland writes:

I didn't instrument the functions, but found that there are two places
that test '(if (version< emacs-version "26.1"...'. If I change that to
use "version<=", the problem goes away (I'm still running 26.1). I don't
know whether this is the right fix (the underlying problem may be a
quirk in my system, and this is just masking it).  I'm hesitant to
submit a patch unless someone else can replicate the problem.

The commit `d02ad1f207e1579aff8f36f740a065d71472c182` introduced the
use of `replace-buffer-contents` when available. This function was
introduced in emacs 26.1, hence the version tests.

There must be an issue with the `replace-buffer-contents` calls. Can
you call `trace-function` on `replace-buffer-contents` and trigger the
behaviour again to see what it returns ?

You said it also happens with `emacs -q`, right ? I'll try to see if I
can reproduce with emacs 26.1 tomorrow.

--
Sébastien Miquel




Re: source blocks mangled when edited

2021-05-31 Thread Sébastien Miquel

Hi Michael,

Michael Gauland writes:

The file has two identical source blocks. The first generally behaves
fine, though some lines get extra indentation.

The second suffers more serious distortions. For example, the first line
changes from "digraph G {" to "aph G {".


I'm unable to reproduce with a recent emacs version.


I'm not even sure how to start tracking this down. Any help would be
greatly appreciated!

The relevant functions are `org-edit-src-exit` and perhaps
`org-src--contents-for-write-back`.

Can you instrument these functions to see what's happening ? Is
`org-src--contents-for-write-back` populating the buffer correctly ?
Does the `replace-buffer-contents` call in `org-edit-src-exit` return
`t` ?

Regards,

--
Sébastien Miquel




Re: [PATCH] Bug: No highlighting after [9.4.6 (release_9.4.6-544-gc5573b @ /home/user/.emacs.d/straight/build/org/)]

2021-05-28 Thread Sébastien Miquel

Hi,

Axel Svensson writes:

Steps to reproduce:
1) In an empty org-mode buffer, type a * SPC a C-b C-b C-b .
2) The buffer now has two lines, the first one "a" and the second "* a".

Expected:
3) The second line is formatted as a first-level heading.

Actual:
3) The second line is formatted as normal text.


Thanks for the report, I can confirm this bug with latest org.

Here's a patch that fixes this.

Regards,

--
Sébastien Miquel

>From c598f705bf1d8003514751fffc07fd64620a7e42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Fri, 28 May 2021 21:14:22 +0200
Subject: [PATCH] org.el (org-fontify-extend-region): Fix headline
 fontification in edge case

* lisp/org.el (org-fontify-extend-region): Fix fontification of
headline or meta line created by inserting a newline.

Unrelated to the fix: `org-fontify-extend-region' is added to
`font-lock-extend-after-change-region-function' and doesn't need to
use `save-excursion'.
---
 lisp/org.el | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..b7b1416bd 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5427,7 +5427,9 @@ by a #."
 	  t)

 (defun org-fontify-extend-region (beg end _old-len)
-  (let ((begin-re "\\(\\[\\|\\(#\\+begin_\\|begin{\\)\\S-+\\)")
+  (let ((end (if (progn (goto-char end) (looking-at-p "^[*#]"))
+ (1+ end) end))
+(begin-re "\\(\\[\\|\\(#\\+begin_\\|begin{\\)\\S-+\\)")
 	(end-re "\\(\\]\\|\\(#\\+end_\\|end{\\)\\S-+\\)")
 	(extend
  (lambda (r1 r2 dir)
@@ -5437,15 +5439,14 @@ by a #."
"[][]" r2
 		   (match-string-no-properties 0)
 	 (re-search-forward (regexp-quote re) nil t dir)
+(goto-char beg)
+(back-to-indentation)
 (save-match-data
-  (save-excursion
-	(goto-char beg)
-	(back-to-indentation)
-	(cond ((looking-at end-re)
-	   (cons (or (funcall extend "begin" "[" -1) beg) end))
-	  ((looking-at begin-re)
-	   (cons beg (or (funcall extend "end" "]" 1) end)))
-	  (t (cons beg end)))
+  (cond ((looking-at end-re)
+	 (cons (or (funcall extend "begin" "[" -1) beg) end))
+	((looking-at begin-re)
+	 (cons beg (or (funcall extend "end" "]" 1) end)))
+	(t (cons beg end))

 (defun org-activate-footnote-links (limit)
   "Add text properties for footnotes."
-- 
2.31.1


Re: Question Regarding Yasnippet With Org Mode (Emacs 27.2)

2021-05-23 Thread Sébastien Miquel

Samuel Banya writes:
Do you think that maybe changing the setting you had mentioned before, 
'org-src-tab-acts-natively' to false (aka nil or '0' (zero) value) via 
a change in my configuration would make this error not happen within 
Org-Mode in that case?


Yes, that should work. I have not tested it though.

Regards,

--
Sébastien Miquel




Re: Question Regarding Yasnippet With Org Mode (Emacs 27.2)

2021-05-23 Thread Sébastien Miquel

Hi Samuel,

I'm guessing its some kind of Org Mode vs Yasnippet issue where 
Org-mode is expanding it too fast, when it should wait for user input 
hence the "$1" section.


I guess yasnippet tries to indent the inside of the block (see
=yas-indent-line=) before the lang part of the src block is specified.

In Emacs 27.2, the default value of =org-src-tab-acts-natively= was
changed to `t`. With this setting, trying to indent a src block with
no language results in this error.

--
Sébastien Miquel




Re: Bug: [PATCH] Can't set background color of latex fragment

2021-05-23 Thread Sébastien Miquel

Hi,

Here's a patch that fixes this bug by calling `dvipng' with the `-bg
Transparent' argument only when no background color is set.

Regards,

--
Sébastien Miquel

>From 5872fc3143162fbda11cf2aa5a3798567664be99 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sun, 23 May 2021 22:07:25 +0200
Subject: [PATCH] org.el (org-create-formula-image): Fix ignored background
 color

* lisp/org.el (org-preview-latex-process-alist): add a `:transparent-image-converter'
property for `dvipng'.
(org-create-formula-image): If available, use
`:transparent-image-converter' when no background color is set.
---
 lisp/org.el | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..d544e62fb 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3319,7 +3319,9 @@ All available processes and theirs documents can be found in
  :image-output-type "png"
  :image-size-adjust (1.0 . 1.0)
  :latex-compiler ("latex -interaction nonstopmode -output-directory %o %f")
- :image-converter ("dvipng -D %D -T tight -bg Transparent -o %O %f"))
+ :image-converter ("dvipng -D %D -T tight -o %O %f")
+ :transparent-image-converter
+ ("dvipng -D %D -T tight -bg Transparent -o %O %f"))
 (dvisvgm
  :programs ("latex" "dvisvgm")
  :description "dvi > svg"
@@ -3374,6 +3376,9 @@ PROPERTIES accepts the following attributes:
   given to the shell and supports any of the following
   place-holders defined below.

+If set, :transparent-image-converter is used instead of :image-converter to
+convert an image when the background color is nil or \"Transparent\".
+
 Place-holders used by `:image-converter' and `:latex-compiler':

   %finput file name
@@ -16288,7 +16293,6 @@ a HTML file."
 	   org-format-latex-header
 	   'snippet)))
 	 (latex-compiler (plist-get processing-info :latex-compiler))
-	 (image-converter (plist-get processing-info :image-converter))
 	 (tmpdir temporary-file-directory)
 	 (texfilebase (make-temp-name
 		   (expand-file-name "orgtex" tmpdir)))
@@ -16302,7 +16306,11 @@ a HTML file."
 		 "Black"))
 	 (bg (or (plist-get options (if buffer :background :html-background))
 		 "Transparent"))
-	 (log-buf (get-buffer-create "*Org Preview LaTeX Output*"))
+	 (image-converter
+  (or (and (string= bg "Transparent")
+   (plist-get processing-info :transparent-image-converter))
+  (plist-get processing-info :image-converter)))
+ (log-buf (get-buffer-create "*Org Preview LaTeX Output*"))
 	 (resize-mini-windows nil)) ;Fix Emacs flicker when creating image.
 (dolist (program programs)
   (org-check-external-command program error-message))
-- 
2.31.1


Re: Bug: Can't set background color of latex fragment

2021-05-19 Thread Sébastien Miquel

Hi Roshan,

Roshan Shariff writes:

I can confirm this bug with dvipng --- with the "-bg Transparent"
option, dvipng ignores the background color from the input tex file,
whereas without that option it always produces an opaque background.
There's currently no way to dynamically change command line
parameters, so I'm not sure how to solve this problem while supporting
both use cases.


I asked about this behaviour on the dvipng mailing list, and the
maintainer doesn't consider it a bug, see
https://lists.nongnu.org/archive/html/dvipng/2021-05/msg2.html.

Can you explain the use for a `Transparent` background ? Transparent
images are poorly supported in emacs, all it does is render it with
the background color of the default face -- which may not be the
expected result.

Regards,

--
Sébastien Miquel



On Wed, Apr 7, 2021 at 1:38 PM Sébastien Miquel
  wrote:

To reproduce with `emacs -Q` :
   - Open an org buffer
   - Call ~(setq org-format-latex-options '(:foreground default
 :background "Black" :matchers ("$")))~
   - Call =C-c C-x C-l= (org-latex-preview) on a latex fragment such as
 $abc$

This bug was introduced by the commit 2f9e1569f which adds the option
`-bg Transparent` to the arguments of `dvipng`. According to its
manual, this option should be ignored if a background is already set,
but it doesn't seem to be. Perhaps org should set it differently.

--
Sébastien Miquel





Re: [PATCH] Fontification for inline src blocks

2021-05-18 Thread Sébastien Miquel

Timothy writes:


In src blocks, you have the org-block-begin-line face applied. This (in
any sensible theme) has the same background as org-block.


I might be confused by my own config, but that doesn't seem to be the
case. Unless customized, the =org-block-begin-line= inherits from
org-meta-line, and the org-block documentation does specify that it
applies *inside* blocks.

I personaly dislike any inline change of background color. It makes
some sense for the python code, since it isn't org anymore (indeed,
the fontification is done in another buffer), but the src_lang, and
the result part are just org syntax.

Here's an example of a reasonable -- I hope -- use of those faces.





The ~org-src-font-lock-fontify-block~ function could be modified to
take an optional =inline= argument. When =t=, it should not set the
=multiline= font property. Although this is very minor, it would allow
one to easily advice this function to behave differently in inline src
blocks. For example, to not use the =org-block= face in this case.

I don't see where the multiline property is currently set, would you mind
pointing it out to me?


Right at the end of ~org-src-font-lock-fontify-block~. The property
is =font-lock-multiline=.


I'm going to be using the original symbols in my configuration anyway
because I think they're nicer, but clearly this is contentious. I'd want
to hear from more people on this.

If results prettification were disabled by default, There would be much
less contention.


Since ~prettify-symbols~ seems to be raising some usability concerns,
perhaps ~org-inline-src-prettify-results~ should default to ~nil~.
It'd be unlike org to hide things from the user in the default
configuration.

This seems somewhat sensible to me, but I must say that {{{results()}}}
is /ugly/ and I suspect that many users would like the effect, but a
minority will be aware of this option. Perhaps this is worth doing
anyway.

I agree. But org-mode is ugly by default, so that is consistent.


So are you suggesting I do or don't create new faces for this?

You should create new faces yes. I do not know whether one or two faces is
best.

Regards,

--
Sébastien Miquel



Re: begin_src Indentation in org 9.4.4, 9.4.5

2021-05-18 Thread Sébastien Miquel

Hi Bastien,

Bastien writes:

Before I revert the commit and try your suggestion, can you share a
patch that add both changes (the revert and your fix) manually so I
can test it?  If this fixes the original issue while preserving
electric indentation, I'm okay with it.

Here's such a patch.


Also, do you want to become the maintainer for org-src.el?  We need
more people taking charge of specific areas in Org's code.

I do intend to keep monitoring this list and help around for the
foreseeable future, and I would certainly agree to whatever sort of
maintainer position eventually, but I hold no particular interest (or
deep understanding) in this specific file.

Regards,

--
Sébastien Miquel

>From 1be7fa790e68d1fc2d198eee81c0d3bb72156d08 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Tue, 18 May 2021 14:39:33 +0200
Subject: [PATCH] org.el (org-src--contents-for-write-back): Indent blank lines

* lisp/org.el (org-src--contents-for-write-back): Indent blank lines.
* lisp/org-src.el (org-return): Revert part of commit bfda3cc7df.
---
 lisp/org-src.el | 9 -
 lisp/org.el | 6 +-
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 5604e6568..79f002e56 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -453,15 +453,14 @@ Assume point is in the corresponding edit buffer."
   (insert (org-no-properties contents))
   (goto-char (point-min))
   (when (functionp write-back) (save-excursion (funcall write-back)))
-  ;; Add INDENTATION-OFFSET to every non-empty line in buffer,
+  ;; Add INDENTATION-OFFSET to every line in buffer,
   ;; unless indentation is meant to be preserved.
   (when (> indentation-offset 0)
 	(while (not (eobp))
 	  (skip-chars-forward " \t")
-	  (unless (eolp)		;ignore blank lines
-	(let ((i (current-column)))
-	  (delete-region (line-beginning-position) (point))
-	  (indent-to (+ i indentation-offset
+	  (let ((i (current-column)))
+	(delete-region (line-beginning-position) (point))
+	(indent-to (+ i indentation-offset)))
 	  (forward-line))
 
 (defun org-src--edit-element
diff --git a/lisp/org.el b/lisp/org.el
index ae09f3e99..0add9bc2e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18018,10 +18018,6 @@ object (e.g., within a comment).  In these case, you need to use
 	 (delete-and-extract-region (point) (line-end-position
 	(org--newline indent arg interactive)
 	(save-excursion (insert trailing-data
- ;; FIXME: In a source block, don't try to indent as it may result
- ;; in weird results due to `electric-indent-mode' being `t'.
- ((eq element-type 'src-block)
-  (org--newline nil nil nil))
  (t
   ;; Do not auto-fill when point is in an Org property drawer.
   (let ((auto-fill-function (and (not (org-at-property-p))
@@ -19167,7 +19163,7 @@ Also align node properties according to `org-property-format'."
 		   (line-beginning-position 2
 	 nil)
 	((and (eq type 'src-block)
-  org-src-tab-acts-natively
+		  org-src-tab-acts-natively
 		  (> (line-beginning-position)
 		 (org-element-property :post-affiliated element))
 		  (< (line-beginning-position)
-- 
2.31.1



Re: [PATCH] Fontification for inline src blocks

2021-05-18 Thread Sébastien Miquel

Hi Timothy,

Thanks for your work. I hope this can be merged.

Here are a few comments.

Doesn't this line in ~org-toggle-inline-results-display~ throw the
configured delimiters away when called twice ?
: (setq org-inline-src-prettify-results (not 
org-inline-src-prettify-results))


I think the =org-block= face should only be applied to the actual
code, note the =src_lang= part, nor the result. For normal src blocks,
it is only used inside the block.

The ~org-src-font-lock-fontify-block~ function could be modified to
take an optional =inline= argument. When =t=, it should not set the
=multiline= font property. Although this is very minor, it would allow
one to easily advice this function to behave differently in inline src
blocks. For example, to not use the =org-block= face in this case.

I think the default parenthesis pair around results are bad. I much
preferred your original brackets. Yes, as Tom said, they look alien,
but alien is appropriate for use of ~prettify-symbols~.

Since ~prettify-symbols~ seems to be raising some usability concerns,
perhaps ~org-inline-src-prettify-results~ should default to ~nil~.
It'd be unlike org to hide things from the user in the default
configuration.

As Tom points out, the two faces used (for the =src_= and bracket and
the language part) should be customizable. The default value you chose
are fine IMO. Perhaps the language one could also be used to highlight
the language of normal src blocks, though It might be easier to use a
single face.

Timothy writes:

P.S. Nitpick: You do not need to run fontification in while loops. Just
fontifying next match before limit should be enough. Font-lock will call
the function again if needed.

I'm guessing for this to work I'd need to return the final char
fortified? Or is the moving of point enough?

Maybe related - I've noticed this doesn't seem to work with multiple
src_ blocks per line, might you have any insight here?


You need only return =t= if some fontification has been done (and set
point after the fontified part). If your function returns =t=, it will
be called again.

A case can be made for keeping the loop though. It works fine and is
clearer since the aforementioned fontlock behaviour is poorly
documented. Really, the only downside is the loss of consistency, since
the function ~org-fontify-meta-lines-and-blocks-1~ doesn't loop.

Regards,

--
Sébastien Miquel



Re: begin_src Indentation in org 9.4.4, 9.4.5

2021-05-17 Thread Sébastien Miquel

Hi Bastien,

The commit `bfda3cc7df31fa79222efb4c190618c3c85a3d04` breaks automatic
(electric) indentation  in src blocks for all configurations.

Here's what happens with the original issue.

When you press `RET` after the first ~hello hi~, the result is that
the first line is indented by two spaces, and the second (where the
point is) isn't.
 - since ~electric-indent-mode~ is on, ~org-return~ is called with
   `indent` set to `t`.
 - Since ~org-src-tab-acts-natively~ is `t`, indentation is done by
   calling `tab` in a src edit buffer, which by itself, does nothing.
 - The observed indentation comes from ~org-src--contents-for-write-back~.
   Since ~org-src--content-indentation~ is 2 and 
~org-src--preserve-indentation~

   is ~nil~, this functions further indents each *non blank* line by 2.

At this point, the first line is indented, cursor is at bol. Note
that you cannot indent your current empty line with `tab`. You can
either indent it manually, or call ~org-edit-special~.

When you write your second line, then press `RET`,
~org-src--contents-for-write-back~ will add an additional two spaces,
producing the reported result.

I think a reasonable fix is to have ~org-src--contents-for-write-back~
also indent blank lines. To do this, you need only remove following
line from its definition.

: (unless (eolp)        ;ignore blank lines

With this done and `bfda3cc7df31fa79222efb4c190618c3c85a3d04`
reverted, the original issue is fixed, and the behaviour is better:
when you press `RET` to enter a newline in a src block, it is
automatically indented.

The downside is that, unless ~org-src--preserve-indentation~ is `t`,
when editing a src block, every empty line will be indented with
spaces (according to ~org-edit-src-content-indentation~ + the
indentation of the #+begin_src line). I think this is reasonable, but
perhaps some might disagree.

Regards,

--
Sébastien Miquel




Re: [Patch] Bug: org-indent-region doesn't restore cursor position when org-src-tab-acts-natively is t [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]

2021-05-16 Thread Sébastien Miquel

Hi Bastien,

Bastien writes:

Sorry it took so long to apply this patch, this is now done in maint.

No problem, thank you for getting back on this.

I think something went wrong though. I've attached as a new patch a
part of the previous one that wasn't applied. Without it, some
write-back buffers are never killed.

Regards,

--
Sébastien Miquel

>From f293a9d5808c413ce785646ebf5f480df3a00a2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sun, 16 May 2021 19:13:53 +0200
Subject: [PATCH] org-src.el (org-edit-src-exit): Fix write-back-buf not
 getting killed

* lisp/org.el (org-edit-src-exit): Fix write-back-buf not getting
killed
---
 lisp/org-src.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index df3c76e13..5604e6568 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -1255,8 +1255,8 @@ Throw an error if there is no such buffer."
 	   (narrow-to-region beg end)
 	   (replace-buffer-contents write-back-buf)
 	   (goto-char (point-max
-	 (when (and expecting-bol (not (bolp))) (insert "\n")))
-   (when write-back-buf (kill-buffer write-back-buf
+	 (when (and expecting-bol (not (bolp))) (insert "\n")
+(when write-back-buf (kill-buffer write-back-buf))
 ;; If we are to return to source buffer, put point at an
 ;; appropriate location.  In particular, if block is hidden, move
 ;; to the beginning of the block opening line.
-- 
2.31.1



Re: [PATCH] tangling seems to have broken today

2021-05-06 Thread Sébastien Miquel

Hi Bastien,

Bastien writes:

Also, nitpick: please don't add a full-stop at the end of the first
line of the commit message (or the subject of your patch).

Unless I misunderstand what you mean, the patch seems to follow this
style.


I think this should be applied to the maint branch, right?  In this
case, the patch does not apply.  Can you check and repropose a patch
against maint?  Or just let me know if I'm mistaken.

It fixes an issue introduced by a commit in master, so it should be
applied to master.


So we're all set here?

This should be it!


Regards,

--
Sébastien Miquel




Re: [PATCH] tangling seems to have broken today

2021-05-05 Thread Sébastien Miquel

Hi Bastien,

The issue is that currently tangling a single block by calling
`org-babel-tangle` with a prefix argument fails. This is unrelated to
the earlier thread today, but was introduced by my original commit
a2cb9b853d.

Unfortunately, fixing it requires some refactorisation to avoid code
duplication. To keep the patch as simple as possible, I have
introduced a new helper function, I hope this is okay.

I have tested the attached patch with the uses cases shown so far, as
well as my own and the org test suite.

I apologise again for the troubles.

--
Sébastien Miquel

>From 69be5864d9c936396317d81b6c39ddb166ac45d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Wed, 5 May 2021 17:45:09 +0200
Subject: [PATCH] ob-tangle.el: Fix single block tangle

lisp/ob-tangle.el (org-babel-tangle-single-block): Fix the result when
`only-this-block' is `t' to match what is expected by
`org-babel-tangle'.
(org-babel-effective-tangled-filename): Extract the
computation of filename of tangled src block.
(org-babel-tangle-collect-blocks): Use `org-babel-effective-tangled-filename'.
---
 lisp/ob-tangle.el | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 8af03b11a..562776ae8 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -350,6 +350,22 @@ that the appropriate major-mode is set.  SPEC has the form:
 	   (org-fill-template
 		org-babel-tangle-comment-format-end link-data)

+(defun org-babel-effective-tangled-filename (buffer-fn src-lang src-tfile)
+  "Return effective tangled filename of a source-code block.
+BUFFER-FN is the name of the buffer, SRC-LANG the language of the
+block and SRC-TFILE is the value of the :tangle header argument,
+as computed by `org-babel-tangle-single-block'."
+  (let ((base-name (cond
+((string= "yes" src-tfile)
+ ;; Use the buffer name
+ (file-name-sans-extension buffer-fn))
+((> (length src-tfile) 0) src-tfile)))
+(ext (or (cdr (assoc src-lang org-babel-tangle-lang-exts)) src-lang)))
+(when base-name
+  ;; decide if we want to add ext to base-name
+  (if (and ext (string= "yes" src-tfile))
+  (concat base-name "." ext) base-name
+
 (defun org-babel-tangle-collect-blocks ( lang-re tangle-file)
   "Collect source blocks in the current Org file.
 Return an association list of language and source-code block
@@ -378,17 +394,8 @@ be used to limit the collected code blocks by target file."
 	;; file name.
 	(let* ((block (org-babel-tangle-single-block counter))
(src-tfile (cdr (assq :tangle (nth 4 block
-		   (base-name (cond
-			   ((string= "yes" src-tfile)
-;; buffer name
-(file-name-sans-extension
- (nth 1 block)))
-			   ((> (length src-tfile) 0) src-tfile)))
-		   (ext (or (cdr (assoc src-lang org-babel-tangle-lang-exts)) src-lang))
-		   (file-name (when base-name
-;; decide if we want to add ext to base-name
-(if (and ext (string= "yes" src-tfile))
-(concat base-name "." ext) base-name)))
+		   (file-name (org-babel-effective-tangled-filename
+   (nth 1 block) src-lang src-tfile))
 		   (by-fn (assoc file-name blocks)))
 	  (if by-fn (setcdr by-fn (cons (cons src-lang block) (cdr by-fn)))
 		(push (cons file-name (list (cons src-lang block))) blocks)))
@@ -482,7 +489,10 @@ non-nil, return the full association list to be used by
 		  (org-trim (org-remove-indentation body)))
 		comment)))
 (if only-this-block
-	(list (cons src-lang (list result)))
+(let* ((src-tfile (cdr (assq :tangle (nth 4 result
+   (file-name (org-babel-effective-tangled-filename
+   (nth 1 result) src-lang src-tfile)))
+  (list (cons file-name (list (cons src-lang result)
   result)))

 (defun org-babel-tangle-comment-links ( info)
-- 
2.31.1


Re: tangling seems to have broken today

2021-05-05 Thread Sébastien Miquel

Eric S Fraga writes:

I was using org-babel-tangle.  Although, in this case, with C-u before
to tangle just the particular block.

Indeed, I have broken this. I'll provide a patch, shortly.

--
Sébastien Miquel




Re: tangling seems to have broken today

2021-05-05 Thread Sébastien Miquel

Hi Eric, Timothy,

Eric S Fraga writes:

I can no longer tangle with a given file name.  The error I get
indicates that the tangling procedure is looking at the first line of
the actual code block.

What command are you using ?

Running `org-babel-tangle` works for me with latest master using your
example.


--
Sébastien Miquel




Re: Bug: [PATCH] org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

2021-05-05 Thread Sébastien Miquel

No Wayman writes:

Another related bug to the changes:

I have the :tangle header-arg set to evaluate some elisp to return the 
file name:


org-babel no longer interprets this elisp. It is being used literally 
as the file name:

e.g.

Wrote /home/n/.emacs.d/(concat (file-name-sans-extension 
(buffer-file-name)) ".el") 

Here's another patch, to be applied on top of the previous one, that
fixes this.

The specific case you mention can also be achieved by setting the
:tangle argument to `yes`: in this case, the tangled file name is
computed using the buffer file name and changing the extension
according to the src block language.


Thank you again for the report, and sorry for breaking everything.

--
Sébastien Miquel

>From b7c5103fdd05c3d30805ebcc5084ef82c44cd8ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Wed, 5 May 2021 08:31:43 +0200
Subject: [PATCH] ob-tangle.el: (org-babel-tangle-collect-blocks): Use correct
 tangle name

* lisp/ob-tangle.el: (org-babel-tangle-collect-blocks): Use correct
tangle name.

The :tangle header argument might be some elisp, to be evaluated.
---
Range-diff:
-:  - > 1:  b7c5103fd ob-tangle.el: (org-babel-tangle-collect-blocks): Use correct tangle name

 lisp/ob-tangle.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 96a4ef049..8af03b11a 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -377,6 +377,7 @@ be used to limit the collected code blocks by target file."
 	;; Add the spec for this block to blocks under its tangled
 	;; file name.
 	(let* ((block (org-babel-tangle-single-block counter))
+   (src-tfile (cdr (assq :tangle (nth 4 block
 		   (base-name (cond
 			   ((string= "yes" src-tfile)
 ;; buffer name
-- 
2.31.1


Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

2021-05-04 Thread Sébastien Miquel

Hi Bastien,

Bastien writes:

I tried to apply this (transitory?) patch against maint and it did not
apply.  It applies okay on master.  For bug fixes, please make patches
againt the maint branch.

This fixes a bug introduced by a commit in master. I've attached the same
patch here, properly formated. I think it should be applied to master.

It reverts a part of a2cb9b853: permissions are no longer set before writing
to the tangled file.

I've CC'd Tom, which made the original suggestion. I guess we could set the
write and execute permissions before writing, and set the read permissions
afterwards.

--
Sébastien Miquel

>From e56a05f4f5a3cce9cfdeb71854475e29aac1a6e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Tue, 4 May 2021 22:59:36 +0200
Subject: [PATCH] ob-tangle.el (org-babel-tangle): Fix readonly tangle

* lisp/ob-tangle.el (org-babel-tangle): Fix readonly tangle.
---
 lisp/ob-tangle.el | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 36144d6ae..96a4ef049 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -268,11 +268,11 @@ matching a regular expression."
 		lspecs)
 		   (when make-dir
 		 (make-directory fnd 'parents))
-   ;; erase previous file and set permissions on empty
-   ;; file before writing
-   (write-region "" nil file-name nil 0)
-		   (mapc (lambda (mode) (set-file-modes file-name mode)) modes)
+   ;; erase previous file
+   (when (file-exists-p file-name)
+ (delete-file file-name))
 		   (write-region nil nil file-name)
+		   (mapc (lambda (mode) (set-file-modes file-name mode)) modes)
(push file-name path-collector))
 	 (if (equal arg '(4))
 	 (org-babel-tangle-single-block 1 t)
-- 
2.31.1



Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

2021-05-04 Thread Sébastien Miquel

No Wayman writes:

Subsequent tangles did not fail for me.

Ah yes, I understand, it is possible to delete a file without write
permission.

I'll see if I can fix this bug and keep the security improvements. In
the meantime, you can apply the attached patch that should fix
your issue.

Thank you for the report.

--
Sébastien Miquel

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 36144d6ae..c041ff4b3 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -270,9 +270,10 @@ matching a regular expression."
 		 (make-directory fnd 'parents))
;; erase previous file and set permissions on empty
;; file before writing
-   (write-region "" nil file-name nil 0)
-		   (mapc (lambda (mode) (set-file-modes file-name mode)) modes)
+   (when (file-exists-p file-name)
+ (delete-file file-name))
 		   (write-region nil nil file-name)
+		   (mapc (lambda (mode) (set-file-modes file-name mode)) modes)
(push file-name path-collector))
 	 (if (equal arg '(4))
 	 (org-babel-tangle-single-block 1 t)


Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

2021-05-04 Thread Sébastien Miquel

Hi,

No Wayman writes:
I'm tangling my early-init/init.el with the :tangle-mode header arg 
set to (identity (#o444)).

This should be `(identity #o444)` I believe ?

The idea behind this was to prevent myself from accidentally editing 
the tangled source files
instead of the Org files. 
Unfortunately, since a3cb9b853 there seems to be a behavior change for 
org-babel-tangle which prevents this.

File permissions are now set before writing to the file, for security
reasons. In this case, you remove write permission so emacs fails to
write to the file. Perhaps we should try to support this use case.

However, even with the previous version, it seems that subsequent
tangles should have failed (emacs should fail to delete the previous
tangled file). Can you confirm this and explain how you dealt with it ?

As a workaround, you could use a file-local
`org-babel-post-tangle-hook` to set file permission. Although
subsequent tangles will still fail.

--
Sébastien Miquel




Re: [Feature request] String escaped noweb expansion

2021-05-02 Thread Sébastien Miquel



Timothy writes:

Just quickly, this works:

#+begin_src emacs-lisp :noweb yes
(setq my-latex-code "\
<>
")
#+end_src

I don't understand the purpose of your backslash, is it a typo ? With
or without it, this doesn't tangle to working lisp with my example.

The point of my proposal is to allow one to write unescaped latex in
the latex src block. (Mostly to avoid doubling every backslash). It is
quite the shame to have to write non latex code in a latex src block.

Regards,

--
Sébastien Miquel




[Feature request] String escaped noweb expansion

2021-05-02 Thread Sébastien Miquel

Hi,

Would there be some interest in extending the noweb syntax to allow
for string escaped expansion ?

I've modified my setup so that if the noweb delimiter `<<` is preceded
by a quote `"` then the expansion is string escaped (and the prefix
isn't duplicated for each line). This allows the following.

#+BEGIN_SRC latex :noweb-ref latex-ref
\some \multiline
\unescaped \latex \code
#+END_SRC

#+BEGIN_SRC emacs-lisp :noweb yes
(setq my-latex-code "<>\n")
#+END_SRC

I don't think there's any way to achieve such functionality currently.

--
Sébastien Miquel




Re: <> and ?font-lock? fly-check, ...

2021-05-02 Thread Sébastien Miquel

Hi Greg,

Greg Minshall writes:

is there an obvious thing to do to either get whatever syntax checker is
running to ignore the <> reference, or some such?

From the org side of things, you could customize the variables
`org-babel-noweb-wrap-start` and `org-babel-noweb-wrap-end` to
something that doesn't interfere with bash syntax.

Regards,

--
Sébastien Miquel




Re: [PATCH] ob-tangle.el: Speed up tangling

2021-05-01 Thread Sébastien Miquel

Hi Bastien,

Bastien writes:

The compiler is complaining with

   In toplevel form:
   ob-tangle.el:196:1: Warning: Variable ‘modes’ left uninitialized

Also, it breaks these two tests for me:

2 unexpected results:
FAILED  ob-tangle/block-order
FAILED  ob-tangle/continued-code-blocks-w-noweb-ref


Indeed, I hadn't thought to run the tests, sorry. I've fixed my code
and modified the `block-order` test in order for it to pass.

The patch does modify the order of the tangled blocks. When several
blocks with different languages are tangled to the same file, they
used to be grouped according to language, and are now tangled in the
order in which they appear. I assumed this was an oversight in the
previous code, but since this test exists, maybe it was intended ?

Nicolas Goaziou wrote this test, perhaps he could comment on this.

Regards,

--
Sébastien Miquel

>From 2aa09e8d2f4e8703190e9035d711508c11b3a8eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sat, 1 May 2021 21:18:44 +0200
Subject: [PATCH] ob-tangle.el: Improve tangling

* lisp/ob-tangle.el (org-babel-tangle-collect-blocks): Group
collected blocks by tangled file name.
(org-babel-tangle): Avoid quadratic behavior in number of blocks and
set modes before writing to file.
* testing/lisp/test-ob-tangle.el (ob-tangle/block-order): Update test.
---
 lisp/ob-tangle.el  | 151 -
 testing/lisp/test-ob-tangle.el |   2 +-
 2 files changed, 74 insertions(+), 79 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 4c0c3132d..36144d6ae 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -225,67 +225,55 @@ matching a regular expression."
 	   (or (cdr (assq :tangle (nth 2 (org-babel-get-src-block-info 'light
 		   (user-error "Point is not in a source code block"
 	path-collector)
-	(mapc ;; map over all languages
-	 (lambda (by-lang)
-	   (let* ((lang (car by-lang))
-		  (specs (cdr by-lang))
-		  (ext (or (cdr (assoc lang org-babel-tangle-lang-exts)) lang))
-		  (lang-f (org-src-get-lang-mode lang))
-		  she-banged)
-	 (mapc
-	  (lambda (spec)
-		(let ((get-spec (lambda (name) (cdr (assoc name (nth 4 spec))
-		  (let* ((tangle (funcall get-spec :tangle))
-			 (she-bang (let ((sheb (funcall get-spec :shebang)))
- (when (> (length sheb) 0) sheb)))
-			 (tangle-mode (funcall get-spec :tangle-mode))
-			 (base-name (cond
- ((string= "yes" tangle)
-  (file-name-sans-extension
-   (nth 1 spec)))
- ((string= "no" tangle) nil)
- ((> (length tangle) 0) tangle)))
-			 (file-name (when base-name
-  ;; decide if we want to add ext to base-name
-  (if (and ext (string= "yes" tangle))
-	  (concat base-name "." ext) base-name
-		(when file-name
-		  ;; Possibly create the parent directories for file.
-		  (let ((m (funcall get-spec :mkdirp))
-			(fnd (file-name-directory file-name)))
-			(and m fnd (not (string= m "no"))
-			 (make-directory fnd 'parents)))
-		  ;; delete any old versions of file
-		  (and (file-exists-p file-name)
-			   (not (member file-name (mapcar #'car path-collector)))
-			   (delete-file file-name))
-		  ;; drop source-block to file
-		  (with-temp-buffer
-			(when (fboundp lang-f) (ignore-errors (funcall lang-f)))
-			(when (and she-bang (not (member file-name she-banged)))
+	(mapc ;; map over file-names
+	 (lambda (by-fn)
+	   (let ((file-name (car by-fn)))
+	 (when file-name
+   (let ((lspecs (cdr by-fn))
+		 (fnd (file-name-directory file-name))
+		 modes make-dir she-banged lang)
+	 ;; drop source-blocks to file
+	 ;; We avoid append-to-file as it does not work with tramp.
+	 (with-temp-buffer
+		   (mapc
+		(lambda (lspec)
+		  (let* ((block-lang (car lspec))
+			 (spec (cdr lspec))
+			 (get-spec (lambda (name) (cdr (assq name (nth 4 spec)
+			 (she-bang (let ((sheb (funcall get-spec :shebang)))
+ (when (> (length sheb) 0) sheb)))
+			 (tangle-mode (funcall get-spec :tangle-mode)))
+		(unless (string-equal block-lang lang)
+			  (setq lang block-lang)
+			  (let ((lang-f (org-src-get-lang-mode lang)))
+			(when (fboundp lang-f) (ignore-errors (funcall lang-f)
+		;; if file contains she-bangs, then make it executable
+		(when she-bang
+			  (unless tangle-mode (setq tangle-mode #o755)))
+		(when tangle-mode
+			  (add-to-list 'modes tangle-mode))
+		;; Possibly create the parent directories for file.
+		(let ((m (funcall get-spec :mkdirp)))
+			  (and m fnd (not (string= m "no"))
+			   (setq make-dir t)))
+		;; Handle :padlines unless first line in file
+		(unless (or (string= "no" (funcall get-spec :padline))
+			

Re: [PATCH] ob-tangle.el: Speed up tangling

2021-04-21 Thread Sébastien Miquel

Hi Tom,

Thank you again for your comments.

Tom Gillespie writes:

I think that the location of condition-case is ok, but I wonder what
would happen if something were to fail before entering that? I think
that only a subset of the files would be tangled, but they would all
have their correct modes, so I think that that is ok.

On second thought, I'm uneasy about my approach. If tangling fails,
the user might miss the error message since it is quickly replaced by
the tangling info. Ideally we should backup all the tangled files and
restore them all if a single one fails to ensure we're back to a
consistent state.

I'm unsure what would be best practices here. In case of a remote
tangled files, I don't know if temporary files should be remote or
not, and what guarantees do emacs primitives such as ~rename-file~
offer.

Although a robust tangling system that deals with errors and
guarantees that the state ends up consistent would be nice to have,
I'll take the failure considerations off this patch to keep it simple.
It'll make a better starting point for future work at least.

As is currently the case, if tangling fails, an error with be thrown,
the user will certainly notice and should assume that everything is
broken until another tangling succeeds.

I've kept the modes improvements.

Regards,

--
Sébastien Miquel

>From 6b123c956ac7abe0210cf7b1145ebe0a68f04713 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sat, 17 Apr 2021 21:48:30 +0200
Subject: [PATCH] ob-tangle.el: Improve tangling

,* lisp/ob-tangle.el (org-babel-tangle-collect-blocks): Group
collected blocks by tangled file name.
(org-babel-tangle): Avoid quadratic behavior in number of blocks and
set modes before writing to file.
---
 lisp/ob-tangle.el | 151 ++
 1 file changed, 73 insertions(+), 78 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 4c0c3132d..8ca6b66fe 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -225,67 +225,55 @@ matching a regular expression."
 	   (or (cdr (assq :tangle (nth 2 (org-babel-get-src-block-info 'light
 		   (user-error "Point is not in a source code block"
 	path-collector)
-	(mapc ;; map over all languages
-	 (lambda (by-lang)
-	   (let* ((lang (car by-lang))
-		  (specs (cdr by-lang))
-		  (ext (or (cdr (assoc lang org-babel-tangle-lang-exts)) lang))
-		  (lang-f (org-src-get-lang-mode lang))
-		  she-banged)
-	 (mapc
-	  (lambda (spec)
-		(let ((get-spec (lambda (name) (cdr (assoc name (nth 4 spec))
-		  (let* ((tangle (funcall get-spec :tangle))
-			 (she-bang (let ((sheb (funcall get-spec :shebang)))
- (when (> (length sheb) 0) sheb)))
-			 (tangle-mode (funcall get-spec :tangle-mode))
-			 (base-name (cond
- ((string= "yes" tangle)
-  (file-name-sans-extension
-   (nth 1 spec)))
- ((string= "no" tangle) nil)
- ((> (length tangle) 0) tangle)))
-			 (file-name (when base-name
-  ;; decide if we want to add ext to base-name
-  (if (and ext (string= "yes" tangle))
-	  (concat base-name "." ext) base-name
-		(when file-name
-		  ;; Possibly create the parent directories for file.
-		  (let ((m (funcall get-spec :mkdirp))
-			(fnd (file-name-directory file-name)))
-			(and m fnd (not (string= m "no"))
-			 (make-directory fnd 'parents)))
-		  ;; delete any old versions of file
-		  (and (file-exists-p file-name)
-			   (not (member file-name (mapcar #'car path-collector)))
-			   (delete-file file-name))
-		  ;; drop source-block to file
-		  (with-temp-buffer
-			(when (fboundp lang-f) (ignore-errors (funcall lang-f)))
-			(when (and she-bang (not (member file-name she-banged)))
+	(mapc ;; map over file-names
+	 (lambda (by-fn)
+	   (let ((file-name (car by-fn)))
+	 (when file-name
+   (let ((lspecs (cdr by-fn))
+		 (fnd (file-name-directory file-name))
+		 modes make-dir she-banged lang)
+	 ;; drop source-blocks to file
+	 ;; We avoid append-to-file as it does not work with tramp.
+	 (with-temp-buffer
+		   (mapc
+		(lambda (lspec)
+		  (let* ((block-lang (car lspec))
+			 (spec (cdr lspec))
+			 (get-spec (lambda (name) (cdr (assq name (nth 4 spec)
+			 (she-bang (let ((sheb (funcall get-spec :shebang)))
+ (when (> (length sheb) 0) sheb)))
+			 (tangle-mode (funcall get-spec :tangle-mode)))
+		(unless (string-equal block-lang lang)
+			  (setq lang block-lang)
+			  (let ((lang-f (org-src-get-lang-mode lang)))
+			(when (fboundp lang-f) (ignore-errors (funcall lang-f)
+		;; if file contains she-bangs, then make it executable
+		(when she-bang
+			  (unless tangle-mode (setq tangle-mode #o755)))
+		(when tangle-mode
+			  (add-to-list mode

Re: [PATCH] ob-tangle.el: Speed up tangling

2021-04-19 Thread Sébastien Miquel

Hi Tom,

Thank you for the comments.

Tom Gillespie writes:
> All of the issues that I'm aware of are related to what
> happens if tangling fails part way through the process.

That's not something I had considered. I wrote a new version of the
patch (attached) which addresses the insecure behaviour and the
possibility of failure. Please tell me what you think.

I've also
 + silenced the ~write-region~ messages, since I'm now writing to
   temporary files.
 + added the list of tangled files to the message to the user at the
   end of the tangling process.
 + replaced the use of ~when-let~.

Regards,

--
Sébastien Miquel
>From 82e4c1beade71194c90d377cdff7ef23532f4aa2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sat, 17 Apr 2021 21:48:30 +0200
Subject: [PATCH] ob-tangle.el: Improve tangling

,* lisp/ob-tangle.el (org-babel-tangle-collect-blocks): Group
collected blocks by tangled file name.
(org-babel-tangle): Avoid quadratic behavior in number of blocks.
Preserve original file in case of failure. Display the list of tangled
files at the end.
---
 lisp/ob-tangle.el | 167 --
 1 file changed, 87 insertions(+), 80 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 4c0c3132d..efafef5b8 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -225,87 +225,83 @@ matching a regular expression."
 	   (or (cdr (assq :tangle (nth 2 (org-babel-get-src-block-info 'light
 		   (user-error "Point is not in a source code block"
 	path-collector)
-	(mapc ;; map over all languages
-	 (lambda (by-lang)
-	   (let* ((lang (car by-lang))
-		  (specs (cdr by-lang))
-		  (ext (or (cdr (assoc lang org-babel-tangle-lang-exts)) lang))
-		  (lang-f (org-src-get-lang-mode lang))
-		  she-banged)
-	 (mapc
-	  (lambda (spec)
-		(let ((get-spec (lambda (name) (cdr (assoc name (nth 4 spec))
-		  (let* ((tangle (funcall get-spec :tangle))
-			 (she-bang (let ((sheb (funcall get-spec :shebang)))
- (when (> (length sheb) 0) sheb)))
-			 (tangle-mode (funcall get-spec :tangle-mode))
-			 (base-name (cond
- ((string= "yes" tangle)
-  (file-name-sans-extension
-   (nth 1 spec)))
- ((string= "no" tangle) nil)
- ((> (length tangle) 0) tangle)))
-			 (file-name (when base-name
-  ;; decide if we want to add ext to base-name
-  (if (and ext (string= "yes" tangle))
-	  (concat base-name "." ext) base-name
-		(when file-name
-		  ;; Possibly create the parent directories for file.
-		  (let ((m (funcall get-spec :mkdirp))
-			(fnd (file-name-directory file-name)))
-			(and m fnd (not (string= m "no"))
-			 (make-directory fnd 'parents)))
-		  ;; delete any old versions of file
-		  (and (file-exists-p file-name)
-			   (not (member file-name (mapcar #'car path-collector)))
-			   (delete-file file-name))
-		  ;; drop source-block to file
-		  (with-temp-buffer
-			(when (fboundp lang-f) (ignore-errors (funcall lang-f)))
-			(when (and she-bang (not (member file-name she-banged)))
+	(mapc ;; map over file-names
+	 (lambda (by-fn)
+	   (let ((file-name (car by-fn)))
+	 (when file-name
+   (let ((lspecs (cdr by-fn))
+		 (fnd (file-name-directory file-name))
+		 modes make-dir she-banged lang)
+	 ;; drop source-blocks to file
+	 ;; We avoid append-to-file as it does not work with tramp.
+	 (with-temp-buffer
+		   (mapc
+		(lambda (lspec)
+		  (let* ((block-lang (car lspec))
+			 (spec (cdr lspec))
+			 (get-spec (lambda (name) (cdr (assq name (nth 4 spec)
+			 (she-bang (let ((sheb (funcall get-spec :shebang)))
+ (when (> (length sheb) 0) sheb)))
+			 (tangle-mode (funcall get-spec :tangle-mode)))
+		(unless (string-equal block-lang lang)
+			  (setq lang block-lang)
+			  (let ((lang-f (org-src-get-lang-mode lang)))
+			(when (fboundp lang-f) (ignore-errors (funcall lang-f)
+		;; if file contains she-bangs, then make it executable
+		(when she-bang
+			  (unless tangle-mode (setq tangle-mode #o755)))
+		(when tangle-mode
+			  (add-to-list modes tangle-mode))
+		;; Possibly create the parent directories for file.
+		(let ((m (funcall get-spec :mkdirp)))
+			  (and m fnd (not (string= m "no"))
+			   (setq make-dir t)))
+		;; Handle :padlines unless first line in file
+		(unless (or (string= "no" (funcall get-spec :padline))
+(= (point) (point-min)))
+			  (insert "\n"))
+		(when (and she-bang (not she-banged))
 			  (insert (concat she-bang "\n"))
-			  (setq she-banged (cons file-name she-banged)))
-			(org-babel-spec-to-string spec)
-			;; We avoid append-to-file as it does not work with tramp.

  1   2   >