Re: Compatibility with the GNU Emacs Menu API.

>>>>> "Malcolm" == Malcolm Purvis <[email protected]> writes:

    Malcolm> Note that I'm asking about accepting and ignoring the
    Malcolm> keyword, not necessarily implementing the underlying help
    Malcolm> system.

I don't have any problem with this as long as it's clear we _can_
support the help system without too much effort if users demand it.

    Malcolm> Before I start on developing some patches to improve
    Malcolm> compatibility I'd like to know if they'd be accepted in
    Malcolm> principle.  How far should we go in supporting the GNU
    Malcolm> Emacs API?

Until your stomach turns? :-)

To put it more constructively, right now we don't have the manpower to
refactor everything.  If you've got GNU code that you'd like to port,
and porting some missing API (if only as a stub) would be not much
more effort than kludging around it, why not?  You'll save somebody
else the trouble.

I think that documenting the stubbed functionality in the nearest
docstring is an absolute must.  There should be a standard keyword for
it, to make grepping easy.  Eg, "The XYZ functionality is
unimplemented [GNU compatibility stub]."

I think it might be desirable to have an XEmacs debug API called
`maybe-bitch-about-stubbed-gnuemacs-functionality', which issues a
warning if `warn-about-stubbed-gnuemacs-functionality' is non-nil.
This would be useful for people who don't care about the functionality
per se, but would like to contribute a fix or two for the sake of
completeness, to see what actually gets called in their usage.

Maybe there should be a list of these, perhaps in a TODO node in the
Internals manual.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.