Re: Saving the *Org Edit Src Example* buffer

[Carsten Dominik <carsten.dominik@gmail.com>]

On Jun 9, 2009, at 4:51 PM, Dan Davison wrote:

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

You are right.

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

I think the better way to do this is to first remove the
empty lines at the beginning and end of the buffer, and then to
remember the line.  This is what I have implemented now.

- Carsten

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