| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
| |
Ref #1350
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears that large portion of non-ShaDa ASCII text files may be parsed as
a ShaDa file because it is mostly recognized as a sequence of unknown entries:
all ASCII non-control characters are recognized as FIXUINT shada objects, so
text like
#!/bin/sh
powerline "$@" 2>&1 | tee -a powerline
(with trailing newline) will be recognized as a correct ShaDa file containing
single unknown entry with type 0x23 (dec 35, '#'), timestamp 0x21 (dec 33, '!')
and length 0x2F (dec 47, '/') without this commit. With it parsing this entry
will fail.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For compatibility the following things are done:
1. Items with type greater then greatest type are ignored when reading and
copied when writing.
2. Registers with unknown name are ignored when reading and blindly copied when
writing.
3. Registers with unknown type are ignored when reading and merged as usual when
writing.
4. Local and global marks with unknown names are ignored when reading. When
writing global marks are blindly copied and local marks are also blindly
copied, but only if file they are attached to fits in the `'N` limit defined
in &shada. Unknown local mark’s timestamp is also taken into account when
calculating which files exactly should fit into this limit.
5. History items with unknown type are ignored when reading and blindly copied
when writing.
6. Unknown keys found in register, local marks, global marks, changes, jumps and
search pattern entries are read to additional_data Dictionary and dumped (of
course, unless any of these elements were not overwritten later). It
obviously works only for values conversible to Object type.
7. Additional elements found in replacement string and history entries are read
to additional_elements Array and dumped (same: only if they were not
overwritten later). Again this works only for elements conversible to Object
type.
8. Additional elements found in variable entries are simply ignored when
reading. When writing *new* variables they will be preserved during merging,
but that’s all. Variable values dumped from current NeoVim session never have
additional elements.
|
| | |
|
| |
|
|
|
|
|
|
| |
Modifications:
- If file was not written due to write error then writing stops and temporary
file will not be renamed.
- If NeoVim detects that target file is not a ShaDa file then temporary file
will not be renamed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some notes:
- Replaced msgpack_unpacker usage with regular xmalloc’ed buffer. Also since
msgpack_unpack_next (as well as msgpack_unpacker_next) is not ever going to
return MSGPACK_UNPACK_EXTRA_BYTES this condition was checked manually.
Function that does return this status is msgpack_unpack, but it is marked as
obsolete.
- Zero type is checked prior to main switch in shada_read_next_item because
otherwise check would be skipped.
- Zeroing entry at the start of shada_read_next_item makes it safer.
- dedent('') does not work.
- v:oldfiles list is only replaced with bang, if it is NULL or empty.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
