April 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Karl M. Hegbloom

`clg': <URL:http://home.sol.no/~espejohn/> There's code for generating interfaces from Glade XML files written in Common Lisp.

1 participants
0 comments

Summary of gtk implementation discussion... 24 years, 7 months

William M. Perry

Just wanted to make sure that I have everything straight with all the discussions going on. - Items in the UI should me modified with a 'path' to the object, derived from the names of the widgets. This is similar to ben's proposal at http://www.666.com/xemacs/lisp-interface.html (look for 'Toolbar Interface Changes'. I would propose using a full path instead of just a caption, because then names do not have to be _globally_ unique. - The path used would be a new data type so that the 'get' and 'put' methods for it could be overriden easily. All property modifications done after the gui was instantiated will be made with these calls. - Instead of an assoc list, a property list would be the representation of the widget properties. - Should use real faces to specify the 'look' of a widget - Allows us to have color names based on window systems, etc. - Should we allow inline face definitions? What would they look like? Customize-like property lists? How to specify the name? - Should we automagically update the widget properties when a face changes, or do we require a property change as well? Andy does automatic updating for the toolbars, but how expensive is it? Will it be prohibitively expensive when we get large user interfaces? - There has been some dissension on whether this is simply another 'glyph' representation or not. I don't think so. I think the overall layout of UIs should be the same across windowing systems, and these won't be embedded in a buffer or an emacs frame, so those types of conditionals in a glyph wouldn't be useful. Using faces takes care of colors/etc. Does that about sum it up? I think the main sticking point is the automatic updating of faces (perhaps not in the first release?) and whether to use a glyph representation. -Bill P.

2 participants
1 comments

dialog boxes completely broken 24 years, 7 months

Martin Buchholz

Latest 21.2. Please fix. Looks like a Ben bug. xemacs -vanilla -q C-x C-f RET ~/.emacs RET Modify buffer. Use the Revert Buffer menu entry in the File menu. A dialog box appears with the entries "%_Yes" "%_No" "%_Cancel". No matter which is selected, I get "please answer the dialog box". Worse, the error won't go away. It still thinks there's a dialog box to answer. Even worse, this behavior is non-quittable. C-g has no effect (here there is a difference - Solaris (with motif dialogs) is non-quittable, while on Linux with Athena dialogs, at least C-g gives me back a working XEmacs. Coredumping this xemacs via SIGQUIT gives: next-command-event(#<empty-event>) byte-code("..." [next-command-event event misc-user-event-p event-object yes throw ynp-done t no nil abort menu-no-selection-hook signal quit button-release-event-p beep message "please answer the dialog box"] 3) # (catch ynp-done ...) # bind (echo-keystrokes event prompt) yes-or-no-p-dialog-box("Revert buffer from file /usr/local/x/build/mos+/src/.emacs? ") # bind (prompt) yes-or-no-p("Revert buffer from file /usr/local/x/build/mos+/src/.emacs? ") # bind (file-name auto-save-p opoint preserve-modes noconfirm ignore-auto) #<compiled-function (&optional ignore-auto noconfirm preserve-modes) "...(261)" [revert-buffer-function ignore-auto noconfirm opoint recent-auto-save-p buffer-auto-save-file-name file-readable-p y-or-n-p "Buffer has been auto-saved recently. Revert from auto-save file? " auto-save-p buffer-file-name file-name error "Buffer does not seem to be associated with any file" buffer-modified-p nil found revert-without-query rx --dolist-temp--89016 string-match t yes-or-no-p format "Revert buffer from file %s? " run-hooks before-revert-hook verify-visited-file-modtime buffer-backed-up buffer-undo-list default-value after-revert-hook local-variable-p local-hook local-hook-p global-hook buffer-read-only revert-buffer-insert-file-contents-function file-exists-p "File %s no longer exists!" unlock-buffer insert-file-contents after-find-file preserve-modes set-default revert-buffer-internal-hook make-local-variable kill-local-variable] 7 876055 (list (not current-prefix-arg))>(t) call-interactively(revert-buffer) funcall(call-interactively revert-buffer) # bind (widget-callback-current-channel) (let ((widget-callback-current-channel #<x-frame "emacs" 0x2623>)) (funcall (quote call-interactively) (quote revert-buffer))) ) eval((let ((widget-callback-current-channel #<x-frame "emacs" 0x2623>)) (funcall (quote call-interactively) (quote revert-buffer)))) # (condition-case ... . error) # (catch top-level ...)

2 participants
1 comments

XEmacs frame as a glyph instantiator? 24 years, 7 months

William M. Perry

Would it be possible to create a 'xemacs' glyph type? This way you could put a XEmacs 'frame' inside a layout with the new stuff andy has done. -Bill P.

2 participants
1 comments

Re: Milestone 1 submission... 24 years, 7 months

William M. Perry

Andy Piper <andy.piper(a)bea.com> writes: > At 08:58 AM 4/19/00 -0500, William M. Perry wrote: > >Good point... Does the current widget stuff handle changes to faces though? > >Or is it a 'you get the colors from the face at instantiation time, and no > >changes afterwards'? Or do we require a separate call to > >set-glyph-property? > > Colors (and fonts) get updated dynamically. I've had too many complaints > about colors in the tab widget for it to be otherwise. So for every face property change you have to loop thru the entire widget heirarchy and check whether they are using that face? -Bill P.

2 participants
1 comments

RE: proposed Eistring interface 24 years, 7 months

Bill Tutt

>From Unicode's FAQ: (http://www.unicode.org/unicode/faq) """ Q: Will UTF-16 ever be extended to more than a million characters? A: As stated, the goal of Unicode is not to encode glyphs, but characters. Over a million possible codes is far more than enough for this goal. Unicode is *not* designed to encode arbitrary data. If you wanted, for example, to give each "instance of a character on paper throughout history" its own code, you might need trillions or quadrillions of such codes; noble as this effort might be, you would not use Unicode for such an encoding. No proposed extensions of UTF-16 to more than 2 surrogates has a chance of being accepted into the Unicode Standard or ISO/IEC 10646. """ A good example of Unicode encoding characters but not glyphs are the CJK (Chinese, and Japanese, and Korean) Unicode code points. If i recall, for a given unicode character in these ranges its non uncommon for Chinese, Japanese, and Korean to have different glyphs associated with these code points. I don't think any sane person would expect to have a non UTF-16 encodeable character accepted into Unicode for anytime in the upcoming future, unless we suddenly discover several alien races (that also use ideographs) and need to record their documents in Unicode document stores. In other words, the fact that UTF-16 doesn't encode all 4million code points isn't that big of a deal. I will note that other people have told me that glibc defines wchar_t as a UCS-4 type. Bill > From: Ben Wing [mailto:ben＠666.com] > > > surrogates can only encode 1,000,000 chars. ucs-4 encodes > 4,000,000,000 chars. > is there another extension mechanism to handle the rest? > > Bill Tutt wrote: > > > > From: Ben Wing [mailto:ben＠666.com] > > > "Stephen J. Turnbull" wrote: > > > > > > > (3) We may want to be a little bit careful with the > notion of the > > > > default internal representation. I can see that a default > > > > internal representation of UCS-2 (UTF-16, I presume > is what you > > > > really mean?) would be attractive. So what happens > if you have > > > > data that is not representable in the default internal > > > > representation? Do we just tell those users to get lost? > > > > > > > > It would be kind of weird if the default internal > representation > > > > that Eistrings dealt with was UCS-2 but UTF-8 > representation was > > > > available in buffers, which you don't rule out. > > > > > > by its nature, the default int. rep. must be able to > > > represent all chars. that > > > would rule out utf16 if we have more than 1,000,000 and some > > > chars. but it > > > doesn't rule out ucs4, or some utf16 extension that could > > > encode gigs o' chars, > > > etc. > > > > > > > To clarify UTF-16 can represent all characters in UCS-4. > UTF-16, just like > > UTF-8 breaks that annoying simplification that all > characters are fixed > > width. As a happy concidence, the only difference between > UTF-16 and UCS-2 > > is knowing where the character boundaries are. A UTF-16 > encoding of a > > unicode character (e.g. U+000E0020) is itself two valid > UCS-2 characters. > > This is what the surrogate pair range in the Unicode code > space is for. > > > > Making things completly Unicode aware isn't as easy as some > people think, > > have a gander at some of the stuff on www.unicode.org if you haven't > > recently. (esp. the techincal reports) > > e.g. Implementing a regular expression engine that supports > a good chunk of > > Unicode's "features" is very non-trivial, especially if you > don't want it to > > take forever. > > > > Bill

2 participants
1 comments

RE: proposed Eistring interface 24 years, 7 months

Bill Tutt

> From: Ben Wing [mailto:ben＠666.com] > "Stephen J. Turnbull" wrote: > > > (3) We may want to be a little bit careful with the notion of the > > default internal representation. I can see that a default > > internal representation of UCS-2 (UTF-16, I presume is what you > > really mean?) would be attractive. So what happens if you have > > data that is not representable in the default internal > > representation? Do we just tell those users to get lost? > > > > It would be kind of weird if the default internal representation > > that Eistrings dealt with was UCS-2 but UTF-8 representation was > > available in buffers, which you don't rule out. > > by its nature, the default int. rep. must be able to > represent all chars. that > would rule out utf16 if we have more than 1,000,000 and some > chars. but it > doesn't rule out ucs4, or some utf16 extension that could > encode gigs o' chars, > etc. > To clarify UTF-16 can represent all characters in UCS-4. UTF-16, just like UTF-8 breaks that annoying simplification that all characters are fixed width. As a happy concidence, the only difference between UTF-16 and UCS-2 is knowing where the character boundaries are. A UTF-16 encoding of a unicode character (e.g. U+000E0020) is itself two valid UCS-2 characters. This is what the surrogate pair range in the Unicode code space is for. Making things completly Unicode aware isn't as easy as some people think, have a gander at some of the stuff on www.unicode.org if you haven't recently. (esp. the techincal reports) e.g. Implementing a regular expression engine that supports a good chunk of Unicode's "features" is very non-trivial, especially if you don't want it to take forever. Bill Not a MS PR guy, etc...

2 participants
1 comments

intermittent errors when using viper 24 years, 7 months

Maurice S. Barnum

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 (beta32) "Kastor & Polydeukes" [Lucid] (i686-pc-linux) of Fri Mar 24 2000 on blitz.inprise.com configured using `configure --with-modules --with-site-modules=yes --with-site-lisp=yes' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: while using viper, i'll occassionally see an error message like this: ---- (138) (error/warning) Error in `post-command-hook' (setting hook to nil): (wrong-type-argument extent-live-p #<extent>) ---- a backtrace from a subsequent occurrence: Signaling: (wrong-type-argument extent-live-p #<destroyed extent>) viper-overlay-put(#<destroyed extent> face nil) viper-hide-replace-overlay() viper-change-state-to-vi() viper-mode() #<compiled-function (buf) "...(59)" [buf get-buffer buffer-name major-mode viper-vi-state-mode-list viper-current-state emacs-state viper-mode viper-emacs-state-mode-list viper-change-state-to-emacs viper-insert-state-mode-list insert-state viper-change-state-to-insert] 3>(#<buffer "*Article*">) mapcar(#<compiled-function (buf) "...(59)" [buf get-buffer buffer-name major-mode viper-vi-state-mode-list viper-current-state emacs-state viper-mode viper-emacs-state-mode-list viper-change-state-to-emacs viper-insert-state-mode-list insert-state viper-change-state-to-insert] 3> (#<buffer "*mail*"> #<buffer "xemacs-21.2＠ftp"> #<buffer "beta＠ftp"> #<buffer "*ftp ftp(a)ftp.xemacs.org*"> #<killed buffer> #<killed buffer> #<buffer "*Summary nnimap+mail:INBOX*"> #<buffer " *canonical address*"> #<buffer " *canonical address*"> #<buffer " *extract address components*"> #<buffer " *extract address components*"> #<buffer " *canonical address*"> #<buffer " *canonical address*"> #<buffer " *extract address components*"> #<buffer " *extract address components*"> #<buffer "*Article*"> #<buffer " *canonical address*"> #<buffer " *canonical address*"> #<buffer " *extract address components*"> #<buffer " *extract address components*"> #<buffer " *canonical address*"> #<buffer " *canonical a! ! ddress*"> #<buffer " *extract address components*"> #<buffer " *extract address components*"> #<buffer " *canonical address*"> #<buffer " *canonical address*"> #<buffer " *extract address components*"> #<buffer " *extract address components*"> #<buffer " *canonical address*"> #<buffer " *canonical address*"> #<buffer " *extract address components*"> #<buffer " *extract address components*"> #<buffer "*Article*"> #<buffer " *canonical address*"> #<buffer " *canonical address*"> #<buffer " *extract address components*"> #<buffer " *extract address components*"> #<buffer " *canonical address*"> #<buffer " *canonical address*"> #<buffer " *extract address components*"> #<buffer " *extract address components*"> #<buffer "*Article*"> #<buffer " *canonical address*"> #<buffer " *canonical address*"> #<buffer " *extract address components*"> #<buffer " *extract address components*"> #<buffer " *canonical address*"> #<buffer " *canonical address*"> #<buffer " *extract address component! ! s*"> #<buffer " *extract address components*"> #<buffer "*Article*">)) set-viper-state-in-major-mode() run-hooks(set-viper-state-in-major-mode) viper-post-command-sentinel() Recent keystrokes: x / t r a c e 2 TAB RET t r a c e 2 . c p p BS BS BS BS BS BS BS BS BS BS . . / t r a c e 2 . c p p RET C-x C-f / f t p ＠ f t p . x e a BS m a c s . o r g : / p u b / x e m a c s / b e t a RET C-s b e t a C-s C-s C-s C-g C-g M-> RET q q misc-user Recent messages (most recent first): Loading emacsbug...done Loading emacsbug... Reading directory /ftp＠ftp.xemacs.org:/pub/xemacs/beta/xemacs-21.2/...done Reading directory /ftp＠ftp.xemacs.org:/pub/xemacs/beta/xemacs-21.2/... Listing xemacs-21.2/...done Listing xemacs-21.2/... Quit: isearch Reading directory /ftp＠ftp.xemacs.org:/pub/xemacs/beta/...done Reading directory /ftp＠ftp.xemacs.org:/pub/xemacs/beta/... Loading dired...done ----------

1 participants
0 comments

Re: PCL-CVS 24 years, 7 months

Michael Sperber

>>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: Gunnar> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> >>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: >> Gunnar> let me know if you want me to test your package. >> >> That would be nice. I've now checked it in. Gunnar> when pressing '=' to get diffs against the repository I get: Gunnar> Signaling: (wrong-type-argument stringp nil) Gunnar> re-search-forward(nil nil t) Gunnar> diff-parse-hunks() Gunnar> diff-mode() Gunnar> eval((diff-mode)) Gunnar> cvs-sentinel(#<process "cvs" pid 10633 state:exit> "exited abnormally with code 1\n") Gunnar> diff-parse-hunks uses diff-hunk-pattern which is normally set to Gunnar> something sensible by diff, but this doesn't happen here as we call Gunnar> diff-mode directly. That's why cvs-compat.el has this: (defun cvs-prepare-diff-mode (flags) "Gross hack to support XEmacs's diff-mode." (if (boundp 'diff-hunk-pattern) ; recognize old diff.el from EFS/Dired (catch 'done (let ((flags (or flags (list nil)))) (while flags (let ((patterns (assq (car flags) diff-search-pattern-alist))) (if patterns (progn (setq diff-old-file-pattern (nth 2 patterns) diff-new-file-pattern (nth 3 patterns) diff-hunk-pattern (nth 1 patterns)) (throw 'done nil))) (setq flags (cdr flags)))))))) Doesn't it get called for you? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: PCL-CVS 24 years, 7 months

Gunnar Evermann

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > >>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > Gunnar> let me know if you want me to test your package. > > That would be nice. I've now checked it in. when pressing '=' to get diffs against the repository I get: Signaling: (wrong-type-argument stringp nil) re-search-forward(nil nil t) diff-parse-hunks() diff-mode() eval((diff-mode)) cvs-sentinel(#<process "cvs" pid 10633 state:exit> "exited abnormally with code 1\n") diff-parse-hunks uses diff-hunk-pattern which is normally set to something sensible by diff, but this doesn't happen here as we call diff-mode directly. Gunnar

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