April 2001 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Bug (or doc bug) with zero-length extents? 23 years, 7 months

Jan Vroonhof

Michael Toomim <toomim(a)OCF.Berkeley.EDU> writes: > The more recent stable versions of xemacs don't seem to mention any fixes > of this nature. Can anyone verify this on a new release? Is this a true > xemacs bug (or a documentation bug?)? It happens in the recent betas as well. I think the current behavior is a bug because there is no way let the extent behave the way you want otherwise. Jan

1 participants
0 comments

Re: Bug (or doc bug) with zero-length extents? 23 years, 7 months

Andy Piper

You might want to check with Kyle onthis. I know there was a zero-length extent bug. andy At 11:23 PM 4/3/01 -0700, Michael Toomim wrote: >;;; Note: I posted the following message a couple of days ago, but had an >;;; invalid return address and so haven't recieved a reply. My apologies >;;; go out to anyone who had mailed me an answer in vain! > >I have noticed xemacs' behaviour to be inconsistent with the >documentation, when inserting text onto certain zero-length extents. > >According to the info xemacs lisp reference and comments in extents.c, >insertion at a zero-length extent with the properties start-open and >end-closed (like the extent (5, 5]) should go before the extent: > >---- >extents.c: > "Insertion at the position of a zero-length extent ... goes before the > extent if it is open-closed." > >Info - extent endpoints: > "Insertion at the position of a zero-length extent ... goes before the > extent if it has the `start-open' property " >---- > >Thus, for the above extent, if one inserts the text "###" at position 5 in >the buffer, the documentation implies that the extent would change to >(8, 8]. This doesn't happen. With xemacs version 21.1, patches 12 and 9, >the extent instead expands to include the inserted text (like the extent >[5, 5] does) -- causing the extent to change to (5, 8]. > >The following e-lisp code, according to the documentation, should insert >"1234###56789" into the buffer, un-colored, with a zero-length extent >before the 5. Instead, it creates an extent covering the "###", making >those characters green. > >(save-excursion > (goto-char 1) > (insert "123456789\n") > (let ((ext (make-extent 5 5))) > (set-extent-properties ext '(start-open t > end-closed t > face green)) > (goto-char 5) > (insert "###") > (message "The extent is now %S" ext))) > >The more recent stable versions of xemacs don't seem to mention any fixes >of this nature. Can anyone verify this on a new release? Is this a true >xemacs bug (or a documentation bug?)? > > >Thank you, > >Michael Toomim

1 participants
0 comments

test, please ignore. 23 years, 7 months

Didier Verna

My messages don't make it anymore to xemacs-review. Is it the same for xemacs-beta ? -- Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier(a)xemacs.org

1 participants
0 comments

Re: 21.2.46 stuck 23 years, 7 months

Raymond Toy

>>>>> "Andy" == Andy Piper <andyp(a)bea.com> writes: Andy> At 06:19 PM 3/30/01 -0500, Raymond Toy wrote: >> >>>>> "Andy" == Andy Piper <andyp(a)bea.com> writes: >> Andy> So we've seen variations of this bug for a while. I though Andy> originally it was the colormap code, but this proves Andy> otherwise. Now I look I notice you are using X11R4. Maybe >> >> How did you figure that? It's compiled using Sun's X on Solaris 2.7 >> which is X11R 5 or 6, I think. Andy> From the .4 on the .so version. May you are dynamically Andy> linking against the wrong version. ls /usr/openwin/lib/libXt* only gives the .4 version. So Sun is *still* using R4? However, I do have X11R6 here, so I guess I can recompile/link with that (and Lesstif). >> Which display, colormap or color are you talking about? The process >> is still running, so I can attach and print out stuff. Andy> From x_generate_shadow_pixels Sorry! My windowmanager (sawfish) also got stuck a few hours later and I had to kill my session. That info is gone. If it should happen again, I'll try to get that info out. Ray

2 participants
1 comments

--rel-alloc annoyance 23 years, 7 months

Steve Youngs

I built XEmacs last night with the following subset of configure options: --with-athena=next --with-scrollbars=athena --rel-alloc It built fine, but the scrollbars didn't display properly. Either they wouldn't display at all, or they would, only to disappear as soon as the scrollbar was moved. Re-configuring, omitting '--rel-alloc', fixed my scrollbars. -- |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------<youngs(a)xemacs.org>---|

1 participants
0 comments

Prelimary fix for display-time/text-glyph crash 23 years, 7 months

Jan Vroonhof

For all those seeing the gnuclient+display-time on tty or any other crach with crashes in compact_string_chars, please try out this patch.. Index: redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.69 diff -u -u -r1.55.2.69 redisplay.c --- redisplay.c 2001/03/09 04:13:25 1.55.2.69 +++ redisplay.c 2001/03/31 23:07:26 ＠＠ -972,6 +972,8 ＠＠ for (pos = c_string; pos < end;) { + Bufbyte *old_pos = pos; + data->ch = charptr_emchar (pos); prop = add_emchar_rune (data); ＠＠ -997,6 +999,9 ＠＠ } INC_CHARPTR (pos); assert (pos <= end); + /* Duplicate code from add_string_to_fstring_db_runes + should be do more?*/ + data->bytepos += pos - old_pos; } return NULL;

6 participants
5 comments

This is a coup 23 years, 7 months

SL Baur

Listen up people. I've already killed Ben Wing and Martin Buchholz and I'm holding Jareth Hein, Stephen Turnbull and a dozen lovelies from the Philippines who work in the Kabukicho section of Shinjuku hostage. I have a fully loaded AK-47[1] and I'm not afraid to use it. My demands are as follows: To everyone on xemacs-review, you are fired. I made a mistake creating the review board in the first place. I'm in command now. I want 100 million yen left in the locker numbered 23 outside of JR Shinjuku station. Please also put the source code to InfoDock with the money. I will release the hostages if the executive board of Sumitomo Bank are delivered handcuffed and horse-whipped to replace them. I want safe passage to Manilla. Please await further instructions after the money is delivered. Happy April 1st people, but don't take too long, O.K.? Let's all hope no one else gets hurt. Footnotes: [1] As was eloquently stated in the movie _Jackie Brown_, "when you absolutely, positively have to kill every m***** f***** in the room, accept no substitutes."

4 participants
3 comments

C-k takes for ever 23 years, 7 months

eric dahlman

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta43) "Terspichore" [Lucid] (sparc-sun-solaris2.8) of Wed Jan 31 2001 on sibelius configured using `configure --prefix=/s/chopin/d/proj/meps/common' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I am running a remote display from a Solaris box onto a Linux (Redhat 7.0) box at home. This is going over a dsl line which is very responsive. I have no problems with scrolling or redisplay. However, pressing C-k to kill a line will result in about 4 seconds of blinking lights on the DSL modem during which time xemacs is unresponsive. This also works when using C-w to kill the current region. This happens with -vanilla. I tired version 21.1.14 and it did not have this behavior. That is C-k was responsive and there was not a mess of network traffic associated with it. Thanks, -Eric Recent keystrokes: misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user up prior SPC n SPC q up up up up up up up up up RET c y q y C-x e M-x r e p TAB o TAB r TAB RET Recent messages (most recent first): Loading emacsbug...done Loading emacsbug... Making completion list... Making completion list... No kbd macro has been defined Saving /s/chopin/a/grad/dahlman/.newsrc-news.eld...done Wrote /s/chopin/a/grad/dahlman/.newsrc-news.eld Saving /s/chopin/a/grad/dahlman/.newsrc-news.eld... Wrote /s/chopin/a/grad/dahlman/.newsrc-news Are you sure you want to quit reading news? (y or n) Yes

3 participants
2 comments

Re: Another solution to the hashtable problem? 23 years, 7 months

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > Executive summary: I withdraw previous recent patches for elhash.c, > and propose that all hash table mapping functions operate on copies of > the hash table, partly in response to Jan's and Hrvoje's analysis. I agree, provide of course you it in the only-mild-consing way you proposed. Jan

1 participants
0 comments

Forgot to cut the copyright line 23 years, 7 months

Matthew O. Persico

Someone posted a piece of code last week that changes the modeline for all non-occupied frames to another color as the cursor moves around. The code works great, but I'd like to make one change. I can't get it to work and I didn't cut and paste the header so I don't have the person's address. And, I cannot find any evidence of posting in the nt and beta lists at xemacs-org to which I am subscribed. The change I'd like to make is to NOT modify any modelines if the cursor is switched to the ' *minibuf-0*'; The original section of code looked like this: (unless (eq current-window modeline-last-window) (when modeline-last-window I thought this would work: (unless (or (eq " *Minibuf-0*" 'buffer_name) (eq current-window modeline-last-window) ) (when modeline-last-window but it does not. Can the original author or anyone else step forward and give me a hand here. Thank you -- Matthew O. Persico http://www.acecape.com/dsl AceDSL:The best ADSL in Verizon area

4 participants
4 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta April 2001