bam@rudedog.asd.sgi.com (Brian McClendon) (03/28/91)
After my silly ftp situation (I was just not patient enough), take any problems I have with a grain of salt. I picked up the src for both 3.10m and 3.11B and, after switching back to the old (3.10e) makefile.unx, the first problem I had was with ctrl-S acting as XOFF instead of a normal ctrl character. This was fixed by: changing: curterm.c_iflag &= ~(INLCR|ICRNL|IGNCR); to: curterm.c_iflag &= ~(INLCR|ICRNL|IGNCR|IXON|IXOFF); in unix.c. Now that my ctrl-S gets me into incremental search, I find that a second ctrl-S gets me into a _new_ incremental search instead of searching for the 2nd occurence of the current search string. Is this one obvious? -- ---------------------------------------------------------------------------- Brian McClendon bam@rudedog.SGI.COM ...!uunet!sgi!rudedog!bam 415-335-1110 ----------------------------------------------------------------------------
decouty@irisa.fr (Bertrand Decouty) (03/29/91)
In article <1991Mar28.083424.7514@odin.corp.sgi.com> bam@rudedog.asd.sgi.com (Brian McClendon) writes: | | After my silly ftp situation (I was just not patient enough), take any | problems I have with a grain of salt. | | I picked up the src for both 3.10m and 3.11B and, after switching back to | the old (3.10e) makefile.unx, the first problem I had was with ctrl-S | acting as XOFF instead of a normal ctrl character. This was fixed by: | | changing: | curterm.c_iflag &= ~(INLCR|ICRNL|IGNCR); | to: | curterm.c_iflag &= ~(INLCR|ICRNL|IGNCR|IXON|IXOFF); | | in unix.c. For catching 8-bit characters, you must add | ISTRIP. Now i can type 8-bit chars, but there is still a bug in search proc which prevent me from searching these characters. I shall investigate, as i have done it in 3.10e. BTW, when you do ^S/^R in incremental search, these ^S/^R are put in the search string!! A big (and old ?) bug. As we are speaking of 3.11Beta and bugs: - in eproto.h, mlwrite(va_dcl) must be mlwrite(va_alist) (if you use varargs) - in unix.c, return write(0, outbuf, len) != len; should be (in order for me311 to be called from less pager) status = (fwrite( outbuf, 1, len, stdout) != len); fflush(stdout); return(status) Also, in input.c, there is still no ~/ and $VARIABLE expansion. Hopefully, older patch works but it should be included in the final release. I have compiled me311B on sun3/sun4 with gcc, apart from a lot of warning, it works (flags SUN and GCC, no BSD)! | | Now that my ctrl-S gets me into incremental search, I find that a | second ctrl-S gets me into a _new_ incremental search instead of | searching for the 2nd occurence of the current search string. Is this | one obvious? It works for me, but i have made this patch: *** isearch.c.orig Wed Mar 27 12:27:34 1991 --- isearch.c Wed Mar 27 12:30:46 1991 *************** *** 195,200 **** --- 195,201 ---- while (pat[cpos] != 0) col = echochar((int)pat[cpos++],col); + cmd_buff[--cmd_offset] = '\0'; /* Delete last char (^R/^S) */ status = scanmore(dir); continue; } ============================== If anybody have other patches... Bertrand Decouty | | -- | ---------------------------------------------------------------------------- | Brian McClendon bam@rudedog.SGI.COM ...!uunet!sgi!rudedog!bam 415-335-1110 | ---------------------------------------------------------------------------- -- [ Bertrand DECOUTY | EMAIL : decouty@irisa.fr, decouty@irisa.uucp ] [ IRISA - INRIA (Atelier) | {uunet,mcsun,inria}!irisa!decouty ] [ Campus de Beaulieu | PHONE : +33 99 36 20 00 ] [ F-35042 Rennes Cedex - FRANCE| FAX : +33 99 38 38 32 | TELEX: 950473 UNIRISA]
mike@antel.uucp (Michael Borza) (04/02/91)
In article <1991Mar29.092148.6534@irisa.fr> decouty@irisa.fr (Bertrand Decouty) writes: >- in eproto.h, mlwrite(va_dcl) must be mlwrite(va_alist) (if you use >varargs) >============================== >If anybody have other patches... >Bertrand Decouty well, now that you mention it,.... Compiling uemacs3.11beta with Turbo C++ 2.0, I found the following change to `mlwrite' in `display.c' was required to get it to build: change: CDECL NEAR mlwrite(fmt) char *fmt; {... register va_list ap; to: CDECL NEAR mlwrite(char *fmt,....) { .... va_list ap; If not, TC++ 2.0 fails later in the compile when an attempt to take the address of `ap' is made in TC++'s varargs implementation. I also have other minor changes to makefiles and the like, which I'll submit to Dan once I have changes to build using Zortech C++ as well. While I'm posting, I'd like an opinion: I propose to explicitly declare routines which are to return no value to return VOID. This is done inconsistently throughout the code, resulting in unnecessary warnings for a (largish) number of routines. I found this especially annoying using a heavily "ANSIfied" compiler like TC++, but that's probably just years of pcc's indifference talking. In any event, this change should be transparent, since VOID is suitably defined in ESTRUCT.H for each target system. Comments? cheers, mike borza. -- Michael Borza Antel Optronics Inc. (416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6 work: mike@antel.on.ca or uunet!utai!utgpu!maccs!antel!mike home: mike@boopsy.uucp or uunet!utai!utgpu!maccs!boopsy!mike
apratt@atari.UUCP (Allan Pratt) (04/05/91)
bam@rudedog.asd.sgi.com (Brian McClendon) writes: >Now that my ctrl-S gets me into incremental search, I find that a >second ctrl-S gets me into a _new_ incremental search instead of >searching for the 2nd occurence of the current search string. Is this >one obvious? Reasonably. fisearch() and risearch() interpret the keys you type. If you hit a command key, that command gets done. BUT, if the command is bound to a "search-class" command, the isearch is repeated in the direction of the search whose command key you hit. This is all well and good, but the code doesn't consider fisearch() or risearch() themselves as "search-class" commands, so you don't get what you expect when you hit those keys. I fixed that in a set of patches that I sent Daniel Lawrence last night on his BBS. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt