major mode in new buffers

major mode in new buffers

[René Kyllingstad]

Hi,

new buffers get default-major-mode. I would find it more convenient if
auto-mode-alist was used.

Is there a disadvantage to that?


-- René

Re: major mode in new buffers

[Stefan Monnier]

> new buffers get default-major-mode. I would find it more convenient if
> auto-mode-alist was used.

So you create non-file buffer that have names that look like file names?

> Is there a disadvantage to that?

auto-mode-alist is meant for file-names rather than buffer-names.
It might be OK to use it there, tho.


        Stefan

Re: major mode in new buffers

[René Kyllingstad]

2010/3/30 Stefan Monnier <monnier@iro.umontreal.ca>:
>> new buffers get default-major-mode. I would find it more convenient if
>> auto-mode-alist was used.
>
> So you create non-file buffer that have names that look like file names?

From time to time, for example to diff when the file I'm editing has
changed on disk, or to have a piece of code available in a small temporary
buffer, or to quickly jot down some notes when I'm interrupted.


-- René

Re: major mode in new buffers

[Harald Hanche-Olsen]

+ René Kyllingstad <listmailemacs@kyllingstad.com>:

> new buffers get default-major-mode.

Actually, according to the doc string that variable is obsolete.
You're supposed to use (the global value of) major-mode instead.

> I would find it more convenient if auto-mode-alist was used.
> 
> Is there a disadvantage to that?

One obvious one (I think) is that auto-mode-alist is geared towards
filenames, not buffer names. I also admit I'd find it somewhat creepy
if the mode of a new buffer were to depend on the buffer name.

Couldn't you just bind the global value of major-mode to a function
which picks the mode based on the buffer name?

- Harald

Re: major mode in new buffers

[René Kyllingstad]

On Tue, Mar 30, 2010 at 5:13 PM, Harald Hanche-Olsen
<hanche@math.ntnu.no> wrote:
> Couldn't you just bind the global value of major-mode to a function
> which picks the mode based on the buffer name?

Yes, certainly. It just seemed like a needless difference.

The automatically created buffers I encounter have names that wouldn't
clash with auto-mode-alist, but your mileage might vary.


-- René

Re: major mode in new buffers

[David Reitter]

On Mar 30, 2010, at 7:57 AM, René Kyllingstad wrote:
> new buffers get default-major-mode. I would find it more convenient if
> auto-mode-alist was used.

Maybe not auto-mode-alist, but an extended form of magic-mode-alist.

I often create "untitled" buffers to be saved later, and they start out in my default mode. 
Or, I edit some shell script that doesn't have a file name extension, so the major mode isn't set initially.

After the first few lines, wouldn't it be nice if magic-mode-alist was applied (if reliable!) and changed the major mode?  

We don't want an MS Word Paperclip ("You seem to be writing a letter!"), but some major modes are recognized reliably.

Re: major mode in new buffers

[Juri Linkov]

> new buffers get default-major-mode. I would find it more convenient if
> auto-mode-alist was used.
>
> Is there a disadvantage to that?

You can see in http://thread.gmane.org/gmane.emacs.devel/115520/focus=115794
that the following code can be used for a new non-file buffer to set its
major mode based on the buffer name:

  (setq-default major-mode (lambda ()
                             (if buffer-file-name
                                 (fundamental-mode)
                               (let ((buffer-file-name (buffer-name)))
                                 (set-auto-mode)))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: major mode in new buffers

[René Kyllingstad]

2010/3/30 Juri Linkov <juri@jurta.org>:
>> new buffers get default-major-mode. I would find it more convenient if
>> auto-mode-alist was used.
>>
>> Is there a disadvantage to that?
>
> You can see in http://thread.gmane.org/gmane.emacs.devel/115520/focus=115794
> that the following code can be used for a new non-file buffer to set its
> major mode based on the buffer name:
>
>  (setq-default major-mode (lambda ()
>                             (if buffer-file-name
>                                 (fundamental-mode)
>                               (let ((buffer-file-name (buffer-name)))
>                                 (set-auto-mode)))))

Thank you for both the code and link to the thread!


-- René

Re: major mode in new buffers

[Juanma Barranquero]

2010/3/30 Juri Linkov <juri@jurta.org>:

> that the following code can be used for a new non-file buffer to set its
> major mode based on the buffer name:
>
>  (setq-default major-mode (lambda ()
>                             (if buffer-file-name
>                                 (fundamental-mode)
>                               (let ((buffer-file-name (buffer-name)))
>                                 (set-auto-mode)))))

Try

  emacs -Q -l ehelp --eval "(setq-default major-mode ...etc)"
  M-x electric-describe-function <RET> car <RET>
  r


    Juanma

Re: major mode in new buffers

[Stefan Monnier]

>> that the following code can be used for a new non-file buffer to set its
>> major mode based on the buffer name:
>> 
>>  (setq-default major-mode (lambda ()
>>                             (if buffer-file-name
>>                                 (fundamental-mode)
>>                               (let ((buffer-file-name (buffer-name)))
>>                                 (set-auto-mode)))))

> Try

>   emacs -Q -l ehelp --eval "(setq-default major-mode ...etc)"
>   M-x electric-describe-function <RET> car <RET>
>   r

What about it?


        Stefan

Re: major mode in new buffers

[Juanma Barranquero]

On Wed, Mar 31, 2010 at 05:02, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> What about it?

Well, when I do it, I get a buffer called *Help*, with major-mode
`help' (not `help-mode'), and the C-x suffix is no longer active (I
cannot do C-x o, for example, to switch buffers, or C-x C-x to exit
Emacs).

Don't you see the same thing?

    Juanma

Re: major mode in new buffers

[Juanma Barranquero]

On Wed, Mar 31, 2010 at 12:22, Juanma Barranquero <lekktu@gmail.com> wrote:

> cannot do C-x o, for example, to switch buffers, or C-x C-x to exit

s/buffers/windows/

    Juanma

Re: major mode in new buffers

[Juanma Barranquero]

> or C-x C-x to exit

Some days, I shouldn't try typing or thinking until *way* after breakfast.

    Juanma

Re: major mode in new buffers

[Juri Linkov]

> Well, when I do it, I get a buffer called *Help*, with major-mode
> `help' (not `help-mode'), and the C-x suffix is no longer active (I
> cannot do C-x o, for example, to switch buffers, or C-x C-x to exit
> Emacs).
>
> Don't you see the same thing?

I think what ehelp currently does by default, makes no sense -
it puts the *Help* buffer in fundamental-mode instead of help-mode.

Please look at the code in `with-electric-help':

      ;; We should really get a usable *Help* buffer when retaining
      ;; the electric one with `r'.  The problem is that a simple
      ;; call to help-mode won't cut it; at least RET is bound wrong
      ;; afterwards.  It's also not clear that `help-mode' is always
      ;; the right thing, maybe we should add an optional parameter.
      (condition-case ()
          (funcall (or (default-value 'major-mode) 'fundamental-mode))
        (error nil))

Ehelp creates a problem and tries to solve it in an ugly way.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: major mode in new buffers

[Juanma Barranquero]

2010/3/31 Juri Linkov <juri@jurta.org>:

> Ehelp creates a problem and tries to solve it in an ugly way.

I know, and I would be very happy if someone were to rewrite it from
the ground up. Still, it's a fact that it currently "works", and your
major-mode code (which I find very useful) breaks it. I thought you'd
be interested in knowing that.

    Juanma

Re: major mode in new buffers

[Juri Linkov]

>> Ehelp creates a problem and tries to solve it in an ugly way.
>
> I know, and I would be very happy if someone were to rewrite it from
> the ground up. Still, it's a fact that it currently "works", and your
> major-mode code (which I find very useful) breaks it. I thought you'd
> be interested in knowing that.

I know nothing about ehelp.el, but it seems this patch fixes it:

=== modified file 'lisp/ehelp.el'
--- lisp/ehelp.el	2010-01-13 08:35:10 +0000
+++ lisp/ehelp.el	2010-04-01 18:05:05 +0000
@@ -94,10 +94,13 @@ (defvar electric-help-map
     map)
   "Keymap defining commands available in `electric-help-mode'.")
 
+(defvar electric-help-orig-major-mode nil)
+
 (defun electric-help-mode ()
   "`with-electric-help' temporarily places its buffer in this mode.
-\(On exit from `with-electric-help', the buffer is put in default `major-mode'.)"
+\(On exit from `with-electric-help', the original `major-mode' is restored.)"
   (setq buffer-read-only t)
+  (set (make-local-variable 'electric-help-orig-major-mode) major-mode)
   (setq mode-name "Help")
   (setq major-mode 'help)
   (setq mode-line-buffer-identification '(" Help:  %b"))
@@ -131,7 +134,7 @@ (defun with-electric-help (thunk &option
 
 When the user exits (with `electric-help-exit', or otherwise), the help
 buffer's window disappears (i.e., we use `save-window-excursion'), and
-BUFFER is put into default `major-mode' (or `fundamental-mode')."
+BUFFER is put back into its original major mode."
   (setq buffer (get-buffer-create (or buffer "*Help*")))
   (let ((one (one-window-p t))
 	(config (current-window-configuration))
@@ -175,8 +178,9 @@ (defun with-electric-help (thunk &option
       ;; call to help-mode won't cut it; at least RET is bound wrong
       ;; afterwards.  It's also not clear that `help-mode' is always
       ;; the right thing, maybe we should add an optional parameter.
+      ;; Now we restore the original major mode saved by `electric-help-mode'.
       (condition-case ()
-          (funcall (or (default-value 'major-mode) 'fundamental-mode))
+          (funcall (or electric-help-orig-major-mode 'fundamental-mode))
         (error nil))
 
       (set-window-configuration config)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: major mode in new buffers

[Juanma Barranquero]

2010/4/1 Juri Linkov <juri@jurta.org>:

> I know nothing about ehelp.el, but it seems this patch fixes it:

Yes, thanks. Please install it. Two small comments:

> +(defvar electric-help-orig-major-mode nil)
> +
>  (defun electric-help-mode ()
>   "`with-electric-help' temporarily places its buffer in this mode.
> -\(On exit from `with-electric-help', the buffer is put in default `major-mode'.)"
> +\(On exit from `with-electric-help', the original `major-mode' is restored.)"
>   (setq buffer-read-only t)
> +  (set (make-local-variable 'electric-help-orig-major-mode) major-mode)

It makes sense for `electric-help-orig-major-mode' to be automatically
buffer-local, as it will ever be used as such.

>       ;; call to help-mode won't cut it; at least RET is bound wrong
>       ;; afterwards.  It's also not clear that `help-mode' is always
>       ;; the right thing, maybe we should add an optional parameter.

This part of the comment (and the missing first line that precedes it)
is no longer true and should be deleted.

    Juanma

Re: major mode in new buffers

[Juanma Barranquero]

Well, strictly speaking, this part

>       ;; call to help-mode won't cut it; at least RET is bound wrong
>       ;; afterwards.

is still true.

    Juanma

Re: major mode in new buffers

[Juri Linkov]

> Well, strictly speaking, this part
>
>>       ;; call to help-mode won't cut it; at least RET is bound wrong
>>       ;; afterwards.
>
> is still true.

I don't understand what this comment tries to say.
Do you have a recipe to reproduce the remaining problems?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: major mode in new buffers

[Juanma Barranquero]

2010/4/2 Juri Linkov <juri@jurta.org>:

> I don't understand what this comment tries to say.
> Do you have a recipe to reproduce the remaining problems?

With your patch applied, do this:

  emacs -Q -l ehelp --eval '(global-set-key [?\C-h] 'ehelp-command)'
  C-h f car <RET> r    ;; now the *help* buffer is help-mode
  <RET>    ==>  "End of buffer.  Type q to quit viewing"

so after restoring the previous major mode, *Help* is in help-mode but
the bindings are not OK.

    Juanma

Re: major mode in new buffers

[Juri Linkov]

> With your patch applied, do this:
>
>   emacs -Q -l ehelp --eval '(global-set-key [?\C-h] 'ehelp-command)'
>   C-h f car <RET> r    ;; now the *help* buffer is help-mode
>   <RET>    ==>  "End of buffer.  Type q to quit viewing"
>
> so after restoring the previous major mode, *Help* is in help-mode but
> the bindings are not OK.

The direct call to `help-mode' can't set Help mode correctly.
This should be done by calling `with-help-window' that uses
`with-output-to-temp-buffer' that calls `help-mode-setup'
as one of its hooks in `temp-buffer-setup-hook'.

But at least, after the direct call to `help-mode', RET works correctly
on links (due to its text property's local keymap).  This is most
important.  It's not a big problem when typing RET outside a link
says "End of buffer." instead of "No cross-reference here".

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: major mode in new buffers

[Juanma Barranquero]

2010/4/2 Juri Linkov <juri@jurta.org>:

> But at least, after the direct call to `help-mode', RET works correctly
> on links (due to its text property's local keymap).  This is most
> important.  It's not a big problem when typing RET outside a link
> says "End of buffer." instead of "No cross-reference here".

I agree. I think you should install your change.

    Juanma

Re: major mode in new buffers

[Juri Linkov]

>> But at least, after the direct call to `help-mode', RET works correctly
>> on links (due to its text property's local keymap).  This is most
>> important.  It's not a big problem when typing RET outside a link
>> says "End of buffer." instead of "No cross-reference here".
>
> I agree. I think you should install your change.

This is installed now.  Thanks for your participation.

-- 
Juri Linkov
http://www.jurta.org/emacs/