emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* source blocks mangled when edited
@ 2021-05-31  3:39 Michael Gauland
  2021-05-31  4:21 ` Samuel Wales
  2021-05-31  8:15 ` Sébastien Miquel
  0 siblings, 2 replies; 9+ messages in thread
From: Michael Gauland @ 2021-05-31  3:39 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

I've stared having trouble editing source blocks.    When I use C-c ' to
edit block, the editing behaves as expected, but when I C-c ' to return
to the main org file, the code is altered in strange ways.  I've had
trouble coming up with a really small example, but the attached file
seems to consistently demonstrate the problem, even when running emacs
without my settings.

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've seen this with other types of code as well (at least SQL and json),
so it's not specific to dot.

I'm running emacs 26.1 on Debian 10.9, with org build from git.

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

Kind regards,

Mike Gauland


[-- Attachment #2: bug.org --]
[-- Type: text/plain, Size: 1326 bytes --]

#+BEGIN_SRC dot :file diagram1.png :cmdline -Kdot -Tpng
  digraph G {
      rankdir = "LR"
       pre [label="Preprocessor"]                          
       subgraph cluster_inputs {
           label="Inputs"
           rankdir = "TB"
           input1 [label="input"]
           input2 [label="input"]
           input3 [label="∙\n∙\n∙",shape=none]
           input4 [label="input"]
       } -> pre

               pre -> final

               subgraph users {
         rankdir="TB"
         "End Users"
         "Resellers"
         "Corporate Users"
      }

      final -> "End Users"
      final -> "Resellers"
      final -> "Corporate Users"
  }
#+END_SRC

#+BEGIN_SRC dot :file diagram2.png :cmdline -Kdot -Tpng
  digraph G {
      rankdir = "LR"
       pre [label="Preprocessor"]                          
       subgraph cluster_inputs {
           label="Inputs"
           rankdir = "TB"
           input1 [label="input"]
           input2 [label="input"]
           input3 [label="∙\n∙\n∙",shape=none]
           input4 [label="input"]
       } -> pre

       pre -> final

       subgraph users {
         rankdir="TB"
         "End Users"
         "Resellers"
         "Corporate Users"
      }

      final -> "End Users"
      final -> "Resellers"
      final -> "Corporate Users"
  }
#+END_SRC


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: source blocks mangled when edited
  2021-05-31  3:39 source blocks mangled when edited Michael Gauland
@ 2021-05-31  4:21 ` Samuel Wales
  2021-05-31  8:01   ` Michael Gauland
  2021-05-31  8:15 ` Sébastien Miquel
  1 sibling, 1 reply; 9+ messages in thread
From: Samuel Wales @ 2021-05-31  4:21 UTC (permalink / raw)
  To: Michael Gauland; +Cc: emacs-orgmode

idk if this will help as you probably know all of it already.  butg
you asked for any help so here goes.  i run maint, not master or any
emacs versions.  weird that you are missing 3 cols?

===

here are notes on my workaround which wfm in the meantime if you are
willing to do the same thing.  i was having trouble getting exported
indentation for example blocks.

;; fix default for source and example block indentation
;;
;; when you edit a source or data block, org will by default
;; remove some leading whitespace and then add 2 spaces, so the
;; whole block in org is indented by 2.
;;
;; (the deleted rectangle seems to be the maximum amount of
;; whitespace common to all lines in each block.)
;;
;; initial tabs get converted to spaces.  example blocks get
;; unindented during export incorrectly.  mistakes are possible.
;; this as non-nil prevents all that.  see led for more.
;;
;; we EITHER unindent all and set this non-nil, OR put up with
;; stripping of leading whitespace from blocks where we don't
;; want the indentation stripped.
;;
;; /i prefer t./ it is not possible in babel to indent without
;; having the special feature of removing the whitespace
;; rectangle.
;;
;; you can use -i to locally do t.  there isn't an arg that
;; locally does the reverse of -i.  i.e. to do nil.
;;
;; i have gotten comfortable with no indentation and imo it is a good
default for newcomers and does not surprise.
;;
;; source blocks might actually work without indentation even
;; with the default value, but then when you edit it indents.
(setq org-src-preserve-indentation t)
;; (setq org-src-preserve-indentation nil)
;;
;; only has effect if org-src-preserve-indentation is nil
;; (setq org-edit-src-content-indentation 0)


On 5/30/21, Michael Gauland <mikelygee@gmail.com> wrote:
> I've stared having trouble editing source blocks.    When I use C-c ' to
> edit block, the editing behaves as expected, but when I C-c ' to return
> to the main org file, the code is altered in strange ways.  I've had
> trouble coming up with a really small example, but the attached file
> seems to consistently demonstrate the problem, even when running emacs
> without my settings.
>
> 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've seen this with other types of code as well (at least SQL and json),
> so it's not specific to dot.
>
> I'm running emacs 26.1 on Debian 10.9, with org build from git.
>
> I'm not even sure how to start tracking this down. Any help would be
> greatly appreciated!
>
> Kind regards,
>
> Mike Gauland
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: source blocks mangled when edited
  2021-05-31  4:21 ` Samuel Wales
@ 2021-05-31  8:01   ` Michael Gauland
  0 siblings, 0 replies; 9+ messages in thread
From: Michael Gauland @ 2021-05-31  8:01 UTC (permalink / raw)
  To: Samuel Wales; +Cc: emacs-orgmode

On 31/05/21 4:21 pm, Samuel Wales wrote:
> idk if this will help as you probably know all of it already.  butg
> you asked for any help so here goes.  i run maint, not master or any
> emacs versions.  weird that you are missing 3 cols?
Switching to the maint branch didn't change anything, but I found that I
was unable to reproduce the problem with commit
9802877fbe442a52b4e63782b84921f46cf5d56b, but *could* reproduce it from
commit d02ad1f207e1579aff8f36f740a065d71472c182. Since that commit
affects org-src.el, I may be on the right track.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: source blocks mangled when edited
  2021-05-31  3:39 source blocks mangled when edited Michael Gauland
  2021-05-31  4:21 ` Samuel Wales
@ 2021-05-31  8:15 ` Sébastien Miquel
  2021-05-31  8:54   ` Michael Gauland
  1 sibling, 1 reply; 9+ messages in thread
From: Sébastien Miquel @ 2021-05-31  8:15 UTC (permalink / raw)
  To: Michael Gauland, emacs-orgmode

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: source blocks mangled when edited
  2021-05-31  8:15 ` Sébastien Miquel
@ 2021-05-31  8:54   ` Michael Gauland
  2021-05-31  9:42     ` Sébastien Miquel
  0 siblings, 1 reply; 9+ messages in thread
From: Michael Gauland @ 2021-05-31  8:54 UTC (permalink / raw)
  To: sebastien.miquel, emacs-orgmode

On 31/05/21 8:15 pm, Sébastien Miquel wrote:
> 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` ?
>
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.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: source blocks mangled when edited
  2021-05-31  8:54   ` Michael Gauland
@ 2021-05-31  9:42     ` Sébastien Miquel
  2021-05-31 10:02       ` Michael Gauland
  0 siblings, 1 reply; 9+ messages in thread
From: Sébastien Miquel @ 2021-05-31  9:42 UTC (permalink / raw)
  To: Michael Gauland, emacs-orgmode

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: source blocks mangled when edited
  2021-05-31  9:42     ` Sébastien Miquel
@ 2021-05-31 10:02       ` Michael Gauland
  2021-06-01  8:20         ` [PATCH] " Sébastien Miquel
  0 siblings, 1 reply; 9+ messages in thread
From: Michael Gauland @ 2021-05-31 10:02 UTC (permalink / raw)
  To: sebastien.miquel, emacs-orgmode


On 31/05/21 9:42 pm, Sébastien Miquel wrote:
> 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 ?
>
This is all the *trace-output* buffer shows:

======================================================================
1 -> (replace-buffer-contents #<buffer *org-src-write-back*>)
1 <- replace-buffer-contents: nil



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] source blocks mangled when edited
  2021-05-31 10:02       ` Michael Gauland
@ 2021-06-01  8:20         ` Sébastien Miquel
  2021-06-27 13:54           ` Nicolas Goaziou
  0 siblings, 1 reply; 9+ messages in thread
From: Sébastien Miquel @ 2021-06-01  8:20 UTC (permalink / raw)
  To: Michael Gauland, emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

Michael Gauland writes:
> This is all the*trace-output*  buffer shows:
>
> ======================================================================
> 1 -> (replace-buffer-contents #<buffer*org-src-write-back*>)
> 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


[-- Attachment #2: 0001-org-src.el-Use-replace-buffer-contents-only-for-emac.patch --]
[-- Type: text/x-patch, Size: 1976 bytes --]

From 8ebdbc5eca92de4429d3994a3663d8aa3b9877fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= <sebastien.miquel@posteo.eu>
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


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] source blocks mangled when edited
  2021-06-01  8:20         ` [PATCH] " Sébastien Miquel
@ 2021-06-27 13:54           ` Nicolas Goaziou
  0 siblings, 0 replies; 9+ messages in thread
From: Nicolas Goaziou @ 2021-06-27 13:54 UTC (permalink / raw)
  To: Sébastien Miquel; +Cc: emacs-orgmode, Michael Gauland

Hello,

Sébastien Miquel <sebastien.miquel@posteo.eu> writes:

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

I tweaked the commit message and applied your patch. Thank you.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-06-27 13:55 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-31  3:39 source blocks mangled when edited Michael Gauland
2021-05-31  4:21 ` Samuel Wales
2021-05-31  8:01   ` Michael Gauland
2021-05-31  8:15 ` Sébastien Miquel
2021-05-31  8:54   ` Michael Gauland
2021-05-31  9:42     ` Sébastien Miquel
2021-05-31 10:02       ` Michael Gauland
2021-06-01  8:20         ` [PATCH] " Sébastien Miquel
2021-06-27 13:54           ` Nicolas Goaziou

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).