*scratch* lost

*scratch* lost

[B. T. Raven]

I was doing some key mapping in .emacs and instead of saving the file, 
restarting Emacs, and testing the new assignment I was doing M-x eval 
region on changed areas of .emacs Somehow all (or many) keychords 
started acting strangely, e.g. C-x 1 would open subr.el in a new buffer 
instead of showing current buffer alone in frame, even cursor movement 
keys did something else. I killed .emacs buffer without saving (losing 
changes) and then exited Emacs. On restarting everything looks and works 
normally exept that *scratch* is empty (three commented lines are 
missing) and it is in Fundamental mode instead of Lisp Interaction. Can 
I get the old *scratch* buffer back? How?

Ed

Re: *scratch* lost

[B. T. Raven]

inhibit-startup-screen is nil

initial-scratch-message is ";; This buffer is for notes you don't want 
to save, and for Lisp evaluation.\n;; If you want to create a file, 
visit that file with C-x C-f,\n;; then enter the text in that file's own 
buffer.\n\n"

initial-major-mode is lisp-interaction-mode

Emacs version is w32 22.3


B. T. Raven wrote:
> I was doing some key mapping in .emacs and instead of saving the file, 
> restarting Emacs, and testing the new assignment I was doing M-x eval 
> region on changed areas of .emacs Somehow all (or many) keychords 
> started acting strangely, e.g. C-x 1 would open subr.el in a new buffer 
> instead of showing current buffer alone in frame, even cursor movement 
> keys did something else. I killed .emacs buffer without saving (losing 
> changes) and then exited Emacs. On restarting everything looks and works 
> normally exept that *scratch* is empty (three commented lines are 
> missing) and it is in Fundamental mode instead of Lisp Interaction. Can 
> I get the old *scratch* buffer back? How?
> 
> Ed

Re: *scratch* lost

[Pascal J. Bourguignon]

"B. T. Raven" <nihil@nihilo.net> writes:

> I was doing some key mapping in .emacs and instead of saving the file,
> restarting Emacs, and testing the new assignment I was doing M-x eval
> region on changed areas of .emacs Somehow all (or many) keychords
> started acting strangely, e.g. C-x 1 would open subr.el in a new
> buffer instead of showing current buffer alone in frame, even cursor
> movement keys did something else. I killed .emacs buffer without
> saving (losing changes) and then exited Emacs. On restarting
> everything looks and works normally exept that *scratch* is empty
> (three commented lines are missing) and it is in Fundamental mode
> instead of Lisp Interaction. Can I get the old *scratch* buffer back?
> How?

