[Moved to -design]
>>>>> "Stephen" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> Also, note that patches to *fix* the s&m files are deprecated. We
Stephen> strongly prefer patches to _move_ checks out of the s&m files [...]
What's the preferred way of doing this for things like enabling the use of
system malloc for a given architecture?
XEmacs on PPC64 Linux crashes without system malloc and I'd like to enable it
permanently. Is burying this info in a sea of case statements within
configure.[in|ac] any better that using s&m files?
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>

Hi,
I am writing a minor mode for having "holes" in your buffer that you can
fill by different means. I would like to interface it with skeletons, and I
am not able to get interesting positions after a skeleton has been
inserted. In Emacs there is this variable 'skeleton-position which is made
for this (added recently it seems). Moreover one can define in the skeleton
what are the positions which should be added to this variable.
My question is: is it possible to have such a variable also in XEmacs
please?
Sorry if this is not the right list for this kind of question.
Pierre Courtieu

On 25 fév 2005, Stephen J. Turnbull wrote:
> skeletons are good for forms with few options, or where the author wants
> more control.
I see.
> Arguably both should be superseded by the Emacs widget library, except
> it's slow, unreliable, and hard to program with. :-)
OK this is xemacs-design isn't it? What would be the ideal "template minor
mode"? Something as flexible as skeleton, as interactive as tempo and still
easy to program?
Pierre

