bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13251: Wishlist: Add ability to set initial buffer for new frames.


From: martin rudalics
Subject: bug#13251: Wishlist: Add ability to set initial buffer for new frames.
Date: Sun, 23 Dec 2012 11:14:10 +0100

> Thanks for the tips.

Thanks for the patch.  Unfortunately, we are not yet done :-(

> === modified file 'lisp/server.el'
> --- lisp/server.el 2012-11-09 06:28:27 +0000
> +++ lisp/server.el 2012-12-22 19:36:57 +0000
> @@ -1256,12 +1256,18 @@
>            (mapc 'funcall (nreverse commands))
>
>      ;; If we were told only to open a new client, obey
> -    ;; `initial-buffer-choice' if it specifies a file.
> -    (unless (or files commands)
> -      (if (stringp initial-buffer-choice)
> -          (find-file initial-buffer-choice)
> -        (switch-to-buffer (get-buffer-create "*scratch*")
> -                          'norecord)))
> +    ;; `initial-buffer-choice' if it specifies a file
> +          ;; or a function
> +          (unless (or files commands)

Here we have to make sure that we do _not_ switch to *scratch* when
`initial-buffer-choice' is nil but show the initial start screen.

> +            (switch-to-buffer
> +             (get-buffer-create
> +              (cond
> +               ((stringp initial-buffer-choice)
> +                (find-file-noselect initial-buffer-choice))
> +               ((functionp initial-buffer-choice)
> +                (funcall initial-buffer-choice))

Let's make sure that both `find-file-noselect' and the function called
via `initial-buffer-choice' really returned a live buffer.  So please
add a call to `buffer-live-p' for these cases.  Which also means that
Stefan's initial proposal for a let-bound `buf' is the better choice ;-)
(he's usually always right in these things).

> +               (t "*scratch*")))
> +             'norecord))
>
>            ;; Delete the client if necessary.
>            (cond
>
> === modified file 'lisp/startup.el'
> --- lisp/startup.el        2012-12-01 02:08:30 +0000
> +++ lisp/startup.el        2012-12-22 20:09:27 +0000
> @@ -43,7 +43,7 @@
>  If the value is nil and `inhibit-startup-screen' is nil, show the
>  startup screen.  If the value is a string, visit the specified file
>  or directory using `find-file'.

I suppose this is no longer true.  Let's say "switch to a buffer
visiting the file or directory specified by the string" instead.

>   If t, open the `*scratch*'
> -buffer.

This should come after the function item.  Note that we are not overly
precise in the doc-string - any non-nil value of `initial-buffer-choice'
will show *scratch*.  But it's better to not tell that in the doc-string
so we have room for future changes - just like the one you proposed.

> +buffer. If function, switch to a buffer returned by this function.

"If the value is a function, switch to the buffer returned by that
function." seems more precise here.

>  A string value also causes emacsclient to open the specified file
>  or directory when no target file is specified."
> @@ -51,8 +51,9 @@
>      (const     :tag "Startup screen" nil)
>      (directory :tag "Directory" :value "~/")
>      (file      :tag "File" :value "~/.emacs")
> +          (function  :tag "Function")
>      (const     :tag "Lisp scratch buffer" t))
> -  :version "23.1"
> +  :version "24.4"
>    :group 'initialization)
>
>  (defcustom inhibit-startup-screen nil

And now comes the last problem.  The function `command-line-1' (in
startup.el) contains these lines:

    (when (eq initial-buffer-choice t)
      ;; When initial-buffer-choice equals t make sure that *scratch*
      ;; exists.
      (get-buffer-create "*scratch*"))

I'd remove them because we can handle them here:

    (when initial-buffer-choice
      (cond ((eq initial-buffer-choice t)
             (switch-to-buffer (get-buffer-create "*scratch*")))
            ((stringp initial-buffer-choice)
             (find-file initial-buffer-choice))))

If we allow `initial-buffer-choice' to specify a function, we have to
handle it here in the same way as in server.el.

martin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]