July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 26 years, 1 month

Jan Vroonhof

Raymond Toy <toy(a)rtp.ericsson.se> writes: > No, it's not Window NT native. I've seen exactly the same things > (except with vc-cc) on Solaris. This happened right after some > changes that were made in revert-buffer or something like that. I > vaguely remember someone complaining that font-lock appeared to get > run twice on revert-buffer. Now it does't even get run once. :-( Can one of you guess step through that code and see where the font-locking gets lost? > (This might not be quite right. My mail archives do go back far > enough.) I see what you mean now. I think you mean this stuff from font-lock.el ;; If the buffer is about to be reverted, it won't be fontified afterward. (defun font-lock-revert-setup () (setq font-lock-fontified nil)) ;; If the buffer has just been reverted, normally that turns off ;; Font Lock mode. So turn the mode back on if necessary. ;; sb 1999-03-03 -- The above comment no longer appears to be operative as ;; the first call to normal-mode *will* restore the font-lock state and ;; this call forces a second font-locking to occur when reverting a buffer, ;; which is wasteful at best. ;(defalias 'font-lock-revert-cleanup 'turn-on-font-lock) (defun font-lock-revert-cleanup ()) a. Does undoing Steve's change help for your guys? b. Why _does_ the font-lock-ing work for me? I am using lazy-shot.el, are you? Jan P.S. I am using lazy-shot.el that sim

1 participants
0 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 26 years, 1 month

Raymond Toy

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >>> Currently vc-revert-buffer1 is plain broken, because it looses >>> fontification of font-locked buffers. Jan> No it isn't :-) Something is wrong with font-lock and Jan> insert-file-contents on your side. APA> OK. I'll dig into this. May have to do with the fact that I'm on APA> Windows NT native. No, it's not Window NT native. I've seen exactly the same things (except with vc-cc) on Solaris. This happened right after some changes that were made in revert-buffer or something like that. I vaguely remember someone complaining that font-lock appeared to get run twice on revert-buffer. Now it does't even get run once. :-( (This might not be quite right. My mail archives do go back far enough.) I think my font-lock and insert-file-contents are ok, since I don't think I've done anything special to them. Ray

1 participants
0 comments

Re: image mode broken? 26 years, 1 month

Karl Kleinpaste

I have no idea why you're being asked for an encryption key, but it's been a while since image auto-decoding was disabled during find-file. You have to do something like (image-decode-png (point-min) (point-max)) to render the image.

1 participants
0 comments

image mode broken? 26 years, 1 month

Neal D. Becker

Has anyone else seen this? Recently (last beta or two), visiting an image file no longer works. For example, find-file on junk.png doesn't show an image. It asks for an encryption key instead (this is from crypt). I haven't changed my config. My installation has all the image libs: uname -a: Linux nbeckerpc.hns.com 2.2.10 #14 Wed Jul 7 08:45:55 EDT 1999 i686 unknown ../../xemacs-21/configure '--error-checking=none' XEmacs 21.2-b18 "Toshima" configured for `i686-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-21 What installation prefix should install use? /usr/local 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 -g -O3 -Wall -Wno-switch 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? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging.

2 participants
1 comments

FYI mailcrypt-3.5.4 26 years, 1 month

Neal D. Becker

http://freshmeat.net/news/1999/07/26/933042852.html

1 participants
0 comments

Re: patch very preliminary support for /dev/pts/ 26 years, 1 month

Neal D. Becker

I don't know if you saw my other post, but I'm told that this code should work on *any* glibc2.1 system. Could you try it?

2 participants
1 comments

Re: maybe a menubar bug in 21.1.4 26 years, 1 month

SL Baur

Jeff Miller <jmiller(a)smart.net> writes in xemacs-beta(a)xemacs.org: > I'm kinda confused on this one, so I'd like to see if anyone can > duplicate it. > On my Linux box here at home I can build xemacs 21.1.4 without > menubars without a problem. I tried the same thing on my Solaris > workstation at work today. The compile goes ok until the final link > when it bitches about a missing external reference to > menubar_show_keybindings in gui.c. If I add a "#ifdef HAVE_MENUBARS" > wrapper around that little "if" statement in gui.c, xemacs compiles and > dumps fine. > has anyone else seen this or even begin to have a clue why? Possibly differences in the linker. I don't know. Have you tried it on Solaris with a full GNU toolset (ie. with gas and gnuld)? I just tried a build with X without menubars with 21.2 and it bombs out here: gcc -c -g -O3 -Demacs -I. -DHAVE_CONFIG_H -I/usr/lib/locale/ja/wnn/demo/include -I/usr/local/include -I/usr/local/canna/include -I/usr/dt/include -I/usr/local/X11R6/include /usr/local/devel/xemacs-21.2/src/scrollbar-x.c /usr/local/devel/xemacs-21.2/src/scrollbar-x.c: In function `update_one_scrollbar_bs': /usr/local/devel/xemacs-21.2/src/scrollbar-x.c:189: `XtNuseBackingStore' undeclared (first use in this function) /usr/local/devel/xemacs-21.2/src/scrollbar-x.c:189: (Each undeclared identifier is reported only once /usr/local/devel/xemacs-21.2/src/scrollbar-x.c:189: for each function it appears in.) make[1]: *** [scrollbar-x.o] Error 1 make[1]: Leaving directory `/usr/local/devel/miho-test/src' make: *** [src] Error 2 and I see your problem with a build against 21.1: Undefined first referenced symbol in file menubar_show_keybindings gui.o ld: fatal: Symbol referencing errors. No output written to temacs collect2: ld returned 1 exit status

2 participants
1 comments

Re: maybe a menubar bug in 21.1.4 26 years, 1 month

Jan Vroonhof

Jeff Miller <jmiller(a)smart.net> writes: > > has anyone else seen this or even begin to have a clue why? > Maybe some issue with Motif vs non-Motif? Jan

2 participants
1 comments

Re: Image lib 26 years, 1 month

Didier Verna

Hrvoje Niksic <hniksic(a)srce.hr> writes: > SL Baur <steve(a)xemacs.org> writes: > > > We went through the exercise of using the ImageMagick graphics > > library some time back and it was so successful that we ripped it > > out and put the old code back in. > > I'm afraid Imlib sucks much worse than ImageMagick. It looks rather powerfull (there is a caching mechanism directly implemented in it etc) but the latest version has a bug which makes all applications crash on TrueColor displays. It's been a while that this bug has been identified. As always, the problem is to get the balance right between reinventing the wheel and getting hooked on some external work that we don't have control on. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: Image lib 26 years, 1 month

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > We went through the exercise of using the ImageMagick graphics > library some time back and it was so successful that we ripped it > out and put the old code back in. I'm afraid Imlib sucks much worse than ImageMagick.

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