June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

sample.emacs to break custom-set-face in 21.2b16 under native NT 25 years, 5 months

Adrian Aichner

This may well be related to what Norbert and Jan are discussing here. My site-start.el always does (load-file (locate-file "sample.emacs" (list data-directory))) first. This way I can notice breakage/new features right away. The former is the case now. I noticed in 21.2b16 that my (custom-set-faces '(font-lock-comment-face ((t (:foreground "forest green" :bold t)))) '(font-lock-doc-string-face ((t (:foreground "brown" :bold nil))))) fail to work. Colors are OK, but they are rendered italic and I cannot correct them via custom. Turns out, these lines from sample.emacs: (copy-face 'italic 'font-lock-comment-face) (copy-face 'font-lock-comment-face 'font-lock-doc-string-face) cause the problem. I have no idea where the breakage happened but I'm pretty sure someone will. Does sample.emacs need adjustment? Is (copy-face ...) broken? Is (custom-set-face ...) broken? Regards, Adrian -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: colourless xemacs on NT :-( 25 years, 5 months

Jan Vroonhof

Norbert Koch <n.koch(a)delta-ii.de> writes: > All right, lessee ... I take font-lock-comment-face. It should be set > to its default value, blue4. > > (face-foreground 'font-lock-comment-face) > #<color-specifier global=<unspecified> fallback=#<color-specifier > #global=<unspecified> fallback=(((mswindows) . "black")) 0x194> > #0x4b16> Ouch.. This is very wrong. What does it look like under -vanilla? What happens when you run under vanilla and then evaluate (reset-face 'font-lock-comment-face 'nil '(custom)) in a scratch buffer? Jan

1 participants
0 comments

ediff and Win95 25 years, 5 months

Henk van Dorp

