X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: rugxulo AT gmail DOT com Newsgroups: comp.os.msdos.djgpp Subject: Re: Ispell (found the problem! here's a rough patch) Date: Thu, 12 Jul 2012 16:58:27 -0700 (PDT) Organization: http://groups.google.com Lines: 92 Message-ID: <44cbf133-ea8b-47d6-9f01-0c7cef19c13a@googlegroups.com> References: <83sjd412pe DOT fsf AT gnu DOT org> <83obnql106 DOT fsf AT gnu DOT org> NNTP-Posting-Host: 65.13.115.246 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1342139007 31596 127.0.0.1 (13 Jul 2012 00:23:27 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Fri, 13 Jul 2012 00:23:27 +0000 (UTC) Cc: djgpp AT delorie DOT com In-Reply-To: <83obnql106.fsf@gnu.org> Complaints-To: groups-abuse AT google DOT com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO User-Agent: G2/1.0 Bytes: 4880 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q6D0j2IJ010942 Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Hi, On Sunday, July 8, 2012 10:35:05 AM UTC-5, Eli Zaretskii wrote: > > Thanks, this is indeed the cause of the problem. > > I think I will simply remove that #define of FILE_SYSTEM_CASE for the > DJGPP port. I don't see why we need it nowadays, that all file names > are compared case-insensitively on DOS and Windows. FYI, the reason I had trouble recompiling initially was due to not unpacking the *.elc files. (I was trying to use my 150 MB RAM drive. Alas.) I guess the makefile didn't like those missing. Otherwise fairly straightforward, though I still needed to use $(CURDIR) in two makefiles due to FreeDOS. Anyways, we haven't heard back from the OP, so I don't know if he is able to rebuild it himself or not. That kinda bugs me, heh. I have my own (very very) wimpy source patch to fix it, but it's far from optimal. ======================================== --- callproc.c 2011-01-08 19:45:14 +0000 +++ callproc.new 2012-07-07 19:37:48 +0000 @@ -929,6 +929,10 @@ int fd; BLOCK_INPUT; + + char* rugxulo = strstr(tempfile,".xxx"); + if (rugxulo) strncpy(rugxulo,".XXX",4); + fd = mkstemp (tempfile); UNBLOCK_INPUT; if (fd == -1) ======================================== See? :-)) For simplicity and easier deployment, I'd almost rather we had a small binary patch for EMACS.EXE, so I tried to make my own. It seems to work, but it's very rough, so perhaps it's not totally flawless (huge understatement). I basically just hacked around in raw assembly via HIEW. It's quite weird seeing GCC output, esp. because it (sometimes) does some unusual things. Long story short, I'm basically moving, calling the patch (more or less just "and blah, 0xDF" for a rough toupper() functionality), returning, etc. Ugly, confusing, difficult, probably not ideal, but it seems to work. BTW, I didn't use "cmp -l" because I hate octal. Then I had to use sed to mask FC's unnecessary 8-bit output so nobody would complain. fc /m35 /b emacs.old emacs.exe$ $ Comparing G:\\TONY\\EMACS.OLD and G:\\TONY\\EMACS.EXE$ 00115D83: A9 \251 AE \256$ 00145F00: 80 \200 E8 \350$ 00145F01: 7B { 1E $ 00145F02: FF \377 01 $ 00145F03: 58 X 00 $ 00145F04: 75 u 00 $ 00145F05: 0C 90 \220$ 00146021: 89 \211 C9 \311$ 00146022: EC \354 C3 \303$ 00146023: 5D ] 80 \200$ 00146024: C3 \303 63 c$ 00146025: 8D \215 FF \377$ 00146026: 76 v 58 X$ 00146027: 00 80 \200$ 00146028: 00 7B {$ 00146029: 00 FF \377$ 0014602A: 00 58 X$ 0014602B: 00 74 t$ 0014602C: 00 07 $ 0014602D: 00 5A Z$ 0014602E: 00 E9 \351$ 0014602F: 00 DF \337$ 00146030: 55 U FE \376$ 00146031: 89 \211 FF \377$ 00146032: E5 \345 FF \377$ 00146033: 81 \201 90 \220$ 00146034: EC \354 C3 \303$ 00146035: 04 C8 \310$ 00146036: 01 04 $ 00146037: 00 01 $ I don't really know of a better way to binary patch things outside of manually writing my own wimpy .c program to do so (as I've done twice fairly recently). Maybe CWS knows, maybe bdiff or xdiff or whatever else I'm forgetting. Bah. Feel free to suggest another solution.