June 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: toolbar picks up -bg 27 years, 4 months

Didier Verna

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Why? I think the opposite is true. When you use a bevel to > distinguish non-writable regions on the screen, you no longer > need to use a color change to distinguish them. Yes, you need a color change. Let's say there are 2 kinds of user interface: the ones consisting exclusively of widgets, and the ones consisting of a working area (in which the user focuses 80% of his time) and some widgets around. XEmacs belongs to the second category. If you look at an XEmacs frame, you notice that the relative surface covered by widgets is small. In those conditions, I can assure you that for the majority of people, the bevels *only* (which are colors close to the original one anyway) are not a sufficient clue. The situation might be different for apps in which you have only widgets, although some of them like xv provide a different background color for the container by default. > I find the "this looks ugly" arguments irrelevant, since you can > customize specific colors to your liking after you affect a global > change. If "this looks ugly" for the majority of people, then the argument becomes relevant IMHO. > You can instead honor the user's global background/foreground color > choice, which they may have made for a good reason, such as "reading > black on gray80 text hurts my eyes." > [...] > You cannot easily restore the ability to affect color changes globally > once it is gone. In fact, before the code changes I made, you could not > do it at all. That ability is what I'm trying to preserve. I perfectly understood your goal. It's just that honoring the user's request by simply using his -bg and -fg for widgets is totally bogus. When Joe user says "-bg this -fg that", he means *before anything else* that he prefers a dark background and a bright foreground instead of the opposite. And this, maybe, should be respected by the widgets too. However, I can guarantee that Joe will be surprised to see the widgets turn the same color as the text, and we'll have tons of bug reports regarding this. There might be a way to conciliate our views: something acceptable for me would be that the widgets, by default, get a similar appearance to the text, but brighter if the text background is dark, or darker otherwise. This can be accomplished by computing new colors in a way similar to what is done to compute shadow colors. Then the widgets will "honor" the user's requests, and will still be visually different. This sounds possible for 21.1. But for 21.0, please, leave the widgets alone. Outside of -bg and -fg. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C214 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

6 participants
10 comments

RE: [comp.emacs,gnu.emacs,alt.religion.emacs] ANNOUNCING papercli p-mode 27 years, 4 months

Damon Lipparelli

I've heard that within Microsoft it's called "TFC" (the fucking 'clip).... -lipp >>>> -----Original Message----- >>>> From: SL Baur [mailto:steve＠vmailer.xemacs.org] >>>> Sent: Wednesday, June 17, 1998 12:11 PM >>>> To: xemacs-beta(a)xemacs.org >>>> Subject: Re: [comp.emacs,gnu.emacs,alt.religion.emacs] ANNOUNCING paperclip-mode >>>> >>>> >>>> Damon Lipparelli <lipp(a)primus.com> writes: >>>> >>>> > I'm currently investigating methods of preventing this >>>> virus from infesting XEmacs.... >>>> >>>> There's not a chance of that so long as it remains `ASCII >>>> graphics'. >>>> >>>> I wish someone would make up real graphics though ... :-) >>>>

1 participants
0 comments

Re: [comp.emacs,gnu.emacs,alt.religion.emacs] ANNOUNCING paperclip-mode 27 years, 4 months

Hrvoje Niksic

Damon Lipparelli <lipp(a)primus.com> writes: > I'm currently investigating methods of preventing this virus from > infesting XEmacs.... Gee, and I proposed that he uses real images in XEmacs! -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If anything goes wrong, blame the random-number generator!

1 participants
0 comments

Re: [comp.emacs,gnu.emacs,alt.religion.emacs] ANNOUNCING paperclip-mode 27 years, 4 months

SL Baur

