July 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [PATCH] Enhanced clipboard support bug fixes (for Alastair J. Houghton) 24 years, 4 months

Michael Sperber

>>>>> "Alastair" == Alastair J Houghton <ajhoughton(a)lineone.net> writes: Alastair> Well this has been fixed (and was even fixed fairly quickly Alastair> once I'd figured out what exactly was going on). (See the Alastair> mailing list archive if you're *really* interested in Alastair> exactly what was going on - but it was basically due to Alastair> kludgey behaviour from the X code...) Alastair> However, there have been some more complaints about a Alastair> similar error... Exactly. I apologize for confusing the two bugs. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Selection bug 24 years, 4 months

Alastair Houghton

Various people have noticed something similar to the following > E.g. if I simply do C-k C-y, I get: > > selection-conversion error: "selection owner couldn't convert", > CLIPBOARD, STRING Apologies for this, but although I *have* an X installation, I have still been unable to successfully build the current beta under X (it just fails to map a window). Otherwise this would be much easier to fix, rather than my relying on guesswork ;-) I have some suspicions as to what might be wrong, and I'll try to get a fix done *today*. Regards, Alastair. ____________________________________________________________ Alastair Houghton ajhoughton(a)lineone.net

1 participants
0 comments

RE: [PATCH] Enhanced clipboard support bug fixes (for Alastair J. Houghton) 24 years, 4 months

Alastair Houghton

> -----Original Message----- > From: Ben Wing [mailto:ben＠666.com] > Sent: 17 July 2000 23:33 > To: Michael Sperber [Mr. Preprocessor] > Cc: Vin Shelton; Adrian Aichner; XEmacs Patches; Alastair J. Houghton > Subject: Re: [PATCH] Enhanced clipboard support bug fixes (for Alastair > J. Houghton) > > Michael -- > > first of all, make sure to cc people you are writing about if you > want them to > see your message. otherwise they may not see it -- e.g. alastair > is not on > xemacs-review, and [for awhile at least] not on xemacs-beta. in I *am* on xemacs-beta now. > > This is beyond annoying behavior: the XEmacs in CVS is *unusable* on > > X. I fully support Alastair's patches in general, but they have gone > > in without *any* testing on X, we know they don't work on X, and > > therefore we should back out the changes, and test out a the patch for > > this before it goes in. I'm fully willing to help do this. However, > > currently I have to back out *two* patches in my workspace to get a > > working XEmacs. > > > > Vin> Now exactly what problem are you seeing? > > > > I see the same problem everyone has been seeing: > > > > Signaling: (selection-conversion-error "selection owner > couldn't convert" CLIPBOARD _EMACS_INTERNAL) > > ... > > > > in various circumstances associated with selection, wiping and yanking > > text. Well this has been fixed (and was even fixed fairly quickly once I'd figured out what exactly was going on). (See the mailing list archive if you're *really* interested in exactly what was going on - but it was basically due to kludgey behaviour from the X code...) However, there have been some more complaints about a similar error... Regards, Alastair. ____________________________________________________________ Alastair Houghton ajhoughton(a)lineone.net

1 participants
0 comments

Re: New versions of speedbar, jde, new package semantic 24 years, 4 months

Michael Sperber

>>>>> "Paul" == Paul Krause <pkrause(a)ibelong.com> writes: >> Michael Sperber writes: >> I have superficially working versions of Speedbar 0.11.1 and JDE >> 2.19. Paul> ... >> Here's a problem for you: JDE comes with a massive array of support >> data files in a number of directories: Paul> ... >> I'd like this entire hierarchy dropped unchanged into etc/jde. It >> seems the DATA_FILES thingies in XEmacs.rules are all flat, and there >> are only 9 of them. What do I do? Paul> The psgml package seems to use subdirectories without problems. Paul> Why not do the same for JDE? That's not the point: PSGML has only 3 subdirectories in the data hierarchy; JDE has more than a dozen: DATA_FILES = $(wildcard etc/[EHRWhisw]*) etc/CATALOG $(wildcard etc/*ent) \ $(wildcard etc/*.dtd) $(wildcard etc/*.mod) $(wildcard etc/*.dcl) DATA_DEST = $(PACKAGE) DATA_1_FILES = $(wildcard etc/cdtd/[hi]*) DATA_1_DEST = $(PACKAGE)/cdtd DATA_2_FILES = $(wildcard etc/ISO_8879-1986/entities/[A,D-Z]*) \ $(wildcard etc/ISO_8879-1986/entities/*.ent) DATA_2_DEST = $(PACKAGE)/ISO_8879-1986/entities -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

[PATCH] Minor fix to gpmevent.c 24 years, 4 months

Alastair Houghton