(defun make-scratch ()
  (interactive)
  (if (get-buffer "*scratch*")
     (switch-to-buffer (get-buffer "*scratch*"))
     (progn
        (switch-to-buffer (get-buffer-create "*scratch*"))
        (insert ";; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

")
    (emacs-lisp-mode))))


M-x make-scratch RET



-- 
__Pascal Bourguignon__

Re: *scratch* lost

[B. T. Raven]

Pascal J. Bourguignon wrote:
> "B. T. Raven" <nihil@nihilo.net> writes:
> 
>> I was doing some key mapping in .emacs and instead of saving the file,
>> restarting Emacs, and testing the new assignment I was doing M-x eval
>> region on changed areas of .emacs Somehow all (or many) keychords
>> started acting strangely, e.g. C-x 1 would open subr.el in a new
>> buffer instead of showing current buffer alone in frame, even cursor
>> movement keys did something else. I killed .emacs buffer without
>> saving (losing changes) and then exited Emacs. On restarting
>> everything looks and works normally exept that *scratch* is empty
>> (three commented lines are missing) and it is in Fundamental mode
>> instead of Lisp Interaction. Can I get the old *scratch* buffer back?
>> How?
> 
> (defun make-scratch ()
>   (interactive)
>   (if (get-buffer "*scratch*")
>      (switch-to-buffer (get-buffer "*scratch*"))
>      (progn
>         (switch-to-buffer (get-buffer-create "*scratch*"))
>         (insert ";; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.
> 
> ")
>     (emacs-lisp-mode))))
> 
> 
> M-x make-scratch RET
> 
> 
> 
Thanks, Pascal. I made the mode for *scratch* (lisp-interaction-mode) so 
that C-j alone evaluates but if I needed your function to get a normal 
*scratch* every time I would have reinstalled Emacs instead. My .emacs 
(loaded under switch --debug-init) didn't seem to have any problems 
except for an empty *scratch* in fundamental mode but a normal *scratch* 
was produced with emacs -Q. Somehow a customization of org-agenda-file 
(maybe with extra quotes or something but whatever it was didn't hang up 
debug-init; I didn't pay close enough attention) was producing an empty 
*scratch* in fundamental mode. ??? Anyway I saved your function for 
later use if necessary.
Now,  '(org-agenda-files (quote ("c:/emacs/org"))) under 
custom-set-variables doesn't cause a problem.

Ed

Re: *scratch* lost

[Stefan Kamphausen]

Hi,

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> "B. T. Raven" <nihil@nihilo.net> writes:
>
>> I was doing some key mapping in .emacs and instead of saving the file,
>> restarting Emacs, and testing the new assignment I was doing M-x eval
>> region on changed areas of .emacs Somehow all (or many) keychords
>> started acting strangely, e.g. C-x 1 would open subr.el in a new
>> buffer instead of showing current buffer alone in frame, even cursor
>> movement keys did something else. I killed .emacs buffer without
>> saving (losing changes) and then exited Emacs. On restarting
>> everything looks and works normally exept that *scratch* is empty
>> (three commented lines are missing) and it is in Fundamental mode
>> instead of Lisp Interaction. Can I get the old *scratch* buffer back?
>> How?

Maybe you somehow interfered with the variables

* inhibit-startup-screen
* initial-scratch-message

? 

>
> (defun make-scratch ()

[...]

>     (emacs-lisp-mode))))
>
>
> M-x make-scratch RET

Hm, I don't seem to need that.  I can always M-x switch-to-buffer
*scratch* RET (having to type "*scratch*" without completion since it
may have been killed) and end up in a perfect stracth-buffer with
lisp-interaction-mode.  It even works with iswitchb-buffer which asks
before creating the new buffer.


Cheers,
Stefan
-- 
Stefan Kamphausen --- http://www.skamphausen.de
a blessed +42 regexp of confusion (weapon in hand)
You hit. The format string crumbles and turns to dust.

Re: *scratch* lost

[Pascal J. Bourguignon]

Stefan Kamphausen <skampi@gmx.net> writes:

> Hi,
>
> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
>> "B. T. Raven" <nihil@nihilo.net> writes:
>>
>>> I was doing some key mapping in .emacs and instead of saving the file,
>>> restarting Emacs, and testing the new assignment I was doing M-x eval
>>> region on changed areas of .emacs Somehow all (or many) keychords
>>> started acting strangely, e.g. C-x 1 would open subr.el in a new
>>> buffer instead of showing current buffer alone in frame, even cursor
>>> movement keys did something else. I killed .emacs buffer without
>>> saving (losing changes) and then exited Emacs. On restarting
>>> everything looks and works normally exept that *scratch* is empty
>>> (three commented lines are missing) and it is in Fundamental mode
>>> instead of Lisp Interaction. Can I get the old *scratch* buffer back?
>>> How?
>
> Maybe you somehow interfered with the variables
>
> * inhibit-startup-screen
> * initial-scratch-message
>
> ? 
>
>>
>> (defun make-scratch ()
>
> [...]
>
>>     (emacs-lisp-mode))))
>>
>>
>> M-x make-scratch RET
>
> Hm, I don't seem to need that.  I can always M-x switch-to-buffer
> *scratch* RET (having to type "*scratch*" without completion since it
> may have been killed) and end up in a perfect stracth-buffer with
> lisp-interaction-mode.  It even works with iswitchb-buffer which asks
> before creating the new buffer.

Of course, but if you want to insert the initial-scratch-message...
And switch-to-buffer creates a buffer in default-major-mode, not
emacs-lisp-mode.

-- 
__Pascal Bourguignon__

Re: *scratch* lost

[Stefan Kamphausen]

Hi Pascal,

pjb@informatimago.com (Pascal J. Bourguignon) writes:

