From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Saving the *Org Edit Src Example* buffer Date: Tue, 9 Jun 2009 20:20:55 +0200 Message-ID: References: <873aain0f7.fsf@stats.ox.ac.uk> <87prdmljpo.fsf@stats.ox.ac.uk> <871vptpij3.fsf@stats.ox.ac.uk> Mime-Version: 1.0 (Apple Message framework v935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ME5wY-0005k4-J2 for emacs-orgmode@gnu.org; Tue, 09 Jun 2009 14:21:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ME5wT-0005iq-Jx for emacs-orgmode@gnu.org; Tue, 09 Jun 2009 14:21:06 -0400 Received: from [199.232.76.173] (port=56357 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ME5wT-0005in-CR for emacs-orgmode@gnu.org; Tue, 09 Jun 2009 14:21:01 -0400 Received: from mail-ew0-f225.google.com ([209.85.219.225]:50291) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ME5wS-0005gJ-OT for emacs-orgmode@gnu.org; Tue, 09 Jun 2009 14:21:01 -0400 Received: by ewy25 with SMTP id 25so206304ewy.42 for ; Tue, 09 Jun 2009 11:20:59 -0700 (PDT) In-Reply-To: <871vptpij3.fsf@stats.ox.ac.uk> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Dan Davison Cc: emacs org-mode mailing list On Jun 9, 2009, at 4:51 PM, Dan Davison wrote: > Carsten Dominik 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 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