September 2000 - XEmacs-Beta - XEmacs Mailing List Archives

[EXP] Getting the pixel position of a window point 24 years, 2 months

Darryl Okahata

[ This is experimental, and thus is not (yet) being submitted to xemacs-patches. ] Here's an experimental patch for 21.2 that provides a way of getting the window pixel co-ordinates of a window point. I found that the function, "current-pixel-column", already existed, and so I just added the corresponding function, "current-pixel-row". However, there's a big "gotcha" (issue) with these functions: they both use the redisplay tables to determine the pixel position. This basically means that a screen update/refresh must be done (e.g., "(sit-for 0)") before these functions will return correct values. For newly-created frames, you have to do something like this instead: ;; idea stolen from set-mouse-position (while (not (frame-visible-p frame)) (sleep-for .5)) Unfortunately, there doesn't seem to be a better way. Jonathan Harris <jhar(a)tardis.ed.ac.uk> suggested the use of "glyph_to_pixel_translation()". The problem with this is that you need to provide the desired row and column, and there's no easy way to get the row/column of a window point. Also, glyph_to_pixel_translation() still depends on the redisplay tables being up-to-date. Because of all this, I decided to simply extend "current-pixel-column". Comments? I'll send a patch to xemacs-patches if I don't hear anything. -- Darryl Okahata darrylo(a)soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day.

2 participants
1 comments

Re: More gtk-xemacs fun [was: Minor problems w/gtk-xemacs build] 24 years, 2 months

William M. Perry

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > More gtk-xemacs fun. Only a native Pervect would try this, so I'm not > surprised it failed: > > **** > bash-2.04$ src/xemacs -batch -l /coda/Projects/XEmacs/gtk-xemacs/tests/gtk/gtk-test.el -eval '(gtk-test)' & > [3] 17852 > bash-2.04$ Loading /coda/Projects/XEmacs/gtk-xemacs/tests/gtk/gnome-test.el... > GLib-CRITICAL **: file ghash.c: line 138 (g_hash_table_lookup): assertion `hash_table != NULL' failed. > > /** error msg repeated 13 times, alternating between l 138 ..._lookup > and l 152 ..._insert **/ Just fixed this... gtk-init is now exposed to lisp (and is a noop if it is called more than once). So you can create a gtk app in batch or TTY mode. The only oddity is that you cannot use XEmacs glyphs as GdkPixmap or GdkBitmap types (TTY/batch mode has no glyph converters). I will check this code in when I get home late tonight. > **** > bash-2.04$ src/xemacs -l /coda/Projects/XEmacs/gtk-xemacs/tests/gtk/gtk-test.el -funcall gtk-test > **** > > apparently ignores the -funcall (on second check, there are two messages > indicating successful load of gnome-test.el followed by one about > `Unknown argument type: "GtkAdjustment"' in *Message-Log*), but happily > runs the test interactively from the gtk-xemacs frame. Strange... I think this is fixed with the changes I have here. There is a chicken & egg problem with creating a scrolled window and expect it to have default adjustments. Because gtk_adjustment_new has not been called, the type is not registered with the object system, so it screams when I try to convert 'nil' to an unknown type. *sigh* I work around this by just creating & destroying a GtkAdjustment before I call anything else in the test code. -Bill P.

2 participants
1 comments

Re: New file for edit-utils (vertical-mode.el) 24 years, 2 months

Steve Youngs

* Steve Youngs <youngs(a)xemacs.org> writes: > I'm planning on adding vertical-mode.el to edit-utils, but before I > do, I'd like some people to test it. (It runs fine here, but I'd be > happier if someone else told me it's ok). > So it's in ftp.xemacs.org/pub/xemacs/beta/experimental/ > Please let me know how it goes. Forgot to mention... ,---- | ;;; Commentary: | | ; This minor mode allows you to conviently edit things that are oriented vertically | ; (like tables in computer programs): after each action, cursor moves down. Therefore, | ; to move block of text to the right, you simply enter vertical mode and then hold | ; spacebar, waiting for autorepeat to do the job for you. `---- -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: EFD82ED2]---| | XEmacs - It's not just an editor... | | It's a way of life. | |----------------------------------<mailto:youngs＠xemacs.org>---|

1 participants
0 comments

Re: Syntax-table text properties 24 years, 2 months

Hrvoje Niksic