>> Hm, I don't seem to need that.  I can always M-x switch-to-buffer
>> *scratch* RET (having to type "*scratch*" without completion since it
>> may have been killed) and end up in a perfect stracth-buffer with
>> lisp-interaction-mode.  It even works with iswitchb-buffer which asks
>> before creating the new buffer.
>
> Of course, but if you want to insert the initial-scratch-message...

OK, I loose that.  I understand that it is meant for newcomers anyway. 

> And switch-to-buffer creates a buffer in default-major-mode, not
> emacs-lisp-mode.

My default-major-mode is fundamental-mode and my scratch buffer is
always in lisp-interaction-mode.  I tried to find out where that comes
from but without success.  Nothing in auto-mode-alist, magic-mode-alist,
interpreter-mode-alist.  No configuration found with grep -ir
lisp-interaction-mode ~/.emacs.d/.  Nothing found using apropos-value
lisp-interaction-mode.  Funny that it, but very handy ;-)


Best,
Stefan
-- 
Stefan Kamphausen --- http://www.skamphausen.de
a blessed +42 regexp of confusion (weapon in hand)
You hit. The format string crumbles and turns to dust.

Re: *scratch* lost

[B. T. Raven]

Stefan Kamphausen wrote:
> Hi Pascal,
> 
> pjb@informatimago.com (Pascal J. Bourguignon) writes:
> 
>>> Hm, I don't seem to need that.  I can always M-x switch-to-buffer
>>> *scratch* RET (having to type "*scratch*" without completion since it
>>> may have been killed) and end up in a perfect stracth-buffer with
>>> lisp-interaction-mode.  It even works with iswitchb-buffer which asks
>>> before creating the new buffer.
>> Of course, but if you want to insert the initial-scratch-message...
> 
> OK, I loose that.  I understand that it is meant for newcomers anyway. 
> 
>> And switch-to-buffer creates a buffer in default-major-mode, not
>> emacs-lisp-mode.
> 
> My default-major-mode is fundamental-mode and my scratch buffer is
> always in lisp-interaction-mode.  I tried to find out where that comes
> from but without success.  Nothing in auto-mode-alist, magic-mode-alist,
> interpreter-mode-alist.  No configuration found with grep -ir
> lisp-interaction-mode ~/.emacs.d/.  Nothing found using apropos-value
> lisp-interaction-mode.  Funny that it, but very handy ;-)
> 
> 
> Best,
> Stefan

Thanks for insight, Stefan. My problem was that I had a *scratch* buffer 
sans message, in Fundamental mode immediately after restarting Emacs. 
Impossible, no? But it was caused by some anomaly in specifing (via 
custom) 'org-agenda-files and in some way that debug-init didn't catch. 
After fixing that, the normal *scratch* was generated spontaneously. 
Also I learned that most of .emacs's (not all) can be gotten by 
evaluating .emacs piecewise after running emac -Q. When I was thinking 
elisp had gone crazy I discovered that I had invoked another keyboard 
(Italian instead of U.S Dvorak) that I had neglected to unload after 
testing something. The whole experience was so bizarre that I don't even 
want to understand what happened.


Ed

RE: *scratch* lost

[Rancier, Jeffrey]

[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]

Would the following help?

