emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Dan Davison <davison@stats.ox.ac.uk>
Cc: emacs org-mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: Saving the *Org Edit Src Example* buffer
Date: Tue, 9 Jun 2009 20:20:55 +0200	[thread overview]
Message-ID: <B61872EA-B6C4-4D66-B236-66B94C02FC90@gmail.com> (raw)
In-Reply-To: <871vptpij3.fsf@stats.ox.ac.uk>


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

  reply	other threads:[~2009-06-09 18:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02 15:02 Saving the *Org Edit Src Example* buffer Dan Davison
2009-06-02 15:49 ` Dan Davison
2009-06-02 17:12   ` Carsten Dominik
2009-06-09 14:51     ` Dan Davison
2009-06-09 18:20       ` Carsten Dominik [this message]
2009-06-02 17:04 ` Carsten Dominik
2009-08-11 16:44   ` PATCH: proposed improvements to org-src-mode Dan Davison
2009-08-12 12:22     ` Carsten Dominik
2009-08-12 14:58       ` Dan Davison
2009-08-19 11:03         ` Dan Davison
2009-08-24 12:17           ` Carsten Dominik
2009-08-28  2:36             ` Dan Davison
2009-08-28  7:59               ` Carsten Dominik
2009-09-05 17:33                 ` Dan Davison
2009-09-06 11:41                   ` Carsten Dominik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B61872EA-B6C4-4D66-B236-66B94C02FC90@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=davison@stats.ox.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).