Here's a patchette to update the parameter lists for a couple of the functions in gpmevent.c. The functions themselves look rather dubious to me - perhaps someone with knowledge of GPM could take a look at them and maybe do something about them? Regards, Alastair. src/ChangeLog: 2000-07-17 Alastair J. Houghton <ajhoughton(a)lineone.net> * gpmevent.c (tty_selection_exists_p): * gpmevent.c (tty_own_selection): Updated parameter lists. --- ../orig/xemacs-21.2/src/gpmevent.c Mon Mar 13 07:27:58 2000 +++ xemacs-21.2/src/gpmevent.c Mon Jul 17 13:39:19 2000 ＠＠ -309,7 +309,7 ＠＠ } static Lisp_Object -tty_selection_exists_p (Lisp_Object selection) +tty_selection_exists_p (Lisp_Object selection, Lisp_Object selection_type) { return (Qt); } ＠＠ -317,7 +317,8 ＠＠ #if 0 static Lisp_Object -tty_own_selection (Lisp_Object selection_name, Lisp_Object selection_value) +tty_own_selection (Lisp_Object selection_name, Lisp_Object selection_value, + Lisp_Object how_to_add, Lisp_Object selection_type) { /* There is no way to do this cleanly - the GPM selection ** 'protocol' (actually the TIOCLINUX ioctl) requires a start and -- ____________________________________________________________ Alastair Houghton ajhoughton(a)lineone.net

2 participants
1 comments

XEmacs Build Report for XEmacs-21.1.11 24 years, 4 months

XEmacs Build 'Bot

Hello XEmacs beta testers. I am in the process of building XEmacs-21.1.11 for distribution. I have tested the attached configuration. Have a great day! Sincerely, The XEmacs Build 'Bot (revision 2) -- uname -a: Linux zion.rcn.com 2.2.17pre13 #2 SMP Mon Jul 17 22:02:46 EDT 2000 i686 unknown ./configure '--prefix=/home/acs/cvsroot' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.1.11 "Carlsbad Caverns" configured for `i686-pc-linux'. Where should the build process find the source code? /home/acs/cvsroot/xemacs-21.1 What installation prefix should install use? /home/acs/cvsroot What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -O Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? none Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for LDAP. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits.

1 participants
0 comments

Lstreams and Lisp 24 years, 4 months

Alastair Houghton

Why does it say /* #define CHECK_LSTREAM(x) CHECK_RECORD (x, lstream) Lstream pointers should never escape to the Lisp level, so functions should not be doing this. */ in lstream.h? The reason I'm wondering is that I'd like to make my encode-binary and decode-binary functions work with arbitrary output sinks/input sources, so the obvious implementation is to create a suitable Lstream within the Lisp-visible functions. The trouble is that I want the interface to the functions to include the facility to add user-defined conversions, which means that a Lisp function may have to accept an Lstream parameter... so I'm wondering whether there was any reason for this comment ;-) Just in case you're interested, here's the interface I'm proposing (there'll be an additional encode-binary-string function that works in an efficient way). The STREAM parameter could accept any Lisp object for which an Lstream can be created. DEFUN ("encode-binary-stream", Fencode_binary_stream, 3, 3, 0, /* Encode the sequence DATA into a binary STREAM using the specified binary FORMAT vector. Each element of the FORMAT vector should either be a symbol, or a list of the form (SYMBOL PARAMETER...). SYMBOL may be one of binary string bit-vector integer float space vector or alternatively the name of a Lisp function that will be called with the remaining data, the output stream and a list of PARAMETER values as its arguments. i.e. it's declaration should look something like the following (defun my-conversion data stream parameter-list ... ) and it will be called using (my-conversion data stream parameter-list) Such a function should return the remaining data after it has consumed whatever it required. The built-in encodings support the following parameters: Encoding Parameters binary :length string :length :pad :terminator bit-vector :length :direction integer :length :signed :direction float :length :format :direction space :length vector FORMAT-ELT :length :pack where FORMAT-ELT is anything that could be an element of the FORMAT parameter. :length is followed by a length in bytes (or in bits for bit-vector). :pad is followed by a character used to pad the string to the specified length. :terminator is followed by a character used to terminate the string. :direction is followed by one of `big-endian', `little-endian', `host' or `network'. :signed is followed by t or nil. :format is followed by `native'. Conversions to other floating point formats are currently not supported. :pack is followed by an integer specifying the vector stride (e.g. the format [(vector (integer :length 2) :pack 4)] represents an array of 16-bit integers, but with a gap of 2 bytes between successive elements). The function returns a string containing the raw binary data. */ (format, data, stream)) DEFUN ("decode-binary-stream", Fdecode_binary_stream, 2, 2, 0, /* Decode the specified STREAM using the binary FORMAT vector. See `encode-binary-stream' for more information on the FORMAT vector; note however that user-defined conversion functions should be declared as (defun my-conversion stream parameter-list ...) and should return the data they have converted. */ (format, stream)) Kind Regards, Alastair. ____________________________________________________________ Alastair Houghton ajhoughton(a)lineone.net

2 participants
1 comments

Re: [PATCH] Minor fix to gpmevent.c 24 years, 4 months

