November 1998 - XEmacs-Beta - XEmacs Mailing List Archives

[comp.emacs.xemacs] BUG: 20.4 fails to report timestamp of X selection 25 years, 5 months

Hrvoje Niksic

Any comments on this? To me it's not obvious what code should be added to x_own_selection() to fix the bug. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A sadist is a masochist who follows the Golden Rule. ------- Start of forwarded message ------- Message-ID: <199811101141.MAA19689(a)takefive.co.at> Mime-Version: 1.0 (NeXT Mail 4.1mach v148) Content-Type: text/enriched; charset=us-ascii Content-Transfer-Encoding: 7bit From: joe(a)takefive.co.at (Joe Leherbauer) Date: Tue, 10 Nov 1998 12:41:08 +0100 Subject: BUG: 20.4 fails to report timestamp of X selection Newsgroups: comp.emacs.xemacs I'm using a plain xemacs-20.4 sparc-sun-solaris2.4 binary kit downloaded via ftp on a Solaris 2.5 machine. I select some text and copy-region-as-kill. xemacs becomes the owner of the X11 PRIMARY selection. When my own X application queries the timestamp of that selection, xemacs signals an error like this: unrecognized selection-conversion type: nil, #<<INTERNAL EMACS BUG (opaque, size=4) 0x5d5e80> The same happens with the CLIPBOARD selection. Scanning through file src/xselect.c I found the following which might be the reason (my own comments start with JL): .. static void x_own_selection (Lisp_Object selection_name, Lisp_Object selection_value) { ... Time thyme = DEVICE_X_MOUSE_TIMESTAMP (d); ... /* Now update the local cache */ { /* We do NOT use time_to_lisp() here any more, like we used to. That assumed equivalence of time_t and Time, which is not necessarily the case (e.g. under OSF on the Alphas, where Time is a 64-bit quantity and time_t is a 32-bit quantity). Opaque pointers are the clean way to go here. */ Lisp_Object selection_time = make_opaque (sizeof (thyme), (void *) &thyme); JL: As the comment indicates a change has been made here. An opaque value is now used instead of time_to_lisp() (which I guess returns an integer ?) I think the maintainer forgot to update function x_get_local_selection not far below which uses that selection_time. <nofill> .. static Lisp_Object x_get_local_selection (Lisp_Object selection_symbol, Lisp_Object target_type) { ... /* TIMESTAMP and MULTIPLE are special cases 'cause that's easiest. */ if (EQ (target_type, QTIMESTAMP)) { handler_fn = Qnil; value = XCAR (XCDR (XCDR (local_value))); } JL: At this point `value' holds the selection time, the opaque type from above. Later in that function `value' is checked against several common types, but not whether it's an opaque type. So `x_get_local_selection' fails and signals an error. --- Josef Leherbauer TakeFive Software GmbH Software Engineer Jakob-Haringer-Str. 8 A-5020 Salzburg/Austria joe(a)takefive.co.at Tel +43 662 457 915 0 http://www.takefive.com/ Fax +43 662 457 915 6 The Source Code Engineering Company </nofill> ------- End of forwarded message -------

1 participants
0 comments

Re: Toolbar icons package 25 years, 5 months

Jan Vroonhof

Sean MacLennan <seanm(a)storm.ca> writes: > However, I had to change the data directory from "toolbar-color" to > "toolbar-fancy" to work with the package. > > (defun init-fancy-toolbar (type) > (toolbar-add-item-data (symbol-value > (plist-get fancy-toolbar-lists-plist type)) > (locate-data-directory "toolbar-fancy")) Oops. I renamed the package at the last moment. Sorry (I still have a toolbar-color dir lying around)/ > You might also want to mention that there are no captioned versions > for 'next and nil. As 'nil' is just the normal icons there should be captioned versions of that. > The following line fixes that: > > (set-specifier toolbar-buttons-captioned-p nil) I was rather hoping somebody would get 'xpaint/gimp' etc out and paint some captioned versions for me! The toolbar claims to fallback to non captioned versions if not available but for some reasons this isn't happening. Jan

1 participants
0 comments

Toolbar icons package 25 years, 5 months

Jan Vroonhof

As an experiment I tried packaging up the various Toolbar icons available on the net. http://www.math.ethz.ch/~vroonhof/emacs/packages/toolbar-fancy-0.01-pkg.t... http://www.math.ethz.ch/~vroonhof/emacs/packages/toolbar-fancy-0.01-src.t... Please comment on the src package. I hacked 'XEmacs.rules' and the makefile so it builds locally. This NOT for inclusion in ftp.xemacs.org/pub/xemacs/packages (I can be stuffed in the beta dir though). Jan

2 participants
1 comments

Re: [Bug foound/Suggested Solution] Suspending on linux Console and lingpm 25 years, 5 months

Jan Vroonhof

Glynn Clements <glynn(a)sensei.co.uk> writes: > > > -D_USE_BSD?) > > > > Could it be that for some reason using this flag in the application > > breaks the library too? > > Well, it won't cause libgpm to start using BSD signal semantics. > However, libgpm reinstalls the old handler with signal(), which may > not be the same version of signal() that the handler was designed to However in XEmacs case this handler is SIG_DFL. Is this also specialcased in the libc5 include files? I.e. is there a sysv SIG_DFL and a BSD SIG_DFL? This problem is also solved by using sigaction right? Jan

2 participants
1 comments

cus-dep.el broken 25 years, 5 months

Jan Vroonhof

cus-dep.el tries to be smart and only evaluates the defcustoms, defgroups, etc in the files it loads however. If the defcustom contains a :set function that is defined locally this breaks. cus-dep.el does not evaluate the defun and therefore the function is undefined when the defcustom is evaluated. cus-dep should either just 'load' the file or redefine custom-add-variable and friends to not try to call the functions. Jan

1 participants
0 comments

Re: [Bug foound/Suggested Solution] Suspending on linux Console and lingpm 25 years, 5 months

Jan Vroonhof

Ian T Zimmerman <itz(a)rahul.net> writes: > No it won't, not on my system (ix86, kernel 2.0.35, libc 5.4.44). Do > you use glibc? Yes I do. However we have been seeing these bug reports for quite some time now on XEmacs. I guess even before the big move towards glibc2. So there must be something else happening too (or my recollection is wrong/all these bug reports were from glibc early adopters). So like I commented the code was written for a different signal behaviour and you think this changed during the libc5->libc6 change over. > That may be the root of the trouble. Otherwise I'd > suspect the way you have compiled libgpm (maybe you added > -D_USE_BSD?) I am fairly sure some versions ago XEmacs used those flags on Linux. Could it be that for some reason using this flag in the application breaks the library too? I am not at my linux system so I cannot check what the mechanism is. > > Note. Signal handlers installed with 'signal' are called with the > > signal that generated them blocked. It is then unblocked on exiting > > the signal handler. > > > > No. Under ix86 Linux up to and including 2.0 (don't know about 2.1, > but I am not sure but I am fairly certain that on every glibc6 system (and there are quite a few now) the signal() behaviour is now as I described and therefore libgpm is broken there. I was confused in thinking this was universal because the Solaris 2.x 'signal' manpage also decribes the 'bsd' behaviour. > I won't be fixing gpm to be compatible with a development kernel), All the bug reports we had were from people running stable Kernels. So at the very least you would have to deal with 2.0.x+glibc2. > > Here the signal handler exits. The SIGTSTP handler is unblocked and > > any queued signals are sent including the one we sent > > outselves. Bingo! we now have a sinal loop. The process will hang > > sucking up 100% of CPU. > > > > See above. On my glibc2 system this is happening for sure. > OK, this should work even if your system's signal semantics is > different for some weird reason. I'll add it is soon as I can get > back. > (Using sigaction with SA_NOMASK will have the same effect and > will make the intent a bit clearer). Ok thanks. It will kill off a lot of bug reports in the future. > > 2. The SIGWINCH handler just above it just calls the old signal > > handler direct. That obviously works. May I suggest however > > that a more complete prototype is used for the signal handler. > > You'd need special cases for SIG_DFL and SIG_IGN. Ugly. Note that you already special case SIG_IGN when installing the handler. > > What's this BSD stuff?? Are we talking Linux or not? See above about > gpm compilation. I was being confused by both the Solaris and the glibc2 docs (or at least the man paged derived from it for the Debian distribution) describing 'signal' as a BSD compatibility layer over sigaction. > > I would like a combination of 1 and 5. With 5 being low priority so > > it can wait till there actually is a client that needs it. > > OK, agreed, I'll do [1] ASAP. Thank you very much. Jan

2 participants
1 comments

pcl-cvs vs. VC 25 years, 5 months

Stefan Monnier