--- Matt Tucker <tuck(a)whistlingfish.net> wrote: > Perhaps I'm confused. I can use the get-text-property and > put-text-property defuns to apply "text properties" to a character. > Are these handled as extents under XEmacs? And would it then > be possible to apply one of these to a range of characters? In XEmacs, text properties are just a fancy way of interfacing to extents. This means that when you "apply one of these to a range of characters", the `put-text-property' code defines an extent behind the scenes. When you create two such regions that touch, the code notices it and merges the two adjacent extents. And so on. All of this code is implemented in Lisp (some stuff was converted to C for speed, though). Therefore, at Lisp level, you can use both interfaces (textprops have been provided as a convenience as well as a porting help). However, to in order to add a new low-level feature, it only makes sense to add it to the C implementation of extents. Extents, as well as text properties, are described in the XEmacs Lisp reference manual (Lispref) in depth. > That's the impression I get from what you were saying, but I must > confess that while I was aware of the concept of extents (Emacs has > them as well, in fact), GNU Emacs has overlays, which are a parallel implementation of the same or very similar feature. Under XEmacs, text properties are implemented using extents. This is not the case with GNU Emacs. > I'll definitely look into this. I hadn't realized that overlaps were > a possibility. With GNU Emacs text properties, they're not. But in XEmacs, it's a bit different. I just wanted to remind you of the option. > So I'd noticed. :) Case-in-point: Emacs does not contain the > syntactically-sectionize function, and in fact does most of the > fontification work in lisp rather than C. Yup. But I don't think syntactically-sectionize and friends in font-lock.c will be a problem to modify; they merely handle strings and comments anyway. The real beef is in the engine behind parse-partial-sexp. > My plan is to leave this structure mostly alone and simply modify it > to support the syntax-table property, as well as adding the necessary > support to syntax.c. Right now I'm doing the lookup for each > character, but I suspect by the time I'm done that I'll have mimicked > Emacs' caching mechanism in the interests of speed. I'm not sure what caching mechanisms Emacs uses. It might well show that different optimization strategies will apply to XEmacs, due to a vastly different extents code. I have a feeling that under XEmacs it is much more expensive to search for an extent on a char-by-char bases, due to them being stored as a list, whereas under GNU Emacs, properties are a balanced tree. > I've been much happier with the XEmacs product over GNU's offering > ever since I switched (for a number of reasons, not the least of which > is better appearance and implementation of GUI concepts), and I'm > really looking forward to finally getting rid of this one major thorn. Thanks. I wish you the best of luck. Then I might look into Tcl mode and making it suck less. :-) __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

1 participants
0 comments

Re: Syntax-table text properties 24 years, 2 months

Hrvoje Niksic

I've now noticed your message regarding the syntax-table text properties. I believe adding this feature to XEmacs would be very worthwhile, and a correct patch that implements this would certainly be accepted by the maintainers. I myself considered adding this, but never got around to it, partly due to my not being familiar with Emacs syntax engine. As a former Perl hacker, I've often been extremely annoyed at XEmacs' inability to comprehend the finer points of Perl syntax. Note however that, under the hood, XEmacs is quite different from GNU Emacs. Specifically, there are no "text properties" in XEmacs, but "extents". You would need to implement a `syntax-table' extent property and make the code in syntax.c respect it. You might want to introduce some optimizations to make this efficient (repeated querying for extents from within syntax.c could be slow), but it's probably to early to talk about that. As XEmacs text-property implementation is in fact based on extents, everything you implement for extents would automatically reflect the text properties, so you don't need to worry about modifying Perl mode at this point. You would also need to consider what happens when two overlapping extents both have syntax-table properties define. You might want to consider implementing a cascading scheme, so that e.g. the inner extent takes precedence over the outer one, or you might declare such overlappings undefined, if you think it's an overkill. Also note that syntax engine implementation in XEmacs is probably different from the GNU Emacs one. You might want to sync it with the latest one in GNU Emacs, while being careful not to break XEmacs in the process. Syncing is often tricky. All in all, I don't want to give an impression that I'm trying to discourage you. In most places, XEmacs is very well written, and adding new features is more of a challenge than just boring typing. I hope that you will decide to undertake implementing this feature. You have my support. __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

2 participants
1 comments

Re: yank-pop behavior different under XEmacs-21.2-b35 24 years, 2 months

Mark Thomas

Of course, five seconds after I post I find the solution: set the interprogram-cut-function to nil. In order to destroy Windows, we have to become Windows. Joy and happiness! -Mark _________________________________________________________ Do You Yahoo!? Get your free ＠yahoo.com address at http://mail.yahoo.com

1 participants
0 comments

yank-pop behavior is different in 21.2.b35 24 years, 2 months

Mark Thomas