Damon Lipparelli <lipp(a)primus.com> writes: > I'm currently investigating methods of preventing this virus from infesting > XEmacs.... There's not a chance of that so long as it remains `ASCII graphics'. I wish someone would make up real graphics though ... :-)

1 participants
0 comments

[Success] 21.0 "Swedish Landrace" XEmacs Lucid on i386-pc-cygwin3 2 27 years, 4 months

Michael Hill

Fantastic! Builds with Andy's patch and works as advertized. The frame re-sizes without having to be poked with the cursor, and dialog boxes work with a top-mounted toolbar. Now it's ready for Windows. > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /binary/xemacs-21.0-b44/Installation: > (Output from most recent run of ./configure) uname -a: CYGWIN32_NT DILBERT 4.0 19.1 i686 unknown ./configure '--site-includes=/usr/local/include' XEmacs 21.0 "Swedish Landrace" configured for `i386-pc-cygwin32'. Where should the build process find the source code? /binary/xemacs-21.0-b44 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/cygwin32.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O2 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? default What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6.3/include Where do we find X Windows libraries? /usr/X11R6.3/lib Additional header files: /usr/local/include Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for JPEG image conversion. Compiling in support for PNG image conversion. Compiling in support for TIFF image conversion. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in File coding support. Compiling in support for OffiX. Compiling in EXPERIMENTAL support for Drag'n'Drop ( OffiX ). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. > /binary/xemacs-21.0-b44/beta.err does not exist!

1 participants
0 comments

[comp.emacs,gnu.emacs,alt.religion.emacs] ANNOUNCING paperclip-mode 27 years, 4 months

Damon Lipparelli

I'm currently investigating methods of preventing this virus from infesting XEmacs.... -lipp ------- Start of forwarded message ------- From: mawarkus(a)t-online.de (Matthias Warkus) Newsgroups: comp.emacs,gnu.emacs,alt.religion.emacs Subject: ANNOUNCING paperclip-mode Date: 15 Jun 1998 19:38:18 GMT Organization: Question Mark Software Message-ID: <6m3t7a$m4m$1(a)news01.btx.dtag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, today I have started learning Elisp and I did the skeleton for a Talking Paperclip mode at once. It includes ASCII art and will soon feature cabbages, Zippyisms and a doctor interface. mawa -- mawa(a)iname.com | have a look: http://www.angelfire.com/ny/mawaspace/ -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GAT/U d-(--) s:- a--- C++(++++)>$ P+(--) L++>++++>$ E++>+++ W++(-) N++ o? K w---(+) >M+ V-- PS+(++) PE(-)(--) Y+>++ >PGP++ t+(---)＠ 5>+ X-＠ >R+++＠ tv(+) b+++(++++)>$ >DI+ D(--)(---) G++ e＠(*)>++++ h! !y+ ------END GEEK CODE BLOCK------ ------- End of forwarded message -------

1 participants
0 comments

Info-validate: Some observations and questions 27 years, 4 months

Adrian Aichner