(require 'protbuf)
(protect-buffer-from-kill-mode nil (get-buffer "*scratch*")) 

|-----Original Message-----
|From: help-gnu-emacs-bounces+jeffrey.rancier=xerox.com@gnu.org 
|[mailto:help-gnu-emacs-bounces+jeffrey.rancier=xerox.com@gnu.or
|g] On Behalf Of B. T. Raven
|Sent: Wednesday, June 17, 2009 8:25 AM
|To: help-gnu-emacs@gnu.org
|Subject: Re: *scratch* lost
|
|Stefan Kamphausen wrote:
|> Hi Pascal,
|> 
|> pjb@informatimago.com (Pascal J. Bourguignon) writes:
|> 
|>>> Hm, I don't seem to need that.  I can always M-x switch-to-buffer
|>>> *scratch* RET (having to type "*scratch*" without completion since 
|>>> it may have been killed) and end up in a perfect 
|stracth-buffer with 
|>>> lisp-interaction-mode.  It even works with iswitchb-buffer which 
|>>> asks before creating the new buffer.
|>> Of course, but if you want to insert the initial-scratch-message...
|> 
|> OK, I loose that.  I understand that it is meant for 
|newcomers anyway. 
|> 
|>> And switch-to-buffer creates a buffer in default-major-mode, not 
|>> emacs-lisp-mode.
|> 
|> My default-major-mode is fundamental-mode and my scratch buffer is 
|> always in lisp-interaction-mode.  I tried to find out where 
|that comes 
|> from but without success.  Nothing in auto-mode-alist, 
|> magic-mode-alist, interpreter-mode-alist.  No configuration 
|found with 
|> grep -ir lisp-interaction-mode ~/.emacs.d/.  Nothing found using 
|> apropos-value lisp-interaction-mode.  Funny that it, but very handy 
|> ;-)
|> 
|> 
|> Best,
|> Stefan
|
|Thanks for insight, Stefan. My problem was that I had a 
|*scratch* buffer sans message, in Fundamental mode immediately 
|after restarting Emacs. 
|Impossible, no? But it was caused by some anomaly in specifing (via
|custom) 'org-agenda-files and in some way that debug-init 
|didn't catch. 
|After fixing that, the normal *scratch* was generated spontaneously. 
|Also I learned that most of .emacs's (not all) can be gotten 
|by evaluating .emacs piecewise after running emac -Q. When I 
|was thinking elisp had gone crazy I discovered that I had 
|invoked another keyboard (Italian instead of U.S Dvorak) that 
|I had neglected to unload after testing something. The whole 
|experience was so bizarre that I don't even want to understand 
|what happened.
|
|
|Ed
|

