Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: two CVS checkout differ though -D is same
Well, though -D specifies 00:00:00 midnight, there are differences in files:
diff -r -q -x CVS src src-new > src.diff.txt
-------------------------------------------------------
Files src/usr.bin/vi/docs/features and src-new/usr.bin/vi/docs/features
differ
Files src/usr.bin/vi/docs/internals/autowrite and
src-new/usr.bin/vi/docs/internals/autowrite differ
Files src/usr.bin/vi/docs/internals/context and
src-new/usr.bin/vi/docs/internals/context differ
Files src/usr.bin/vi/docs/internals/gdb.script and
src-new/usr.bin/vi/docs/internals/gdb.script differ
Files src/usr.bin/vi/docs/internals/input and
src-new/usr.bin/vi/docs/internals/input differ
Files src/usr.bin/vi/docs/internals/quoting and
src-new/usr.bin/vi/docs/internals/quoting differ
Files src/usr.bin/vi/docs/internals/structures and
src-new/usr.bin/vi/docs/internals/structures differ
Both checkout was for 20080925-UTC, while one of them is on 20080927
while other one is on 20081031. There should be something affecting cvs
checkouts though -D is same.
I'm also attaching file differences as txt file.
Regards,
Cem
Alan Barrett, 11/03/08 10:35:
On Sun, 02 Nov 2008, David Maxwell wrote:
I've never spent the time to figure out exactly what cvs returns for
-D checkouts, but when there are multiple commits in a day, which one
you get isn't obvious beforehand.
-D specifies an instant in time. The cvs operation should yield the
code as it was at that instant.
If you pass -D only a date, without a time of day, then the instant of
time that you get is midnight (00:00:00) on that date. No matter how
many commits there were on that day, the result you get is from before
the first of those commits.
--apb (Alan Barrett)
diff -r -x CVS src.old/usr.bin/vi/docs/features src.new/usr.bin/vi/docs/features
1c1
< List of things that should be added:
---
> List of things that should be added at some point:
4,6c4,5
< + X11 (Tk, Motif, Xaw) interface.
< + Interpreted language (Perl, Scheme, Tcl/Rush, Python)
< + Additional ports: Windows, Windows NT, MSDOS
---
> + X11 interface.
>
8,13c7,14
< + Internationalization, including wide character and multibyte support.
< + Support for single line window editing, including full editing
< capability on the vi colon command line.
< + Rob Pike's sam style RE's.
< + Right-to-left and bottom to top text support.
< + Quitall command, to leave all windows. A ! will force the quit.
---
>
> + Internationalization, including wide character support.
>
> + Make db, curses real libraries that we load against instead of
> compiling directly.
>
> + Add a ":resize =N" command, that sets the window to a specific
> size.
17,42c18,28
< + It would be nice to have the completion mechanism found in tcsh versions
< >= 6.03. For instance, the completion for the `:cd' command will be
< directories only. The completion for the `:set' command will be all
< options not set at that moment, and for `:set un' will be all options
< that are set at that moment. The completion for `:< count' will be the
< flags.
<
< + Add an command-line option to initially split the screen based on the
< number of file arguments, e.g., "nvi -a file1 file2" would initialize
< a two edit-buffer display.
<
< + Add a "push" command that would push a file on the tags stack.
< (Essentially make tags a special case of the stack, and make
< the stack more general purpose.)
<
< + Make :script just run a command and edit the output, and :interactive,
< which allows interactive shell session, instead of just the current
< :script.
<
< + Add tagging information to the man page so that users can display
< the part of the man page that discusses the command in which they're
< interested.
<
< + Add a zone option so that you can declare that top/bottom few lines
< of the screen aren't filled except by accident, so that the text
< you ask for is always concentrated in the center of the screen.
---
> + Change tags to also attempt to find the file using the directory
> where it found the tags file.
>
> + Add versioning based on a "set version" variable, that would
> create backup copies when the file was written back, i.e. the
> ":w" and autowrite's would copy the original.
>
> + Add "set searchdir" for a list of directories to look in for
> files to edit. The semantic is that ":e foo" is replaced with
> the file name that is found, so there's no confusion as to
> which file is written.
52a39,42
> + Put multiple messages on a single line if they fit in their entirety,
> so that ":n" with autowrite set doesn't force users to hit return to
> get see both the "written" and "new file status" messages.
>
58,83d47
<
< + An option to turn on a ``quarter plane'' model so that you can
< go as far to the right or down as you wish. The File or the
< current line is only extended if you actually put down a char at
< the new location. Very handy for ascii graphics and tables.
<
< + Some way of replacing the command bindings. For this to work
< cleanly the notion of a command must be separate from that of a
< key. (Simulate the Rand editor?)
<
< + Vertical splitting, so you can see files side by side.
<
< + Tracking. Two or more files are associated so that when one file
< is scrolled up/down/left/right other files track by the same amount.
< Tracking may be constrained such that two files only track vertically
< or horizontally. This is relatively easy to implement.
<
< + A status file so that the next time invocation of the editor returns
< to the same place, with the same number of windows etc. In case of
< change of the screen size, reasonable defaults are used. For each
< window size and location of the window, name of the file and position
< in it, any tab settings, any other settings for the window (such as
< insert/overwrite mode, auto indent etc). Last search RE and maybe
< direction. If a file does not exist the next time you invoke the
< editor, its window is left in the same place but with some default
< message.
diff -r -x CVS src.old/usr.bin/vi/docs/internals/autowrite
src.new/usr.bin/vi/docs/internals/autowrite
1c1
< # @(#)autowrite 8.3 (Berkeley) 2/17/95
---
> # @(#)autowrite 8.2 (Berkeley) 9/28/93
16,18c16,18
< ^^ Y Y Write file and jump.
< ^^ Y N Error.
< ^^ N * Jump.
---
> ^ Y Y Write file and jump.
> ^ Y N Error.
> ^ N * Jump.
diff -r -x CVS src.old/usr.bin/vi/docs/internals/context
src.new/usr.bin/vi/docs/internals/context
1c1
< # @(#)context 8.6 (Berkeley) 10/14/94
---
> # @(#)context 8.5 (Berkeley) 7/23/94
9c9
< ex commands: undo, "z.", global, v
---
> ex commands: undo, "z.", global, vglobal
diff -r -x CVS src.old/usr.bin/vi/docs/internals/gdb.script
src.new/usr.bin/vi/docs/internals/gdb.script
1c1
< # @(#)gdb.script 8.5 (Berkeley) 5/4/96
---
> # @(#)gdb.script 8.2 (Berkeley) 9/29/93
3c3
< # display the VI screen map
---
> # display the SVI screen map
6,7c6,7
< set $h = ((VI_PRIVATE *)$arg0->vi_private)->h_smap
< set $t = ((VI_PRIVATE *)$arg0->vi_private)->t_smap
---
> set $h = ((SVI_PRIVATE *)$arg0->svi_private)->h_smap
> set $t = ((SVI_PRIVATE *)$arg0->svi_private)->t_smap
9,10c9
< printf "lno: %2d; soff %d coff %d ", \
< (int)$h->lno, (int)$h->soff, (int)$h->coff
---
> printf "lno: %d; off %d ", (int)$h->lno, (int)$h->off
24c23
< # display the tail of the VI screen map
---
> # display the tail of the SVI screen map
26,27c25,26
< set $h = ((VI_PRIVATE *)$arg0->vi_private)->h_smap
< set $t = ((VI_PRIVATE *)$arg0->vi_private)->t_smap
---
> set $h = ((SVI_PRIVATE *)$arg0->svi_private)->h_smap
> set $t = ((SVI_PRIVATE *)$arg0->svi_private)->t_smap
29,30c28
< printf "lno: %2d; soff %d coff %d ", \
< (int)$t->lno, (int)$t->soff, (int)$t->coff
---
> printf "lno: %d; off %d ", (int)$t->lno, (int)$t->off
44,52c42,44
< # display the private structures
< define clp
< print *((CL_PRIVATE *)sp->gp->cl_private)
< end
< define vip
< print *((VI_PRIVATE *)sp->vi_private)
< end
< define exp
< print *((EX_PRIVATE *)sp->ex_private)
---
> # display the SVI private structure
> define svp
> print *((SVI_PRIVATE *)sp->svi_private)
diff -r -x CVS src.old/usr.bin/vi/docs/internals/input
src.new/usr.bin/vi/docs/internals/input
1c1
< # @(#)input 5.5 (Berkeley) 7/2/94
---
> # @(#)input 5.4 (Berkeley) 8/26/93
68,69d67
< 7: Characters in executable buffers are remapped.
< 8: Characters in executable buffers are not quoted.
317,350d314
< 7: Characters in executable buffers are remapped.
<
< === test file ===
< abcdefghijklmnnop
< ggg
< === end test file ===
<
< :map g x
< 2G"ay$1G@a
<
< The output should be:
<
< === output file ===
< defghijklmnnop
< ggg
< === end output file ===
<
< =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
< 8: Characters in executable buffers are not quoted.
<
< === test file ===
< iFOO^[
<
< === end test file ===
<
< 1G"ay$2G@a
<
< The output should be:
<
< === output file ===
< iFOO^[
< FOO
< === end output file ===
< =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
diff -r -x CVS src.old/usr.bin/vi/docs/internals/quoting
src.new/usr.bin/vi/docs/internals/quoting
1c1
< # @(#)quoting 5.5 (Berkeley) 11/12/94
---
> # @(#)quoting 5.4 (Berkeley) 8/20/93
5c5,14
< There are four escape characters in historic ex/vi:
---
> There are two escape characters in historic ex/vi, ^V (or whatever
> character the user specified as their literal next character) and
> backslashes. There are two different areas in ex/vi where escaping
> is interesting: the command and text input modes, and within the ex
> commands themselves. In the examples below, ^V is used as the
> typical literal next character.
>
> 1: Escaping characters in ex and vi command and text input modes.
> The set of characters that users might want to escape are as
> follows:
7,10c16
< \ (backslashes)
< ^V
< ^Q (assuming it wasn't used for IXON/IXOFF)
< The terminal literal next character.
---
> vi text input mode (a, i, o, etc.):
12,13c18,26
< Vi did not use the lnext character, it always used ^V (or ^Q).
< ^V and ^Q were equivalent in all cases for vi.
---
> carriage return (^M)
> escape (^[)
> autoindent characters
> (^D, 0, ^, ^T)
> erase, word erase, and line erase
> (^H, ^W, ^U)
> newline (^J) (not historic practice)
> suspend (^Z) (not historic practice)
> repaint (^L) (not historic practice)
15,16c28
< There are four different areas in ex/vi where escaping characters
< is interesting:
---
> vi command line (:colon commands):
18,21c30,36
< 1: In vi text input mode.
< 2: In vi command mode.
< 3: In ex command and text input modes.
< 4: In the ex commands themselves.
---
> carriage return (^M)
> escape (^[)
> erase, word erase, and line erase
> (^H, ^W, ^U)
> newline (^J) (not historic practice)
> suspend (^Z) (not historic practice)
> repaint (^L) (not historic practice)
23c38
< 1: Vi text input mode (a, i, o, :colon commands, etc.):
---
> ex text input mode (a, i, o, etc.):
25,26c40,45
< The set of characters that users might want to escape are as follows.
< As ^L and ^Z were not special in input mode, they are not listed.
---
> carriage return (^M)
> erase, word erase, and line erase
> (^H, ^W, ^U)
> newline (^J) (not historic practice)
>
> ex command line:
29,80c48,84
< escape (^[)
< autoindents (^D, 0, ^, ^T)
< erase (^H)
< word erase (^W)
< line erase (^U)
< newline (^J) (not historic practice)
<
< Historic practice was that ^V was the only way to escape any
< of these characters, and that whatever character followed
< the ^V was taken literally, e.g. ^V^V is a single ^V. I
< don't see any strong reason to make it possible to escape
< ^J, so I'm going to leave that alone.
<
< One comment regarding the autoindent characters. In historic
< vi, if you entered "^V0^D" autoindent erasure was still
< triggered, although it wasn't if you entered "0^V^D". In
< nvi, if you escape either character, autoindent erasure is
< not triggered.
<
< Abbreviations were not performed if the non-word character
< that triggered the abbreviation was escaped by a ^V. Input
< maps were not triggered if any part of the map was escaped
< by a ^V.
<
< The historic vi implementation for the 'r' command requires
< two leading ^V's to replace a character with a literal
< character. This is obviously a bug, and should be fixed.
<
< 2: Vi command mode
<
< Command maps were not triggered if the second or later
< character of a map was escaped by a ^V.
<
< The obvious extension is that ^V should keep the next command
< character from being mapped, so you can do ":map x xxx" and
< then enter ^Vx to delete a single character.
<
< 3: Ex command and text input modes.
<
< As ex ran in canonical mode, there was little work that it
< needed to do for quoting. The notable differences between
< ex and vi are that it was possible to escape a <newline> in
< the ex command and text input modes, and ex used the "literal
< next" character, not control-V/control-Q.
<
< 4: The ex commands:
<
< Ex commands are delimited by '|' or newline characters.
< Within the commands, whitespace characters delimit the
< arguments. Backslash will generally escape any following
< character. In the abbreviate, unabbreviate, map and unmap
< commands, control-V escapes the next character, instead.
---
> erase, word erase, and line erase
> (^H, ^W, ^U)
> newline (^J) (not historic practice)
> suspend (^Z)
>
> I intend to follow historic practice for all of these cases, which
> was that ^V was the only way to escape any of these characters, and
> that whatever character followed the ^V was taken literally, i.e.
> ^V^V is a single ^V.
>
> The historic ex/vi disallowed the insertion of various control
> characters (^D, ^T, whatever) during various different modes, or,
> permitted the insertion of only a single one, or lots of other random
> behaviors (you can use ^D to enter a command in ex). I have
> regularized this behavior in nvi, there are no characters that cannot
> be entered or which have special meaning other than the ones listed
> above.
>
> One comment regarding the autoindent characters. In historic vi,
> if you entered "^V0^D" autoindent erasure was still triggered,
> although it wasn't if you entered "0^V^D". In nvi, if you escape
> either character, autoindent erasure is not triggered.
>
> This doesn't permit whitespace in command names, but that wasn't
> historic practice and doesn't seem worth doing.
>
> Fun facts to know and tell:
> The historic vi implementation for the 'r' command requires
> *three* ^V's to replace a single character with ^V.
>
> 2: Ex commands:
>
> Ex commands are delimited by '|' or newline characters. Within
> the commands, whitespace characters delimit the arguments.
>
> I intend to treat ^V, followed by any character, as that literal
> character.
86c90
< Escaping characters in file names in ex commands:
---
> 3: Escaping characters in file names in ex commands:
100,104c104,114
< Since file names are also subject to word expansion, the
< underlying shell had better be doing the correct backslash
< escaping. This is NOT historic behavior in vi, making it
< impossible to insert a whitespace, newline or carriage return
< character into a file name.
---
> I intend to treat a backslash in a file name, followed by any
> character, as that literal character.
>
> This is historic behavior in vi.
>
> In addition, since file names are also subject to word expansion,
> the rules for escape characters in section 3 of this document also
> apply. This is NOT historic behavior in vi, making it impossible
> to insert a whitespace, newline or carriage return character into
> a file name. This change could cause a problem if there were files
> with ^V's in their names, but I think that's unlikely.
110a121
> :k key (key)
111a123
> :mark key (key)
138,140c150,152
< In addition, the edit and ex commands have historically
< ignored literal next characters in the +cmd string, so that
< the following command won't work.
---
> In addition, the edit and ex commands have historically ignored
> literal next characters in the +cmd string, so that the following
> command won't work.
158,160c170,172
< The set command treats ^V's as literal characters, so the
< following command won't work. Backslashes do work in this
< case, though, so the second version of the command does work.
---
> The set command treats ^V's as literal characters, so the following
> command won't work. Backslashes do work in this case, though, so
> the second version of the command does work.
165,170c177,182
< I intend to continue permitting backslashes in set commands,
< but to also permit literal next characters to work as well.
< This is backward compatible, but will also make set
< consistent with the other commands. I think it's unlikely
< to break any historic .exrc's, given that there are probably
< very few files with ^V's in their name.
---
> I intend to continue permitting backslashes in set commands, but
> to also permit literal next characters to work as well. This is
> backward compatible, but will also make set consistent with the
> other commands. I think it's unlikely to break any historic
> .exrc's, given that there are probably very few files with ^V's
> in their name.
208d219
<
diff -r -x CVS src.old/usr.bin/vi/docs/internals/structures
src.new/usr.bin/vi/docs/internals/structures
1c1
< # @(#)structures 5.4 (Berkeley) 10/4/95
---
> # @(#)structures 5.2 (Berkeley) 11/1/93
3,20c3,16
< There are three major data structures in this package, plus a single data
< structure per screen type. The first is a single global structure (GS)
< which contains information common to all files and screens. It hold
< global things like the input key queues, and functions as a single place
< to hang things. For example, interrupt routines have to be able to find
< screen structures, and they can only do this if they have a starting
< point. The number of globals in nvi is dependent on the screen type, but
< every screen type will have at least one global, __global_list, which
< references the GS structure.
<
< The GS structure contains linked lists of screen (SCR) structures.
< Each SCR structure normally references a file (EXF) structure.
<
< The GS structure has a set of functions which update the screen and/or
< return information about the screen from the underlying screen package.
< The GS structure never goes away. The SCR structure persists over
< instances of screens, and the EXF structure persists over references to
< files.
---
> There are three major data structures in this package. The first is a
> single global structure (named GS) which contains information common to
> all files and screens. It's really pretty tiny, and functions more as a
> single place to hang things than anything else.
>
> The second and third structures are the file structures (named EXF) and
> the screen structures (named SCR). They contain information theoretically
> unique to a screen or file, respectively. Each SCR structure has a set
> of functions which update the screen and/or return information about the
> screen from the underlying screen package.
>
> The GS structure contains linked lists SCR structures. The structures
> can also be classed by persistence. The GS structure never goes away
> and the SCR structure persists over instances of files.
26,32c22,29
< In general, functions are always passed an SCR structure, which usually
< references an underlying EXF structure. The SCR structure is necessary
< for any routine that wishes to talk to the screen, the EXF structure is
< necessary for any routine that wants to modify the file. The relationship
< between an SCR structure and its underlying EXF structure is not fixed,
< and various ex commands will substitute a new EXF in place of the current
< one, and there's no way to detect this.
---
> In general, functions are always passed an SCR structure and often an EXF
> structure as well. The SCR structure is necessary for any routine that
> wishes to talk to the screen, the EXF structure is necessary for any
> routine that wants to modify the file. The relationship between an SCR
> structure and its underlying EXF structure is not fixed, and although you
> can translate from an SCR to the underlying EXF, it is discouraged. If
> this becomes too onerous, I suspect I'll just stop passing around the EXF
> in the future.
47,49d43
< CL The curses screen private data structure. Everything to
< do standalone curses screens.
<
57,63c51,55
< TK The Tcl/Tk screen private data structure. Everything to
< do standalone Tcl/Tk screens.
<
< EXCMD In nvi/ex/ex.h. The structure that gets passed around to the
< functions that implement the ex commands. (The main ex command
< loop (see nvi/ex/ex.c) builds this up and then passes it to the
< ex functions.)
---
> EXCMDARG
> In nvi/ex/excmd.h.stub. The structure that gets passed around
> to the functions that implement the ex commands. (The main
> ex command loop (see nvi/ex/ex.c) builds this up and then passes
> it to the ex functions.)
65c57,58
< VICMD In nvi/vi/vi.h. The structure that gets passed around to the
---
> VICMDARG
> In nvi/vi/vcmd.h. The structure that gets passed around to the
Home |
Main Index |
Thread Index |
Old Index