[ I'm not on this mailing-list, so please include me in the cc ] I've been hacking at pcl-cvs and have heard recently that there's been discussion on this list about bad interactions between VC and pcl-cvs. Being a VC as well as pcl-cvs user, I'd like to fix pcl-cvs w.r.t those bad interactions. Anybody remember what they were/are ? Stefan

1 participants
0 comments

[Bug foound/Suggested Solution] Suspending on linux Console and lingpm 25 years, 5 months

Jan Vroonhof

I have been at the XEmacs-with-gpm problem again (with a debugger and a -g build of libgpm this time) and I found the problem. It is a bug in the way libgpm tries to handle relaying to the old signal handler. I debugged against 1.13 (that's what I have at home) but the code did not change in 1.14. Note that even a simple program of the type int main(int argc,char *argv[]) { /* setup conn struct */ Gpm_Open(conn,0); puts("Here we go.."); killpg(0,SIGTSTP); puts("Back again"); Gpm_Close(); } will hang when run on a Linux console (and not on an Xterm). Alternatively, just run the 'mev' example program on a Linux console and send it a SIGTSTP and it will also hang. The problem is here in (liblow.c): > #if (defined(SIGTSTP)) > /* itz: support for SIGTSTP */ First comment. Compare this handler with the way the SIGWINCH is relayed just above. > /* Old SIGTSTP handler. */ > > static __sighandler_t gpm_saved_suspend_hook; > > static void gpm_suspend_hook (int signum) Note. Signal handlers installed with 'signal' are called with the signal that generated them blocked. It is then unblocked on exiting the signal handler. > { > Gpm_Connect gpm_connect; > sigset_t old_sigset; > sigset_t new_sigset; > int success; > > sigemptyset (&new_sigset); > sigaddset (&new_sigset, SIGTSTP); > sigprocmask (SIG_BLOCK, &new_sigset, &old_sigset); Not necessary signal is already blocked. > /* Open a completely transparent gpm connection */ > [code snipped] > > /* take the default action, whatever it is (probably a stop :) */ > sigprocmask (SIG_SETMASK, &old_sigset, 0); > signal (SIGTSTP, gpm_saved_suspend_hook); Reinstall old signal handler. > kill (getpid (), SIGTSTP); Send the signal to ourselves. The idea here is that the old signal handler will now get called. However as the signal is currently blocked it will get queued. > /* in bardo here */ No we aren't! > /* Reincarnation. Prepare for another death early. */ > signal (SIGTSTP, gpm_suspend_hook); Gpm handler is installed again. > /* Pop the gpm stack by closing the useless connection */ > /* but do it only when we know we opened one.. */ > if (success) { > Gpm_Close (); [*] Suppose the old SIGTSTP handler was called. How are we sure we get back here? What if the old handler longjmp's to somewhere? > } /*if*/ > } Here the signal handler exits. The SIGTSTP handler is unblocked and any queued signals are sent including the one we sent outselves. Bingo! we now have a sinal loop. The process will hang sucking up 100% of CPU. > #endif /* SIGTSTP */ This code was obviously written for a system where signal handlers were not called with the signal blocked. Did Linux change its behaviour sometime in the past? How to fix 1. Maybe explicitly unblocking the signal between reinstalling the old handler and sending the signal works. [Last minute addition. Yes this must work, it is the way Emacs relays signals to their default handler]. 2. The SIGWINCH handler just above it just calls the old signal handler direct. That obviously works. May I suggest however that a more complete prototype is used for the signal handler. 3. The signal handler is installed using a more general interface than the BSD signal wich allows setting the handler type such that the signal is NOT blocked by default. This however leads to race conditions. Solutions [1] [2] have the advantage that they are relatively minor changes and do not require the libgpm user to be aware of the signal issues. However as the user is not aware this leads to problems such as [*]. However for XEmacs this is not relevant. It does not have its own SIGTSTP handler. However this might change in the future (for instance to fix the 'gnuclient on same tty problem' . 4. The Debian bug tracking system contains patches that allow processes to specify before and after hooks that get called by the libgpm singal handler instead of calling the origional handler. This is better however it still does not solve [*]. Moreover we still want to call the SIG_DFL handler to actuall do the suspending (or can we just call pause()) I am not sure how that is handled correctly or how that is done in this particular patch. 5. Alternatively one can take the dual interface to 4. There is is a hook that says the process will take care of signal handling itself and libgpm will provide function gpm_before_suspend and gpm_after_suspend that the program must call. I would like a combination of 1 and 5. With 5 being low priority so it can wait till there actually is a client that needs it. Jan

3 participants
2 comments

Re: XEmacs' autoconf weirdness (was Re: Spurious "file has changed on disk" warnings on Linux) 25 years, 5 months

William M. Perry

SL Baur <steve(a)xemacs.org> writes: > Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > > > A project worth investigating is trying to migrate to automake > > directly. But I'm not sure offhand what it would buy us. Maybe we > > would get libtool shared lib support for free? > > What would that buy? I thought libtool was for building shared > libraries. The only thing close in the XEmacs tree is building as an > external widget. Have more than a dozen people ever even tried it? Not that I know of. :) lwlib might be nice as a shared library, or migrating the current lwlib stuff so that you could just drop in a new liblw.so and it would get a new 'look'. I dunno. But libtool will eventually migrate to being able to fully support dlopen'able modules, so this could be used as the basis for some of the module support. I know jean is working on getting libtool to work on sco from some of the messages on the mailing list. :) -Bill P.

2 participants
1 comments

Experimental subwindow / widget patch for review 25 years, 5 months

Andy Piper

Hi, For anyone who's interested here is my work in progress for implementing platform widgets in a buffer. As a side effect I have had to implement subwindows. Any comments, feedback, criticisms welcome. Also, I have only implemented the device level stuff for mswindows because I don't understand / use X so much. If anyone is interested in implementing the X side I would be really interested to know. I've done a partial implementation but it needs actual widgets (motif or whatever) which I don't have access to. It shouldn't be that difficult since most of it is generalised / platform independent. ChangeLog follows (this is against 21.2). andy 1998-11-09 Andy Piper <andy(a)xemacs.org> * window.h (struct window): add a cache of subwindows on a per-window basis. * window.c (mark_window): mark the subwindow_instance_cache. (allocate_window): initialise the subwindow instance_cache. * toolbar-x.c (x_output_toolbar): call redisplay_clear_region instead of the devmeth. (x_clear_toolbar): ditto. * redisplay-x.c (x_output_display_block): call redisplay_output_subwindow for subwindows and widgets. * redisplay-tty.c (tty_output_display_block): add IMAGE_WIDGET to types to do nothing for. * lisp.h: declare new widget/subwindow symbols. * glyphs.c (image_instantiate): cache subwindows on a per-window basis. (subwindow_possible_dest_types): new function for subwindow dest types. (subwindow_instantiate): generic instantiation of a subwindow. specialised by device multi-methods. (Fsubwindowp): moved from glyphs-x.c. adapted for glyph-based subwindows. (Fimage_instance_subwindow_id): ditto. (Fresize_subwindow): ditto. (Fforce_subwindow_map): ditto. * glyphs-x.c (x_print_image_instance): remove subwindow stuff. Handled genrically in glyphs.c. (x_image_instance_equal): ditto. (x_image_instance_hash): ditto. (x_finalize_image_instance): delete subwindows when required. (mark_subwindow) (print_subwindow) (finalize_subwindow) (subwindow_hash) (Fmake_subwindow): deleted because of new, glyph-based, subwindow implementation. (Fsubwindow_height) (Fsubwindow_width) (Fsubwindow_xid): aliased in glyphs.el (Fsubwindowp) (Fresize_subwindow) (Fforce_subwindow_map): moved to glyphs.c. (x_unmap_subwindow): new function to unmap X subwindows. (x_map_subwindow): new function to map X subwindows. (x_subwindow_instantiate): new function to instantiate X subwindows. (x_resize_subwindow): new function to resize X subwindows. (console_type_create_glyphs_x): add subwindow functions. (image_instantiator_format_create_glyphs_x): add device multi-methods for xpm, xbm and subwindow. * glyphs.el (subwindow-xid): old alias for new subwindow functions. (subwindow-width): ditto. (subwindow-height): ditto. * glyphs-msw.c (mswindows_widget_instantiate): new function for generally instantiating ms subwindows. Used by mswindows_*_instantiate. (mswindows_edit_instantiate): instantiate an edit field on a mswindows frame. 1998-11-04 Andy Piper <andy(a)xemacs.org> * symsinit.h: declare new functions. * redisplay.h: declare new functions. * redisplay-x.c (x_output_display_block): call redisplay_clear_region rather than x_clear_region. (x_output_string): ditto. (x_output_pixmap): ditto. (x_clear_to_window_end): ditto. (x_output_eol_cursor): ditto. (x_clear_region): only do X specific things. other duties handled in redisplay_clear_region. * redisplay-tty.c (tty_clear_region): do tty specific things - some duties moved to redisplay_clear_region. * redisplay-output.c (clear_left_border): use redisplay_clear_region instead of device method. (clear_right_border): ditto. (output_display_line): ditto. (redisplay_output_subwindow): ditto. (redisplay_clear_top_of_window): ditto. (redisplay_clear_region): perform duties previously handled by device methods. call the appropriate device method at the end. unmap subwindows if necessary. * redisplay-msw.c (mswindows_output_string): use redisplay_clear_region instead of mswindows_clear_region. (mswindows_clear_to_window_end): ditto. (mswindows_output_display_block): output subwindows when required. (mswindows_clear_region): only do mswindows specific things, everything else is now handled in redisplay_clear_region. * gui.h: add item id hash defines and declare function prototypes. * gui.c (mark_gui_item): new function for marking gui_items. (gui_item_hash): generic hash function for generating command ids for gui_items. * gui-msw.c: new file. (mswindows_handle_gui_wm_command): new function to handle widget callbacks. * glyphs.h (MAYBE_IIFORMAT_DEVMETH): new function for device multi-methods. (IIFORMAT_HAS_SHARED_METHOD): ditto. (DEFINE_DEVICE_IIFORMAT): ditto. (INITIALIZE_DEVICE_IIFORMAT): ditto. (struct Lisp_Image_Instance): add widget and subwindow data plus appropriate access functions. * glyphs.c (decode_device_ii_format): new function for decoding image instantiator functions based on a device type as well as an image format. (decode_image_instantiator_format): just call decode_device_ii_format with nil device. (add_entry_to_device_ii_format_list): new function for per device method instances. (add_entry_to_image_instantiator_format_list): just call add_entry_to_device_ii_format_list with nil device. (check_valid_vector): new function. (instantiate_image_instantiator): instantiate using per-format method and then per-format-per-device method (device multi-methods). signal an error if neither is possible. (mark_image_instance): cope with subwindows and widgets. (print_image_instance): ditto. (image_instance_equal): ditto. (image_instance_hash): ditto. (allocate_glyph): ditto. (glyph_width): ditto. (glyph_height_internal): ditto. (xpm_instantiate): removed because of device multi-methods. (mark_subwindow_cachels): new cachel functions for caching instantiated subwindows on a per-frame basis. mostly copied from glyph cachel functions. (update_subwindow_cachel_data): ditto. (add_subwindow_cachel): ditto. (get_subwindow_cachel_index): ditto. (reset_subwindow_cachels): ditto. (mark_subwindow_cachels_as_not_updated): ditto. (unmap_subwindow): generic unmapping of subwindows based on cachel data. (map_subwindow): ditto. (initialize_subwindow_image_instance): generic initialisation of subwindow data. (syms_of_glyphs): add widget keywords. * glyphs-x.h (struct x_subwindow_data): convert Lisp_Subwindow to x_subwindow_data. 1998-11-04 Andy Piper <andy(a)xemacs.org> * glyphs-widget.c: new file for instantiating widget type glyphs. (widget_possible_dest_types): new general dest type function for widgets. (widget_validate): ditto. (initialize_widget_image_instance): ditto (widget_instantiate): ditto. Sets up fg/bg, gui_item parsing before handing on control to device multi-methods. (syms_of_glyphs_widget): new function. (image_instantiator_format_create_glyphs_widget): new function, added placeholders for button, edit, combo, scrollbar (vars_of_glyphs_widget): new function. * glyphs-msw.h (WIDGET_INSTANCE_MSWINDOWS_HANDLE): new define for storing window ids of widgets. * glyphs-msw.c (mswindows_finalize_image_instance): cope with deletion of widget and subwindow glyphs. (mswindows_unmap_subwindow): new device function for unmapping subwindows on a msw frame. (mswindows_map_subwindow): ditto. (mswindows_register_image_instance): register instantiated widgets with the widget hastable. (mswindows_button_instantiate): instantiate a button type widget on an msw frame. (mswindows_subwindow_instantiate): instanttiate a subwindow on a mswindows frame. (image_instantiator_format_create_glyphs_mswindows): add device multi-methods for xbm, xpm, subwindow, edit and button. * frame.h (struct frame): add subwindow_cachels dynarr for caching information about subwindows visible on the current frame. used by redisplay_clear_region to unmap subwindows as required. * frame.c (mark_frame): mark subwindow_cachels. (allocate_frame_core): instantiate subwindow_cachels. * frame-msw.c (mswindows_init_frame_1): instntiate and mark the widget hashtable. * event-msw.c (mswindows_wnd_proc): add call to mswindows_handle_gui_wm_command to handle widget callbacks. * emacs.c (main_1): add calls to glyphs-widget initialisation routines. * console.h (struct console_methods): add unmap/map_subwindow_method for use be redisplay_clear_region to map and unmap subwindows. Remove xpm and xbm stuff - now dealt with by image instantiator multi-methods. Add resize_subwindow_method. * console-stream.c (stream_clear_region): change signature to match new generic clear region function. * configure.in: add gui-msw.o to msw objects. * Makefile.in.in: add glyphs-widget.o to list of objects. * console-msw.h (struct mswindows_frame): add widget hashtable for wiring command ids to callbacks. --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

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

2002

2001

2000

1999

1998

XEmacs-Beta November 1998