emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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: Re: PATCH: proposed improvements to org-src-mode
Date: Wed, 19 Aug 2009 12:03:26 +0100	[thread overview]
Message-ID: <87ljlgysjl.fsf@stats.ox.ac.uk> (raw)
In-Reply-To: <87iqgt5ba2.fsf@stats.ox.ac.uk> (Dan Davison's message of "Wed, 12 Aug 2009 10:58:45 -0400")

Dan Davison <davison@stats.ox.ac.uk> writes:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>> Hi Dan,
>> thank you for studying and describing these issues, and for proposing
>> a patch.

I have noticed a bug in the patch I proposed: the configuration of the
edit buffer for saving must be done only after C-c ', and not for
example when entering org-src-mode during HTML export. Here's the
revised patch (again, assuming org-edit-src-from-org-mode is a valid
test that C-c ' has just been done).


--8<---------------cut here---------------start------------->8---
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 2a6c087..6ba58f5 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -113,7 +113,6 @@ but which mess up the display of a snippet in Org exported files.")
 (defvar org-src-mode-map (make-sparse-keymap))
 (define-key org-src-mode-map "\C-c'" 'org-edit-src-exit)
-(define-key org-src-mode-map "\C-x\C-s" 'org-edit-src-save)
 (defvar org-edit-src-force-single-line nil)
 (defvar org-edit-src-from-org-mode nil)
 (defvar org-edit-src-picture nil)
@@ -168,7 +167,8 @@ the edited version."
 	    (if (boundp 'org-edit-src-overlay)
 		(org-delete-overlay org-edit-src-overlay)))
 	  (kill-buffer buffer))
-	(setq buffer (generate-new-buffer "*Org Edit Src Example*"))
+	(setq buffer (generate-new-buffer
+		      (concat "*Org Src " (file-name-nondirectory buffer-file-name) "[" lang "]*")))
 	(setq ovl (org-make-overlay beg end))
 	(org-overlay-put ovl 'face 'secondary-selection)
 	(org-overlay-put ovl 'edit-buffer buffer)
@@ -186,8 +186,7 @@ the edited version."
 				'(display nil invisible nil intangible nil))
 	(let ((org-inhibit-startup t))
-	  (funcall lang-f)
-	  (org-src-mode))
+	  (funcall lang-f))
 	(set (make-local-variable 'org-edit-src-force-single-line) single)
 	(set (make-local-variable 'org-edit-src-from-org-mode) org-mode-p)
 	(when lfmt
@@ -201,6 +200,7 @@ the edited version."
 	(org-set-local 'org-edit-src-end-marker end)
 	(org-set-local 'org-edit-src-overlay ovl)
 	(org-set-local 'org-edit-src-nindent nindent)
+	(org-src-mode)
 	(and org-edit-src-persistent-message
 	     (org-set-local 'header-line-format msg)))
       (message "%s" msg)
@@ -400,12 +400,13 @@ the language, a switch telling of the content should be in a single line."
 (defun org-edit-src-exit ()
   "Exit special edit and protect problematic lines."
-  (unless (string-match "\\`*Org Edit " (buffer-name (current-buffer)))
-    (error "This is not an sub-editing buffer, something is wrong..."))
+  (unless org-edit-src-from-org-mode
+    (error "This is not a sub-editing buffer, something is wrong..."))
   (let ((beg org-edit-src-beg-marker)
 	(end org-edit-src-end-marker)
 	(ovl org-edit-src-overlay)
 	(buffer (current-buffer))
+	(buffer-file-name nil)
 	(nindent org-edit-src-nindent)
 	code line)
     (untabify (point-min) (point-max))
@@ -444,7 +445,6 @@ the language, a switch telling of the content should be in a single line."
     (switch-to-buffer (marker-buffer beg))
     (kill-buffer buffer)
     (goto-char beg)
-    (org-delete-overlay ovl)
     (delete-region beg end)
     (insert code)
     (goto-char beg)
@@ -464,6 +464,19 @@ the language, a switch telling of the content should be in a single line."
     (goto-char (min p (point-max)))
     (message (or msg ""))))
+(defun org-src-mode-configure-edit-buffer ()
+  (when org-edit-src-from-org-mode
+    (setq buffer-offer-save t)
+    (setq buffer-file-name
+	  (concat (buffer-file-name (marker-buffer org-edit-src-beg-marker))
+		  "[" (buffer-name) "]"))
+    (set (if (featurep 'xemacs) 'write-contents-hooks 'write-contents-functions)
+	 '(org-edit-src-save))
+    (org-add-hook 'kill-buffer-hook
+		  '(lambda () (org-delete-overlay org-edit-src-overlay)) nil 'local)))
+(org-add-hook 'org-src-mode-hook 'org-src-mode-configure-edit-buffer)
 (provide 'org-src)
 ;; arch-tag: 6a1fc84f-dec7-47be-a416-64be56bea5d8
--8<---------------cut here---------------end--------------->8---

>>> * Notes on patch
>>> *** write-contents-functions
>>>    A good start seems to be to use org-src-mode-hook to add
>>>    org-edit-src-save to the write-contents-functions list. This
>>>    means that when it comes to saving, org-edit-src-save will be
>>>    called and no subsequent attempt will be made to save the buffer
>>>    in the normal way. (This should obviate the remapping of C-x C-s
>>>    to org-edit-src-save in org-src.el)
>>> *** buffer-offer-save
>>>    We also want to set this to t.
>>> *** Where does this get us?
>>>    - C-x s still does *not* offer to save the edit buffer. That's
>>>      because buffer-file-name is nil.
>>>    - C-x C-c does ask us whether we want to save the
>>>      edit buffer. However, since buffer-file-name is nil it asks us
>>>      for a file name. The check in org-edit-src-exit throws an error
>>>      unless the buffer is named '* Org Edit '...
>>>    - C-x k kills the buffer silently, leaving a broken overlay
>>>      link. If buffer-file-name were set, it would have warned that
>>>      the buffer was modified.
>>> *** buffer-file-name
>>>    So, that all suggests that we need to set buffer-file-name, even
>>>    though we don't really want to associate this buffer with a file
>>>    in the normal way. As for the file name, my current suggestion
>>>    is parent-org-filename[edit-buffer-name].
>>>    [I had to move the (org-src-mode) call to the end of
>>>    org-edit-src-code to make sure that the required variables were
>>>    defined when the hook was called.]
>>> *** And so where are we now?
>>>    - C-x s *does* offer to save the edit buffer, but in saving
>>>      produces a warning that the edit buffer is modified.
>>>    - C-x k now gives a warning that the edit buffer is modified
>>>      (even if it's not).
>>>    - C-x C-c is working as desired, except that again we get
>>>      warnings that the edit buffer is modified, once when we save,
>>>      and again just before exiting emacs.
>>>    - And C-c ' now issues a warning that the edit buffer is
>>>      modified when we leave it, which we don't want.
>>> *** So, we need to get rid of the buffer modification warnings.
>>>    I've made buffer-file-name nil inside the let binding in
>>>    org-edit-src-exit.
>>> *** And?
>>>    - C-x s behaves as desired, except that as was already the case,
>>>      the edit buffer is always considered modified, and so repeated
>>>      invocations keep saving it.
>>>    - As was already the case, C-x k always gives a warning that the
>>>      edit buffer has been modified.
>>>    - C-x C-c is as desired (offers to save the edit buffer) except
>>>      that it warns of the modified buffer just before exiting.
>>>    - C-c ' is as it should be (silent)

  reply	other threads:[~2009-08-19 11:03 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
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 [this message]
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:

  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=87ljlgysjl.fsf@stats.ox.ac.uk \
    --to=davison@stats.ox.ac.uk \
    --cc=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* 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


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