Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105470: Improve documentation of `special' modes.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105470: Improve documentation of `special' modes.

[Stefan Monnier]

>> > +If this mode is appropriate only for specially-prepared text produced by
>> > +the mode itself (rather than by the user typing at the keyboard or by an
>> > +external file), then the major mode command symbol should have a
>> > +property named @code{mode-class} with value @code{special}, put on as
>> > +follows:
>> AFAIK we also use `special' for things like doc-view-mode.
> It was mostly the old text, I just added the part in parentheses.
> I don't actually have a good understanding of why would a mode want to
> behave like that.  The above explanation is purely phenomenological,
> so if I would need to determine whether my mode needs it, I'd be
> probably stumped.  I don't really see the connection between
> "specially-prepared" and "don't use me as the default mode".
> Can you explain the considerations for when to use this feature?  I
> will then clarify this in the manual.

Indeed, I'm just as lost as you are :-(
For that reason, I'd be happy to get rid of this "use as the default
mode" thingy.  I.e. we should simply never inherit the major mode of new
buffers from the current buffer (if the global value of major-mode is
nil, then the default major-mode when creating a new buffer will be
fundamental-mode, and that's it).


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105470: Improve documentation of `special' modes.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Tue, 16 Aug 2011 13:11:22 -0400
> 
> > I don't actually have a good understanding of why would a mode want to
> > behave like that.  The above explanation is purely phenomenological,
> > so if I would need to determine whether my mode needs it, I'd be
> > probably stumped.  I don't really see the connection between
> > "specially-prepared" and "don't use me as the default mode".
> > Can you explain the considerations for when to use this feature?  I
> > will then clarify this in the manual.
> 
> Indeed, I'm just as lost as you are :-(
> For that reason, I'd be happy to get rid of this "use as the default
> mode" thingy.  I.e. we should simply never inherit the major mode of new
> buffers from the current buffer (if the global value of major-mode is
> nil, then the default major-mode when creating a new buffer will be
> fundamental-mode, and that's it).

Are we sure the nil-means-use-current-buffer-major-mode feature is not
used too much to get rid of it?

And if we do that, how would a Lisp program specify that the major
mode of the current buffer is to be used for a newly created buffer?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105470: Improve documentation of `special' modes.

[Stefan Monnier]

>> > I don't actually have a good understanding of why would a mode want to
>> > behave like that.  The above explanation is purely phenomenological,
>> > so if I would need to determine whether my mode needs it, I'd be
>> > probably stumped.  I don't really see the connection between
>> > "specially-prepared" and "don't use me as the default mode".
>> > Can you explain the considerations for when to use this feature?  I
>> > will then clarify this in the manual.
>> Indeed, I'm just as lost as you are :-(
>> For that reason, I'd be happy to get rid of this "use as the default
>> mode" thingy.  I.e. we should simply never inherit the major mode of new
>> buffers from the current buffer (if the global value of major-mode is
>> nil, then the default major-mode when creating a new buffer will be
>> fundamental-mode, and that's it).
> Are we sure the nil-means-use-current-buffer-major-mode feature is not
> used too much to get rid of it?

I think it's very rarely used by Elisp code.  It might be used by a few
rare users as well.

> And if we do that, how would a Lisp program specify that the major
> mode of the current buffer is to be used for a newly created buffer?

By calling that major mode in the new buffer?


        Stefan