May 2001 - XEmacs-Beta - XEmacs Mailing List Archives

mouse-track-insert bug (windows native) now also in 21.4.1, 21.5-b0 22 years, 12 months

Adrian Aichner

See the thread starting at http://list-archive.xemacs.org/xemacs-beta/200006/msg00136.html I was looking forward to 21.4 for a long time because this problem was fixed there. Now, alas, the problem is also in 21.4.1 and 21.5-b0. Can we try to fix this now? I will need some help with this. Ben, one suspect is this: > From: Ben Wing <ben(a)xemacs.org> > Subject: [PATCH] misc changes, some for 21.4 > To: xemacs-patches(a)xemacs.org > Date: Sat, 28 Apr 2001 03:50:28 -0400 > Message-Id: <200104280750.DAA29568(a)gwyn.tux.org> I'm running out of time for today. Perhaps you can have a look at this. I sure miss C-double-click between buffers! C-button1 at that spot runs the command mouse-track-insert Best regards, Adrian -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

3 participants
4 comments

21.5.1: etags: buffer-tag-table-list endless loop 22 years, 12 months

Gregory Neil Shapiro

In XEmacs 21.5 (beta1) "anise" [Lucid] (i386-unknown-freebsd4.3) of Fri May 11 2001 on horsey.gshapiro.net configured using `configure --site-prefixes=/usr/local --with-database=berkdb --with-pop' After upgrading to 21.5.1 (from 21.5.0), find-tags stopped working. I tracked it down to buffer-tag-table-list and change 1.12 to that file. Specifically this: ＠＠ -185,10 +190,13 ＠＠ ;; Current directory (when (file-readable-p (concat default-directory "TAGS")) (push (concat default-directory "TAGS") result)) - ;; Parent directory - (let ((parent-tag-file (expand-file-name "../TAGS" default-directory))) - (when (file-readable-p parent-tag-file) - (push parent-tag-file result))) + ;; Parent directories + (when tags-check-parent-directories-for-tag-files + (let ((cur default-directory)) + (while (file-exists-p (setq cur (expand-file-name ".." cur))) + (let ((parent-tag-file (expand-file-name "TAGS" cur))) + (when (file-readable-p parent-tag-file) + (push parent-tag-file result)))))) ;; tag-table-alist (let* ((key (or buffer-file-name (concat default-directory (buffer-name)))) This change has a bug in that it will never get out of the while loop. Using the debugger, it would check each directory going up the tree but wouldn't stop at the root. This led to: /usr/local/src/../TAGS /usr/local/../TAGS /usr/../TAGS /../TAGS /../../TAGS /../../../TAGS ... There is always a ".." for the root directory and nothing in the code ever breaks out of the while. That is probably why the old code checked for "../TAGS" instead of setting directory to ".." and checking for the TAGS file.

1 participants
0 comments

Re: 21.5.1: dired.o can't be linked on Win9x 22 years, 12 months

Ben Wing

i just sent a patch to fix the link problems. i'll send another tomorrow that implements GetUserName. Craig Lanning wrote: > > On Fri, 11 May 2001 22:23:56 -0700 Ben Wing <ben(a)666.com> wrote: > > > > > > > Craig Lanning wrote: > > > > > > [This appears to be caused by a patch that Ben made so I am including him on > > > the cc list.] > > > > > > When I try to do a MinGW build on my Win98 system, I get a runtime error > > > about being "linked to missing export NETAPI32.DLL:NetApiBufferFree" > > > I traced this back to the function user_name_completion in dired.c. > > > > > > The functions NetApiBufferFree and NetUserEnum are not defined on Win9x > > > systems. > > > > > > What is needed from NetUserEnum? Can we get it some other way? > > > > uh ..... list of current users. i suppose there are none under windows 9x? > > > > is there a current username? how do you get it? > > Yes. > BOOL GetUserName(LPTSTR,LPDWORD) > lib: advapi32 > header: winbase.h -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.

1 participants
0 comments

jde/setnu.el 22 years, 12 months

Jeff Mincy

IN 21.1.13 xemacs, jde/setnu.el. I do (find-file " (require 'setnu) (setnu-mode) When I try to kill-line, I get the following: Signaling: (wrong-type-argument extentp nil) setnu-set-extent-property(nil setnu-next-extent #<extent [13121, 13121) setnu 0x36ade5c in buffer setnu.el<2>>) setnu-extent-at-create(13121 nil) setnu-before-change-function(13121 13122) kill-region(13121 13122) kill-line(nil) call-interactively(kill-line) BTW, it seems like jde is the wrong place for this file? Wouldn't text-modes or something be more appropriate? -jeff

3 participants
4 comments

[BUG] Font-lock refuses to turn on in some buffers 22 years, 12 months

Hrvoje Niksic

XEmacs font-lock has a "feature" where it refuses to start in buffers whose name begins with SPC. The idea begind the feature is to prevent accidental fontification of various temporary buffers. As accidental fontification goes, the argument stands. But I consider it really evil that it refuses to work even when turned on *explicitly*, and the same even when its own code turns it on. Here is a weird bug I've been seeing: Gnus tries to fontify part of the buffer by effectively doing the following: (insert (with-temp-buffer (funcall desired-major-mode) (font-lock-fontify-buffer) ... some code that forces all text-prop extents to be duplicable ... (buffer-string))) This works, but leaves everything except strings and comments unfontified. This bug had me baffled for a long time, because all my attempts to repeat it in "laboratory conditions" failed. Finally I tracked down the problem to this: font-lock-fontify-buffer temporarily sets font-lock-mode because some of its magic depends on font-lock-mode being on. But since the buffer name begins with SPC, font-lock-mode silently (which is evil!) refuses to turn itself on, and fontification fails in a random way. I think the optimization should be changed to only affect turning on font-lock with font-lock-auto-fontify and friends. If somebody explicitly turns on font-lock, either through `font-lock-fontify-buffer' or otherwise, it has to just work, regardless of what the buffer happens to be named! If that is for whatever reason undesirable, we should at least implement a `force' argument for font-lock-mode which you can call and be sure that font-lock will be used.

