Motif buttons bug
23 years, 11 months
Nickolay Pakoulin
Nickolay Pakoulin
21.2.36 compiled with lesstif-0.91 on Linux --with-widgets=motif
Buttons in Custom buffer:
Buttons in dialogs:
Nick.
- 2 participants
- 1 comments
Re: outstanding issues
23 years, 11 months
Raymond Toy
Raymond Toy
>>>>> "John" == John A Turner <turner(a)blueskystudios.com> writes:
John> I'm not sure what the schedule for a 21.2 release is, but I thought I'd
John> mention a couple of things that I see as outstanding issues - everything is
John> as of b36, possibly slightly more recent
John> they're pretty minor
[issues snipped]
I've experienced these (but haven't tried the dired customize
problem).
I'd like to add the following:
o xemacs crashes for me quite often in either gc or
make_lisp_buffer_stream. (Already reported). I have a sneaking
suspicion that it's a gcc 2.95.2 problem. After recompiling with
Sun CC 5.0, I haven't run into it today in the last few hours,
whereas it was happening as often as every 30 minutes with gcc
2.95.2. I'll have to try with gcc 2.7.2.2 too. Perhaps a note in
the PROBLEMS file?
o This one I haven't reported yet. When fontifying a buffer, the
progress bar moves very very slowly and fontification takes forever
(> many seconds). However, if I just move the mouse around in the
window, the progress bar zips by very quickly, and fontification
finishes in less than a second.
o A possibly related problem: I start up xemacs and gnus from the
command line and have it iconified. It gets stuck somewhere loading
up something. As soon as I deiconify it, it zips right along.
John> I have to admit that I've been working w/o gutters turned on recently -
John> maybe I should turn them back on and work them out a bit...
Hmm, I should do the same....
Ray
- 3 participants
- 2 comments
Problems with alloca on Alpha Linux with Compaq cc
24 years
Falk Hueffner
Falk Hueffner
Hi,
with xemacs-21.2 CVS from October 12 and Compaq C V6.2-504 I get
[...]
checking for working alloca.h... no
checking for alloca... no
Defining C_ALLOCA
checking whether alloca needs Cray hooks... no
checking stack direction for C alloca... -1
Defining STACK_DIRECTION = -1
xemacs will be linked with "alloca.o"
[...]
The reason is that ccc won't find alloca when linking if passed
"-std1", which is added by xemacs configure. (ccc picks up gcc's
alloca.h, but the alloca.h check wants to link, too, so it fails.)
Then when building one gets lots of warnings:
ccc -O3 -Demacs -I. -I../src -I/usr/local/src/xemacs-21.2-10.12/lib-src -I/usr/local/src/xemacs-21.2-10.12/src -DHAVE_CONFIG_H -std1 /usr/local/src/xemacs-21.2-10.12/lib-src/wakeup.c -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o wakeup
cc: Warning: /usr/include/alloca.h, line 33: In this declaration, the type of the function "alloca", declared in a system header file, is not compatible with the earlier declaration of "alloca" at line number 43 in file ../src/config.h. (funcredeclext1)
extern __ptr_t alloca __P ((size_t __size));
---------------^
(__ptr_t is a #define for void *, while config.h declares the return
value as char *)
Finally, it fails:
ccc -c -O3 -Demacs -I. -I../src -I/usr/local/src/xemacs-21.2-10.12/lib-src -I/usr/local/src/xemacs-21.2-10.12/src -DHAVE_CONFIG_H -std1 /usr/local/src/xemacs-21.2-10.12/lib-src/../src/alloca.c
cc: Error: /usr/local/src/xemacs-21.2-10.12/lib-src/../src/alloca.c, line 191: In this declaration, the type of "alloca" is not compatible with the type of a previous declaration of "alloca" at line number 43 in file ../src/config.h. (notcompat)
alloca (size)
^
because alloca.c declares alloca as returning "pointer", which is
typedefed to void *.
Now I wonder how to fix this best; one could for example:
* remove -std1 from the ccc flags
* use something like
#if defined(__DECC) && defined(__linux__)
# include <machine/builtins.h>
# define alloca __ALLOCA
#endif
which also works with -std1
* consistentialize xemacs' declarations; regex.c also wants to declare
alloca as returning char *.
And if anybody feels a bit bored, here are a few interesting warnings:
cc: Warning: miscplay.c, line 384: In this statement, the expression "*dest++=(unsigned char)(((int)*((signed char ...)(src++))+(int)*((signed char ...)(src++)))/2)" modifies the variable "src" more than once without an intervening sequence point. This behavior is undefined. (undefvarmod)
*dest++ = (unsigned char)(((int)*((signed char *)(src++)) +
----^
cc: Warning: miscplay.c, line 405: In this statement, the expression "*dest++=(unsigned char)(((int)*((signed char ...)(src++))+(int)*((signed char ...)(src++)))/2)^0X0000000000000080" modifies the variable "src" more than once without an intervening sequence point. This behavior is undefined. (undefvarmod)
*dest++ = (unsigned char)(((int)*((signed char *)(src++)) +
----^
cc: Warning: miscplay.c, line 496: In this statement, the expression "*p++=ulaw_dsp[*p]" modifies "p", and fetches its value in a computation that is not used to produce the modified value without an intervening sequence point. This behavior is undefined. (undefvarfetch)
*p++ = ulaw_dsp[*p];
----^
cc: Warning: miscplay.c, line 570: In this statement, the expression "*p++=((*p&0X00000000000000FF)<<8)|(*p>>8)" modifies "p", and fetches its value in a computation that is not used to produce the modified value without an intervening sequence point. This behavior is undefined. (undefvarfetch)
*p++ = ((*p & 0x00ff) << 8) | (*p >> 8);
----^
cc: Warning: miscplay.c, line 570: In this statement, the expression "*p++=((*p&0X00000000000000FF)<<8)|(*p>>8)" modifies "p", and fetches its value in a computation that is not used to produce the modified value without an intervening sequence point. This behavior is undefined. (undefvarfetch)
*p++ = ((*p & 0x00ff) << 8) | (*p >> 8);
----^
cc: Warning: regex.c, line 5627: This statement uses the type "union declared without a tag" to reference the same storage location as the statement at line number 5627 in file regex.c, which uses the type "long". This does not conform to the ANSI aliasing rules. (badansialias)
POP_FAILURE_POINT (d, p,
----------^
cc: Warning: regex.c, line 5312: This statement uses the type "union declared without a tag" to reference the same storage location as the statement at line number 5312 in file regex.c, which uses the type "long". This does not conform to the ANSI aliasing rules. (badansialias)
POP_FAILURE_POINT (sdummy, pdummy,
------------^
Falk
- 3 participants
- 4 comments
Mule redisplay crash
24 years
Gunnar Evermann
Gunnar Evermann
This is one of the oldest crashes on my to do list.
loading the following in a vanilla Mule XEmacs will trigger a crash.
(defun delete-and-split ()
(interactive)
(delete-other-windows)
(split-window))
(split-window-vertically)
(insert "$B$,(B")
(backward-char)
(redraw-frame)
(delete-and-split)
Fatal error: assertion failed, file /deb-huge/home/gunnar/src/XEmacs/xemacs/src/objects.h, line 143, RECORD_TYPEP (obj, &lrecord_font_instance)
#3 0x808eb81 in assert_failed (file=0x8218c60 "/deb-huge/home/gunnar/src/XEmacs/xemacs/src/objects.h", line=143,
expr=0x8218d40 "RECORD_TYPEP (obj, &lrecord_font_instance)")
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/emacs.c:2825
#4 0x80c9db4 in error_check_font_instance (obj=136776524)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/objects.h:143
#5 0x81c730f in x_output_string (w=0x85a8c10, dl=0x8609808, buf=0x85e7640, xpos=4, xoffset=0, clip_start=4,
width=16, findex=0, cursor=1, cursor_start=4, cursor_width=16, cursor_height=13)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-x.c:883
#6 0x81c60d5 in x_output_display_block (w=0x85a8c10, dl=0x8609808, block=0, start=0, end=1, start_pixpos=4,
cursor_start=4, cursor_width=16, cursor_height=13)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-x.c:390
#7 0x81799c2 in redisplay_output_display_block (w=0x85a8c10, dl=0x8609808, block=0, start=0, end=1,
start_pixpos=4, cursor_start=4, cursor_width=16, cursor_height=13)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-output.c:1088
#8 0x8178a28 in output_display_line (w=0x85a8c10, cdla=0x0, ddla=0x85e2668, line=1, force_start=4, force_end=20)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-output.c:751
#9 0x8179839 in redraw_cursor_in_window (w=0x85a8c10, run_end_begin_meths=1)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-output.c:1029
#10 0x81798be in redisplay_redraw_cursor (f=0x8577f00, run_end_begin_meths=1)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-output.c:1054
#11 0x81760e9 in Fforce_cursor_redisplay (frame=139951872)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay.c:8938
#12 0x8176761 in text_cursor_visible_p_changed (specifier=137474936, w=0x85e8148, oldval=136988916)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay.c:9005
#13 0x81999b1 in recompute_one_cached_specifier_in_window (specifier=137474936, w=0x85e8148)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/specifier.c:2812
#14 0x8199b67 in recompute_all_cached_specifiers_in_window (w=0x85e8148)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/specifier.c:2854
#15 0x81d5e1e in Fset_window_buffer (window=140411208, buffer=137541312)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/window.c:3198
#16 0x81d6b4e in Fsplit_window (window=140151824, chsize=136988916, horflag=136988916)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/window.c:3503
#17 0x8094ed9 in Feval (form=140010872) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/eval.c:2975
#18 0x8090870 in Fprogn (args=140010812) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/eval.c:767
#19 0x8096629 in funcall_lambda (fun=140010896, nargs=0, args=0xbffff048)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/eval.c:3497
#20 0x8095522 in Feval (form=140007804) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/eval.c:3081
#21 0x8146b51 in readevalloop (readcharfun=140386240, sourcename=139813548, evalfun=0x80947b0 <Feval>, printflag=0)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/lread.c:1448
[...]
#43 0x808d520 in xemacs_21_2_b23_i586_pc_linux (argc=4, argv=0xbffffc34, envp=0xbffffc48, restart=0)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/emacs.c:1898
#44 0x808e0ab in main (argc=4, argv=0xbffffc34, envp=0xbffffc48)
at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/emacs.c:2323
The problem is that the face cache doesn't contain the font instance
for the relevant charset or to be precise that the cache has been
cleared but we do not regenerate the necessary entries.
A quick fix for the crash would be adding a call to
ensure_face_cachel_contains_charset() at the relevant place in
x_output_string like this:
Index: redisplay-x.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-x.c,v
retrieving revision 1.23.2.17
diff -u -r1.23.2.17 redisplay-x.c
--- redisplay-x.c 1999/10/15 10:11:51 1.23.2.17
+++ redisplay-x.c 1999/12/13 22:58:35
＠＠ -879,10 +879,14 ＠＠
for (i = 0; i < nruns; i++)
{
- Lisp_Object font = FACE_CACHEL_FONT (cachel, runs[i].charset);
- struct Lisp_Font_Instance *fi = XFONT_INSTANCE (font);
+ Lisp_Object font;
+ struct Lisp_Font_Instance *fi;
int this_width;
int need_clipping;
+
+ ensure_face_cachel_contains_charset(cachel, window, runs[i].charset);
+ font = FACE_CACHEL_FONT (cachel, runs[i].charset);
+ fi = XFONT_INSTANCE (font);
if (EQ (font, Vthe_null_font_instance))
continue;
This works but is kindof expensive to do, as x_output_string is called
very very often :-)
Maybe our Mule and redisplay experts can try to come up with something
more clever...
Gunnar
- 3 participants
- 2 comments
crash when loading file which contains EUC-JP and ISO-2022-JP
24 years
Mike FABIAN
Mike FABIAN
Save the following attached file:
(This file is only gzipped, because Gnus runs into an endless loop
when I attach it without gzipping. That is probably also a bug, but a
different one.).
Gunzip it, start XEmacs and let it load this file:
mfabian＠gregory:~/xemacs-bug$ LANG=ja_JP xemacs -q -vanilla kanji.euc-iso
Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
It is important to use "LANG=ja_JP", it will not happen with "LANG=C".
The file "kanji.euc-iso" contains only two lines. Both lines contain
only the Japanese word "漢字" (Kanji). The first line contains this
word in EUC-JP encoding, the second line in ISO-2022-JP encoding.
The order of these lines is also important, if the ISO-2022-JP line
comes first like in the gunzipped version of this file:
XEmacs will not crash (but of course the EUC-JP part is unreadable).
I encounter this problem often when opening Japanese *.patch files,
which often contain both EUC-JP in some hunks and ISO-2022-JP in other
hunks. If the EUC-JP comes first, XEmacs will crash.
I use the following XEmacs version:
In XEmacs 21.1 (patch 10) "Capitol Reef" [Lucid] (i686-pc-linux, Mule) of Mon May 8 2000 on nozomi
configured using `configure --prefix=/opt/stow/xemacs-21.1.10 --with-mule=yes --with-dialogs=athena3d --with-xface=yes --with-wnn=yes --with-canna=yes --with-xim=xlib --with-xfs --with-menubars=lucid --site-includes=/opt/include --site-libraries=/opt/lib '--cflags=-g -O4 -fno-strength-reduce''
(The same problem also occurs with the XEmacs 21.1.12 from the SuSE
rpm).
Here is the lisp backtrace:
And here is the C backtrace:
--
Mike Fabian <mfabian(a)suse.de>
- 3 participants
- 4 comments
Re: file-truename in Windows native build
24 years
Dan Holmsand
Dan Holmsand
Mike Alexander <mta(a)arbortext.com> writes:
> It's annoyed me for some time that the native Windows version of
> XEmacs often ends up with two (or more) buffers visiting the same
> file, even if find-file-compare-truenames or find-file-use-truenames
> is set.
I totally agree. In fact I also started to fix this a while ago...
[...]
> The attached patch changed Ffile_truename to use
> win32_get_long_filename on Windows after changing it to do something
> reasonable when given a path that contains a file or directory that
> doesn't exist. This latter change might cause a problem with code
> that used win32-long-file-name to test for the existence of a file,
> but I can't find any code that uses it at all, let alone for that
> purpose. I also changed xemacs.mak to remove realpath.c from the
> native Windows build since it isn't needed anymore. With this patch I
> haven't had any more problems with multiple buffers visiting the same
> file if I set find-file-compare-truenames or find-file-use-truenames.
I chose the other alternative - making xrealpath work on windows. I
obviously think this is a better choice, mainly because it's mine :-)
My code have some real advantages, though. Mainly, it also works with
cygwin xemacs, which is broken in basically the same way as the native
built one. Besides that the current code doesn't care for case or
short filenames, it is totally broken when you feed it UNC paths.
My code deals with UNC paths by lower-casing the server and share
parts of the filename (i.e. //server/share/...), since case is not
significant here.
It is perhaps also an advantage that the code is shared between unix,
cygwin and native windows xemacsen. It should, for example, be quite
easy to add support for Win2k's reparse points (which basically work
like symlinks).
I also definitely think find-file-compare-truenames should be true by
default on windows.
Anyway, here it is. I've been using it for a while, on both native
xemacs and cygwin. However, I haven't tested the code on unix (the
changes there are mainly trivial, though; mostly *s == '/' ->
IS_DIRECTORY_SEP (*s), etc.).
/dan
--
Dan Ola Holmsand
IB
dan(a)eyebee.com
2000-08-31 Dan Holmsand <dan(a)eyebee.com>
* buffer.c: Make find-file-compare-truenames default to true on
windows.
* realpath.c (win32_abs_start):
(cygwin_readlink):
(win32_readlink): New functions.
(xrealpath): Return really real filenames on windows.
* fileio.c (Ffile_truename): Make file-truename work on windows.
Index: src/buffer.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/buffer.c,v
retrieving revision 1.36.2.38
diff -u -u -r1.36.2.38 buffer.c
--- buffer.c 2000/08/18 17:16:00 1.36.2.38
+++ buffer.c 2000/08/31 21:19:18
＠＠ -2227,7 +2227,11 ＠＠
See also the variable find-file-use-truenames.
*/ );
+#if defined(CYGWIN) || defined(WIN32_NATIVE)
+ find_file_compare_truenames = 1;
+#else
find_file_compare_truenames = 0;
+#endif
DEFVAR_BOOL ("find-file-use-truenames", &find_file_use_truenames /*
If this is true, then a buffer's visited file-name will always be
Index: src/fileio.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/fileio.c,v
retrieving revision 1.51.2.26
diff -u -u -r1.51.2.26 fileio.c
--- fileio.c 2000/08/06 09:27:12 1.51.2.26
+++ fileio.c 2000/08/31 21:19:40
＠＠ -1316,14 +1316,30 ＠＠
we just use our own version in realpath.c. */
for (;;)
{
- p = (Extbyte *) memchr (p + 1, '/', elen - (p + 1 - path));
- if (p)
- *p = 0;
+ Extbyte *pos;
+#ifdef WIN32_NATIVE
+ if (IS_DRIVE (p[0]) && IS_DEVICE_SEP (p[1])
+ && IS_DIRECTORY_SEP (p[2]))
+ /* don't test c: on windows */
+ p = p+2;
+ else if (IS_DIRECTORY_SEP (p[0]) && IS_DIRECTORY_SEP (p[1]))
+ /* start after // */
+ p = p+1;
+#endif
+ for (pos = p + 1; pos < path + elen; pos++)
+ if (IS_DIRECTORY_SEP (*pos))
+ {
+ *(p = pos) = 0;
+ break;
+ }
+ if (p != pos)
+ p = 0;
+
if (xrealpath ((char *) path, resolved_path))
{
if (p)
- *p = '/';
+ *p = DIRECTORY_SEP;
else
break;
＠＠ -1342,13 +1358,13 ＠＠
{
int plen = elen - (p - path);
- if (rlen > 1 && resolved_path[rlen - 1] == '/')
+ if (rlen > 1 && IS_DIRECTORY_SEP (resolved_path[rlen - 1]))
rlen = rlen - 1;
if (plen + rlen + 1 > countof (resolved_path))
goto toolong;
- resolved_path[rlen] = '/';
+ resolved_path[rlen] = DIRECTORY_SEP;
memcpy (resolved_path + rlen + 1, p + 1, plen + 1 - 1);
}
break;
＠＠ -1361,12 +1377,12 ＠＠
{
Lisp_Object resolved_name;
int rlen = strlen (resolved_path);
- if (elen > 0 && XSTRING_BYTE (expanded_name, elen - 1) == '/'
- && !(rlen > 0 && resolved_path[rlen - 1] == '/'))
+ if (elen > 0 && IS_DIRECTORY_SEP (XSTRING_BYTE (expanded_name, elen - 1))
+ && !(rlen > 0 && IS_DIRECTORY_SEP (resolved_path[rlen - 1])))
{
if (rlen + 1 > countof (resolved_path))
goto toolong;
- resolved_path[rlen++] = '/';
+ resolved_path[rlen++] = DIRECTORY_SEP;
resolved_path[rlen] = '\0';
}
TO_INTERNAL_FORMAT (DATA, (resolved_path, rlen),
Index: src/realpath.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/realpath.c,v
retrieving revision 1.6.2.7
diff -u -u -r1.6.2.7 realpath.c
--- realpath.c 2000/06/12 04:18:21 1.6.2.7
+++ realpath.c 2000/08/31 21:19:47
＠＠ -23,42 +23,145 ＠＠
/* Synched up with: Not in FSF. */
#include <config.h>
+#include "lisp.h"
+#include "sysfile.h"
-#include <sys/types.h>
#include <stdio.h>
#include <string.h>
-#include <errno.h>
#include <limits.h>
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
+/* First char after start of absolute filename. */
+#define ABS_START(name) (name + ABS_LENGTH (name))
-#if defined (HAVE_SYS_PARAM_H)
-#include <sys/param.h>
-#endif
+#if defined (WIN32_NATIVE)
+/* Length of start of absolute filename. */
+# define ABS_LENGTH(name) (win32_abs_start (name))
+static int win32_abs_start (const char * name);
+/* System dependent version of readlink. */
+# define sys_readlink(name, buf, size) win32_readlink (name, buf, size)
+#else
+# ifdef CYGWIN
+# define ABS_LENGTH(name) (IS_DIRECTORY_SEP (*name) ? \
+ (IS_DIRECTORY_SEP (name[1]) ? 2 : 1) : 0)
+# define sys_readlink(name, buf, size) cygwin_readlink (name, buf, size)
+# else
+# define ABS_LENGTH(name) (IS_DIRECTORY_SEP (*name) ? 1 : 0)
+# define sys_readlink(name, buf, size) readlink (name, buf, size)
+# endif /* CYGWIN */
+#endif /* WIN32_NATIVE */
+
+#if defined (WIN32_NATIVE) || defined (CYGWIN)
+#include "syswindows.h"
+/* Emulate readlink on win32 - finds real name (i.e. correct case) of
+ a file. UNC servers and shares are lower-cased. Directories must be
+ given without trailing '/'. One day, this could read Win2K's
+ reparse points. */
+static int
+win32_readlink (const char * name, char * buf, int size)
+{
+ WIN32_FIND_DATA find_data;
+ HANDLE dir_handle = NULL;
+ int len = 0;
+ int err = 0;
+ const char* lastname;
+ int count = 0;
+ const char* tmp;
+ char* res = NULL;
+
+ assert (*name);
+
+ /* Sort of check we have a valid filename. */
+ if (strpbrk (name, "*?|<>\"") || strlen (name) >= MAX_PATH)
+ {
+ errno = EIO;
+ return -1;
+ }
+
+ /* Find start of filename */
+ lastname = name + strlen (name);
+ while (lastname > name && !IS_DIRECTORY_SEP (lastname[-1]))
+ --lastname;
+
+ /* Count slashes in unc path */
+ if (ABS_LENGTH (name) == 2)
+ for (tmp = name; *tmp; tmp++)
+ if (IS_DIRECTORY_SEP (*tmp))
+ count++;
+
+ if (count >= 2 && count < 4)
+ {
+ /* UNC server or share name: just copy lowercased name. */
+ res = find_data.cFileName;
+ for (tmp = lastname; *tmp; tmp++)
+ *res++ = tolower (*tmp);
+ *res = '\0';
+ }
+ else
+ dir_handle = FindFirstFile (name, &find_data);
+
+ if (res || dir_handle != INVALID_HANDLE_VALUE)
+ {
+ if ((len = strlen (find_data.cFileName)) < size)
+ {
+ if (strcmp (lastname, find_data.cFileName) == 0)
+ /* Signal that the name is already OK. */
+ err = EINVAL;
+ else
+ memcpy (buf, find_data.cFileName, len + 1);
+ }
+ else
+ err = ENAMETOOLONG;
+ if (!res) FindClose (dir_handle);
+ }
+ else
+ err = ENOENT;
+ errno = err;
+ return err ? -1 : len;
+}
+#endif /* WIN32_NATIVE || CYGWIN */
+
+#ifdef CYGWIN
+/* Call readlink and try to find out the correct case for the file. */
+static int
+cygwin_readlink (const char * name, char * buf, int size)
+{
+ int n = readlink (name, buf, size);
+ if (n < 0)
+ {
+ /* The file may exist, but isn't a symlink. Try to find the
+ right name. */
+ char* tmp = alloca (cygwin_posix_to_win32_path_list_buf_size (name));
+ cygwin_posix_to_win32_path_list (name, tmp);
+ n = win32_readlink (tmp, buf, size);
+ }
+ return n;
+}
+#endif /* CYGWIN */
+
#ifdef WIN32_NATIVE
-#include <direct.h>
+#ifndef ELOOP
+#define ELOOP 10062 /* = WSAELOOP in winsock.h */
#endif
-
-#include <sys/stat.h> /* for S_IFLNK */
+/* Length of start of absolute filename. */
+static int
+win32_abs_start (const char * name)
+{
+ if (isalpha (*name) && IS_DEVICE_SEP (name[1])
+ && IS_DIRECTORY_SEP (name[2]))
+ return 3;
+ else if (IS_DIRECTORY_SEP (*name))
+ return IS_DIRECTORY_SEP (name[1]) ? 2 : 1;
+ else
+ return 0;
+}
+#endif /* WIN32_NATIVE */
#if !defined (HAVE_GETCWD) && defined (HAVE_GETWD)
#undef getcwd
#define getcwd(buffer, len) getwd (buffer)
#endif
-#ifndef PATH_MAX
-# if defined (_POSIX_PATH_MAX)
-# define PATH_MAX _POSIX_PATH_MAX
-# elif defined (MAXPATHLEN)
-# define PATH_MAX MAXPATHLEN
-# else
-# define PATH_MAX 1024
-# endif
-#endif
-
#define MAX_READLINKS 32
char * xrealpath (const char *path, char resolved_path []);
＠＠ -68,78 +171,63 ＠＠
char copy_path[PATH_MAX];
char *new_path = resolved_path;
char *max_path;
-#ifdef S_IFLNK
+#if defined (S_IFLNK) || defined (WIN32_NATIVE)
int readlinks = 0;
char link_path[PATH_MAX];
int n;
+ int abslen = ABS_LENGTH (path);
#endif
/* Make a copy of the source path since we may need to modify it. */
strcpy (copy_path, path);
path = copy_path;
max_path = copy_path + PATH_MAX - 2;
+
#ifdef WIN32_NATIVE
- /*
- ** In NT we have two different cases: (1) the path name begins
- ** with a drive letter, e.g., "C:"; and (2) the path name begins
- ** with just a slash, which roots to the current drive. In the
- ** first case we are going to leave things alone, in the second
- ** case we will prepend the drive letter to the given path.
- ** Note: So far in testing, I'm only seeing case #1, even though
- ** I've tried to get the other cases to happen.
- ** August Hill, 31 Aug 1997.
- **
- ** Check for a driver letter...C:/...
- */
- if (*(path + 1) == ':')
+ /* Check for c:/... or //server/... */
+ if (abslen == 2 || abslen == 3)
{
- strncpy(new_path, path, 3);
- new_path += 3;
- path += 3;
+ strncpy (new_path, path, abslen);
+ new_path += abslen;
+ path += abslen;
}
-
- /*
- ** No drive letter, but a beginning slash? Prepend the drive
- ** letter...
- */
- else if (*path == '/')
+ /* No drive letter, but a beginning slash? Prepend drive letter. */
+ else if (abslen == 1)
{
getcwd (new_path, PATH_MAX - 1);
new_path += 3;
path++;
}
-
- /*
- ** Just a path name, prepend the current directory
- */
+ /* Just a path name, prepend the current directory */
else
{
getcwd (new_path, PATH_MAX - 1);
- new_path += strlen(new_path);
- if (new_path[-1] != '/')
- *new_path++ = '/';
+ new_path += strlen (new_path);
+ if (!IS_DIRECTORY_SEP (new_path[-1]))
+ *new_path++ = DIRECTORY_SEP;
}
-
#else
/* If it's a relative pathname use getcwd for starters. */
- if (*path != '/')
+ if (abslen == 0)
{
getcwd (new_path, PATH_MAX - 1);
- new_path += strlen(new_path);
- if (new_path[-1] != '/')
- *new_path++ = '/';
+ new_path += strlen (new_path);
+ if (!IS_DIRECTORY_SEP (new_path[-1]))
+ *new_path++ = DIRECTORY_SEP;
}
else
{
- *new_path++ = '/';
- path++;
+ /* Copy first directory sep. May have two on cygwin. */
+ strncpy (new_path, path, abslen);
+ new_path += abslen;
+ path += abslen;
}
#endif
/* Expand each slash-separated pathname component. */
while (*path != '\0')
{
/* Ignore stray "/". */
- if (*path == '/')
+ if (IS_DIRECTORY_SEP (*path))
{
path++;
continue;
＠＠ -148,7 +236,7 ＠＠
if (*path == '.')
{
/* Ignore ".". */
- if (path[1] == '\0' || path[1] == '/')
+ if (path[1] == '\0' || IS_DIRECTORY_SEP (path[1]))
{
path++;
continue;
＠＠ -156,23 +244,24 ＠＠
/* Handle ".." */
if (path[1] == '.' &&
- (path[2] == '\0' || path[2] == '/'))
+ (path[2] == '\0' || IS_DIRECTORY_SEP (path[2])))
{
path += 2;
/* Ignore ".." at root. */
- if (new_path == resolved_path + 1)
+ if (new_path == ABS_START (resolved_path))
continue;
/* Handle ".." by backing up. */
- while ((--new_path)[-1] != '/')
- ;
+ --new_path;
+ while (!IS_DIRECTORY_SEP (new_path[-1]))
+ --new_path;
continue;
}
}
/* Safely copy the next pathname component. */
- while (*path != '\0' && *path != '/')
+ while (*path != '\0' && !IS_DIRECTORY_SEP (*path))
{
if (path > max_path)
{
＠＠ -182,10 +271,10 ＠＠
*new_path++ = *path++;
}
-#ifdef S_IFLNK
+#if defined (S_IFLNK) || defined (WIN32_NATIVE)
/* See if latest pathname component is a symlink. */
*new_path = '\0';
- n = readlink (resolved_path, link_path, PATH_MAX - 1);
+ n = sys_readlink (resolved_path, link_path, PATH_MAX - 1);
if (n < 0)
{
＠＠ -204,14 +293,14 ＠＠
/* Note: readlink doesn't add the null byte. */
link_path[n] = '\0';
-
- if (*link_path == '/')
+
+ if (ABS_LENGTH (link_path) > 0)
/* Start over for an absolute symlink. */
- new_path = resolved_path;
+ new_path = resolved_path + ABS_LENGTH (link_path) - 1;
else
/* Otherwise back up over this component. */
- while (*(--new_path) != '/')
- ;
+ for (--new_path; !IS_DIRECTORY_SEP (*new_path); --new_path)
+ assert (new_path > resolved_path);
/* Safe sex check. */
if (strlen(path) + n >= PATH_MAX)
＠＠ -225,15 +314,21 ＠＠
strcpy(copy_path, link_path);
path = copy_path;
}
-#endif /* S_IFLNK */
- *new_path++ = '/';
+#endif /* S_IFLNK || WIN32_NATIVE */
+ *new_path++ = DIRECTORY_SEP;
}
/* Delete trailing slash but don't whomp a lone slash. */
- if (new_path != resolved_path + 1 && new_path[-1] == '/')
+ if (new_path != ABS_START (resolved_path) && IS_DIRECTORY_SEP (new_path[-1]))
new_path--;
/* Make sure it's null terminated. */
*new_path = '\0';
+
+#ifdef WIN32_NATIVE
+ if (ABS_LENGTH (resolved_path) == 3)
+ /* Lowercase drive letter. */
+ *resolved_path = tolower (*resolved_path);
+#endif
return resolved_path;
}
- 3 participants
- 3 comments
Small windows with scroll-step set
24 years
Mike Alexander
Mike Alexander
The problem described in
<http://www.xemacs.org/list-archives/xemacs-beta/200003/msg00645.html>
is still occurring for me sometimes. This causes random crashes if
you have a value set for scroll-step. One way that I've made it
happen, although not every time, is to run XEmacs -vanilla,
immediately use M-: (i.e., don't type into the *scratch* buffer) to
set toolbar-visible-p and gutter-buffers-tab-visible-p to nil and
scroll-step to 15, then do a File->Save As. This doesn't make much
sense to do since it tries to save the default *scratch* buffer, but
it sometimes causes the crash.
The patch below avoids this problem. It occurs if the height of a
window is so small that not even one line can be formatted in it. In
this case the line cache will always be empty and
point-in-line-start-cache will return -1 which was causing vmotion-1
to assert. I looked at the various callers of vmotion-1 and it
appears that it is reasonable to just have it return the input point
unchanged in this case, so that's what I did. If this is not the
right thing to do, I'd be happy to hear alternative suggestions.
Mike
2000-04-29 Mike Alexander <mta(a)arbortext.com>
* indent.c (vmotion_1): If point_in_line_start_cache fails simply
return the input position instead of asserting out.
Index: src/indent.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/indent.c,v
retrieving revision 1.9.2.4
diff -u -r1.9.2.4 indent.c
--- indent.c 2000/02/07 07:59:19 1.9.2.4
+++ indent.c 2000/04/29 06:58:00
＠＠ -624,8 +624,15 ＠＠
/* #### This assertion must be true before the if statements are hit
but may possibly be wrong after the call to
point_in_line_start_cache if orig is outside of the visible
- region of the buffer. Handle this. */
- assert (elt >= 0);
+ region of the buffer. Handle this.
+
+ This occurs sometimes if scroll-step is non-zero and the window
+ is very small. In this case it's not possible to lay out any lines
+ in the window and point_in_line_start_cache returns -1 because
+ the line cache is empty. In this case we will just return the
+ original point and hope for the best. */
+ if (elt < 0)
+ return orig;
/* Moving downward. */
if (vtarget > 0)
- 2 participants
- 2 comments
vm crashes on linux console
24 years
Giacomo Boffi
Giacomo Boffi
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 (beta34) "Molpe" [Lucid] (i586-pc-linux) of Tue Jul 18 2000 on boffi95
configured using `configure --extra-verbose --without-wmcommand --with-athena=3d --with-modules --debug --error-checking=none --use-union-type --with-clash-detection --rel-alloc'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
i started xemacs on linux console, then i started vm (M-x vm RET),
bang
Recent keystrokes:
inappropriate
Lisp backtrace follows:
# (unwind-protect ...)
# (unwind-protect ...)
# (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque-ptr, adr=0x81e9df8) 0x823bd68> ...)
# (unwind-protect ...)
# bind (inhibit-quit frame-being-created)
make-frame(nil)
# bind (params types)
vm-goto-new-frame(primary-folder folder)
apply(vm-goto-new-frame (primary-folder folder))
# bind (w types)
vm-goto-new-folder-frame-maybe(primary-folder folder)
apply(vm-goto-new-folder-frame-maybe (primary-folder folder))
# bind (full-startup did-read-index-file folder-buffer first-time totals-blurb preserve-auto-save-file)
byte-code("..." [bufferp folder nil preserve-auto-save-file totals-blurb first-time folder-buffer did-read-index-file full-startup expand-file-name vm-primary-inbox vm-folder-directory file file-directory-p error "%s is a directory" vm-get-file-buffer default-directory t no-conversion coding-system-for-read default-enable-multibyte-characters enable-local-variables inhibit-local-variables message "Reading %s..." find-file-noselect item vm-folder-history "Reading %s... done" vm-fsfemacs-mule-p enable-multibyte-characters set-buffer-multibyte buffer-file-coding-system current-load-list vm-xemacs-mule-p get-coding-system no-conversion-unix no-conversion-dos no-conversion-mac binary buffer-modified-p omodified buffer-read-only ((set-buffer-modified-p omodified)) encode-coding-region set-buffer-file-coding-system decode-coding-region coding-system-base ((set-buffer-modified-p omodified)) vm-check-for-killed-summary vm-check-for-killed-presentation 0 vm-messages-not-on-disk major-!
mode vm-mode buffer-file-name file-newer-than-file-p make-auto-save-file-name read-only default-value vm-folder-read-only buffer-disable-undo abbrev-mode auto-fill-mode vm-mode-internal vm-read-index-file-maybe vm-assimilate-new-messages vm-gobble-visible-header-variables vm-gobble-bookmark vm-gobble-pop-retrieved vm-gobble-imap-retrieved vm-gobble-summary vm-gobble-labels vm-start-itimers-if-needed this-command apply vm-goto-new-folder-frame-maybe (folder) (primary-folder folder) vm-summary-buffer vm-presentation-buffer buffer-to-display vm-display vm startup vm-raise-frame-at-startup vm-raise-frame vm-emit-totals-blurb vm-thoughtfully-select-message vm-update-summary-and-mode-line vm-toolbar-support-possible-p vm-use-toolbar "Initializing toolbar..." vm-toolbar-install-toolbar "Initializing toolbar... done" vm-toolbar-update-toolbar vm-use-menus vm-menu-support-possible-p vm-menu-install-visited-folders-menu vm-should-generate-summary vm-summarize vm-mutable-frames vm-frame-!
per-summary vm-mutable-windows switch-to-buffer vm-message-list vm-preview-current-message run-hooks vm-visit-folder-hook substitute-command-keys "Auto save file is newer; consider \\[recover-file]. FOLDER IS READ ONLY." throw done vm-auto-get-new-mail vm-block-new-mail "Checking for new mail for %s..." buffer-name vm-get-spooled-mail vm-startup-message-displayed vm-display-startup-message input-pending-p] 7)
# (catch done ...)
# bind (read-only folder)
#<compiled-function (&optional folder read-only) "...(7)" [vm-session-initialization done (byte-code "À !? À !« ªà ®É\n \" Í !«ÎÏ \"ªÇÐ !®Á «É !®ÒÂÓ ØÙ \"Ú ! ®\n ＠¬ B )ØÝ \"-)q « «àÂ!á\"B\"#«Åä!!äå!=¬»ä!!äæ!=¬±ä!!äç!=¬§ä!!äè!=¬Âé * +ìíed!#îÓÂ\"ïed!#+ «±ð!!ðÓ!=¬§ð!!ðè!=¬Âé * +ñíed!#îÓÂ\"ïed!#+ò ó é ¬ô56÷=?8é ?ùú 8\"®;®üý!®
+=
«þp!ÿô!＠
- 2 participants
- 1 comments
Re: working on getting XEmacs/GTK to 21.2...
24 years
William M. Perry
William M. Perry
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> >>>>> "-BP" == William M Perry <wmperry(a)aventail.com> writes:
>
> -BP> Any objections? This would land on the main 21.2 branch. I
> -BP> really think GTK should be made the default on systems that
> -BP> support it, and that is how
>
> GTK still doesn't support multiple X displays, right? I need that a lot
> more than I need prettier dialogs---I see a dialog about once a week....
> Of course, this is a personal issue and should be handled by my own
> configuration.
Correct - no multidisplay, and it doesn't look like GTK 2.0 is going to
have it either. *sigh*
> Also, until GTK is used for Custom, I think it's going to look very very
> half-assed.
Why is that not the case for X and Motif then? Or Windows?
> On that basis, my vote is "not yet".
I've almost got it running here (compiles, but craps out at initialization
when I try to set the specifiers for the pointers).
-Bill P.
- 5 participants
- 7 comments
Re: Just when you thought it was safe to use the tabs widget
24 years, 1 month
Markus Alt
Markus Alt
"Stephen J. Turnbull" wrote:
>
> CC'ing Andy Piper, since this may confirm his guess, and tabs are his
> baby anyway. suggestions on experiments, Andy?
Oops, apparently I forgot to cc: the xemacs-beta mailing list. Sorry.
Will do this now.
> >>>>> "Markus" == Markus Alt <altmark(a)de.ibm.com> writes:
>
> Markus> "Stephen J. Turnbull" wrote:
> >> I have no idea how I did this or how to reproduce it. I'll try
> >> not to let this Emacs die....
>
> Markus> I have experienced the same problem once and also didn't
> Markus> know how to reproduce it (that's why I haven't reported
> Markus> it). But now it looks like this happens when I open more
> Markus> buffers than tabs fit in the buffer tab area.
>
> Thanks. This is new behavior for me, though---I use desktop.el, and
> often have 10--15 .el files open simultaneously. It first happened a
> few days ago, after Martin bumped us to 21.2.36 "Notus", and is
> happening to me often now, although I don't know how to reproduce
> without desktop.el (and therefore I need my .emacs, for now :( ).
>
> When (and what platform and version) did you first notice this?
> Your best guesses are better than nothing.
I first noticed it with 21.2.36 "Notus" on Linux:
uname -a: Linux altmark 2.2.16 #8 Wed Sep 13 08:35:13 CEST 2000 i686
unknown
xemacs -V: XEmacs 21.2 (beta36) "Notus" [Lucid] (i686-pc-linux) of Thu
Oct 5 2000 on altmark
But it also happens on AIX 4.3.3:
uname -a: AIX pdw7 3 4 00494C4A4C00
xemacs -V: XEmacs 21.2 (beta36) "Notus" [Lucid] (rs6000-ibm-aix4.3.3.0)
of Tue Oct 10 2000 on pdw7.boeblingen.de.ibm.com
I couldn't reproduce it with 21.2.35 "Nike" (neither on Linux nor on
AIX) and IIRC from the time I used 21.2.35 (not soo long ago! ;-) ), it
has never occured with that XEmacs version.
> Markus> Note: I have set `buffers-tab-max-buffer-line-length' to 0
> Markus> and `buffers-tab-max-size' to nil.
>
> Useful information, maybe. Mine are:
>
> buffers-tab-max-buffer-line-length 25
> buffers-tab-max-size 6
I should also note that I have set `buffers-tab-selection-function' to
nil. Only this in addition to the two other settings shows all buffer
tabs at a time.
Ah, and it looks like it has to do with whether there's already a buffer
open for a file or if you open a file for the first time. In other
words, here's how I can reproduce the aforementioned behaviour:
Start XEmacs, set the above variables for buffer-tabs to their values to
display the tabs for *all* buffers, open a few files - long filenames
preferred - until the gutter is filled up with buffer tabs. This is all
ok, as long as you open files for which there's no existing buffer (i.e.
haven't been opened before). But if you *switch* to a file previously
opened (i.e. an existing buffer), the buffer tabs overlap.
Hopefully this is enough information so that an expert can track this
down ...
Markus
- 2 participants
- 1 comments