Hello $tex$?info experts! Another big texi patch from me is lurking around the corner, so beware! Using C-u M-x texinfo-format-buffer M-x Info-tagify M-x Info-validate I found some problems with Info-validate. 1. I fixed a bug which caused Info-validate to misunderstand " Menu" in the middle of a line as the start of a proper Menu. Non-Errors where genereated as a result. 2. xrefs containing spaces may be folded during paragraph filling in `texinfo-format-buffer'. This will cause false "invalid reference ..." errors. I have fixed this problem by replacing "[ \t]+" inside reference names with single spaces. Q: Is this the Right Thing to do? 3. Info-validate complains about (at least) the following invalid references. All of these are not real xrefs but rather `Notes' written in the texi sources. Constructs as ＠strong{Note:} and ＠emph{NOTE:} are wrong according to the Texinfo manual: *Caution:* Do not use `＠emph' or `＠strong' with the word `Note'; Info will mistake the combination for a cross reference. Use a phrase such as *Please note* or *Caution* instead. Q: Is it acceptable if I change all occurences from ...{note.?} to ...{[Pp]lease note.?}? The '{note' occurences: cd /u/aichner/tmp/xemacs-20/man/ find . -type d $ -name SCCS -o -name RCS $ -prune -o $ -type f -o -type l $ -name "*.texi" -exec egrep -n -i '{note' "{}" /dev/null \; Compilation started at Wed Jun 17 19:38:13 1998 ./cl.texi:3224:＠strong{Note:} This declaration remains in effect after the ./info-stnd.texi:626:＠dfn{menu} references, and ＠dfn{note} references. Menu references ./standards.texi:1340:Used in many programs to inhibit the usual output. ＠strong{Note:} every ./standards.texi:1455:＠strong{Note:} every program accepting ./texinfo.texi:703:＠dfn{Texinfo}＠footnote{Note that the first syllable of ``Texinfo'' is ./texinfo.texi:6892:word ＠samp{Note}; Info will mistake the combination for a cross ./xemacs-faq.texi:2799:＠strong{NOTE:} The single minibuffer frame may not be to everyone's ./internals/internals.texi:1698: ＠strong{Note:} This kludge only works on a few systems nowadays, and is ./internals/internals.texi:1987: ＠strong{Note:} It is potentially deadly if you declare a ＠samp{Q...} ./internals/internals.texi:4329:＠strong{Note}: When the mark method is called, garbage collection ./lispref/buffers.texi:656:;; ＠r{Note that the name of the minibuffer} ./lispref/compile.texi:486:＠emph{NOTE:} Unlike all other Emacs-lisp functions, calling this with ./lispref/debugging.texi:193: ＠strong{Note:} if you redefine a function after using ./lispref/eval.texi:112: ＠strong{Note:} it is generally cleaner and more flexible to call ./lispref/extents.texi:48: ＠emph{NOTE}: An alternative way to add properties to a buffer or ./lispref/loading.texi:650:＠strong{NOTE}: The advanced arguments of this function (anything other than a ./lispref/text.texi:1431:;; ＠r{Note that the first two lines of doc string} ./lispref/variables.texi:1090:＠strong{Note:} do not use ＠code{make-local-variable} for a hook igrep finished at Wed Jun 17 19:38:38 and the resulting damage (bad xrefs "*Note:*"): cd /export/home/tmp/xemacs-21.0-b44/info/ egrep -ni '\*Note:' *.info* /dev/null Compilation started at Wed Jun 17 19:29:19 1998 cl.info-3:757: *Note:* This declaration remains in effect after the containing internals.info-2:564: *Note:* This kludge only works on a few systems nowadays, and is internals.info-2:838: *Note:* It is potentially deadly if you declare a `Q...' variable lispref.info-12:253: *NOTE:* Unlike all other Emacs-lisp functions, calling this with lispref.info-12:683: *Note:* if you redefine a function after using `debug-on-entry' on lispref.info-7:1120: *Note:* it is generally cleaner and more flexible to call functions lispref.info-9:1045: *Note:* do not use `make-local-variable' for a hook variable. standards.info-1:1282: Used in many programs to inhibit the usual output. *Note:* every standards.info-1:1394: Used in many programs to inhibit the usual output. *Note:* every xemacs-faq.info-3:258: *NOTE:* The single minibuffer frame may not be to everyone's taste, Please advise, Adrian -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail aichner(a)ecf.teradyne.com

1 participants
0 comments

Re: toolbar picks up -bg 27 years, 4 months

Hrvoje Niksic

Charles G Waldman <cgw(a)pgt.com> writes: > Color discrimination varies widely between individuals. Some people > are colorblind. I've read that it's considered poor interface > design to distinguish interface elements by color alone - there > should also be a difference in absolute brightness level. Then we should be OK: 1) We have the bevel effect for distinguishing widget elements (modeline included) from the text area; 2) gray75 is less bright than gray80. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Your lucky number today is 29842924728. Look for it everywhere.

1 participants
0 comments

Re: compile is busted 27 years, 4 months

Raymond Toy

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Let's say I've run a compile already, and want to do it again via the > popup menu. However, the current buffer is different from the > *compilation* buffer. The new compilation assumes the > default-directory of the current buffer, which is bad > juju---especially if I'm doing a recompile which should do exactly the > same thing as the last time around. This is really annoying. I also find it rather annoying that when I run compile again, it removes the window and then creates it again. This didn't happen in the previous beta: It just left the compilation buffer wherever it was and just cleared the contents. I find the window deletion/creation visually annoying. Ray

1 participants
0 comments

Re: [Offix DnD crash] 21.0 "Swedish Landrace" on i686-pc-linux 27 years, 4 months

Jan Vroonhof

Oliver Graf <ograf(a)fga.de> writes: > It only happens for drags from within XEmacs to the same instance of > XEmacs. Drags from other apps/XEmacsens do not produce the problem. But why does it crash in the timer code? Somehow it thinks it gets an unexpected timer event. > Perhaps I can solve it the following way: I test if the window is one of this > XEmacs, and if this is true, the drag handler does not send an event to > itself, but directly creates the misc-user-event. This is ugly. Wouldn't it be better to try find the real cause? Jan

1 participants
0 comments

2025

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 June 1998