2 participants
2 comments

find-*-source-path 22 years, 12 months

Ben Wing

i just added this: * lib-complete.el: * lib-complete.el (find-library-source-path): New. * lib-complete.el (find-library): add a variable to control where `find-library' looks, analogous to `find-function-source-path'. should i instead call it something like `find-file-source-path' and modify find-function to use the same? or just use find-function-source-path? or other? -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.

1 participants
0 comments

Re: find-function & load-history 22 years, 12 months

Nickolay Pakoulin

intro: "SY" == Steve Youngs <youngs(a)xemacs.org> writes: SY> |--==> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes: SY> How can I make [find-function] show me [...] the installed version? SJT> (setq find-function-source-path nil) should work. SY> Nope, tried that. It doesn't work, sorry. Any other ideas? Replace in `load-history' filenames for dumped filee. Make an evil hack: (dolist (entry load-history) (when (string-match "/build/directory/" (car entry)) (setcar entry (replace-match "/installation/directory/" t t (car entry))))) Nick.

2 participants
1 comments

Re: Core dump on exit in 21.5.1 22 years, 12 months

Petr Konecny

>>>>> I previously said: Petr> I get a coredump on exit in XEmacs 21.5 (beta1) "anise" compiled and Petr> used on Debian/Linux sid box, with 2.4.4-ac5 kernel. Happens only under Petr> X windows. I have not seen anybody reporting this, so I suspect it could Petr> be Debian problem. Any clues ? After reading `configure --help` I added --with-xim=xlib and it does not dump core anymore. IMHO configure --help is inconsistent with the behaviour of configure: --with-xim=motif (*) Used in conjunction withMule support. Use either raw Xlib to provide XIM support, or the Motif XmIm* routines (when available). NOTE: On some systems bugs in X11's XIM support will cause XEmacs to crash, so by default, no XIM support is compiled in, unless running on Solaris and the XmIm* routines are detected. I do not run in on Solaris, so it should not use it by default. Of course another way to fix it is to fix/get rid of OpenMotif. Petr -- If you think last Tuesday was a drag, wait till you see what happens tomorrow!

3 participants
3 comments

Re: 21.5.1: dired.o can't be linked on Win9x 22 years, 12 months

Ben Wing

Craig Lanning wrote: > > [This appears to be caused by a patch that Ben made so I am including him on > the cc list.] > > When I try to do a MinGW build on my Win98 system, I get a runtime error > about being "linked to missing export NETAPI32.DLL:NetApiBufferFree" > I traced this back to the function user_name_completion in dired.c. > > The functions NetApiBufferFree and NetUserEnum are not defined on Win9x > systems. > > What is needed from NetUserEnum? Can we get it some other way? uh ..... list of current users. i suppose there are none under windows 9x? is there a current username? how do you get it? > > Craig -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.

2 participants
1 comments

21.5.1: dired.o can't be linked on Win9x 22 years, 12 months

Craig Lanning

[This appears to be caused by a patch that Ben made so I am including him on the cc list.] When I try to do a MinGW build on my Win98 system, I get a runtime error about being "linked to missing export NETAPI32.DLL:NetApiBufferFree" I traced this back to the function user_name_completion in dired.c. The functions NetApiBufferFree and NetUserEnum are not defined on Win9x systems. What is needed from NetUserEnum? Can we get it some other way? Craig

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 May 2001