all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
Cc: monnier+gnu/emacs@rum.cs.yale.edu, emacs-devel@gnu.org
Subject: Re: Recent attempts at standardizing major mode definitions.
Date: Wed, 04 Sep 2002 11:27:54 -0400	[thread overview]
Message-ID: <200209041527.g84FRsZ19321@rum.cs.yale.edu> (raw)
In-Reply-To: 200209040059.TAA28323@eel.dms.auburn.edu

> I see that yesterday I forgot to answer the following question:
> 
> Stefan Monnier wrote:
> 
>    I have the following requirements:
>    - it must be easy for a user to add abbrevs that are available in
>      all "related" modes.
> 
> Definitely, that is essential.
> 
>    - it must be easy for a user to add abbrevs that are only available in
>      a particular mode.
> 
> If the mode is not related to any other mode and is not a read-only
> type mode, say dired, help buffer, info and so on, definitely.

latex-mode is definitely related to plain-tex-mode which is definitely
related to text-mode and yet I want to have abbrevs specifically for
the Tex and LaTeX languages.
As for read-only buffers, abbrevs are irrelevant there anyway.

> Otherwise, I am hesitating as I already mentioned.
> 
>    - mode authors should be able to provide the above behavior without
>      having to think about it (because they generally don't, especially
>      since some of them don't even use abbrevs).
> 
> They can not do it completely without thinking.  They have to make a
> decision about which abbrev tables to use, regardless of whether we
> implement inheritance.  It is possible that say an abbrev table of a
> mode is perfectly suitable for another mode even if the syntax-table
> of another mode is more suitable as the parent syntax table.  Such
> situations can occur.  I would rather have somebody who never uses
> abbrevs think about which abbrev-table to use, than, say , have
> somebody who never uses font-lock worry about font-lock-defaults.

Many authors just don't think about abbrevs at all, so you end up
with either no abbrev-table or with some default.  I just want the
default to be as close to possible to the most likely "ideal".
A new table that inherits from the parent is a pretty damn good default,
if you ask me.


	Stefan

  reply	other threads:[~2002-09-04 15:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-02  2:40 Recent attempts at standardizing major mode definitions Luc Teirlinck
2002-09-02 16:51 ` Stefan Monnier
2002-09-02 17:49   ` Kai Großjohann
2002-09-02 20:39   ` Luc Teirlinck
2002-09-02 23:14     ` Stefan Monnier
2002-09-04  0:59       ` Luc Teirlinck
2002-09-04 15:27         ` Stefan Monnier [this message]
2002-09-04  1:24   ` Luc Teirlinck
2002-09-04 15:25     ` Stefan Monnier
2002-09-05  2:46     ` Richard Stallman
2002-09-04  1:35   ` Luc Teirlinck
2002-09-04 15:24     ` Stefan Monnier
2002-09-04 21:52       ` Luc Teirlinck
2002-09-05 15:54         ` Stefan Monnier
2002-09-05 16:52           ` Luc Teirlinck
2002-09-05 17:15             ` Luc Teirlinck
2002-09-04  2:06   ` Luc Teirlinck
2002-09-04 15:40     ` Stefan Monnier
2002-09-04 22:36       ` Luc Teirlinck
2002-09-06 18:03         ` Stefan Monnier
2002-09-06 18:48           ` David Masterson
2002-09-06 22:53           ` Luc Teirlinck
2002-09-07  0:05             ` Luc Teirlinck
2002-09-07  2:47             ` Luc Teirlinck
2002-09-07  3:06               ` Luc Teirlinck
2002-09-03 13:26 ` Richard Stallman
2002-09-03 13:56   ` Mario Lang
2002-09-05  2:45     ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200209041527.g84FRsZ19321@rum.cs.yale.edu \
    --to=monnier+gnu/emacs@rum.cs.yale.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.