From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: xraysmalevich@gmail.com Newsgroups: gmane.emacs.help Subject: clone buffer that is visiting a file Date: Thu, 4 Sep 2008 05:55:49 -0700 (PDT) Organization: http://groups.google.com Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220535754 9414 80.91.229.12 (4 Sep 2008 13:42:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2008 13:42:34 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Sep 04 15:43:28 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KbF7O-0007rq-Hv for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2008 15:43:26 +0200 Original-Received: from localhost ([127.0.0.1]:59630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KbF6N-0002Or-VE for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2008 09:42:24 -0400 Original-Path: news.stanford.edu!headwall.stanford.edu!newsfeed.stanford.edu!postnews.google.com!z11g2000prl.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 107 Original-NNTP-Posting-Host: 209.183.178.159 Original-X-Trace: posting.google.com 1220532949 7902 127.0.0.1 (4 Sep 2008 12:55:49 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Thu, 4 Sep 2008 12:55:49 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: z11g2000prl.googlegroups.com; posting-host=209.183.178.159; posting-account=GWRmcQoAAAByQPzrR7mhf5cbvIm17KAJ User-Agent: G2/1.0 X-HTTP-Via: 1.1 PROXY1 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.help:161916 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:57259 Archived-At: If you try to run clone-buffer on a file-visiting buffer, it won't happen, and you get the error message "Cannot clone a file-visiting buffer." I think I understand why -- if you clone a file-visiting buffer, both buffers are visiting the same file -- and this is more a situation for an indirect buffer. Is this correct? But what about situations where you want the entire text of the file- visiting buffer, the same major mode, but not have it be visiting a file? Is there any easier way to do this other than copying the entire buffer and starting from scratch? I poked around in the the internals of clone-buffer, and it seems to be happy with copying file-visiting buffers if I turn off the file- visiting checks AND disable copying local variables. Is this safe? Are there any reason why I might NOT want to do this? below is my modified clone-buffer code, with mooning internal commentary on my suspicious changes: (defun clone-this-buffer (&optional newname display-flag) "Create and return a twin copy of the current buffer. Unlike an indirect buffer, the new buffer can be edited independently of the old one (if it is not read-only). NEWNAME is the name of the new buffer. It may be modified by adding or incrementing at the end as necessary to create a unique buffer name. If nil, it defaults to the name of the current buffer, with the proper suffix. If DISPLAY-FLAG is non-nil, the new buffer is shown with `pop-to-buffer'. Trying to clone a file-visiting buffer, results in a buffer not tied to a file. hopefully. Interactively, DISPLAY-FLAG is t and NEWNAME is the name of the current buffer with appropriate suffix. However, if a prefix argument is given, then the command prompts for NEWNAME in the minibuffer. This runs the normal hook `clone-buffer-hook' in the new buffer after it has been set up properly in other respects." (interactive (progn (if (get major-mode 'no-clone) (error "Cannot clone a buffer in %s mode" mode-name)) (list (if current-prefix-arg (read-buffer "Name of new cloned buffer: " (current-buffer))) t))) (if (get major-mode 'no-clone) (error "Cannot clone a buffer in %s mode" mode-name)) (setq newname (or newname (buffer-name))) (if (string-match "<[0-9]+>\\'" newname) (setq newname (substring newname 0 (match-beginning 0)))) (let ((buf (current-buffer)) (ptmin (point-min)) (ptmax (point-max)) (pt (point)) (mk (if mark-active (mark t))) (modified (buffer-modified-p)) (mode major-mode) (lvars (buffer-local-variables)) (process (get-buffer-process (current-buffer))) (new (generate-new-buffer (or newname (buffer-name))))) (save-restriction (widen) (with-current-buffer new (insert-buffer-substring buf))) (with-current-buffer new (narrow-to-region ptmin ptmax) (goto-char pt) (if mk (set-mark mk)) (set-buffer-modified-p modified) ;; Clone the old buffer's process, if any. ;; commented-out to avoid file-visiting issues ;; may not be related ;;(when process (clone-process process)) ;; Now set up the major mode. (funcall mode) ;; Set up other local variables. ;;; NOT copying local-vars seems to kill the associations to a visited file. ;; I think ;; (mapc (lambda (v) ;; (condition-case () ;in case var is read-only ;; (if (symbolp v) ;; (makunbound v) ;; (set (make-local-variable (car v)) (cdr v))) ;; (error nil))) ;; lvars) ;; Run any hooks (typically set up by the major mode ;; for cloning to work properly). (run-hooks 'clone-buffer-hook)) (if display-flag ;; Presumably the current buffer is shown in the selected frame, so ;; we want to display the clone elsewhere. (let ((same-window-regexps nil) (same-window-buffer-names)) (pop-to-buffer new))) new)) --the Other michael