Hello everybody,
I tried to update my xemacs-21.5.11 tree to 21.5.12 with the diff file
found in ftp mirrors, but all attempts failed (patch said "patch: ****
malformed patch at line 315").
I tried to skip several parts of the diff file without success (the main
problem ends in the part of "configure", which could not be skipped).
Did anyone encoutered the same problem? Could it be possible to re-generate
the patch file?
\bye
S.
--
MAKING MILHOUSE CRY IS NOT A SCIENCE PROJECT.
MAKING MILHOUSE CRY IS NOT A SCIENCE PROJECT.
MAKING MILHOUSE CRY IS NOT A SCIENCE PROJECT.
-+- Bart Simpson on chalkboard, episode #213

>>>>> "Paul" == Paul Krause <paulkrause1(a)mediaone.net> writes:
Paul> Adrian Aichner <adrian(a)xemacs.org> writes:
>> >> Do we want to make C-u M-x comment-region smarter?
>>
Paul> No! Make indentation smarter. If a comment begins in column
Paul> 1, don't
Paul> indent it when reindenting a region. This solves the
Paul> problem without
Paul> style-changes or hacks to comment-region.
>>
Paul> Have I overlooked anything?
>>
>> This, maybe?
>>
>> (Info-goto-node "(xemacs)Comments")
>>
>> Adrian
Paul> Could you be a little more specific? I don't what you're
Paul> referring to. Maybe this?
Paul> You can also use `Meta-;' to align an existing comment. If a line
Paul> already contains the string that starts comments, `M-;' just moves
Paul> point after it and re-indents it to the conventional place.
Paul> Exception:
Paul> comments starting in column 0 are not moved.
Yes, that, and also the following paragraph.
Some major modes have special rules for indenting certain kinds of
comments in certain contexts. For example, in Lisp code, comments which
start with two semicolons are indented as if they were lines of code,
instead of at the comment column. Comments which start with three
semicolons are supposed to start at the left margin. Emacs understands
these conventions by indenting a double-semicolon comment using TAB and
by not changing the indentation of a triple-semicolon comment at all.
You have a valid point, though.
single-; comments srarting in column 0 should not be moved and
comment-region would work as advertised!
You opened my eyes!
To All:
Isn't this what we should do?
Martin?
Stephen?
Best regards,
Adrian
Paul> The trouble is, it doesn't work as documented. Here's a sample.
Paul> ;;; header comment
Paul> ;; This function is just an example.
Paul> ;;; Here either two or three semicolons are appropriate.
Paul> (defun foo (x)
Paul> ;;; And now, the first part of the function:
Paul> (lambda (foo bar)
Paul> (if (foo bar)
Paul> 'bif
Paul> 'baz))
Paul> ;; The following line adds one.
Paul> (1+ x)) ; This line adds one.
Paul> ;; This function is just an example.
Paul> ;;; Here either two or three semicolons are appropriate.
Paul> (defun foo (x)
Paul> ;;; And now, the first part of the function:
Paul> ;; The following sexp is commented out using comment-region.
Paul> ; (lambda (foo bar)
Paul> ; (if (foo bar)
Paul> ; 'bif
Paul> ; 'baz))
Paul> ;; The following line adds one.
Paul> (1+ x)) ; This line adds one.
Paul> I get the same indentation using either M-; or C-M-q.
Paul> Testing using xemacs -vanilla on
Paul> XEmacs 21.2 (beta37) "Pan" (win32) of Sun Dec 03 2000 on PAULKRAUSE
Paul> as well as
Paul> XEmacs 21.0 "20 minutes to Nikko" (win32) of Fri Mar 26 1999 on
Paul> BLACKBIRD
Paul> (which I just happen to have lying around)
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/

Hi,
If "xemacs -vanilla" (21.5-b11 or 21.4.12) is run with the following X
resources set:
XEmacs.default.attributeForeground: white
XEmacs.default.attributeBackground: midnightblue
You see all sorts of display cruft along the outer edges of the frame.
Random grey lines appear frequently when listing completions and
aborting out of completion listing commands. For example,
C-x C-f <space>
results in a grey line drawn along the bottommost pixel or two of the
frame (under the minibuffer). If I then do:
C-g
I'm left with a short vertical grey bar along the left edge of the
frame where the modeline was for the split window when showing
completions. This is not completely deterministic, sometimes
everything is fine, other times the vertical bar extends along the
whole extent of what was the upper window.
If I load a file (C-x C-f) and then kill the buffer (C-x k <RET>) then
the entire left edge of the frame has a two pixel wide vertical grey
line. C-l clears it.
I can send screenshots if anyone is interested.
The bug does not appear in 21.4.6 (as distributed with RH 7.3).
The problems show whether or not the buffers-tab is on or off, though
I suspect has something to do with that code or the code supporting
it.
thanks,
Greg

Hi-
I just built and am running xemacs 21.5b16. I sometimes run it in a tty
(well...putty window on an XP box ssh'd into a Linux box, with no X
display). If I'm running in a shell-mode (`M-x shell') buffer and do a
command like
gnuclient foo
it complains about:
IO Error: Terminal type undefined (or can't access database?), "emacs"
presumably because my TERM envar was set to "emacs". If I try to set it to
"xterm" or some such, then it tries to take over my shell-mode buffer as a
tty and run an xemacs within it (presumably not a separate xemacs process,
but my existing xemacs process thinking that my shell-mode buffer is a tty
that it has to operate within).
Any suggestions on getting this to work? (like it used to with xemacs
21.1.8, and other versions I've used) Or should it be filed somewhere
as a bug?
Thanx,
Scott

How exactly do we handle the NEWS entries for packages? In the old,
pre-package times, I would have liked to announce changes in
`htmlize' between 21.4 and (the hypothetical) 21.5 like this:
* htmlize 1.16 contains many improvements over the version 0.69
shipped with XEmacs 21.4, including:
** A stable API that Lisp code can use to invoke features of htmlize.
(This is what prompted the major version increase. I plan not to
change the API incompatibly without also bumping the major version.)
** Better I18N support under Mule. htmlize can now convert non-ASCII
characters to HTML (Unicode) entities. Alternatively, it allows you
to specify the charset that the resulting HTML will declare using the
META tag.
** Better support for operation under TTY's and better
color-robustness in general -- if a color cannot be resolved to RGB,
it is copied to the resulting HTML intact. (0.69 would throw a
cryptic error.)
** Invisible regions of buffer are ignored during conversion.
** Overlapping faces are merged. This applies both to face lists in
the `face' text property and to multiple faces specified by all
extents overlapping a region. (0.69 completely ignored multiple
faces.)
<!-- [This wouldn't go in XEmacs]
** Some of the GNU Emacs 21 face attributes are now supported.
E.g. strike-through and overline are recognized.
** Emacs 20+ property lists instead of faces are supported as well.
E.g. (put-text-property START END '(:foreground "red")) will be
recognized by `htmlize' when generating the HTML.
-->
* The buffer is untabified before conversion to HTML.
How does this kind of announcement fit into the world of packages?

Please keep the list as a CC, at least. I know about a fair amount of
XEmacs, but for everything I know, there are other developers and
users who know a lot more about it. "Many eyes, shallow bugs."
>>>>> "junq" == junq <junq(a)ihubbell.com> writes:
junq> I'm certainly no authority on mem leaks but this looked too
junq> consistent to me. Anyway I stumbled across this measuring
junq> processes and this one happened to have caught my eye as
junq> unusual.
Well, the problem is that there are memory leaks, and there are stupid
Lisp programs that use unbounded amounts of memory. One thing that
makes me curious is the CPU usage which looks to be about 2-3%. On my
machines (450MHz Pentia) a quiescent XEmacs uses more like 0.2%. I
wonder if there might not be a subprocess or itimer doing evil things.
junq> This has 10 buffers open with small perl scripts, a dir and
junq> some scheme code. I use early a.m. and late p.m. now and
junq> again.
Use C-u M-x (buffer-list) RET to insert the list of all live buffers
in the current buffer, and see if any of them look weird. (Use M-%
SPC #<buf RET C-q RET #<buf RET ! to reformat the list sanely.)
Try M-x list-processes to see if there are any subprocesses that might
be generating junk or using space somehow.
junq> Here's the latest png FWIW. It's about 5 1/2 days worth.
Ah, much more convenient. Thanks for going to the trouble.
junq> I'd be willing but finding the time will be difficult. Is
junq> there anything I can do with the xemacs I have that might
junq> help getting to the bottom?
See above. I'd really like the output of M-x show-memory-usage to
compare to your VSZ, but that function is only available if you
configure with --debug.
junq> I'll try to help if I can. Just not sure I want to get into
junq> compiling the software. (I'm a little afraid to ask) What
junq> dev. env. is required to build it?
1. Usual GCC toolchain.
2. -devel RPMs for all libraries used (X, Motif, GIF, XPM, TIFF,
JPEG, PNG, ncurses, Berkeley DB, LDAP, PostgreSQL, Canna, Wnn).
You can omit the databases, Canna, and Wnn if you don't use them.
You can omit GIF, TIFF, and JPEG, but they're really nice to
have. Don't omit XPM, PNG, or ncurses, they require a certain
amount of expertise to work around likely problems.
3. XEmacs sources.
My guess is that if you get the source RPM from Red Hat, it will
complain if you don't have what it wants. I don't know how to change
the configuration that they've set up, though.
--
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.