Moving to xemacs-design.
>>>>> "Ben" == Ben Wing <ben(a)666.com> writes:
Ben> Either we generate sections of the Lisp manual directly from
Ben> the doc strings or we incorporate the doc strings into the
Ben> Lisp manual and fix C-h f to automatically go to the right
Ben> place.
Ben> The latter solution is what Microsoft uses.
Well, so do we, really. That's what etc/DOC is, as you point out.
Ben> What think you, stephen? Any time?
The biggest technical problem I see is how to handle user-defined and
packaged docstrings seamlessly. Simply generalizing the current
scheme (if it's a string, it's a conventional docstring, if it's a
cons the car is an info reference, the cdr is a list of additional
indexing information---eg, if we decide not to do a node-per-defun
strategy, maybe a line number) should work. But it's not "seamless,"
they wouldn't have access to the info-docstring features.
The big problem in doing a quality job on a real manual is the God-
Forsaken-Documentation-License. We can't put docstrings under the doc
license, and we can't mix GPLed docstrings or postprocessed versions
of them with our Texinfo docs.
For unifying help into Info, I'd suggest a transition strategy of
creating a DOC.info based on picking up _all_ docstrings, creating a
nodename from the symbol name (which has to be unique since Emacs Lisp
doesn't have namespaces), and have the master menu simply be an
alphabetical list of .el and .c names, which also have to be unique
because of our rather flat directory structure.
This would also have the advantage that you could use Info's strategy
for finding nodes rather than the brain-dead straight indexing that
C-h f uses. Slow? Dunno, let's try it and see.
Give me a week and ping me. I probably won't get done by then, not
even started, but I should have some free time after next Tuesday.
This looks actually doable, and we can add bells and whistles for
creating real manuals later. The real manual might even just refer to
DOC.info for function and variable defs.
Finally, we could think about doing more sensible things with Info,
like hiding the stupid *note: markers and things like that. I think
GNU is already doing some of that in their info.el.
========================================================================
The following is a possibly dumb idea that I wrote first and now don't
know if it make sense in context. May as well document it here.
I think we should generate everything except the toplevel menu from
the source files.
As an interim step, we could have something like this (borrowing the
pragma notation from autoloads):
;;;###info:lispref
;;;
;;; the Lisp-to-texi code that processes lispref-declaration
;;; 0. ignores a header comment (like this) and blank lines up to an
;;; ＠node line (alternatively, we could just require ＠c)
;;; 1. strips off the leading and trailing (in C) comment syntax
;;; 2. copies it to man/lispref/thisfile-basename.texi
;;; ＠node Glyphs
;;; ＠chapter Glyphs
;;; ＠cindex glyphs
;;; ＠cindex images
;;;
;;; Glyphs are the Lisp-level API used by XEmacs to display anything
;;; other than buffer text. A glyph contains a generalized image
;;; specifier. "Generalized" means that things not usually considered
;;; to be images such as formatted text and GUI widgets are handled
;;; with a uniform API. A "specifier" is used so that the "image" may
;;; vary according to display context (TTY vs. graphical console,
;;; color vs. monochrome visual). The glyph also contains other
;;; information such as the baseline so that alignment of the image
;;; can be controlled via the glyph API.
;;;
;;; ＠menu
;;; make-glyph::
;;; set-glyph-image::
;;; ＠end menu
;;;###endinfo
;;;###info:lispref-declaration
;;;
;;; the Lisp-to-texi code that processes lispref-declaration
;;; 0. ignores a header comment (like this) and blank lines
;;; 1. parses out the kind of declaration (function, macro, variable,
;;; custom, behavior, ...)
;;; 2. in this case creates
;;; ＠node make-glyph
;;; ＠section make-glyph
;;; ＠defun make-glyph &optional spec-list type
;;; then inserts the docstring as the body
;;; 3. filters out literate programming codes like ＠ifmanual below
;;;
;;; the help code needs to deal with a limited number of ＠ codes
;;; appropriate to docstrings. I hope, anyway.
(defun make-glyph (&optional spec-list type)
"Return a new glyph.
Optional argument ＠var{spec-list}, if non-nil, should be an image
specification.
Optional argument ＠var{type}, if non-nil, should be one of the symbols
＠samp{buffer}, ＠samp{pointer}, or ＠samp{icon}.
＠ifmanual ＠c not really Texinfo; replaced by a hyperlink "for more
＠c info" in help
User code should never use types ＠samp{pointer} or ＠samp{icon}, since
only one global glyph for each of those types is needed, and those are
created at initialization.
＠end ifmanual
"
;; Lisp definition here
)
We could obviously do without the lispref-declaration marker, but I
don't think that internal, implementation code should get into the
lispref. If we really want it documented, it could get an
internals-declaration marker.
Note that this comment pragma would allow us to put XEmacs User Guide
documentation close to the code it documents, too.
--
Institute of Policy and Planning Sciences 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.

I notice that my new font-lock port requires the :inherit face property.
The idea seems to be that faces under GNU Emacs are now specified through a
series of attributes, the importance of which is that fonts have been
exploded into a whole series of new properties -- slant, weight, height,
family, etc. In GNU Emacs the code to combine them happens at the C code.
In our C code, the font is just a unified font spec, although there are
nasty functions to `make-font-smaller' etc. There also exist, in our C
code, inheritance which is in some way more powerful than FSF [individual
properties can each inherit from some other face, even from a
differently-named property if there is semantic equivalency]. FSF has only
a single :inherit attribute, which is not as powerful as what is just
mentioned but more convenient to specify and more powerful in that the font
properties have been split out. Currently we have Lisp code to combine
multiple face properties to generate a display face (e.g. multiple faces may
overlay a particular region of text, and in general faces need not specify
values for all possible properties, so one might specify a only foreground
color, another a font, and a third a background pixmap, and the resulting
text has all three properties applied). It would be very easy to add an
`inherit' property (currently inheritance is always from the `default'
face), and we could hook the Lisp code into the C code so that we could
directly set the exploded properties on faces and have the fonts generated
automatically. But it would probably have problems getting proper
on-the-fly inheritance of all the various font properties. Doing this right
would not be too difficult since all the complex algorithmic stuff is
already written, but it would require a bit of work.
So ... There are various paths I could take, from doing nothing at all to
doing the whole thing, complete and correct, to in-between steps that should
be clear from the above discussion.
I'd like to hear people's thoughts on [a] how important is this
functionality, [b] who would use it, [c] how much of it needs to be
implemented, and when [e.g. "While you're at it, do it right" or "Just put
in a minimal hack to get font-lock minimally working, then worry about it
properly later."
Ben

> it's doable, but is a bit tricky, as I'll have to wait from
> the menu's window thread for the main thread to fill it
> before returning the submenu...
>
> Now, is that thing supposed to change in the near future as
> Stephen said or can I start on it ?
Go ahead, I think Stephen was confusing this with my recent behavior
changes, which are something else entirely.

Hi, there.
Didn't get many replies *g* to my last post
( http://list-archive.xemacs.org/xemacs-design/200412/msg00062.html ), so I'll post the question separately, maybe it won't be filtered out on subj=.*BeOS.* :p
The menubar implementations I have seen so far all seem to construct menu trees on the fly (= submenus are created when an item is selected).
It would be simpler for me if I could generate all the menu at once, and update it in case it changes. Is this at all possible ?
François.

This does _not_ belong on XEmacs Review.
Reply-To and M-F-T directed to XEmacs Design.
>>>>> "Ben" == Ben Wing <ben(a)666.com> writes:
Ben> I moved it into core because I didn't really see any
Ben> alternative given that paragraphs.el depends on it. And I
Ben> think it's pretty basic functionality. I really question the
Ben> wisdom of having xemacs-base separate at all ... The
Ben> packages should be *optional* but xemacs-base is completely
Ben> required.
IMO, "required editor functionality" != "XEmacs core functionality".
Equating them was a fundamental mistake that Steve Baur made when he
first split up the packages.
The point of packages is to define _modules_, not to save disk or RAM
space. The UI should mostly _not_ be considered part of the core, no
matter how basic it is to users! Very little of the editor (ie, far
less than classic vi presents, more like say "pico") should be part of
the core. "Core" to me means Lisp engine + Lisp primitives + basic
text manipulation + redisplay + I/O. Ie, those lowlevel APIs which
can't be robustly changed by loading a Lisp library or two.
If the core functionality of 21.4 (as I defined it) is sufficient to
support the functionality of easy-mmode.el, paragraphs.el,
regexp-opt.el---and as far as I know all of those things are
true---then these should be in separate packages that can be used by
both 21.4 and 21.5. There is no reason why modern functionality, and
especially bugfixes, that happened to not to have been available when
21.4 was released should deliberately be made hard to add to 21.4.
If it turns out to really be that hard, after actually trying it,
_then_ move the library/package into the cores separately. Or maybe
have a load-path like
("package1" "package2" "stdlib-vn" "stdlib-vn-1" "stdlib")
(normally no "core"; if it's in core, I'm thinking it should be
dumped; of course we'll probably need a mechanism to dump a lot of the
stdlib packages, too).
Ie, what we should have is
XEmacs -+- 21.4-core
|
+- 22.0-core (nee 21.5-core)
|
+- standard-packages (eg, efs, dired, xemacs-base, field, stdlib-22.0)
|
+- unbundled-packages
And then we can finally rm -rf xemacs-packages/apel!
The main thing I see is that we would have to do a much better job
than we currently do of testing multi-version compatibility of changes
to the standard packages. But in the case of a new standard package,
say field, we would simply say "we hope it's compatible with 21.4, but
we can't promise that without field testing" (pun unintended).
If this makes 21.5 harder to develop, then we need to further refactor
to make packages work better in this context. What you're saying
AFAICT is equivalent to you need to move this stuff into 21.5 because
the underlying internal APIs are poorly designed so the dependencies
can't move into packages. Maybe that's not true, but you sure aren't
documenting your case in a way that it can be reviewed.
The argument that we have to distribute basic editor UI with the text/
Lisp/redisplay core will shortly be moot. I have the basic facility
in place; I need to address a couple more common use-cases, and I'll
be ready to commit to 21.5 in a week or so. It can be implemented as
a pure extension with no changes to existing files except a new
directory in etc/ to hold the packages and a new target in the
toplevel Makefile, so it could be added to 21.4 (and I expect it to
be; this is something that people, including you, have been demanding
for seven or eight years now).
Ben> The counter "argument" that having this in the packages
Ben> allows people to get this stuff automatically upon updating
Ben> is not something I buy. Updates should not change core
Ben> functionality; if we want it into 21.4, we can release a new
Ben> version of 21.4.
Nice in theory, but in practice trying to backport your code from 21.5
to 21.4, and screwing it up because gratuitous renaming in the 21.5
codebase makes diff useless, is something that has embarrassed me on
several occasions. (Most recently the very nasty regexp bug that
David Kastrup continues to badger us about.)
If you are going to continue your habit of refactoring and renaming
stuff all over the place---and I think you SHOULD---"we can release a
new version of 21.4" is semantically equivalent to "let's mostly not
bother with 21.4", assuming you're not willing to commit to doing a
lot more work on the stable branch than you've done in the past. I
don't consider that good policy, especially since you pretty clearly
intend to go on to apply it to 22.0 once it goes stable.
Ben> BTW I strongly think that field.el should be moved into core,
Ben> as there is a core dependency. This is also a good example
Ben> of core functionality that should *not* be part of the
Ben> packages.
True, but "core dependency" is a reason for moving that dependency out
of core, not vice versa.
"Core" should be defined by "there are reasons why this would be hard
to implement in a conceptually separate module", not "it would be
convenient if I could just change these two modules in a parallel
fashion without being screamed at by people depending on a different
version of the API." field.el may very well be such a module, but the
fact that you've introduced a new dependency in core (obviously it's
new, because it can't possibly be in 21.4) doesn't prove that the
dependency itself belongs in core!
--
Institute of Policy and Planning Sciences 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.