Creating new major mode

Creating new major mode

[Paulo Jorge Matos]

Hello,

I have been working on a new major mode and it is striking me that, for 
example, lisp-mode doesn't use generic-mode or derived-mode. It seems to 
define just a couple of functions which set specific parameters. When 
should generic-modes or derived-modes be created?

Any tutorial on creating new major modes around?

Cheers,
-- 
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Creating new major mode

[Nikolaj Schumacher]

Paulo Jorge Matos <pocm@soton.ac.uk> wrote:

> When should generic-modes or derived-modes be created?

Generally, I suggest you just derive any mode from fundamental-mode.
That takes care of most the house keeping, and you'll only need to add
what you actually want.

Maybe you should look at more recent and smaller modes than lisp-mode to
learn.  Look around in the Emacs Wiki.


regards,
Nikolaj Schumacher

Re: Creating new major mode

[Paulo Jorge Matos]

Nikolaj Schumacher wrote:
> Paulo Jorge Matos <pocm@soton.ac.uk> wrote:
> 
>> When should generic-modes or derived-modes be created?
> 
> Generally, I suggest you just derive any mode from fundamental-mode.
> That takes care of most the house keeping, and you'll only need to add
> what you actually want.
> 
> Maybe you should look at more recent and smaller modes than lisp-mode to
> learn.  Look around in the Emacs Wiki.
> 

Thank you. It seems then that the issue is that some modes predate the 
existence of the derived-mode API. New modes should use though, right?

I will check the wiki out for new modes, thanks! :)

> 
> regards,
> Nikolaj Schumacher
> 
> 


-- 
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Creating new major mode

[Nikolaj Schumacher]

Paulo Jorge Matos <pocm@soton.ac.uk> wrote:

> Thank you. It seems then that the issue is that some modes predate the
> existence of the derived-mode API. New modes should use though, right?

Well, "should" is relative.  I absolutely suggest it, but it's strictly
optional.  Some newer modes also elect not to use it.

Maybe take a look at the bundled css-mode.  It's not too big and has a
typical design.


regards,
Nikolaj Schumacher

Re: Creating new major mode

[Paulo J. Matos]

On Wed, Sep 24, 2008 at 4:06 PM, Nikolaj Schumacher <me@nschum.de> wrote:
> Paulo Jorge Matos <pocm@soton.ac.uk> wrote:
>
>> Thank you. It seems then that the issue is that some modes predate the
>> existence of the derived-mode API. New modes should use though, right?
>
> Well, "should" is relative.  I absolutely suggest it, but it's strictly
> optional.  Some newer modes also elect not to use it.
>
> Maybe take a look at the bundled css-mode.  It's not too big and has a
> typical design.
>

Thanks for the tip, I will look at it! :)

>
> regards,
> Nikolaj Schumacher
>
>
>



-- 
Paulo Jorge Matos - pocm at ecs.soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Creating new major mode

[Tim X]

"Paulo J. Matos" <pocm@ecs.soton.ac.uk> writes:

> On Wed, Sep 24, 2008 at 4:06 PM, Nikolaj Schumacher <me@nschum.de> wrote:
>> Paulo Jorge Matos <pocm@soton.ac.uk> wrote:
>>
>>> Thank you. It seems then that the issue is that some modes predate the
>>> existence of the derived-mode API. New modes should use though, right?
>>
>> Well, "should" is relative.  I absolutely suggest it, but it's strictly
>> optional.  Some newer modes also elect not to use it.
>>
>> Maybe take a look at the bundled css-mode.  It's not too big and has a
>> typical design.
>>
>
> Thanks for the tip, I will look at it! :)
>

The other nice thing about using derived mode et al is that you can get
a lot of functionality for free. For example, if you derive from a mode
that has the same basic formatting requirements as your new mode, then
you only need to tweak things rather than re-invent from scratch. 
It can be a lot less work and result in a lot less you need to maintain.

Tim


-- 
tcross (at) rapttech dot com dot au