2019-04-02 00:50:28 +02:00
|
|
|
local helpers = require('test.functional.helpers')(after_each)
|
|
|
|
|
|
|
|
|
|
local clear = helpers.clear
|
|
|
|
|
local command = helpers.command
|
|
|
|
|
local eq = helpers.eq
|
|
|
|
|
local funcs = helpers.funcs
|
|
|
|
|
local feed = helpers.feed
|
2021-09-19 02:29:37 -07:00
|
|
|
local exec_capture = helpers.exec_capture
|
2019-04-02 00:50:28 +02:00
|
|
|
local write_file = helpers.write_file
|
|
|
|
|
|
|
|
|
|
describe('jumplist', function()
|
|
|
|
|
local fname1 = 'Xtest-functional-normal-jump'
|
|
|
|
|
local fname2 = fname1..'2'
|
|
|
|
|
before_each(clear)
|
|
|
|
|
after_each(function()
|
|
|
|
|
os.remove(fname1)
|
|
|
|
|
os.remove(fname2)
|
|
|
|
|
end)
|
|
|
|
|
|
|
|
|
|
it('does not add a new entry on startup', function()
|
|
|
|
|
eq('\n jump line col file/text\n>', funcs.execute('jumps'))
|
|
|
|
|
end)
|
|
|
|
|
|
|
|
|
|
it('does not require two <C-O> strokes to jump back', function()
|
|
|
|
|
write_file(fname1, 'first file contents')
|
|
|
|
|
write_file(fname2, 'second file contents')
|
|
|
|
|
|
|
|
|
|
command('args '..fname1..' '..fname2)
|
|
|
|
|
local buf1 = funcs.bufnr(fname1)
|
|
|
|
|
local buf2 = funcs.bufnr(fname2)
|
|
|
|
|
|
|
|
|
|
command('next')
|
|
|
|
|
feed('<C-O>')
|
|
|
|
|
eq(buf1, funcs.bufnr('%'))
|
|
|
|
|
|
|
|
|
|
command('first')
|
|
|
|
|
command('snext')
|
|
|
|
|
feed('<C-O>')
|
|
|
|
|
eq(buf1, funcs.bufnr('%'))
|
|
|
|
|
feed('<C-I>')
|
|
|
|
|
eq(buf2, funcs.bufnr('%'))
|
|
|
|
|
feed('<C-O>')
|
|
|
|
|
eq(buf1, funcs.bufnr('%'))
|
|
|
|
|
|
|
|
|
|
command('drop '..fname2)
|
|
|
|
|
feed('<C-O>')
|
|
|
|
|
eq(buf1, funcs.bufnr('%'))
|
|
|
|
|
end)
|
|
|
|
|
end)
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
|
2019-12-10 01:24:20 -08:00
|
|
|
describe("jumpoptions=stack behaves like 'tagstack'", function()
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
before_each(function()
|
|
|
|
|
clear()
|
|
|
|
|
feed(':clearjumps<cr>')
|
|
|
|
|
|
|
|
|
|
-- Add lines so that we have locations to jump to.
|
|
|
|
|
for i = 1,101,1
|
|
|
|
|
do
|
|
|
|
|
feed('iLine ' .. i .. '<cr><esc>')
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
-- Jump around to add some locations to the jump list.
|
|
|
|
|
feed('0gg')
|
|
|
|
|
feed('10gg')
|
|
|
|
|
feed('20gg')
|
|
|
|
|
feed('30gg')
|
|
|
|
|
feed('40gg')
|
|
|
|
|
feed('50gg')
|
|
|
|
|
|
|
|
|
|
feed(':set jumpoptions=stack<cr>')
|
|
|
|
|
end)
|
|
|
|
|
|
|
|
|
|
after_each(function()
|
|
|
|
|
feed('set jumpoptions=')
|
|
|
|
|
end)
|
|
|
|
|
|
|
|
|
|
it('discards the tail when navigating from the middle', function()
|
|
|
|
|
feed('<C-O>')
|
|
|
|
|
feed('<C-O>')
|
|
|
|
|
|
2021-09-19 02:29:37 -07:00
|
|
|
eq( ''
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
.. ' jump line col file/text\n'
|
|
|
|
|
.. ' 4 102 0 \n'
|
|
|
|
|
.. ' 3 1 0 Line 1\n'
|
|
|
|
|
.. ' 2 10 0 Line 10\n'
|
|
|
|
|
.. ' 1 20 0 Line 20\n'
|
|
|
|
|
.. '> 0 30 0 Line 30\n'
|
|
|
|
|
.. ' 1 40 0 Line 40\n'
|
|
|
|
|
.. ' 2 50 0 Line 50',
|
2021-09-19 02:29:37 -07:00
|
|
|
exec_capture('jumps'))
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
|
|
|
|
|
feed('90gg')
|
|
|
|
|
|
2021-09-19 02:29:37 -07:00
|
|
|
eq( ''
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
.. ' jump line col file/text\n'
|
|
|
|
|
.. ' 5 102 0 \n'
|
|
|
|
|
.. ' 4 1 0 Line 1\n'
|
|
|
|
|
.. ' 3 10 0 Line 10\n'
|
|
|
|
|
.. ' 2 20 0 Line 20\n'
|
|
|
|
|
.. ' 1 30 0 Line 30\n'
|
|
|
|
|
.. '>',
|
2021-09-19 02:29:37 -07:00
|
|
|
exec_capture('jumps'))
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
end)
|
|
|
|
|
|
|
|
|
|
it('does not add the same location twice adjacently', function()
|
|
|
|
|
feed('60gg')
|
|
|
|
|
feed('60gg')
|
|
|
|
|
|
2021-09-19 02:29:37 -07:00
|
|
|
eq( ''
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
.. ' jump line col file/text\n'
|
|
|
|
|
.. ' 7 102 0 \n'
|
|
|
|
|
.. ' 6 1 0 Line 1\n'
|
|
|
|
|
.. ' 5 10 0 Line 10\n'
|
|
|
|
|
.. ' 4 20 0 Line 20\n'
|
|
|
|
|
.. ' 3 30 0 Line 30\n'
|
|
|
|
|
.. ' 2 40 0 Line 40\n'
|
|
|
|
|
.. ' 1 50 0 Line 50\n'
|
|
|
|
|
.. '>',
|
2021-09-19 02:29:37 -07:00
|
|
|
exec_capture('jumps'))
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
end)
|
|
|
|
|
|
|
|
|
|
it('does add the same location twice nonadjacently', function()
|
|
|
|
|
feed('10gg')
|
|
|
|
|
feed('20gg')
|
|
|
|
|
|
2021-09-19 02:29:37 -07:00
|
|
|
eq( ''
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
.. ' jump line col file/text\n'
|
|
|
|
|
.. ' 8 102 0 \n'
|
|
|
|
|
.. ' 7 1 0 Line 1\n'
|
|
|
|
|
.. ' 6 10 0 Line 10\n'
|
|
|
|
|
.. ' 5 20 0 Line 20\n'
|
|
|
|
|
.. ' 4 30 0 Line 30\n'
|
|
|
|
|
.. ' 3 40 0 Line 40\n'
|
|
|
|
|
.. ' 2 50 0 Line 50\n'
|
|
|
|
|
.. ' 1 10 0 Line 10\n'
|
|
|
|
|
.. '>',
|
2021-09-19 02:29:37 -07:00
|
|
|
exec_capture('jumps'))
|
jumplist: browser-style (or 'tagstack') navigation #11530
Traditionally, when navigating to a specific location from the middle of
the jumplist results in shifting the current location to the bottom of
the list and adding the new location after it. This behavior is not
desireable to all users--see, for example
https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior.
Here, another jumplist behavior is introduced. When jumpoptions (a new
option set added here) includes stack, the jumplist behaves like the
tagstack or like history in a web browser. That is, when navigating to
a location from the middle of the jumplist
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
to a new location the locations after the current location in the jump
list are discarded
2 first
1 second
0 third
<-- current location
The result is that when moving forward from that location, the new
location will be appended to the jumplist:
3 first
2 second
1 third
0 new
If the new location is the same
new == second
as some previous (but not immediately prior) entry in the jumplist,
2 first
1 second
0 third <-- current location
1 fourth
2 fifth
both occurrences preserved
3 first
2 second
1 third
0 second (new)
when moving forward from that location.
It would be desireable to go farther and, when the new location is the
same as the location that is currently next in the jumplist,
new == fourth
make the result of navigating to the new location by jumping (e.g. 50gg)
be the same as moving forward in the jumplist
2 first
1 second
0 third
1 new <-- current location
2 fifth
and simply increment the jumplist index. That change is NOT part of
this patch because it would require passing the new cursor location to
the function (setpcmark) from all of its callees. That in turn would
require those callees to know *before* calling what the new cursor
location is, which do they do not currently.
2019-12-10 00:56:56 -08:00
|
|
|
end)
|
|
|
|
|
end)
|