Re: Saving the *Org Edit Src Example* buffer

From: Dan Davison <davison@stats.ox.ac.uk>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: emacs org-mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: Saving the *Org Edit Src Example* buffer
Date: Tue, 09 Jun 2009 10:51:28 -0400	[thread overview]
Message-ID: <871vptpij3.fsf@stats.ox.ac.uk> (raw)
In-Reply-To: <BF98B563-9E06-42C4-96D0-9EFBC48224E9@gmail.com> (Carsten Dominik's message of "Tue, 2 Jun 2009 19:12:54 +0200")

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Applied, thanks.

Sorry to go on about this, but I don't think the patch that I sent has
been applied and I believe that the problem it addresses still exists:
go into a source code block, hit C-c ', go to end of edit buffer, press
return a few times, try C-x C-s and you'll either be back in the org
buffer (or if you're really unlucky in an edit buffer for a different
code block!). This occurs because when we drop out of the edit buffer,
point ends up outside the code block in the parent org buffer. I've now
realised that a similar problem occurs if you add blank lines at the
top, and so my original patch was insufficient.

My current patch follows. It's not perfect: if there are leading blank
lines then after C-x C-s point will end up in a different place, but at
least it's in the correct buffer :) It seems to me that making point
stay still would require org-edit-src-exit to inform org-edit-src-save
about exactly how many whitespace characters it has removed, and I
haven't tried to do that.

Dan

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 401c628..f4559f2 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -403,18 +403,19 @@ the language, a switch telling of the content should be in a single line."
   (interactive)
   (unless (string-match "\\`*Org Edit " (buffer-name (current-buffer)))
     (error "This is not an sub-editing buffer, something is wrong..."))
-  (let ((line (if (org-bound-and-true-p org-edit-src-force-single-line)
-                 1
-               (org-current-line)))
-       (beg org-edit-src-beg-marker)
+  (let ((beg org-edit-src-beg-marker)
        (end org-edit-src-end-marker)
        (ovl org-edit-src-overlay)
        (buffer (current-buffer))
        (nindent org-edit-src-nindent)
-       code)
-  (goto-char (point-min))
-  (if (looking-at "[ \t\n]*\n") (replace-match ""))
-  (if (re-search-forward "\n[ \t\n]*\\'" nil t) (replace-match ""))
+       line code)
+  (save-excursion
+    (goto-char (point-min))
+    (if (looking-at "[ \t\n]*\n") (replace-match ""))
+    (if (re-search-forward "\n[ \t\n]*\\'" nil t) (replace-match "")))
+  (setq line (if (org-bound-and-true-p org-edit-src-force-single-line)
+                1
+              (org-current-line)))
   (when (org-bound-and-true-p org-edit-src-force-single-line)
     (goto-char (point-min))
     (while (re-search-forward "\n" nil t)

Dan

>
> - Carsten
>
> On Jun 2, 2009, at 5:49 PM, Dan Davison wrote:
>
>> Dan Davison <davison@stats.ox.ac.uk> writes:
>>
>>> Following on from the recent improvements to the *Org Edit Src
>>> Example*
>>> buffer, I have one more proposal: I have remapped C-x C-s so that it
>>> saves the code in the org buffer, rather than offering to save the
>>> Edit
>>> buffer itself (as it used to be with the indirect edit buffer). I
>>> find
>>> this essential, although I recognise that remapping C-x C-s is a
>>> rather
>>> radical thing to do to an emacs buffer.
>>>
>>> I am using the simple-minded approach below; it seems to work fine (I
>>
>> Hmm, well I had used that for at least a week before posting, but I
>> have
>> now noticed a problem. It's a bit of a corner case. If you create
>> extra
>> blank lines at the end of the source code edit buffer and leave point
>> down there, then do org-edit-src-exit, now back in the org buffer
>> point
>> is outside the source code block. In that case, the code that I just
>> posted doesn't work. I suggest that org-edit-src-exit should in this
>> situation place point at the end of the source code block, for example
>> like this:
>>
>>
>> diff --git a/lisp/org.el b/lisp/org.el
>> index 659dfad..be459b5 100644
>> --- a/lisp/org.el
>> +++ b/lisp/org.el
>> @@ -6757,7 +6757,9 @@ the language, a switch telling of the content
>> should be in a single line."
>>        code)
>>   (goto-char (point-min))
>>   (if (looking-at "[ \t\n]*\n") (replace-match ""))
>> -  (if (re-search-forward "\n[ \t\n]*\\'" nil t) (replace-match ""))
>> +  (when (re-search-forward "\n[ \t\n]*\\'" nil t)
>> +    (replace-match "")
>> +    (setq line (min line (org-current-line))))
>>   (when (org-bound-and-true-p org-edit-src-force-single-line)
>>     (goto-char (point-min))
>>     (while (re-search-forward "\n" nil t)
>>
>>
>> Dan
>>
>>
>>
>>
>>> don't even notice a flicker -- should I be surprised at that?), but
>>> if
>>> someone can suggest an improved implementation I'd be happy to
>>> learn how
>>> it should be done (perhaps there are buffer variables other than
>>> point
>>> and mark that I should restore? Is there a general mechanism I should
>>> use for this?).
>>>
>>> Dan
>>>
>>> (defun org-edit-src-save ()
>>>  "Update the parent org buffer with the edited source code, save
>>> the parent org-buffer, and return to the source code edit
>>> buffer."
>>>  (interactive)
>>>  (let ((p (point))
>>> 	(m (mark)))
>>>    (org-edit-src-exit)
>>>    (save-buffer)
>>>    (org-edit-src-code)
>>>    (set-mark m)
>>>    (goto-char p)))
>>>
>>> (define-key org-exit-edit-mode-map "\C-x\C-s" 'org-edit-src-save)
>>>
>>>
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Remember: use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Remember: use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
