February 2005 - XEmacs-Design - XEmacs Mailing List Archives

Moving checks out of s&m files (was Re: [AC21.5Q21.4] xemacs-21.5: fix build on FreeBSD) 19 years, 7 months

Malcolm Purvis

[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>

2 participants
1 comments

skeleton improvement 19 years, 7 months

Pierre Courtieu

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

3 participants
7 comments

Re: skeleton improvement 19 years, 7 months

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

2 participants
1 comments

Re: [R21.4] [COMMIT] Update glyph documentation 19 years, 7 months

Stephen J. Turnbull

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.

1 participants
0 comments

Implementation of :inherit parameter for faces 19 years, 7 months

Ben Wing

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

3 participants
3 comments

Andrew Choi's Carbon work 19 years, 7 months

Michael Sperber

Has anybody here noticed the substantial-looking progress at http://members.shaw.ca/akochoi/2005/01-09/index.html#1 ? Should we try to encourage this guy to check something in? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

RE: question on menubar implementation 19 years, 8 months

Ben Wing

> 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.

2 participants
1 comments

question on menubar implementation 19 years, 8 months

François Revol

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.

3 participants
5 comments

Re: [AC21.5] easy-mmode in core must be dumped 19 years, 8 months

Stephen J. Turnbull

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.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

XEmacs-Design February 2005