William M. Perry

"Alastair J. Houghton" <ajhoughton(a)lineone.net> writes: > Here's a patchette to update the parameter lists for a couple of the > functions in gpmevent.c. The functions themselves look rather dubious to > me - perhaps someone with knowledge of GPM could take a look at them and > maybe do something about them? I wrote the GPM code, so I'll take a crack at explaining why they do what they do. :) The selection handling is actually NOT part of the GPM library. It populates the selection, but there is no 'get the selection' call provided. gpmevent.c does the TIOCLINUX ioctl manually and grabs the results. There is no way to figure out whether the selection exists (at least not in 2.2.x or 2.3.x that I've seen), so we always say there is a selection available. The own_selection stuff is not used at all, it is just a placeholder with the comment about why we cannot implement it. Perhaps it will eventually motivate someone to fix GPM / linux / xemacs to do this nicely. But I won't hold my breath. The linux selection handling is a crock in a lot of ways. See the comment in gpm_next_event_cb about the console permissions. :) -Bill P.

1 participants
0 comments

[PATCH] Enhanced clipboard code tidy. 24 years, 4 months

Alastair Houghton

I was calling intern() every time anyone called select_convert_[in|out]. This patch makes XEmacs use a variable to hold the symbols "select-convert-in" and "select-convert-out". Regards, Alastair. src/ChangeLog: 2000-07-17 Alastair J. Houghton <ajhoughton(a)lineone.net> * select.c (select_convert_in, select_convert_out): Don't call intern() every time. * select.c (Qselect_convert_in, Qselect_convert_out): New. * select.c (vars_of_select): Initialise them. --- ../orig/xemacs-21.2/src/select.c Sun Jul 16 12:32:58 2000 +++ xemacs-21.2/src/select.c Mon Jul 17 17:10:41 2000 ＠＠ -52,6 +52,9 ＠＠ /* "Selection owner couldn't convert selection" */ Lisp_Object Qselection_conversion_error; +/* A couple of Lisp functions */ +Lisp_Object Qselect_convert_in, Qselect_convert_out; + /* These are alists whose CARs are selection-types (whose names are the same as the names of X Atoms or Windows clipboard formats) and whose CDRs are the names of Lisp functions to call to convert the given Emacs selection ＠＠ -543,7 +546,7 ＠＠ Lisp_Object type, Lisp_Object value) { - return call3 (intern ("select-convert-in"), + return call3 (Qselect_convert_in, selection, type, value); } ＠＠ -558,10 +561,9 ＠＠ if (NILP (value)) return Qnil; - return call3 (intern ("select-convert-out"), + return call3 (Qselect_convert_out, selection, type, value); } - /* Gets called from kill-buffer; this lets us dispose of buffer-dependent selections (or alternatively make them independent of the buffer) when ＠＠ -657,6 +659,10 ＠＠ DEFSUBR (Favailable_selection_types); DEFSUBR (Fregister_selection_data_type); DEFSUBR (Fselection_data_type_name); + + /* Lisp Functions */ + defsymbol (&Qselect_convert_in, "select-convert-in"); + defsymbol (&Qselect_convert_out, "select-convert-out"); /* X Atoms */ defsymbol (&QPRIMARY, "PRIMARY"); -- ____________________________________________________________ Alastair Houghton ajhoughton(a)lineone.net

1 participants
0 comments

Re: New versions of speedbar, jde, new package semantic 24 years, 4 months

Michael Sperber

>>>>> "Andreas" == Andreas Jaeger <aj(a)suse.de> writes: >>>>> Michael Sperber writes: >> Hi, >> I have superficially working versions of Speedbar 0.11.1 and JDE >> 2.19. (The latter needs the former.) Moreover, to get JDE to work, >> I've made the semantic bovinator into a package. Andreas> What's the "semantic bovinator"? It's a parsing tool JDE uses for its class browser. >> Objections to me checking these into CVS? Andreas> No, just the opposite - an update of JDE is long needed. Here's a problem for you: JDE comes with a massive array of support data files in a number of directories: java/classes java/classes/jde java/classes/jde/wizards java/classes/jde/parser java/classes/jde/util java/lib java/doc java/doc/jde java/doc/jde/debugger java/doc/jde/debugger/expr java/doc/jde/debugger/spec java/src java/src/jde java/src/jde/wizards java/src/jde/debugger java/src/jde/debugger/interpret java/src/jde/debugger/interpret/syntaxtree java/src/jde/debugger/interpret/visitor java/src/jde/debugger/spec java/src/jde/debugger/expr java/src/jde/debugger/command java/src/jde/parser java/src/jde/parser/syntaxtree java/src/jde/parser/visitor java/src/jde/util I'd like this entire hierarchy dropped unchanged into etc/jde. It seems the DATA_FILES thingies in XEmacs.rules are all flat, and there are only 9 of them. What do I do? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

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 July 2000