In XEmacs 21.2 (beta35) "Nike" [Lucid] (i686-pc-linux, Mule) of Fri Sep 22 2000 on swoon.home configured using `configure --prefix=/home/swoon --with-mule --with-pop' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I think sometime between 21.2-b31 and 21.2-b35 the behavior of yank-pop changed: my 21.2-b31 is built without MULE support and exhibits the "old" behavior; my 21.2-b35 (built after a CVS update around 10am EDT today) is built with MULE and exhibits this "new" behavior. The behavior I see is that after pressing C-y (yank) I need to press M-y (yank-pop) several times to get the previous entry in the kill ring. In the "Recent keystrokes" section below, I had to type M-y twice to get the previous entry. If I do two yanks (C-y C-y), then I need to press M-y three times to get the previous entry. >From looking at the variable kill-ring, what is happening is that issuing a yank is putting the yanked text on the kill ring again. I don't know if this is intentional or a bug; I do not see any mention of it in the NEWS file, in the XEmacs-beta archives, or in the XEmacs bug database. This behavior seems wrong, but if it is a design decision, please clearly document it for all us old-timers (or better yet, give us a variable to return to the old behavior). Thanks, -Mark foo bar Recent keystrokes: C-h c M-y f o o RET RET b a r RET RET up up C-k C-k up up C-k C-k RET C-y M-y M-y RET RET M-x s u b m TAB BS BS BS BS r e p TAB o t BS r t - e m TAB RET _________________________________________________________ Do You Yahoo!? Get your free ＠yahoo.com address at http://mail.yahoo.com

1 participants
0 comments

New file for edit-utils (vertical-mode.el) 24 years, 2 months

Steve Youngs

I'm planning on adding vertical-mode.el to edit-utils, but before I do, I'd like some people to test it. (It runs fine here, but I'd be happier if someone else told me it's ok). So it's in ftp.xemacs.org/pub/xemacs/beta/experimental/ Please let me know how it goes. -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: EFD82ED2]---| | XEmacs - It's not just an editor... | | It's a way of life. | |----------------------------------<mailto:youngs＠xemacs.org>---|

1 participants
0 comments

xemacs lies to my window manager 24 years, 2 months

Giacomo Boffi

i use gwm, afaict a good behavioured window manager, maybe a little picky in its interaction with applications... some times ago, i complained that the 1st frame that XEmacs mapped to the display had to be remapped by the window manager to got the right dimensions (definition of right: i use my wm to have appropriately sized and properly stacked XEmacs frames) now the situation has gotten worse XEmacs now *lies* to the window manager, that now is unable to get the window to the right size when remapping it, and is addirittura, what's the english word... well, if i resize explicitly the 1st frame using the mouse, there is a discrepancy between the meter displayed by the window manager and the actual size of the window all the subsequent windows are _normal_, and the only cure i devised is killing the 1st frame (rather inelegant, though) ciao ps: what about the bold/italic face bug???

1 participants
0 comments

Xemacs Crashed 24 years, 2 months

Henry Crutcher

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 (beta35) "Nike" [Lucid] (i686-pc-linux) of Wed Sep 20 2000 on harmonic configured using `configure --error-checking=none --memory-usage-stats' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I was hitting tab to complete a filename and the whole Xemacs crashed. The installation information and backtrace are below.... #0 0x40333d41 in __kill () from /lib/libc.so.6 #1 0x80a9453 in fatal_error_signal (sig=11) at emacs.c:514 #2 0x40333c68 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #3 0x810d54f in image_instance_parent_glyph (ii=0x879ea98) at glyphs.c:1343 #4 0x8105e82 in mark_image_instance (obj=142207640) at glyphs.c:784 #5 0x80851e0 in mark_object (obj=142207640) at alloc.c:2500 #6 0x808544c in mark_cons (obj=143640460) at alloc.c:877 #7 0x80851e0 in mark_object (obj=143640460) at alloc.c:2500 #8 0x80cda12 in mark_widget_value_mapper (val=0x8862fe8, closure=0x0) at gui-x.c:70 #9 0x8195b14 in lw_map_widget_values (id=65934, mapfunc=0x80cd9f8 <mark_widget_value_mapper>, closure=0x0) at lwlib.c:446 #10 0x80cd991 in mark_popup_data (obj=143695416) at gui-x.c:90 #11 0x80851e0 in mark_object (obj=143640448) at alloc.c:2500 #12 0x808544c in mark_cons (obj=143640436) at alloc.c:877 #13 0x808282f in garbage_collect_1 () at alloc.c:2500 #14 0x80afa0b in Ffuncall (nargs=1, args=0xbfffe084) at eval.c:3163 #15 0x80b0d0f in run_hook_with_args_in_buffer (buf=0x824ff90, nargs=1, args=0xbfffe084, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3702 #16 0x80b3f71 in run_hook_with_args (nargs=1, args=0xbfffe084, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3715 #17 0x80b5d8d in catch_them_squirmers_run_hook (hook_symbol=136463028) at eval.c:3569 #18 0x80b1632 in safe_run_hook_trapping_errors ( warning_string=0x81b2ac0 "Error in `pre-idle-hook' (setting hook to nil)", hook_symbol=136463028, allow_quit=1) at eval.c:1640 #19 0x80d9e1c in run_pre_idle_hook () at event-stream.c:2014 #20 0x80da217 in Fnext_event (event=142730664, prompt=136373300) at event-stream.c:2181 #21 0x80940da in Fcommand_loop_1 () at cmdloop.c:570 #22 0x8094365 in command_loop_1 (dummy=136373300) at cmdloop.c:494 #23 0x80b4baf in condition_case_1 (handlers=136373396, bfun=0x809434c <command_loop_1>, barg=136373300, hfun=0x80943d8 <cmd_error>, harg=136373300) at eval.c:1640 #24 0x809432f in call_command_loop (catch_errors=136373324) at cmdloop.c:256 #25 0x8133a2e in Fread_minibuffer_internal (prompt=139867356) at minibuf.c:188 #26 0x80afbf8 in Ffuncall (nargs=2, args=0xbfffe584) at eval.c:3214 #27 0x808c5c7 in execute_optimized_program ( program=0xbfffe5d0 "À Á V«\013Â\211\e\034Å\016\006!*\207Å\016\006!\207", stack_depth=2, constants_data=0x833ef60) at bytecode.c:745 #28 0x808e481 in Fbyte_code (instructions=137560492, constants=137621328, stack_depth=5) at bytecode.c:2402 #29 0x80af2a9 in Feval (form=137612044) at eval.c:3014 #30 0x80b4a7c in internal_catch (tag=136459204, func=0x80aebf4 <Feval>, arg=137612044, threw=0x0) at eval.c:1306 #31 0x808ce4d in execute_rare_opcode (stack_ptr=0xbfffe868, program_ptr=0x8810e8e "èa«\f\201J", opcode=Bcatch) at bytecode.c:1251 #32 0x808c45b in execute_optimized_program ( program=0x8810d18 "\b¬\022Á ÂV«\fÃ Ä a«\005ÅÆ!\210\016\a«\021\016\aÂV«\013Á \016\aY«\004È \210\016\t«\"\016\t9«\017Ê\016\t!¬\027ÅË\016\t\"\210ª\017Ê\016\t＠!¬\bÅË\016\t＠\"\210Ì «\tÍÎÏ\016\020!\"\210\016\021\036\022Ã \036\023Ô \036\025Ä \036\026Á Âa«\a×\016\026!ª\bØÙÚÁ \"!\036\eÜ\016\026!\211\036\035Ô a?\005Þ\016\035!\036\037Þ \036 \016\t\036!\016\"\036#ä\216å\016\e!q\210\016\022\026\021æç!\210è\026'æé!\210æê!\210æë!\210ì\026)í\026*\016.«\025æï"..., stack_depth=6, constants_data=0x833f010) at bytecode.c:655 #33 0x808c2d7 in funcall_compiled_function (fun=137542636, nargs=7, args=0xbfffe9a8) at bytecode.c:514 #34 0x80afdb4 in Ffuncall (nargs=8, args=0xbfffe9a4) at eval.c:3249 #35 0x808c5c7 in execute_optimized_program ( program=0x8810c18 "\b¬\003\t\020Â\bÃ\"\020\f¬\a\r¬\004Æª\021\r«\013Ç\b\rP!\bGBª\004Ç\b!\036\b\016\t\b\016\nÃa?\002ÃË\036\f\036\r\036\016\036\017Ð\016\021\016\b\016\n¬\005\016\022ª\003\016\023Ë\016\024Ë\016\025&\a,\211\036\026¬\006×Ø!ª\036\016\025«\026\016\026\016\b:«\006\016\b＠ª\003\016\bk«\005\016\025ª\005Ù\016\026!*\207", stack_depth=9, constants_data=0x8341400) at bytecode.c:745 #36 0x808c2d7 in funcall_compiled_function (fun=137543756, nargs=7, args=0xbfffeaf8) at bytecode.c:514 #37 0x80afdb4 in Ffuncall (nargs=8, args=0xbfffeaf4) at eval.c:3249 #38 0x808c5c7 in execute_optimized_program ( program=0x8810b00 "À «\017Á\n\013\f\r\016\006\016\a\016\b&\a\207ÉÊË\"\210Ì\n\013\f\r\016\006\016\a\016\b&\a\207", stack_depth=8, constants_data=0x8341578) at bytecode.c:745 #39 0x808c2d7 in funcall_compiled_function (fun=137543868, nargs=7, args=0xbfffec48) at bytecode.c:514 #40 0x80afdb4 in Ffuncall (nargs=8, args=0xbfffec44) at eval.c:3249 #41 0x808c5c7 in execute_optimized_program ( program=0x8515e50 "À\t®\002Â\013\f\r®\030\016\006«\013ÇÈ\016\006\f\"É\"®\n\016\n\006Ç\016\013É\"\016\f\016\006Í&\a\207", stack_depth=8, constants_data=0x83415c0) at bytecode.c:745 #42 0x808c2d7 in funcall_compiled_function (fun=137631236, nargs=4, args=0xbfffedac) at bytecode.c:514 #43 0x80afdb4 in Ffuncall (nargs=5, args=0xbfffeda8) at eval.c:3249 #44 0x80b41a3 in call4 (fn=136443836, arg0=139867356, arg1=136373300, arg2=136373300, arg3=136373300) at eval.c:3917 #45 0x808f9ec in Fcall_interactively (function=137101956, record_flag=136373300, keys=136373300) at callint.c:704 #46 0x80ae88e in Fcommand_execute (cmd=137101956, record=136373300, keys=136373300) at eval.c:2652 #47 0x80dc535 in execute_command_event (command_builder=0x8437030, event=142730780) at event-stream.c:3838 #48 0x80dcaf1 in Fdispatch_event (event=142730780) at event-stream.c:4205 #49 0x80940f0 in Fcommand_loop_1 () at cmdloop.c:579 #45 0x808f9ec in Fcall_interactively (function=137101956, record_flag=136373300, keys=136373300) at callint.c:704 #46 0x80ae88e in Fcommand_execute (cmd=137101956, record=136373300, keys=136373300) at eval.c:2652 #47 0x80dc535 in execute_command_event (command_builder=0x8437030, event=142730780) at event-stream.c:3838 #48 0x80dcaf1 in Fdispatch_event (event=142730780) at event-stream.c:4205 #49 0x80940f0 in Fcommand_loop_1 () at cmdloop.c:579 ---Type <return> to continue, or q <return> to quit--- #50 0x8094365 in command_loop_1 (dummy=136373300) at cmdloop.c:494 #51 0x80b4baf in condition_case_1 (handlers=136373396, bfun=0x809434c <command_loop_1>, barg=136373300, hfun=0x80943d8 <cmd_error>, harg=136373300) at eval.c:1640 #52 0x80944c7 in command_loop_2 (dummy=136373300) at cmdloop.c:256 #53 0x80b4a7c in internal_catch (tag=136445060, func=0x809448c <command_loop_2>, arg=136373300, threw=0x0) at eval.c:1306 #54 0x8093dfe in initial_command_loop (load_me=136373300) at cmdloop.c:305 #55 0x80aa294 in sort_args (argc=2, argv=0xbffff3b4) at emacs.c:2155 #56 0x80abf39 in main () at emacs.c:2584 #57 0x4032d9cb in __libc_start_main (main=0x80abe3c <main>, argc=2, argv=0xbffff3b4, init=0x807d2cc <_init>, fini=0x81a4bac <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff3ac) at ../sysdeps/generic/libc-start.c:92 Installation-information uname -a: Linux harmonic 2.2.14 #3 SMP Wed Jun 21 09:13:44 EDT 2000 i686 unknown ./configure '--error-checking=none' '--memory-usage-stats' XEmacs 21.2-b35 "Nike" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /tmp/xem/xemacs-21.2.35 Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. The information below was added by this instance of xemacs, which is obiously not the one which crashed. Thanks, Henry 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 misc-user misc-user misc-user misc-user misc-user button1 button1up button3 button3up right right right right right right right right right right right down down down down down down down down down down RET misc-user Recent messages (most recent first): Loading efs-cu... Loading gnus-util...done Loading gnus-util... Loading mail-abbrevs...done Loading mail-abbrevs... Loading mail-extr...done Loading mail-extr... Loading message...done Loading message... Loading emacsbug...done

2 participants
1 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 September 2000