[-- Attachment #2: protbuf.el --]
[-- Type: application/octet-stream, Size: 7097 bytes --]

;;; protbuf.el --- protect buffers from accidental killing

;; Copyright (C) 1994, 1999 Noah S. Friedman

;; Author: Noah Friedman <friedman@splode.com>
;; Maintainer: friedman@splode.com
;; Keywords: extensions
;; Status: Works with emacs 19.23 or later.
;; Created: 1994-06-21

;; $Id: protbuf.el,v 1.7 2000/08/21 10:45:38 friedman Exp $

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; if not, you can either send email to this
;; program's maintainer or write to: The Free Software Foundation,
;; Inc.; 59 Temple Place, Suite 330; Boston, MA 02111-1307, USA.

;;; Commentary:

;; This package allows you to make it harder to kill buffers accidentally,
;; e.g. by being too trigger happy selecting items in the buffer menu.
;; protect-process-buffer-from-kill-mode is perhaps the more useful of the
;; two, making it harder to accidentally kill shell buffers without
;; terminating the process in them first.

;;; Code:

(defvar protect-buffer-verbose t
  "*If non-nil, print a message when attempting to kill a protected buffer.")

(defvar protect-buffer-bury-p t
  "*If non-nil, bury buffer when attempting to kill it.
This only has an effect if the buffer to be killed is the one
visible in the selected window.")

\f
;;;###autoload
(defvar protect-buffer-from-kill-mode nil
  "*If non-`nil', then prevent buffer from being accidentally killed.
This variable is local to all buffers.")
(progn
  (make-variable-buffer-local 'protect-buffer-from-kill-mode)
  (put 'protect-buffer-from-kill-mode 'permanent-local t)
  (or (assq 'protect-buffer-from-kill-mode minor-mode-alist)
      (setq minor-mode-alist (cons '(protect-buffer-from-kill-mode " ProtBuf")
                                   minor-mode-alist))))

;;;###autoload
(defvar protect-process-buffer-from-kill-mode nil
  "*If non-`nil', then protect buffer with live process from being killed.
This variable is local to all buffers.")
(progn
  (make-variable-buffer-local 'protect-process-buffer-from-kill-mode)
  (put 'protect-process-buffer-from-kill-mode 'permanent-local t)
  (or (assq 'protect-process-buffer-from-kill-mode minor-mode-alist)
      (setq minor-mode-alist
            (cons '(protect-process-buffer-from-kill-mode " ProtProcBuf")
                  minor-mode-alist))))

;;;###autoload
(defvar protect-process-buffer-from-kill-preserve-function nil
  "*Function to run to determine whether to kill a process buffer.
If function returns non-nil, buffer is preserved.  Otherwise, the buffer
may be killed.

If this variable is undefined, default action is to test whether a process
object is using this buffer as a process buffer.

This variable is buffer-local when set.")
(make-variable-buffer-local 'protect-process-buffer-from-kill-preserve-function)
(put 'protect-process-buffer-from-kill-preserve-function 'permanent-local t)


\f
;;;###autoload
(defun protect-buffer-from-kill-mode (&optional prefix buffer)
  "Protect buffer from being killed.
To remove this protection, call this command with a negative prefix argument."
  (interactive "P")
  (or buffer (setq buffer (current-buffer)))
  (save-excursion
    ;; Each cond does its own set-buffer *after* comparing prefix just in
    ;; case there's a buffer-local variable `prefix' to screw up the works.
    (cond
     ((null prefix)
      (set-buffer buffer)
      (setq protect-buffer-from-kill-mode
            (not protect-buffer-from-kill-mode)))
     ((>= prefix 0)
      (set-buffer buffer)
      (setq protect-buffer-from-kill-mode t))
     (t
      (set-buffer buffer)
      (setq protect-buffer-from-kill-mode nil)))
    ;; This is always done because kill-buffer-query-functions might have
    ;; been buffer-local when this package was initially loaded, leaving
    ;; the global value unchanged.
    (add-hook 'kill-buffer-query-functions 'protect-buffer-from-kill)))

;; This function is listed in kill-buffer-query-functions; it should return
;; nil if the buffer should not be killed, t otherwise.
(defun protect-buffer-from-kill ()
  (cond
   (protect-buffer-from-kill-mode
    (and protect-buffer-verbose
         (message "Buffer \"%s\" is protected from being killed."
                  (buffer-name)))
    (and protect-buffer-bury-p
         (eq (current-buffer)
             (window-buffer (selected-window)))
         (bury-buffer))
    nil)
   (t)))

\f
;;;###autoload
(defun protect-process-buffer-from-kill-mode (&optional prefix buffer)
  "Protect buffer from being killed as long as it has an active process.
To remove this protection, call this command with a negative prefix argument."
  (interactive "P")
  (or buffer (setq buffer (current-buffer)))
  (save-excursion
    ;; Each cond does its own set-buffer *after* comparing prefix just in
    ;; case there's a buffer-local variable `prefix' to screw up the works.
    (cond
     ((null prefix)
      (set-buffer buffer)
      (setq protect-process-buffer-from-kill-mode
            (not protect-process-buffer-from-kill-mode)))
     ((>= prefix 0)
      (set-buffer buffer)
      (setq protect-process-buffer-from-kill-mode t))
     (t
      (set-buffer buffer)
      (setq protect-process-buffer-from-kill-mode nil)))
    ;; This is always done because kill-buffer-query-functions might have
    ;; been buffer-local when this package was initially loaded, leaving
    ;; the global value unchanged.
    (add-hook 'kill-buffer-query-functions 'protect-process-buffer-from-kill)))

;; This function is listed in kill-buffer-query-functions; it should return
;; nil if the buffer should be protected, t if buffer should be killed.
(defun protect-process-buffer-from-kill ()
  (cond
   ((not protect-process-buffer-from-kill-mode) t)
   ((or (and (boundp 'protect-process-buffer-from-kill-preserve-function)
             protect-process-buffer-from-kill-preserve-function
             (funcall protect-process-buffer-from-kill-preserve-function))
        (get-buffer-process (current-buffer)))
    (and protect-buffer-verbose
         (message "Buffer \"%s\" has live process; not killing."
                  (buffer-name)))
    (and protect-buffer-bury-p
         (eq (current-buffer)
             (window-buffer (selected-window)))
         (bury-buffer))
    nil)
   (t t)))

(add-hook 'kill-buffer-query-functions 'protect-buffer-from-kill)
(add-hook 'kill-buffer-query-functions 'protect-process-buffer-from-kill)

(provide 'protbuf)

;;; protbuf.el ends here

Re: *scratch* lost

[Johan Bockgård]

Stefan Kamphausen <skampi@gmx.net> writes:

> My default-major-mode is fundamental-mode and my scratch buffer is
> always in lisp-interaction-mode.  I tried to find out where that comes
> from but without success.  Nothing in auto-mode-alist, magic-mode-alist,
> interpreter-mode-alist.

It's in the C code.