Small inconsistencies

[kevinboulain]

I hope I don't bother you :)
Same setup as previous issues.

I quickly glanced over the other issues to see if these weren't reported already and I didn't find anything similar.

I separated inconsistencies with an horizontal rule below.

That's all I can think of for now (I still have something I can't reproduce as I'm not sure if it's lentic-related but one time, a huge part of non-code blocks in an Org buffer disappeared leaving mostly code-blocks).

---

Create an Org file:

hello world

Start lentic (C-c , c & C-c , t).

In the Org view add code blocks:

#+begin_src
hello world
#+end_src

The Elisp view will show:

;; #+begin_src emacs-lisp
;; hello world
;; #+end_src

I was probably expecting hello world to be auto-magically uncommented. It's probably bad performance-wise or may introduce other unwanted behaviors?

---

In the following Elisp view:

;; #+begin_src emacs-lisp
;; hello world
;; #+end_src

Put the cursor on the underscore of begin_src then M-c to uppercase the s.

The Org view will show:

#+beginSrc emacs-lisp
hello world
#+end_src

Editing it further won't fix it, it looks like the whole line must be rewritten.
Undoing in the Org buffer will add another underscore in the Elisp buffer.

The same issue arises for titles and special characters (for example, between s-expressions boundaries in Elisp).

* hello world

;; * hello world

M-c on the star to uppercase the h will completely remove it from the Elisp buffer.

* Hello world

;; Hello world

---

Some stuff doesn't seem to be refreshed.

Create an empty Org buffer, then in the Elisp buffer:

;; [[example.org][link]]

The Org buffer should pretty print the link and only show link in a custom face.

You can now start removing stuff from the ] side in the Elisp buffer and the Org buffer won't reflect modifications (it should expand the link again but won't do it unless you modify the link from the Org buffer itself).

Not that much of a problem since the actual content is okay.

---

I'm totally new to Org (in fact lentic made me give it a try), this may seem stupid at first.
Depending on the keyboard, I sometimes use shift + arrow to change buffers so I encountered this one.

Create an Org file:

* title

#+begin_src emacs-lisp
(hello world)
#+end_src

#+begin_src emacs-lisp
(hello world)
#+end_src

The Elisp file should be:

;; * title

;; #+begin_src emacs-lisp
(hello world)
;; #+end_src

;; #+begin_src emacs-lisp
(hello world)
;; #+end_src

Save the Org file and close Emacs if you inserted the content from Emacs directly (to lose any history and start with something that isn't an empty buffer)

Put the cursor on the title then use S-<right>.
This will only change the title to: * TODO title (since I'm new to Org I actually never intended to do that in the first place, but this isn't the actual issue as it's documented that Org conflicts with windmove :)).

However, it will comment out every code block in the Elisp file:

;; * TODO title

;; #+begin_src emacs-lisp
;; (hello world)
;; #+end_src

;; #+begin_src emacs-lisp
;; (hello world)
;; #+end_src

I don't know why but I may mechanically go to the Elisp buffer (C-x o) then revert (C-_). Strangely if I revert one more time I'll get to the point where I have an empty buffer (which shouldn't happen since we reopened Emacs). If I had to guess it's probably due to the fact that the Elisp buffer is actually recreated from scratch and populated at the beginning so it's counting as the first history step?

---

Again, thanks for lentic! I really want to use it as it seems to be the most advanced module to do this kind of editing but I'm still a bit wary of data loss.

[kevinboulain]

I finally found why I lost some parts of my Org buffer :)

It's a conflict between org-babel-load-file (which will discard most of the .org file while tangling) and lentic as they both write to the same file (the name with the .org replaced with .el).
When Org rewrite the file, Emacs will see that the file has changed and if the lentic buffer is reverted to match its contents, lentic will rightly rewrite the whole .org file to match the cut down .el from Org.

So in short, it's not a problem with lentic and a corner case.

[kevinboulain]

Small update for characters that disappear with some commands after I gave a quick glance at lentic's code (after seeing your comments about {after,before}-change-functions I better understand the complexity :)).

With an Org buffer only containing hellO if I M-l on the e in the Elisp buffer, I can log (I put some lentic-log around, mainly at the start of some interesting functions and before returning a result in lentic-clone):

lentic-before-change-function-1 buffer:example.el start:5 stop:9 seen-buffer:nil
lentic-before-change-function-1 buffer:example.org start:2 stop:6 seen-buffer:(example.el)
lentic-after-change-function-1 buffer:example.el start:8 stop:9 length-before:1 seen-buffer:nil
lentic-update-contents command:downcase-word start:8 stop:9 length-before:1
lentic-clone generic start:8 stop:9 length-before:1 start-converted:#<marker at 2 in example.org> stop-converted:#<marker at 6 in example.org>
lentic-clone generic converted-start:2 (+ converted-start (- stop start)):3 (- converted-stop converted-start):4
lentic-after-change-function-1 buffer:example.org start:2 stop:3 length-before:4 seen-buffer:(example.el)

So it seems there is some confusion with the length of the reported region and where to apply it (similar behavior with M-c, but easier to understand with M-l) starting from lentic-clone (by the way, why aren't the lentic-clone from lentic-org.el called?).
However, for now I still don't fully understand where the problems lies :)