Re: Hideshow
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
But we've usually refused to do the reverse. We'd rather
suffer
with our low-level glyph/image/specifier interfaces than provide
something saner/higher-level that could smoothly handle what GNU
[...] can do, while making access to the XEmacs facilities
convenient.
This mixes two different points I (think I) was making.
1. Our "low-level" glyph/image/specifier interface is hard to pick up
and use. Introducing a higher-level API (such as annotations over
extents and glyphs) doesn't help at all.
2. Creating dumbed down API's that take into account the limitations
of both Emacsen is a waste of time.
>> AFAIK the keymap APIs are mostly the same, aren't
they?
Hrvoje> Not really; for example, they use keymaps to implement
Hrvoje> menus. "Why doesn't XEmacs have `define-key-after'?"
And toolbars. But do people really use `define-key-after' to define
_keys_?
They don't. The point was that in some cases the API's are
sufficiently different that writing compatibility functions is not
just a small matter of programming. In this case, you cannot
implement define-key-after in XEmacs because our keymaps (objects
created with `make-keymap') simply do not hold information about
menus and toolbars.
If we provided a decent compatible interface abstracted to toolbars
or menus, don't you think there's a reasonable chance that 3rd party
maintainers would be happy to forget the existence of such cruft
entirely?
Nope. For one, some people won't think of it as cruft. Second, the
FSF documentation will still document `define-key-after' and friends,
which means that developers exposed to FSF will see it before they
ever see the compatible interface. Finally, to be really useful, the
compatible interface should be bundled with FSF, which means they get
to "improve" it incompatibly without telling us.