martin@mwtech.UUCP (Martin Weitzel) (07/19/90)
In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes: >Has anyone else experienced this? I have AT&T/Intel Unix V/386 on my box: > >Take a 50 line file (not sure if 50-line specific, but that's where I found it). >Go to 2 lines below the bottom line using the G command. For example, under >TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26. >Then type ^B. It will beep. Then, type j. Suddenly the current line will >be copied onto line 1, and your file just got modified. Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here. I produced it in the following way: 1) Take a file somewhat larger than your screen (50 lines are not critical) 2) Make line "LINES+1" to be shown in the last line of your screen. Use any command you like to do so, move the cursor to any place you like, after you have positioned the screen. (Note: LINES defaults to 25 for TERM=AT386; so line 26 schould be last on the screen. You may verify this by ":set nu") 3) Type ^B (CTRL-B) ==> terminal beeps; screen *doesn't* change 4) Type ^L (Redraw screen) ==> Screen changes, topmost line is 1 now! 5) Type ^L once more ==> first line of screen changes and shows the same as the line your cursor were in when you typed ^B in step 3) I hope somebody who can fix this bug will read this description. *********************************************** ** ALL OTHERS BE WARNED: ** ** ** ** USING CTRL-B IN vi MAY RESULT IN CHANGING ** ** YOUR FILE UNDER CERTAIN CIRCUMSTANCES! ** *********************************************** Note: I've crossposted this to several other groups where the readers might be interested in this warning. Furthermore I'm not at all sure if this bug is specific to SysV. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
greim@sbsvax.cs.uni-sb.de (Michael Greim) (07/20/90)
In article <846@mwtech.UUCP>, martin@mwtech.UUCP (Martin Weitzel) writes: = In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes: = >Has anyone else experienced this? I have AT&T/Intel Unix V/386 on my box: = > = >Take a 50 line file (not sure if 50-line specific, but that's where I found it). = >Go to 2 lines below the bottom line using the G command. For example, under = >TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26. = >Then type ^B. It will beep. Then, type j. Suddenly the current line will = >be copied onto line 1, and your file just got modified. = = Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here. = I produced it in the following way: = [... detailed description of how to reproduce bug ...] I tried it on several machines with several 24 and 25 line terminals. I could not reproduce the bug. As all these systems are BSD or -related, it seems that the bug is specific to the SYS V version of vi. -mg -- .-. .-. .-. Michael Greim ( X )( __) e-mail : greim@cs.uni-sb.de \ / \ / \ / or : ...!uunet!unido!sbsvax!greim ~ ~ ~
rubin@cbnewsl.att.com (Mike Rubin) (07/20/90)
In article <846@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes: >>Has anyone else experienced this? I have AT&T/Intel Unix V/386 on my box: >> >>Take a 50 line file (not sure if 50-line specific, but that's where I found it). >>Go to 2 lines below the bottom line using the G command. For example, under >>TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26. >>Then type ^B. It will beep. Then, type j. Suddenly the current line will >>be copied onto line 1, and your file just got modified. > >Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here. >I produced it in the following way: > >1) Take a file somewhat larger than your screen (50 lines are not > critical) >2) Make line "LINES+1" to be shown in the last line of your screen. > Use any command you like to do so, move the cursor to any place > you like, after you have positioned the screen. > (Note: LINES defaults to 25 for TERM=AT386; so line 26 schould > be last on the screen. You may verify this by ":set nu") >3) Type ^B (CTRL-B) ==> terminal beeps; screen *doesn't* change >4) Type ^L (Redraw screen) ==> Screen changes, topmost line is 1 now! >5) Type ^L once more ==> first line of screen changes and shows the > same as the line your cursor were in when you typed ^B in step 3) > >I hope somebody who can fix this bug will read this description. I have reproduced it in the current development load of AT&T SVR4.0/386 version 2.0. I'll file the trouble report; it may or may not get fixed in time for the next customer release. --Mike Rubin <mike@attunix.att.com, address changing soon>
peter@ficc.ferranti.com (Peter da Silva) (07/20/90)
Another bug in 'vi' relates to the use of uparrow to switch to another file. If it fails for any reason, it will do weird things. It might be as benign as throwing you into line mode (repeat by: starting in a modified file, ":f non-existent-file" then "^^") or erasing the current line. That one I can't create on demand, but it's happened several times. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
rick@tetrauk.UUCP (Rick Jones) (07/25/90)
In article <846@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes: >>Has anyone else experienced this? I have AT&T/Intel Unix V/386 on my box: >> >>Take a 50 line file (not sure if 50-line specific, but that's where I found it). >>Go to 2 lines below the bottom line using the G command. For example, under >>TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26. >>Then type ^B. It will beep. Then, type j. Suddenly the current line will >>be copied onto line 1, and your file just got modified. > >Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here. I can confirm this happens with SCO Unix, too (ODT version, at least). On this subject, this version has another annoying bug, involving the use of p or P in macros. E.g. I use a key mapping to swap adjacent characters, which is the sequence xph (the h keeps the cursor in the same position). As a macro, the h gets inserted into the text! This happens in any macro using p or P followed by other characters, all the subsequent characters get inserted, not obeyed as commands. Lots of macros won't work because of this, including the wonderful word-completion macro recently posted in comp.editors. Is this unique to the SCO version of vi? And will someone at SCO please fix it. -- Rick Jones You gotta stand for something Tetra Ltd. Maidenhead, Berks Or you'll fall for anything rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick) - John Cougar Mellencamp
martin@mwtech.UUCP (Martin Weitzel) (07/26/90)
In article <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: > >On this subject, this version has another annoying bug, involving the use of p >or P in macros. E.g. I use a key mapping to swap adjacent characters, which is >the sequence xph (the h keeps the cursor in the same position). As a macro, >the h gets inserted into the text! This happens in any macro using p or P >followed by other characters, all the subsequent characters get inserted, not >obeyed as commands. Lots of macros won't work because of this, including the >wonderful word-completion macro recently posted in comp.editors. > >Is this unique to the SCO version of vi? And will someone at SCO please fix >it. Same on ISC 386/ix 2.0.2 as I just tried. Strange enough that p and P work if they are the last command character of a mapped sequence. For any particular problem one may try to change the sequence so that the p or P appears last, like lxhhp which gives you what you expect from xph, but in general it's annoying. One more of these things (which I don't consider a real bug, as the topics this thread started with, but rather a "anomality"). The commands d, c, y, <, >, and ! require a following move. Has anybody allready noticed that this seems all fine but there's an inconsitency with a w-move vs. the e-move in the context of the c-command? Though e and w move to different places and do something different in case of the de- and ye-command, they behave the same when combined with the c-command. Shouldn't cw include the blanks after the word and only ce behave the way most of us know from cw. (Yes, it would be inconvienient to change habits, but it's not "logical" how it is now.) P.S. Wouldn't it be a nice idea to archive these "anomalities" somewhere. (Volunteers? Oh what a silence around - I could hear a penny fall ... :-)) -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
rob@dutncp8.tudelft.nl (Rob Kurver) (07/27/90)
In <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >On this subject, this version has another annoying bug, involving the use of p >or P in macros. E.g. I use a key mapping to swap adjacent characters, which is >the sequence xph (the h keeps the cursor in the same position). As a macro, >the h gets inserted into the text! This happens in any macro using p or P >followed by other characters, all the subsequent characters get inserted, not >obeyed as commands. Lots of macros won't work because of this, including the >wonderful word-completion macro recently posted in comp.editors. >Is this unique to the SCO version of vi? And will someone at SCO please fix >it. I've experienced the same problem with the ESIX version of vi. When used in a macro, p and P don't work correctly. -- Rob Kurver rob@dutncp8.tudelft.nl Computational Physics Group rob@pact.nl Faculty of Applied Physics, Delft University of Technology Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis
petebob@sequent.UUCP (Pete_Bob Apple) (07/30/90)
In article <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >On this subject, this version has another annoying bug, involving the use of p >or P in macros. E.g. I use a key mapping to swap adjacent characters, which is >the sequence xph (the h keeps the cursor in the same position). As a macro, >the h gets inserted into the text! This happens in any macro using p or P >followed by other characters, all the subsequent characters get inserted, not >obeyed as commands. Lots of macros won't work because of this, including the >wonderful word-completion macro recently posted in comp.editors. > >Is this unique to the SCO version of vi? And will someone at SCO please fix >it. From some investigation, this bug seems to be related to how the sys5 version of vi treats the p. It tosses the p, and inserts an 'a' into the command queue, to append the last buffer. Unfortunately, it seems the append that happens doesn't end after the buffer, and ends up appending the rest of your macro as well. Need an escape sequence in there to work around it. On our version of vi (at least), if you use the sequence xp<ESC>h, it works correctly. A hack, in the very least. Pete_Bob -- Pete_Bob Apple Sequent Computer Systems sequent!petebob 15450 S.W. Koll Parkway Bob is not just a name.. Beaverton, Oregon 97006 It's a way of life.. (503) 626-5700
petebob@sequent.UUCP (Pete_Bob Apple) (07/31/90)
In article <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: > >On this subject, this version has another annoying bug, involving the use of p >or P in macros. E.g. I use a key mapping to swap adjacent characters, which is >the sequence xph (the h keeps the cursor in the same position). As a macro, >the h gets inserted into the text! This happens in any macro using p or P >followed by other characters, all the subsequent characters get inserted, not >obeyed as commands. Lots of macros won't work because of this, including the >wonderful word-completion macro recently posted in comp.editors. > >Is this unique to the SCO version of vi? And will someone at SCO please fix >it. > I've got a fix for those of you out there that might have source to modify. The fix is in the file ex_vget.c, in the getbr() function. Basically, the order in which the various strings are searched for input needs to be reordered. If you take a look at the file, you'll notice it looks for input from a few different buffers before going out to read something new. The bug occurs because when the p command goes to read the characters to "put", it ends up reading in the rest of the macro before the input characters themselves. This is the current order of the buffers searched: if (Peekkey) { ... } /* Peek ahead buffer */ if (vmacp) { ... } /* Macro string buffer */ if (Peek2key) { ... } /* 2nd Peek ahead buffer*/ if (vglobp) { ... } /* New text to insert */ The fix is to change the order like so: if (Peekkey) { ... } /* Peek ahead buffer */ if (Peek2key) { ... } /* 2nd Peek ahead buffer*/ if (vglobp) { ... } /* New text to insert */ if (vmacp) { ... } /* Macro string buffer */ This bug exists in V.3.2, and V.4 as well. -- Pete_Bob Apple Sequent Computer Systems sequent!petebob 15450 S.W. Koll Parkway Bob is not just a name.. Beaverton, Oregon 97006 It's a way of life.. (503) 626-5700
mmengel@cuuxb.ATT.COM (~XT6561110~Marc Mengel~C25~M27~6184~) (08/04/90)
In article <rob.649040634@dutncp8> rob@dutncp8.tudelft.nl (Rob Kurver) writes: >In <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >> This happens in any macro using p or P >>followed by other characters, all the subsequent characters get inserted, not >>obeyed as commands. >I've experienced the same problem with the ESIX version of vi. When used >in a macro, p and P don't work correctly. Having hacked on vi in the past, I would suspect this is yet another buffer management bug; i.e. the buffer containing the macro is being labeled as the "current" buffer for the p command. You can *probably* work around this by using a named buffer, as in "ayyj"ap instead of yyjp in your favorite macros, as the vi buffer code is notoriously tough to make sense of... -- Marc Mengel mmengel@cuuxb.att.com attmail!mmengel ...!{lll-crg|att}!cuuxb!mmengel
petebob@sequent.UUCP (Pete_Bob Apple) (08/06/90)
In article <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >In article <846@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >>In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes: >>>Has anyone else experienced this? I have AT&T/Intel Unix V/386 on my box: >>> >>>Take a 50 line file (not sure if 50-line specific, but that's where I found it). >>>Go to 2 lines below the bottom line using the G command. For example, under >>>TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26. >>>Then type ^B. It will beep. Then, type j. Suddenly the current line will >>>be copied onto line 1, and your file just got modified. >> >>Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here. > >I can confirm this happens with SCO Unix, too (ODT version, at least). > I've a fix for this bug too, if you have vi source to recompile. In V3.2 and V.4, the source for vi, the file ex_vmain.c: ---------------------------------------------- Change this: /* * ^B Window backwards, with 2 lines of continuity. * Inverse of ^F. */ case CTRL('b'): vsave(); if (one + vcline != dot && vcnt > 2) { > addr = dot - vcline - 2 - (cnt-1)*basWLINES; forbid (addr <= zero); dot = addr; vcnt = vcline = 0; } vzop(0, 0, '^'); continue; ---------------------------------------------- To: /* * ^B Window backwards, with 2 lines of continuity. * Inverse of ^F. */ case CTRL('b'): vsave(); if (one + vcline != dot && vcnt > 2) { > addr = dot - vcline + 2 - (cnt-1)*basWLINES; forbid (addr <= zero); dot = addr; vcnt = vcline = 0; } vzop(0, 0, '^'); continue; ---------------------------------------------- This fix makes CTRL-b operate correctly, and the bug goes away. I compared with the BSD world, and this fix was already in there. -- Pete_Bob Apple Sequent Computer Systems sequent!petebob 15450 S.W. Koll Parkway Bob is not just a name.. Beaverton, Oregon 97006 It's a way of life.. (503) 626-5700