October 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: xemacs background pixmaps (ala Eterm) 24 years, 8 months

Jan Vroonhof

[This is better taken to xemacs-beta(a)xemacs.org] proff-spam-usenet(a)iq.org writes: <teletubbies> Ooooo... Ohhhhh </teletubbies> I hope I guessed your real address correctly. > Has anyone looking at hacking this into the xemacs c-code? Not really. You are welcome to do this though. Doing it cleanly will take some effort though. If I understand correctly this is done by taking a snapshot of part of the root window and then using that as the background pixmap? If then you could also implement it that way. Make a new frame-property that returns a glyph containing the background and then you can use (set-face-background-pixmap 'default (frame-background-glyph (selected-frame)) (selected-frame)) Of course you have to make sure the glyph is updated when the frame is moved and/or resized. Or does eterm do it some other way? Xshape extension? Whatever you do, start from the 21.2 series. This area has been touched quite heavily there. Jan

1 participants
0 comments

Re: XEmacs 21.2 (w/Mule) file-truename 24 years, 8 months

Jan Vroonhof

Lars Magne Ingebrigtsen <larsi(a)gnus.org> writes: > (file-truename "/music/in/Jóga/") > => > "/music/in/J\201óga/" > > (It really adds just the one character "\201".) It simply copies the mule encoded data directly before passing it to the OS. XEmacs elisp may have character type so this doesn't happen but C does not. > Is this a bug or whot? Yep. It is even described in the code! Does this (untested) patch work for you? Index: fileio.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/fileio.c,v retrieving revision 1.51.2.9 diff -u -u -r1.51.2.9 fileio.c --- fileio.c 1999/09/23 07:39:48 1.51.2.9 +++ fileio.c 1999/10/16 12:58:38 ＠＠ -1301,18 +1301,18 ＠＠ { char resolved_path[MAXPATHLEN]; - char path[MAXPATHLEN]; - char *p = path; + char *path; + char *p; int elen = XSTRING_LENGTH (expanded_name); - if (elen >= countof (path)) + GET_STRING_FILENAME_DATA_ALLOCA(expanded_name,path,elen); + p = path; + if (elen > MAXPATHLEN) goto toolong; - - memcpy (path, XSTRING_DATA (expanded_name), elen + 1); - /* memset (resolved_path, 0, sizeof (resolved_path)); */ - + /* Try doing it all at once. */ - /* !!#### Does realpath() Mule-encapsulate? */ + /* !! Does realpath() Mule-encapsulate? + Answer: Nope! So we do it above */ if (!xrealpath (path, resolved_path)) { /* Didn't resolve it -- have to do it one component at a time. */

1 participants
0 comments

Re: Misc patch 24 years, 8 months

Jan Vroonhof

Ben Wing <ben(a)666.com> writes: > because it's quite possible that "regular" progress gauges (i.e. displayed in > their own dialog box) will also be implemented. Aren't they already? > > * gui.el (make-gui-button): Use native widgets for buttons > > unconditionally. > > (insert-gui-button): ditto. > > (gui-button-p): ditto. > > > > * xbm-button.el: remove from core. > > > > * xpm-button.el: remove from core. M-x all-hail-andy! Jan

1 participants
0 comments

Bug (read-input-method-name) 24 years, 8 months

Mikio Nakajima

In XEmacs 21.2 (beta19) "Shinjuku" [Lucid] (i586-pc-linux, Mule) of Sat Jul 31 1999 on libretto configured using `configure --extra-verbose --with-x11=yes --dynamic --with-png=yes --with-xpm --with-xface --with-database=berkdb --with-sound=native --with-mule --with-xim=no --with-xfs --site-libraries=/usr/local/lib' As you know, register-input-method allows its arguments to be symbols or strings; >(register-input-method INPUT-METHOD LANG-ENV &rest ARGS) > >Register INPUT-METHOD as an input method for language environment ENV. >INPUT-METHOD and LANG-ENV are symbols or strings. ^^^^^^^^^^^^^^^^^^^ But when I register INPUT-METHOD by specifying some symbol `japanese-skk' and call `set-input-method', then following error occurs; Wrong type argument: sequencep, japanese-skk I will send patch to xemacs-patches that resoleves this problem. Thank you very much. -- Mikio Nakajima <minakaji(a)osaka.email.ne.jp> <minakaji(a)pdx.ne.jp> (in case of emergency) http://www.asahi-net.or.jp/~gy2m-nkjm/

1 participants
0 comments

RE: (call-process ...) to return correct exit-status on NT 24 years, 8 months

Bill Tutt

> From: Craig Lanning [mailto:CraigL＠DyCon.com] > > > At 10:42 PM 10/15/99 +0200, Adrian Aichner wrote: > >>>>>> "Jonathan" == Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes: > > > > Jonathan> How about using WaitForSingleObject(pid, 1/10s) instead > > > >Hi Jonathan, Craig, All! > > > >Could someone who knows please confirm whether WaitForSingleObject() > >will work on Windows9[58]? > > The book that I have ("Win32 System Programming" by Johnson M. Hart) > indicates that WaitForSingleObject() works for NT/95/98. (I > don't do any > windows programming so I can't answer from personal experience.) > The book's got it right. WaitForSingleObject() does work for all Win32 platforms. > >According to MSDN I have to OpenProcess() with SYNCHRONIZE right on > >WindowsNT. Windows9[58] does not seem to have this access right. So > >I guess I have to open without it there. > > This book does not identify SYNCHRONIZE as an NT only option > so it should > work with 95/98. > The SYNCHRONIZE right is new with Windows 2000. It doesn't exist on NT 3.51, or NT 4. In any event it doesn't matter since the easiest way to do this is just to use PROCESS_ALL_ACCESS that way you can do whatever you want with the called process. (it includes the SYNCHRONIZE right in the bitmask in the Win2k headers) Bill

1 participants
0 comments

XEmacs 21.2 (w/Mule) file-truename 24 years, 8 months

Lars Magne Ingebrigtsen

`file-truename' seems to be doing odd stuff in 21.2: (file-truename "/music/in/Jóga/") => "/music/in/J\201óga/" (It really adds just the one character "\201".) Is this a bug or whot? -- (domestic pets only, the antidote for overdose, milk.) larsi(a)gnus.org * Lars Magne Ingebrigtsen

1 participants
0 comments

windows cut and paste (one for the faq) 24 years, 8 months

Scott Otterson

Hi, I just installed the MS windows build of xemacs 21.1.6. Most things work as they do on my Unix machine, with the exception of cut and paste with other programs. How do I enable cut/paste from/to other MS Windows such as Word? Thanks, Scott

2 participants
1 comments

Re: (call-process ...) to return correct exit-status on NT 24 years, 8 months

Hrvoje Niksic

Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes: > On Windows 95/98 process IDs are negative(!) which screws up in a > call to make_int() in Fcall_process_internal() by blowing the 30(?) > bit lisp integer size. Huh? Lisp integers are 31-bit, and should be fully capable of holding negative values. In fact, their range is [-2^30, 2^30). Or, do you mean that the PID's under 95/98 are *large* negative integers? That would be very strange, for they would have to be very large indeed to not fit in Lisp ints.

1 participants
0 comments

Re: cus-edit.el custom comments changes 24 years, 8 months

Dave Love

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Thanks a lot for the cooperation. I hope mutual cooperation isn't a surprise. Jan> Does that mean this will be in a released Emacs soon? In Emacs 21 (for an unknown value of `soon'). Your theme support (thanks) should be ported too when someone has the time. Jan> The problem with this is that the whole Jan> custom-set-*s interface seems fragile to me with regard to future Jan> extension. Jan> Do you think it would be a good idea to move this to keyword Jan> arguments? Then we could specify that unknown keyword arguments must Jan> be preserved but ignored. That sounds reasonable to me, at least. Jan> i.e. Jan> (custom-set-variables Jan> '(gnus-ignored-from-addresses "vroonhof＠.*math") Jan> '(gnus-decay-scores t nil :comment "This variable is important"!) Jan> Is it too late to do this now? We currently only have this in beta Jan> releases so we can still make the changes. For us now is a good time to make such a change.

1 participants
0 comments

Extent lossage with `decode-coding-region' and friends 24 years, 8 months

Stephen J. Turnbull

The attached file defines a wrapper `safer-decode-coding-region' that preserves most markers and extents across calls to `decode-coding-region'. It also contains some example code which shows how `decode-coding-region' is normally broken. It works by temporarily setting the endpoint of all extents abutting the region to `open', and placing "fenceposts" at each end of the region to ensure that markers get pushed and pulled in the right directions by operations acting entirely within the region. I have understood Hrvoje to say `decode-coding-region' totally breaks markers and extents but I haven't found that; my experience is that only markers and extent endpoints within the closure of the region being decoded are at risk. You can see that the "whole-extent" and the external endpoint of "overlap-extent" in the example code are fine. If somebody has bugs that involves external markers or extent endpoints, and recipes to replicate I'd love to have a look at them. `safer-decode-coding-region' is safer only for markers and extent endpoints at the boundaries. Strictly interior markers end up at the beginning of the decoded region; I don't know the general rule for extent endpoints, but in the example the extent endpoint moves in the opposite direction, to the end of the decoded region. I don't see much reason to care about this in the case of `decode-coding-region'; setting markers in the middle of an externally-encoded region is semantically dubious at best. Unfortunately, that's not true for `encode-coding-region', and I suspect it's probably not true for any functions that work the way `*code-coding-region' does (feeding buffer text to an lstream, deleting the text, and inserting the output of the lstream into the buffer). I have figured out but not implemented a hack that can make a pretty good guess at where an interior extent endpoint belongs after the region is en/decoded (at least for non-modal and ISO-2022-conformant modal encodings). I don't see any way to handle markers, though, because according to Info there's no way to get a list of markers. In any case it probably ought to be possible to handle extents much more easily in the C code for F*code-coding-region. Probably some of this (the hacking at the boundary of the region) should be done at the level of lstream.c (nothing I do is specific to `decode-coding-region'; in fact the insight came after considering an RMS comment about the ordering of block insertions and deletions in wid-edit.el, but this doesn't work with extents because of their flexible closure properties). Unfortunately that level of code is beyond me at the moment. Here's the code. You need a Mule XEmacs (of course), and a Japanese font and a color-capable terminal for the visuals. You can't just use `load-file' on it because that automatically translates the Japanese from ISO-2022-JP to Mule internal encoding, ruining the experiment. It's probably easiest to load it into a buffer, raw, and then do `eval-buffer' on it. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."

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 October 1999