I think this is fucking horrible, but I value Ilya’s input as a user, and
it’s not a ridiculously complicated change.
src/ChangeLog addition:
2006-11-28 Aidan Kehoe <kehoea(a)parhasard.net>
* mule-charset.c (Fset_charset_registries):
Add an optional argument FORCE, to allow specifying badly-formed
CHARSET_REGISTRY-CHARSET_ENCODING combinations. Re-enables the
sort of hacks described in 96wt67fa3f.fsf(a)mo.msk.ru from Ilya
Golubev.
XEmacs Trunk source patch:
Diff command: cvs -q diff -u
Files affected: src/mule-charset.c
===================================================================
RCS
Index: src/mule-charset.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/mule-charset.c,v
retrieving revision 1.52
diff -u -r1.52 mule-charset.c
--- src/mule-charset.c 2006/11/15 21:40:02 1.52
+++ src/mule-charset.c 2006/11/28 13:31:11
@@ -891,7 +891,7 @@
face_property_was_changed (Vdefault_face, Qfont, Qglobal);
}
-DEFUN ("set-charset-registries", Fset_charset_registries, 2, 2, 0, /*
+DEFUN ("set-charset-registries", Fset_charset_registries, 2, 3, 0, /*
Set the `registries' property of CHARSET to REGISTRIES.
REGISTRIES is an ordered vector of strings that describe the X11
@@ -906,8 +906,22 @@
(set-charset-registries 'ascii ["jisx0201.1976-0"])
+If optional argument FORCE is non-nil, avoid sanity-checking the elements of
+REGISTRIES. Normally the strings are checked to make sure they contain no
+XLFD wild cards and that they contain at least one hyphen; the only context
+in which one might want not to do this is in order to use a font which
+doesn't have a full XLFD--and thus, an effective
+CHARSET_REGISTRY-CHARSET_ENCODING of ""--to display ASCII.
+
+We recommend strongly that you specify a full XLFD, since this makes
+multilingual and variant font handling work much better. To get the full
+XLFD of any font, start xfd with the short name as the pattern argument:
+
+ xfd -fn 8x16kana
+
+and use the text that appears at the top of the window.
*/
- (charset, registries))
+ (charset, registries, force))
{
int i;
charset = Fget_charset (charset);
@@ -916,6 +930,12 @@
for (i = 0; i < XVECTOR_LENGTH(registries); ++i)
{
CHECK_STRING (XVECTOR_DATA(registries)[i]);
+
+ if (!NILP(force))
+ {
+ continue;
+ }
+
if (NULL == qxestrchr(XSTRING_DATA(XVECTOR_DATA(registries)[i]), '-'))
{
invalid_argument("Not an X11 REGISTRY-ENCODING combination",
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
Ar an triú lá déag de mí na Samhain, scríobh stephen(a)xemacs.org:
> > Hilarity ensues as-is. When I start up in "/tmp/aidan/за родину!" , I
> > can’t open the current directory, even though my init files set the
> > file name coding systems appropriately,
>
> Then there's a bug somewhere, isn't there?
If ‘the startup code trusts the locale-sniffing code’ can be ruled a bug,
sure. The issue is this, from emacs.c:
#ifdef MULE
init_intl (); /* Figure out the locale and set native and
file-name coding systems, initialize the Unicode tables
so that we will be able to process non-ASCII from here
on out! */
#endif
init_xemacs_process (); /* Set up the process environment (so that
egetenv works), the basic directory variables
(exec-directory and so on), and stuff related
to subprocesses. This should be first because
many of the functions below call egetenv() to
get environment variables. */
#ifdef WIN32_NATIVE
/*
* For Win32, call init_environment() to properly enter environment/registry
* variables into Vprocess_environment.
*/
init_mswindows_environment ();
#endif
init_initial_directory (); /* get the directory to use for the
"*scratch*" buffer, etc. */
The init_initial_directory() call uses the value for Qnative determined in
init_intl(). On Unix, in general, there is no better indicator of the coding
system of file names than the charset info in the user-specific locale--it
would be better if there were some means to query the file name charset
specifically, and that’s what we should do for OS X, but in the absence of
that, we need to check the locale.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
APPROVE COMMIT
NOTE: This patch has been committed.
See Sebastian’s original patch here:
http://www.sxemacs.org/list-archives/html/sxemacs-patches/2006-10/msg0000...
and the SXEmacs bug here:
http://issues.sxemacs.org/show_bug.cgi?id=18
for more details. Sebastian could use snprintf in his patch because SXEmacs
only builds on Unix; while I would prefer to do the same, snprintf is not
available in our Windows builds. Maybe we should integrate it when it’s not
available. Thank you for the fix, Sebastian!
src/ChangeLog addition:
2006-11-28 Aidan Kehoe <kehoea(a)parhasard.net>
* doprnt.c (emacs_doprnt_1):
Integrate Sebastian Freundt's SXEmacs bug fix for cases where a
format specifier overflows the allocated buffer with a float
format string.
XEmacs Trunk source patch:
Diff command: cvs -q diff -u
Files affected: src/doprnt.c
===================================================================
RCS
Index: src/doprnt.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/doprnt.c,v
retrieving revision 1.30
diff -u -r1.30 doprnt.c
--- src/doprnt.c 2005/01/24 23:33:50 1.30
+++ src/doprnt.c 2006/11/28 12:51:43
@@ -776,16 +776,9 @@
#endif /* HAVE_BIGFLOAT */
else
{
- /* ASCII Decimal representation uses 2.4 times as many
- bits as machine binary. */
- char *text_to_print =
- alloca_array (char, 32 +
- max (spec->minwidth,
- (int) max (sizeof (double),
- sizeof (long)) * 3 +
- max (spec->precision, 0)));
- char constructed_spec[100];
- char *p = constructed_spec;
+ Ibyte *text_to_print = alloca_array (char, 350);
+ Ibyte constructed_spec[100];
+ Ibyte *p = constructed_spec;
/* Mostly reconstruct the spec and use sprintf() to
format the string. */
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
Set INCLUDE to point to the include directory of the SDK. You can do
this in the customize dialog box of visual studio, or in the
environment.
Once you do this, you can compile the versions I sent along in my
revised patch :-)
In other words, I seem to have confused two processes:
Process 1: Set INCLUDE to the platform SDK (and LIB, as well), and
compile the full version of my revised patch.
Process 2:
1- Regenerate QXE using my version of intl-encap-win32.c, and ignore
the platform SDK altogether.
2- build and test.
I'm recommending #1.
-----Original Message-----
From: ethersoft(a)gmail.com [mailto:ethersoft@gmail.com] On Behalf Of Vin
Shelton
Sent: Sunday, November 26, 2006 3:45 PM
To: Benson Margulies
Cc: xemacs-patches(a)xemacs.org
Subject: Re: [PATCH] check_writable for Win32 and cygwin repair
On 11/25/06, Benson Margulies <bim2006(a)basistech.com> wrote:
> You need to start with my changes to intl-encap-win32.c. My changes
add
> a comment that is read by the perl script. If you run the nmake, you
> should get one new function in each of the two generated files. If
> you're willing to commit the results, I can make sure that my changes
> work with what happens when you generate, and we're off to the races.
Attached are the diffs for the 2 auto-generated files from what's
currently in CVS.
BTW, after generating these diffs, I downloaded and installed the SDK;
now if I can just figure out how to use it.....
- Vin
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
You need to start with my changes to intl-encap-win32.c. My changes add
a comment that is read by the perl script. If you run the nmake, you
should get one new function in each of the two generated files. If
you're willing to commit the results, I can make sure that my changes
work with what happens when you generate, and we're off to the races.
-----Original Message-----
From: ethersoft(a)gmail.com [mailto:ethersoft@gmail.com] On Behalf Of Vin
Shelton
Sent: Saturday, November 25, 2006 9:02 PM
To: Benson Margulies
Cc: xemacs-patches(a)xemacs.org
Subject: Re: [PATCH] check_writable for Win32 and cygwin repair
On 11/25/06, Benson Margulies <bim2006(a)basistech.com> wrote:
> You might try my improved version, but I have my doubts about whether
it
> will help those missing parties, which were introduced by Microsoft
into
> the platform SDK for 64-bit compatibility.
>
> I strongly recommend a policy of requiring a Platform SDK. Ever since
> VC7, Microsoft has stopped including Win32 API headers in the visual
> studio hierarchy. Instead, you are supposed to have the platform SDK.
> You always \could/ use the platform SDK, which is more up-to-date.
It's
> a free download from Microsoft. The platform SDK is compatible with
VC6.
>
> If you don't want to go here, we'll have to find SOMEONE to regenerate
> qxe who has the old, dusty, VC6 environment, and who is willing to run
> the qxe generation target against my addition of aclapi.h and check in
> the results.
I'm happy to give this a try. I ran "nmake -f xemacs.mak
unicode-encapsulate", but no differences were detected. Can you tell
me what else I need to do?
- Vin
--
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
You might try my improved version, but I have my doubts about whether it
will help those missing parties, which were introduced by Microsoft into
the platform SDK for 64-bit compatibility.
I strongly recommend a policy of requiring a Platform SDK. Ever since
VC7, Microsoft has stopped including Win32 API headers in the visual
studio hierarchy. Instead, you are supposed to have the platform SDK.
You always \could/ use the platform SDK, which is more up-to-date. It's
a free download from Microsoft. The platform SDK is compatible with VC6.
If you don't want to go here, we'll have to find SOMEONE to regenerate
qxe who has the old, dusty, VC6 environment, and who is willing to run
the qxe generation target against my addition of aclapi.h and check in
the results.
-----Original Message-----
From: ethersoft(a)gmail.com [mailto:ethersoft@gmail.com] On Behalf Of Vin
Shelton
Sent: Saturday, November 25, 2006 2:10 PM
To: Benson Margulies
Cc: xemacs-patches(a)xemacs.org
Subject: Re: [PATCH] check_writable for Win32 and cygwin repair
Hi Benson,
Thanks for sending this in for review.
On 11/24/06, U-SOBIGbenson <bim2006(a)basistech.com> wrote:
>
>
>
> lib-src/ChangeLog addition:
>
> 2006-11-24 Benson Margulies <benson(a)dchbk.us>
>
> * make-mswin-unicode.pl: allow for lower case header file
names in the current platform SDK.
>
>
> src/ChangeLog addition:
>
> 2006-11-24 Benson Margulies <benson(a)dchbk.us>
>
> * fileio.c: Change check_writable to use the full Win32
mechanism to check access.
> * intl-auto-encap-win32.c: Add GetNamedSecurityInfo
> * intl-auto-encap-win32.h: Add GetNamedSecurityInfo
> * intl-auto-encap-win32.h Add qxeGetNamedSecurityInfo.
> * intl-encap-win32.c: Add aclapi.h : GetNamedSecurityInfo
> * syswindows.h: Add aclapi.h
You're using VC .Net, right? It looks like some definitions may be
missing on VC6; in a native build, I'm getting the following errors:
console-msw.c
e:\cygwin\usr\local\src\xemacs-21.5-2006-11-25\src\intl-auto-encap-win32
.h(476)
: error C2061: syntax error : identifier 'PDWORD_PTR'
e:\cygwin\usr\local\src\xemacs-21.5-2006-11-25\src\intl-auto-encap-win32
.h(488)
: error C2061: syntax error : identifier 'ULONG_PTR'
e:\cygwin\usr\local\src\xemacs-21.5-2006-11-25\src\intl-auto-encap-win32
.h(1025)
: error C2061: syntax error : identifier 'ULONG_PTR'
e:\cygwin\usr\local\src\xemacs-21.5-2006-11-25\src\intl-auto-encap-win32
.h(1297)
: error C2061: syntax error : identifier 'DWORD_PTR'
NMAKE: fatal error U1077: 'cl' : return code '0x2'
Stop.
FWIW, I did not find those definitions anywhere in my VC6 install
directory hierarchy.
- Vin
--
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches