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
next prev parent reply other threads:[~2009-06-09 14:51 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 [this message]
2009-06-09 18:20 ` Carsten Dominik
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=871vptpij3.fsf@stats.ox.ac.uk \
--to=davison@stats.ox.ac.uk \
--cc=carsten.dominik@gmail.com \
--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).