Dear all, Unwittingly becoming a kind of beta-tester (win95 box, no build facilities, using Fabrice Popineau's XEmacs21.2.b14 binaries and distribution files), using only elementary facilities of XEmacs, I came across the following problem, In XEmacs 21.2 "Dionysos" [Lucid] (i586-pc-win32) of Tue May 18 1999 on NEVERYON configured using `configure UNKNOWN' Through the menu: Comparing two buffers (.emacs and EMACS~1.NEW): > Loading ediff... > Loading ediff...done > Computing differences between .emacsR4WTUl and EMACS~1.NEWR4WHTD ... > Errors in diff output. Diff output is in #<buffer "*ediff-diff*"> which says: > /CYGNUS/CYGWIN~1/H-I586~1/BIN/diff.exe: C:TempEMACS~1.NEWR4WHTD: No such file or directory First a remark on the misleading error message: it skips /'s and or \'s and the essential c:/ before cygnus. Superfluous that both files were present, so I thought something was terribly amiss deep down inside, BUT, > Computing differences between XEMACSW.BAK and XEMACSW.BAT ... > Buffer A: Processing difference region 0 of 1 > Buffer B: Processing difference region 0 of 1 > Processing difference regions ... done, Perhaps it has something to do with the names of the files, check that by renaming the EMACS~1.NEW to .joris ... and again ... > Computing differences between .jorisR4WUdJ and .emacsR4WhnP ... > Buffer A: Processing difference region 0 of 6 > Buffer B: Processing difference region 0 of 6 > Processing difference regions ... done ergo, twas in the name ahah. To be on the safe side: Copy [-p]: 1 file. .joris into EMACS~1.NJU (so two identical files!) > Computing differences between .jorisJ6-e9D and EMACS~1.NJUJ6-rHK ... > Errors in diff output. Diff output is in #<buffer "*ediff-diff*"> > /CYGNUS/CYGWIN~1/H-I586~1/BIN/diff.exe: C:TempEMACS~1.NJUJ6-rHK: No such file or directory Also, now try: comparing two files (and not buffers) > Reading file c:\xemacs\.emacs ... > Reading file c:\xemacs\EMACS~1.NJU ... > Computing differences between .emacs and EMACS~1.NJU ... > Errors in diff output. Diff output is in #<buffer "*ediff-diff<2>*"> which says: > /CYGNUS/CYGWIN~1/H-I586~1/BIN/diff.exe: c:xemacsEMACS~1.NJU: No such file or directory > Computing differences between .emacs.~1~x5-0Mr and .emacsx5-oLJ ... > Errors in diff output. Diff output is in #<buffer "*ediff-diff*"> which says: > /PROGFILE/CYGNUS/CYGWIN-B20/H-I586-CYGWIN32/BIN/diff.exe: C:temp.emacs.~1~x5-0Mr: No such file or directory I think it has something to do with the ~ in the filename, is it the 8.3 filenaming system?. A bug in XEmacs, in cygnus' diff, or, still, a beginners mistake in initialising XEmacs (by not RT complete FM)?? For that reason, could someone please provide me with an .emacs file that correctly identifies my keypad-keys, so that I can put (e.g.) cut, copy and paste under those keys. I tried many things, but none worked so far (e.g. what kind of /term/typefile.el can I (do I have to) use?) Thanks a lot (in advance, (also for XEmacs in general :-)) for your help; in any case, your gracious attention is much appreciated. Cheers, Henk van Dorp -- (vandorp(a)ieee.org)

1 participants
0 comments

Re: colourless xemacs on NT :-( 25 years, 5 months

Norbert Koch

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Hi Jan, thanks for the reply. > The custom system now uses the XEmacs-ly correct way of setting faces > somehow this tickling a problem on NT. It works correctly under X. I see. > Please give more info. Pick a face that is wrong and list All right, lessee ... I take font-lock-comment-face. It should be set to its default value, blue4. (face-foreground 'font-lock-comment-face) #<color-specifier global=<unspecified> fallback=#<color-specifier #global=<unspecified> fallback=(((mswindows) . "black")) 0x194> #0x4b16> M-x customize-face RET font-lock-comment-face RET Font Lock Comment Face: (sample) * [State]: this face is unchanged from its standard setting. Font Lock mode face used to highlight comments. Attributes: * Foreground: blue4 (sample) * Background: (sample) [...] which looks ok. Also the Foreground:'s line (sample) is blue4. Correct. The (sample) in the Font Lock Comment Face: line is black, though. Nothing changes, if I change the default settings and thus create an entry in the custom-set-faces section of my customisation file or .emacs. The only faces that are displayed correctly are the one I've explicitly defined and setq'ed. Do you need more information? L8er, norbert.

1 participants
0 comments

Re: colourless xemacs on NT :-( 25 years, 5 months

Adrian Aichner

>>>>> "lykos" == Norbert Koch <n.koch(a)delta-ii.de> writes: Hello Norbert, (emacs-version) "XEmacs 21.2 (beta16) \"Sumida\" [Lucid] (i586-pc-win32) of Sun Jun 13 1999 on ZJ75T" shows correct face colors for me. Some face properties seem wrong though. My font-lock-comment-face is rendered italic instead of bold (which I have set via custom. What do you see when you: runxemacs -vanilla M-x find-library RET simple RET M-x font-lock-mode RET Do you get colors again? Using Options->Edit Faces... Is face "Bold" rendered in bold-face? Is face "Italic" rendered in italic? All this works for me. Regards, Adrian lykos> Hi, lykos> after installing b16 (also after applying , I only have a lykos> grayscaled XEmacs which is sort of colourless so to lykos> speak. Funny thing is, when I look into the customisation lykos> variables (eg font-lock-faces) I see the correct faces lykos> displayed there, ie the correct colours are shown. Bugger lykos> is, they aren't used, so it seems, some global variable has lykos> been messed up with. lykos> If I set colours by hand using set-face-foreground, lykos> everything looks fine, but this is tedious :-) lykos> Has anybody else seen this feature? Dmitry, was your lykos> trouble along the same lines? lykos> TIA, norbert. -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: colourless xemacs on NT :-( 25 years, 5 months

Jan Vroonhof

Norbert Koch <n.koch(a)delta-ii.de> writes: > colourless so to speak. Funny thing is, when I look into the > customisation variables (eg font-lock-faces) I see the correct faces > displayed there, ie the correct colours are shown. Bugger is, they > aren't used, so it seems, some global variable has been messed up > with. The custom system now uses the XEmacs-ly correct way of setting faces somehow this tickling a problem on NT. It works correctly under X. > If I set colours by hand using set-ace-foreground, everything looks > fine, but this is tedious :-) > > Has anybody else seen this feature? Dmitry, was your trouble along the > same lines? Please give more info. Pick a face that is wrong and list 1. The color you think it should be. 2. The custom-set-faces line specific to this font. 3. The result of (face-foreground '<face-name>) 4. Whether changing something in customize-face and then pressing "Set" works. Jan

1 participants
0 comments

Re: Variable initialization fixes 25 years, 5 months

Adrian Aichner

>>>>> "acs" == acs <acs(a)ne.mediaone.net> writes: Hello Vin, building of 21.1 from CVS fails, alas. Please see my recent build report to xemacs-beta. ntproc.obj : error LNK2001: unresolved external symbol _GET_C_STRING_FILENAME_DATA_ALLOCA ..\src\temacs.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' I can investigate more this evening, if you want me to. Regards, Adrian acs> I committed this patch to 21.1.3. I got 3 minor rejects when acs> applying it, but they all seemed simple to remedy. Someone acs> please try to build XEmacs-21.1 from CVS for MS Windows soon, acs> before I cut the 21.1.3 tarball. I hope to cut the tarball acs> no later than Wednesday. acs> Thanks, acs> vin -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

colourless xemacs on NT :-( 25 years, 5 months

Norbert Koch

Hi, after installing b16 (also after applying , I only have a grayscaled XEmacs which is sort of colourless so to speak. Funny thing is, when I look into the customisation variables (eg font-lock-faces) I see the correct faces displayed there, ie the correct colours are shown. Bugger is, they aren't used, so it seems, some global variable has been messed up with. If I set colours by hand using set-face-foreground, everything looks fine, but this is tedious :-) Has anybody else seen this feature? Dmitry, was your trouble along the same lines? TIA, norbert.

1 participants
0 comments

Re: [PATCH] `LDAP' as opaque data type 25 years, 5 months

Oscar Figueiredo

>>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: >> [...] My patch is a little more extensive than yours and handles the errors in >> compliance with the current IETF draft-ietf-ldapext-ldap-c-api-02. >> Furthermore if I read it well, yours should fail if you use libraries >> without liblber. William> Are there any such? Netscape's Directory SDK on Solaris at least. Oscar

1 participants
0 comments

Re: LDAP support enhancements... (XEmacs) 25 years, 5 months

Oscar Figueiredo

>>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: William> I think we could pretty easily do _really_ asynchronous searches. We can William> actually get the socket out of the LDAP library by using William> #ifdef HAVE_LDAP_GET_OPTION William> LBER_SOCKET fd; William> if (ldap_get_option(ld,LDAP_OPT_DESC,&fd) != LDAP_SUCCESS) William> { William> /* Could not get the descriptor, bail */ William> return(-1); William> } William> #else William> int fd = ld->ld_sb.sb_sd; William> #endif William> /* Somehow add the socket to the list of fd's the event loop is William> ** waiting on. If the event loop sees the FD as getting data, William> ** go into a do { } while (1) loop calling ldap_result() with a William> ** 0-second timeout. William> ** William> ** If we get a '0' back indicating a timeout, we must have William> ** gotten only a partial result back, and there are no more records to be William> ** read, so break out of the loop and handle the rest of the events. William> ** William> ** Otherwise, we got a result back, call a callback function that William> ** just gets a single LDAP record, and continue through the loop. William> */ William> This would be really nice, I think. We'd just have to add an William> 'event-stream-select-fd' that would be really close to the existing William> event-stream-select-process William> -Bill P. Sounds nice but to tell the truth I've never experienced a situation where I wished we had that feature so I really don't know if it's worth the effort given the sensitivity of the code we need to plug into. But if you feel it's important then definitely go for it, I am sure I will be happy to use it in the end. Oscar

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