TrailBlazer enables you to seemlessly move through important project marks as quickly and efficiently as possible to make your workflow blazingly fast ™.
License: GNU General Public License v3.0
I intend to set up only a couple of mappings, but exclude most of them.
Here's my suggestion:
Currently the mappings option is inclusive. That is: The default mapping is always created unless specifically changed.
It would be nice to have the option to make the mappings non-inclusive. That is: The mapping will not be created, unless it's overtly specified.
So for example:
inclusive_mappings = true, -- the default
mappings = {
nv = {
motions = {
new_trail_mark = ',ba',
track_back = ',bb',
peek_move_next_down = ',bh',
peek_move_previous_up = ',bl',
},
},
},would change the mappings mentioned, and create all the other ones as default.
On the other hand:
inclusive_mappings = false, -- changed
mappings = {
nv = {
motions = {
new_trail_mark = ',ba',
track_back = ',bb',
peek_move_next_down = ',bh',
peek_move_previous_up = ',bl',
},
},
},this would only create the 4 mappings specified, and no others.
And also:
inclusive_mappings = false,
mappings = nil,this would exclude all mappings, which is neat side-effect feature of this option. It can act as a toggle on/off for the mappings.
Disable all mappings and create the desired mappings myself in a different file.
No response
0.8.3
13
Manually load a session
No error
First, thanks for this amazing plugin! It is exactly what I wanted to marks. I am doing some tests to understand how it works, and I did'nt find any command to cycle through, or mode, or setting? Did I missed something?
I would like to cycle through marks, when TrailBlazerPeekMovePreviousUp arrive at the end for example, it loops. It would be usefull or me because I think using few temporary marks to navigate files I edit. So cycle through them will not be confusing and it would let me use a single key binding to cycle.
Another option, of course, would be to have the possibility of displaying a list of the marks and quickly select one. It is even better maybe, even it is only worthy for few marks probably. Anyway, I saw there is a command TrailBlazerToggleTrailMarkList which seems to do that, but for now, it returns me an error. I am gonna try to fix it before asking help on that forum...
PS: by the way, the doc on the main page is a bit verbose and not always clear to my opinion! Personally, I struggle a bit to understand all the trailblazer functionalities.
NVIM v0.9.0-dev-849+g7880eeb2e
Pop!_OS 22.04 LTS
Note: I don't know if this a bug or a feature request.
Setting a mappings options as an empty string ('') but instead yields an error.
Use the following mapping config:
mappings = {
nv = {
motions = {
new_trail_mark = '',
},
},
},Which will yield an error similar to the following:
Failed to run `config` for trailblazer.nvim
vim/keymap.lua:0: Invalid (empty) LHS
# stacktrace:
- vim/keymap.lua:0 _in_ **set**
- /trailblazer.nvim/lua/trailblazer/keymaps.lua:49 _in_ **register_for_buf**
- /trailblazer.nvim/lua/trailblazer/keymaps.lua:22 _in_ **register_api_maps**
- /trailblazer.nvim/lua/trailblazer/init.lua:159 _in_ **setup**
- .config/nvim/init/plugins_portable.lua:1139 _in_ **config**
- lua:40
Disable (do not create) the mapping if specified with an empty string.
Actually, when navigating through marks, it could be hard to figure out how a wished destination is far away.
In the current implementation of global_buf_line_sorted, it is possible to navigate marks by sorting buffer IDs.
This could be an example of a trail mark list for such a mode:
/path/to/project1/file1:10
/path/to/project1/file2:20
/path/to/project2/file1:30
/path/to/project1/file2:40
/path/to/project2/file2:50
But in many cases, it could be needed to switch to a particular location of a known project, and with the global_buf_line_sorted mode jumping can occur multiple times between two projects, before reaching the wished destination.
It would be great to add a mode, for example, global_buf_path_line_sorted, which sorts marks by buffer paths, and then by buffer lines.
Example of trail mark panel for such mode:
/path/to/project1/file1:10
/path/to/project1/file2:20
/path/to/project1/file2:40
/path/to/project2/file1:30
/path/to/project2/file2:50
Why paths? Because projects most of the time are set by paths, a trail mark mode which sorts marks by paths could be more useful than sorting by buffer IDs.
N/A
No response
0.8.4
Macos 13.2
First of all, love the plugin!!!! I've always been frustrated with marks implementation in neovim, and never really been a fan of Harpoon since it doesn't fit my workflow. Having multiple stacks, allows me to separate my marked files in groups which is something I REALLY needed.
So the bug is that if I'm using git signs and I have edits on the same line as the mark, gitsigns will take over and override the mark icon. Is there anyway to set a priority by plugin on this?
I would expect trailblazer to show the mark icon instad of the gitsigns icon, or ideally both!
Today, the plugin doesn't provide a way to get an overview of the marks that a user has set in an editing session. (It also doesn't persist marks across neovim restarts.)
Neovim's tag stack lets you display a list of available tags with :tags:
# TO tag FROM line in file/text
1 1 main 1 harddisk2:text/vim/test
> 2 2 FuncA 58 i = FuncA(10);
3 1 FuncC 357 harddisk2:text/vim/src/amiga.c
This is great for remembering where you can navigate/jump to, particularly when marks are spread across different buffers/files; e.g., when you are learning a code base by navigating through the code, or by opening the definition of functions etc. imported from third-party or system libraries. It would be nice to have a similar list feature in this plugin.
However, I understand that the plugin's main purpose is back-tracking, where marks are quickly placed and then consumed (removed) again. The value of a list feature is likely lower in that context, and more geared towards users that repeatedly use marks to jump back and forth between files and buffers.
A simple list of available marks via a command like :TrailBlazerListMarks. The list should include a snippet of information in which the user can deduce in which file/buffer and/or line a mark is set, ideally with a preview of that line.
The list could also or alternatively be integrated with telescope.nvim or fzf-related plugins like fzf.vim, which cover the functionality to display a list and search/pick entries from the list.
This feature is available in some form in neovim's tag stack and in plugins like harpoon.
See description above, which covers two alternatives.
No response
NVIM v0.9.0-dev-454+g6d7b94ea0
Windows 10 21H2
'TrailBlazerDeleteTrailMarkStack' command clears stack content but not the stack itself.
:TrailBlazerSwitchTrailMarkStack <name_of_stack>.:TrailBlazerDeleteTrailMarkStack.The trailmark stack is completely deleted, not just the content, and after deletion, if the deleted stack was the current stack, the previous/next stack is automatically switched.
Or, the TrailBlazerDeleteTrailMarkStack command could be removed and instead added:
TrailBlazerClearTrailMarkStack: clear the content of the current / specified trailmark stack.TrailBlazerDeleteTrailMarkStack: delete the current / specified trailmark stack, removing it from the list of stacks.It would be nice to add some options/commands to simply clear the content of a stack, or to delete the stack itself removing it from the list of stacks.
I dislike having marks displayed as highlights on top of my code.
Having an option to work only line-wise (rather than the current char-wise behavior) would enable the possibility for unobtrusive marks, such as gutter signs or virtual text. Having this could be easily extended in the future once anticonceal is implemented in neovim, so we can have the best of both worlds.
Can't think of any, besides what's already implemented.
No response
NVIM v0.9.0-dev-454+g6d7b94ea0
Windows 10 21H2
Multiple duplicated entries in the trailmarks quickfix window.
Pre-requisites: a trailmark session file containing at least 2 trailmark stacks, containing each at least one mark.
Steps to reproduce:
TrailBlazerToggleTrailMarkList).The trailmark list (quickfix) for the selected stack will contain multiple duplicated entries, as follow:
trailmark 1
trailmark 2
trailmark 3
trailmark 1
trailmark 2
trailmark 3
...
a repeated list of the trailmarks for the selected stack. In my setup, the original list is repeated 24 times in the quickfix window.
Example:
Under this condition, the quickfix window with the trailmark list is cleaned of duplicates when switching to the next or previous trailmark of the current stack.
It is important to note that the duplicates seem to randomly appear in the quickfix window and that the number of duplicates for my current session file is equal to k * 24, where k is the number of trailmarks of the selected stack. So, if a stack has 3 trailmarks, then I see multiple duplicated groups of marks, for a total of 72.
No duplicated trailmarks should be reported in the trailmarks list quickfix.
v0.8.3
Windows 10 21H2
When the mark quick-fix list is open, marks navigation with the TrailBlazerPeekMovePreviousUp and TrailBlazerPeekMoveNextDown commands is really slow, compared to when the quick-fix mark list is closed.
Neovim session.NOTE: In my test, I used a number of buffers other than 10.
TrailBlazerPeekMovePreviousUp and TrailBlazerPeekMoveNextDown commands.Two tests:
:profile start profile.log
:profile func *
:profile file *TrailBlazerPeekMoveNextDown 9 times so that the cursor is positioned on the last mark.:profile stopMy output:
https://gist.github.com/pidgeon777/d1bea4a7955605a963f5f14fcb88deef
TrailBlazerToggleTrailMarkList.:profile start profile.log
:profile func *
:profile file *TrailBlazerPeekMoveNextDown 9 times so that the cursor is positioned on the last mark.:profile stopMy output:
https://gist.github.com/pidgeon777/67202fa42d33a9d9361d2feb076477a2
Timings of Test A:
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
5 0.113866 0.112961 <SNR>1_LoadFTPlugin()
5 0.062757 <SNR>11_SynSet()
5 0.030490 <SNR>2_LoadIndent()
32 0.018744 0.018509 <SNR>61_display_annotation()
47 0.018551 0.010289 <SNR>60_SetupAutoCommands()
71 0.008575 0.007703 <SNR>16_Highlight_Matching_Pair()
42 0.005942 0.003510 <SNR>60_HighlightEOLWhitespace()
86 0.002365 <SNR>60_ClearHighlighting()
89 0.002176 <SNR>60_ShouldHighlight()
75 0.000915 <SNR>16_Remove_Matches()
47 0.000876 <SNR>60_ShouldStripWhitespaceOnSave()
30 0.000236 bm#has_bookmark_at_line()
4 0.000014 <SNR>36_dopopd()
<SNR>111_setup_toc()
<SNR>80_try_cmd()
9()
provider#clipboard#Call()
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
5 0.113866 0.112961 <SNR>1_LoadFTPlugin()
5 0.062757 <SNR>11_SynSet()
5 0.030490 <SNR>2_LoadIndent()
32 0.018744 0.018509 <SNR>61_display_annotation()
47 0.018551 0.010289 <SNR>60_SetupAutoCommands()
71 0.008575 0.007703 <SNR>16_Highlight_Matching_Pair()
42 0.005942 0.003510 <SNR>60_HighlightEOLWhitespace()
86 0.002365 <SNR>60_ClearHighlighting()
89 0.002176 <SNR>60_ShouldHighlight()
75 0.000915 <SNR>16_Remove_Matches()
47 0.000876 <SNR>60_ShouldStripWhitespaceOnSave()
30 0.000236 bm#has_bookmark_at_line()
4 0.000014 <SNR>36_dopopd()
<SNR>80_try_cmd()
9()
provider#clipboard#Call()
<SNR>111_setup_toc()
Timings of Test B:
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
245 7.050313 6.613126 <SNR>1_LoadFTPlugin()
245 3.849984 3.825071 <SNR>11_SynSet()
245 1.672516 <SNR>2_LoadIndent()
485 0.114609 0.075307 <SNR>60_SetupAutoCommands()
485 0.016504 <SNR>60_ClearHighlighting()
525 0.011392 <SNR>60_ShouldHighlight()
485 0.008247 <SNR>60_ShouldStripWhitespaceOnSave()
43 0.004787 0.004323 <SNR>16_Highlight_Matching_Pair()
40 0.004172 0.003159 <SNR>60_HighlightEOLWhitespace()
7 0.002136 0.002108 <SNR>61_display_annotation()
47 0.000514 <SNR>16_Remove_Matches()
5 0.000028 bm#has_bookmark_at_line()
4 0.000017 <SNR>36_dopopd()
1 0.000012 <SNR>111_setup_toc()
<SNR>80_try_cmd()
9()
provider#clipboard#Call()
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
245 7.050313 6.613126 <SNR>1_LoadFTPlugin()
245 3.849984 3.825071 <SNR>11_SynSet()
245 1.672516 <SNR>2_LoadIndent()
485 0.114609 0.075307 <SNR>60_SetupAutoCommands()
485 0.016504 <SNR>60_ClearHighlighting()
525 0.011392 <SNR>60_ShouldHighlight()
485 0.008247 <SNR>60_ShouldStripWhitespaceOnSave()
43 0.004787 0.004323 <SNR>16_Highlight_Matching_Pair()
40 0.004172 0.003159 <SNR>60_HighlightEOLWhitespace()
7 0.002136 0.002108 <SNR>61_display_annotation()
47 0.000514 <SNR>16_Remove_Matches()
5 0.000028 bm#has_bookmark_at_line()
4 0.000017 <SNR>36_dopopd()
1 0.000012 <SNR>111_setup_toc()
9()
provider#clipboard#Call()
<SNR>80_try_cmd()
We can notice how with the mark list quick-fix window open, there are big differences on how many times the following functions are called (i.e. function call ratio between Test A and Test B):
| FUNCTION | Test A | Test B |
|---|---|---|
<SNR>1_LoadFTPlugin() |
5 | 245 |
<SNR>11_SynSet() |
5 | 245 |
<SNR>2_LoadIndent() |
5 | 245 |
<SNR>60_SetupAutoCommands() |
47 | 485 |
<SNR>60_ClearHighlighting() |
86 | 485 |
<SNR>60_ShouldHighlight() |
89 | 525 |
<SNR>60_ShouldStripWhitespaceOnSave() |
47 | 485 |
With Test B, buffer switching was much more slower than with Test A, because some "heavy" functions (e.g. syntax and indent apply) where called many more times.
Interestingly, the following functions were called more times in Test A rather than in Test B, but those where "light":
| FUNCTION | Test A | Test B |
|---|---|---|
<SNR>16_Highlight_Matching_Pair() |
71 | 43 |
<SNR>16_Remove_Matches() |
75 | 47 |
<SNR>61_display_annotation() |
32 | 7 |
bm#has_bookmark_at_line() |
30 | 5 |
With the rest of the functions, there are no big differences between Test A and Test B:
| FUNCTION | Test A | Test B |
|---|---|---|
<SNR>60_HighlightEOLWhitespace() |
42 | 40 |
<SNR>36_dopopd() |
4 | 4 |
<SNR>111_setup_toc() |
1 | 1 |
9() |
1 | 1 |
provider#clipboard#Call() |
1 | 1 |
<SNR>80_try_cmd() |
1 | 1 |
It is important to note that a further Test C was performed, where the raw (not trailblazer.nvim) quick-fix window was populated simply with the buffer list (thus not using the TrailBlazerToggleTrailMarkList command), and buffer switching occurred with the :cnext commands.
The results were very similar to Test A (mark navigation with no quick-fix mark list open) in terms of timings and function calls:
https://gist.github.com/pidgeon777/3e355a42af4b9b928cb4807d2202772c
Timings of Test C:
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
5 0.119966 0.118921 <SNR>1_LoadFTPlugin()
5 0.064960 <SNR>11_SynSet()
5 0.028906 <SNR>2_LoadIndent()
47 0.017287 0.009662 <SNR>60_SetupAutoCommands()
28 0.014631 0.014461 <SNR>61_display_annotation()
59 0.006307 0.005703 <SNR>16_Highlight_Matching_Pair()
42 0.005532 0.003303 <SNR>60_HighlightEOLWhitespace()
86 0.002173 <SNR>60_ClearHighlighting()
89 0.002052 <SNR>60_ShouldHighlight()
47 0.000766 <SNR>60_ShouldStripWhitespaceOnSave()
63 0.000651 <SNR>16_Remove_Matches()
25 0.000170 bm#has_bookmark_at_line()
4 0.000015 <SNR>36_dopopd()
<SNR>80_try_cmd()
9()
provider#clipboard#Call()
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
5 0.119966 0.118921 <SNR>1_LoadFTPlugin()
5 0.064960 <SNR>11_SynSet()
5 0.028906 <SNR>2_LoadIndent()
28 0.014631 0.014461 <SNR>61_display_annotation()
47 0.017287 0.009662 <SNR>60_SetupAutoCommands()
59 0.006307 0.005703 <SNR>16_Highlight_Matching_Pair()
42 0.005532 0.003303 <SNR>60_HighlightEOLWhitespace()
86 0.002173 <SNR>60_ClearHighlighting()
89 0.002052 <SNR>60_ShouldHighlight()
47 0.000766 <SNR>60_ShouldStripWhitespaceOnSave()
63 0.000651 <SNR>16_Remove_Matches()
25 0.000170 bm#has_bookmark_at_line()
4 0.000015 <SNR>36_dopopd()
9()
provider#clipboard#Call()
<SNR>80_try_cmd()
Comparison of Test A and Test C:
| FUNCTION | Test A | Test C |
|---|---|---|
<SNR>1_LoadFTPlugin() |
5 | 5 |
<SNR>11_SynSet() |
5 | 5 |
<SNR>2_LoadIndent() |
5 | 5 |
<SNR>60_SetupAutoCommands() |
47 | 47 |
<SNR>61_display_annotation() |
32 | 28 |
<SNR>16_Highlight_Matching_Pair() |
71 | 59 |
<SNR>60_HighlightEOLWhitespace() |
42 | 42 |
<SNR>60_ClearHighlighting() |
86 | 86 |
<SNR>60_ShouldHighlight() |
89 | 89 |
<SNR>60_ShouldStripWhitespaceOnSave() |
47 | 47 |
<SNR>16_Remove_Matches() |
75 | 63 |
We can notice how results are very similar between Test A and Test C.
This lead me to the conclusion that the extreme slowness of Test B (mark navigation with mark list panel open) doesn't come from the fact that the quick-fix window used to display the list of marks is open itself (otherwise we would have had slowness even for Test A), but rather from the fact that the trailblazer.nvim plugin seems to always execute some heavy commands when the mark quick-fix list is open and a mark is jumped to.
As if the plugin didn't take into account the fact that a mark can reside in the same buffer as the current one, and that therefore it is not needed to do certain buffer operations again, like applying syntax, and so on (is happening, for example, a big number of times with the 1_LoadFTPlugin() or 11_SynSet() functions in Test B, and which cause the slowness).
Question is: given that buffer switching is very smooth with the raw quick-fix open and the :cnext command, what does cause the mark navigation slowness with the trailblazer.vim quick-fix mark list open, and why this slowness doesn't occur when the list is closed?
See the above considerations.
I would like to have a visual indication which trail mark stacks are available and which one is selected.
Something like this in the first row of the qf list perhaps:
--
No response
Edit: I know that there is this quickfix title:
but it also does not show the available stacks.
0.9.0
Macos 13.3.1
When using a vertical split screen and moving around them while adding trail marks, If I try to use the TrailBlazerPeekMovePreviousUp TrailBlazerPeekMoveNextDown commands, it won't respect the current active window but will skip to an inactive window to skip to the corresponding TrailMark.
TrailBlazerPeekMovePreviousUp TrailBlazerPeekMoveNextDownTrailBlazerPeekMovePreviousUp TrailBlazerPeekMoveNextDownCurrently sessions seem to be connected to the folder. I want sessions to be only relevant for single files.
If I load a session it should only load the session for the currently open files. I.e. if I edit my .zshrc and have a session there and then edit another file in my home directory I dont want the .zshrc session to interfere.
Sessions should be on a buffer level.
--
No response
When navigating between marks, if the marks list is open, the row associated with the currently selected mark is not automatically highlighted.
It would be great if, during marks navigation, the corresponding row in the quick fix panel is automatically highlighted/focused.
N/A.
No response
v0.8.3
Windows 10 21H2
Buffers in Neovim running in Windows have a drive letter which can be in uppercase or lowercase.
When adding a mark in a buffer, and if the sort mode is by path, then the mark is added to the mark list in the "wrong" place:
This happens when buffers in Neovim have mixed case drive letters in their paths.
A possible fix would be one of the following:
See above.
Buffers should be sorted by path keeping into account the case of the drive letter.
0.8.3
macOS 13
Prompt appears when removing a trail mark stack which interrupts workflow:
No prompt to press enter.
Actually, there is only one virtual "group" of marks, a single stack.
When a user switches among buffers, he has to do multiple tasks: adding code, analyzing data, and so on, even for different projects.
If a single stack is implemented, this could lead to some confusion: navigating among multiple marks before finding the wished locations, might be confusing and distracting.
My proposal is to implement more stacks: all of the common commands would remain the same, but it would be possible to specify the stack group where the command should apply.
Example:
<A-1> add mark to stack group 1
<A-2> add mark to stack group 2
<C-1> navigate to next mark of group 1
<S-1> navigate to previous mark of group 1
<C-2> navigate to next mark of group 2
...
Or:
<A-1> Select stack group 1
<A-2> Select stack group 2
...
<A-Right> navigate to next mark of current stack group
<A-Left> navigate to previous mark of current stack group
Or:
<A-m> Open a menu to select the stack group
<A-Right> navigate to next mark of current stack group
<A-Left> navigate to previous mark of current stack group
Stack groups could be associated to:
and so on. It would improve mark navigation a lot, in my opinion.
N/A
No response
NVIM v0.8.3
macOS 13.1
Trail marks are not deleted after removing a marked word.
Trailmarks are deleted when word is deleted
0.9.0-dev-454+g6d7b94ea0
Windows 10 x64 Pro
trailblazer.nvim plugin crashes after deleting a buffer containing marks and subsequently executing one of those commands:
TrailBlazerPeekMoveNextDownTrailBlazerPeekMoveNextUpTrailBlazerNewTrailMark
A.A.B.B.A.TrailBlazer commands:TrailBlazerPeekMoveNextDownTrailBlazerPeekMoveNextUpTrailBlazerNewTrailMarkThis leads to Neovim plugin error messages.
In my opinion, when a buffer gets "killed", all marks associated with that buffer should be removed from the marks list, for each mark group.
Or, before switching to a mark, it should be at least checked if the next/previous mark to be switched, still exists:
I want to be able to navigate between trails that I set freely. For instance, if you edit code in 4 locations, then you want to be able to go between those 4 locations unlimited number of times.
The order of navigation could be one of the folllowing (or both):
When you reach the end, either allow one to go back to the beginning trail or it should halt (perhaps different key mappings for this, since the functionality depends on the context).
I tried accomplishing said task using the:
peek_move_next_down = '<A-J>',
peek_move_previous_up = '<A-K>',
mappings, but it doesn't seem to work after I reach the end of the trail. The trails are still there, but I cannot go back and forth.
No response
NVIM v0.10.0-dev-4698+g622ae2f53-Homebrew
MacOS
The marker symbols not showing if statuscol.nvim installed.
create init.lua in /tmp with following content and run it with nvim -u init.lua
vim.g.mapleader = ' '
local root = vim.fn.fnamemodify('./.repro', ':p')
-- set stdpaths to use .repro
for _, name in ipairs({ 'config', 'data', 'state', 'cache' }) do
vim.env[('XDG_%s_HOME'):format(name:upper())] = root .. '/' .. name
end
-- bootstrap lazy
local lazypath = root .. '/plugins/lazy.nvim'
if not vim.loop.fs_stat(lazypath) then
vim.fn.system({
'git',
'clone',
'--filter=blob:none',
'--single-branch',
'https://github.com/folke/lazy.nvim.git',
lazypath,
})
end
vim.opt.runtimepath:prepend(lazypath)
-- install plugins
local plugins = {
{ 'nvim-lua/plenary.nvim' },
{ 'stevearc/dressing.nvim', opts = {} },
{
'mcchrish/zenbones.nvim',
dependencies = {
'rktjmp/lush.nvim',
},
config = false,
init = function()
vim.g.neobones = {
solid_float_border = false,
colorize_diagnostic_underline_text = true,
transparent_background = false,
-- light
-- darken_comments = 30,
lightness = 'dim',
darken_cursor_line = 10,
--- dark
lighten_cursor_line = 15,
-- lighten_comments = 30,
lighten_non_text = 22,
}
end,
},
-- add any other pugins here
{
"LeonHeidelbach/trailblazer.nvim",
config = function()
require("trailblazer").setup({
lang = "en",
auto_save_trailblazer_state_on_exit = false,
auto_load_trailblazer_state_on_enter = false, -- your custom config goes here
mappings = { -- rename this to "force_mappings" to completely override default mappings and not merge with them
nv = { -- Mode union: normal & visual mode. Can be extended by adding i, x, ...
motions = {
new_trail_mark = '<A-l>',
track_back = '<A-b>',
peek_move_next_down = '<A-J>',
peek_move_previous_up = '<A-K>',
move_to_nearest = '<A-n>',
toggle_trail_mark_list = '<A-m>',
},
actions = {
delete_all_trail_marks = '<A-L>',
paste_at_last_trail_mark = '<A-p>',
paste_at_all_trail_marks = '<A-P>',
set_trail_mark_select_mode = '<A-t>',
switch_to_next_trail_mark_stack = '<A-.>',
switch_to_previous_trail_mark_stack = '<A-,>',
set_trail_mark_stack_sort_mode = '<A-s>',
},
},
}
})
end,
},
{
'luukvbaal/statuscol.nvim',
config = function()
local statuscol = require('statuscol')
local builtin = require('statuscol.builtin')
statuscol.setup({
separator = '│',
relculright = true,
setopt = true,
segments = {
{
sign = { name = { '.*' }, maxwidth = 2, colwidth = 1, auto = true },
},
{ text = { builtin.lnumfunc, ' ' }, click = 'v:lua.ScLa' },
{ text = { builtin.foldfunc, ' ' }, click = 'v:lua.ScFa' },
-- {
-- sign = { name = { 'GitSigns' }, maxwidth = 1, colwidth = 1, auto = true },
-- click = 'v:lua.ScSa',
-- },
{
sign = { name = { 'Diagnostic' }, maxwidth = 1, auto = false },
click = 'v:lua.ScSa',
},
},
})
end,
}
}
require('lazy').setup({
spec = plugins,
root = root .. '/plugins',
defaults = {
lazy = false,
},
state = root .. '/lazy/state.json',
performance = {
cache = {
enabled = false,
}
}
})
-- add anything else here
vim.opt.termguicolors = true
pcall(vim.cmd, [[colorscheme neobones]])Symbols should be work.
0.8.3
Void Linux
When using most colorschemes no colors are present. The ones that do have colors lose them upon switching the colorscheme (even to itself).
Tested with clean neovim config too. With or without custom trailblazer configuration makes no difference. You can change the colors and all, trailblazer works and configuring it works fine, but...
:colorshceme fooColors should be present.
v0.8.3
Windows 10 x64 Pro
Executing the TrailBlazerToggleTrailMarkList command three times leads to a crash:
E5108: Error executing lua Vim(lua):E5108: Error executing lua Vim:E952: Autocommand caused recursive behavior
stack traceback:
[C]: in function 'setloclist'
...ortable\Neovim\share\nvim\runtime/lua\vim\diagnostic.lua:494: in function 'set_list'
...ortable\Neovim\share\nvim\runtime/lua\vim\diagnostic.lua:1462: in function 'setloclist'
...pack\packer\start\diaglist.nvim/lua\diaglist\loclist.lua:24: in function 'diagnostics_hook'
...te\pack\packer\start\diaglist.nvim/lua\diaglist\init.lua:63: in function 'diagnostics_hook'
[string ":lua"]:1: in main chunk
[C]: in function 'setqflist'
...r\start\trailblazer.nvim/lua\trailblazer\trails\list.lua:201: in function 'populate_quickfix_list_with_trail_marks'
...r\start\trailblazer.nvim/lua\trailblazer\trails\list.lua:141: in function 'open_quick_fix_list'
...r\start\trailblazer.nvim/lua\trailblazer\trails\list.lua:131: in function 'toggle_quick_fix_list'
...r\start\trailblazer.nvim/lua\trailblazer\trails\list.lua:68: in function 'toggle_trail_mark_list'
...k\packer\start\trailblazer.nvim/lua\trailblazer\init.lua:307: in function 'toggle_trail_mark_list'
[string ":lua"]:1: in main chunk
stack traceback:
[C]: in function 'setqflist'
...r\start\trailblazer.nvim/lua\trailblazer\trails\list.lua:201: in function 'populate_quickfix_list_with_trail_marks'
...r\start\trailblazer.nvim/lua\trailblazer\trails\list.lua:141: in function 'open_quick_fix_list'
...r\start\trailblazer.nvim/lua\trailblazer\trails\list.lua:131: in function 'toggle_quick_fix_list'
...r\start\trailblazer.nvim/lua\trailblazer\trails\list.lua:68: in function 'toggle_trail_mark_list'
...k\packer\start\trailblazer.nvim/lua\trailblazer\init.lua:307: in function 'toggle_trail_mark_list'
[string ":lua"]:1: in main chunkNeovim session.TrailBlazerToggleTrailMarkList command three times.Should not crash.
v0.8.3
Windows 10 21H2
When saving the trailblazer session, buffer paths are saved in the .tbsv file with this format:
"fb_lookup": {
"C\\Configurations\\Neovim\\config\\LunarVim\\lua\\lvim\\lsp\\init.lua": 109,
"C\\Work\\Temp\\Neovim\\data\\lunarvim\\site\\pack\\packer\\opt\\vista.vim\\autoload\\vista\\types\\uctags\\c.vim": 115,
"C\\Work\\Temp\\Neovim\\data\\lunarvim\\site\\pack\\packer\\start\\aerial.nvim\\lua\\aerial\\backends\\lsp\\init.lua": 79,
},
The drive unit should be C:. The missing : leads to trailblazer not opening the buffers listed in the session file when loading it.
See above.
The drive unit should be C:.
69
13
trailblazer.nvim/lua/trailblazer/init.lua
Line 339 in c5cfc7e
...
...
Some configuration of trailblazer is specific on taste and to handle those better it would be nice if I could register callback functions which are automatically called on an event with standardized arguments delivered.
E.g. I would like to register a function that is called on stack change. Or a function that is called on sort mode change etc.
Implement possibility to hook events via callback function
--
No response
0.8.3
13
Open a file for which an auto saved session exists
No error
0.8.2 (release)
macOS 13.1
I tried a fresh installation of the plugin, using its default settings. Attempting to create the first mark fails with the error described further below.
-- Using packer
use({
"LeonHeidelbach/trailblazer.nvim",
config = function()
require("trailblazer").setup({
-- your custom config goes here
})
end,
}):PackerInstall.:TrailBlazerNewTrailMark or :TrailBlazerNewTrailMark 1 (note: the default keybind Alt-l didn't work).This triggers the following error:
Error executing Lua callback: ...tart/trailblazer.nvim/lua/trailblazer/trails/actions.lua:48: attempt to perform arithmetic on a nil value
stack traceback:
...tart/trailblazer.nvim/lua/trailblazer/trails/actions.lua:48: in function 'new_trail_mark'
...k/packer/start/trailblazer.nvim/lua/trailblazer/init.lua:146: in function 'new_trail_mark'
...ack/packer/start/trailblazer.nvim/plugin/trailblazer.lua:29: in function <...ack/packer/start/trailblazer.nvim/plugin/trailblazer.lua:29>
:TrailBlazerNewTrailMark should set a new trail mark, without errors.
0.8.2 (release)
macOS 13.1
Setting a mark on a non-ASCII character turns the original, marked character into some kind of escape sequence.
ä or ⇥.Marking the non-ASCII characters below changes the displayed characters from their original form:
-- non-ASCII character: ä
-- non-ASCII character: ⇥
into:
-- non-ASCII character: <c3>
-- non-ASCII character: <e2>
Removing the marks reverts the displayed characters back into their original form.
The original character should stay intact after setting a mark.
v0.8.3
Windows 10 21H2
When adding or removing lines, the position of the marks under those lines is not updated accordingly, only their highlights.
When navigating to the next/previous mark, the mark highlights subsequently get updated to their wrong location, too.
It seems as if when removing/adding lines, the new mark position is computed correctly, but not really applied to the mark list, leading to a revert back to the previous mark locations.
This behaviour generates an error if for example, a mark is at the bottom of the buffer, and one line is removed. Then mark navigation produces an error because the mark is placed in a non-existent region.
txt file.-> New mark highlights are correctly applied.
-> Mark highlights go back to their previous positions.
Recording of the issue:
The mark positions below the added/removed lines should be updated accordingly.
If x lines are added/removed, then all the marks should be shifted below/up x times.
It is important to note that in the previous trailblazer.nvim commits, this issue didn't exist.
NVIM v0.9.0-dev-849+g7880eeb2e
Pop!_OS 22.04 LTS
Using the following config, which disables all signs, only allowing number_line_color_enabled:
trail_options = {
multiple_mark_symbol_counters_enabled = false,
number_line_color_enabled = true,
trail_mark_in_text_highlights_enabled = false,
trail_mark_symbol_line_indicators_enabled = false,
symbol_line_enabled = false,
}Creating a new mark still expands the signs column. Furthermore, popping the mark does not collapse the signs column:
trail_options:trail_options = {
multiple_mark_symbol_counters_enabled = false,
number_line_color_enabled = true,
trail_mark_in_text_highlights_enabled = false,
trail_mark_symbol_line_indicators_enabled = false,
symbol_line_enabled = false,
}Note: The issue does not happen if you also set number_line_color_enabled = false
Signs column only expand if a sign setting is enabled.
Improve usability.
It would be nice to have an option (i.e. trail_mark_list_auto_open) to automatically open the trailmark list (quickfix) when navigating trailmarks.
N/A.
No response
Let's consider a stack with global_fpath_line_sorted mode active, and a buffer with some marks.
This could be the mark list:
1: file1.txt:10
2: file1.txt:20
3: file1.txt:30
4: file1.txt:40
Now I execute the TrailBlazerPeekMoveNextDown command, new situation:
1: file1.txt:10
2: file1.txt:20 <--
3: file1.txt:30
4: file1.txt:40
Again:
1: file1.txt:10
2: file1.txt:20
3: file1.txt:30 <--
4: file1.txt:40
Now I decide to move the cursor at line 15, and I execute the TrailBlazerPeekMoveNextDown or TrailBlazerPeekMoveNextDown command, obtaining:
1: file1.txt:10
2: file1.txt:20
3: file1.txt:30 <--
4: file1.txt:40
With the actual behaviour, the cursor goes back to the previously selected mark (#3), which is at line 30.
The wished behaviour could be, in the case of TrailBlazerPeekMoveNextDown command:
1: file1.txt:10
2: file1.txt:20 <--
3: file1.txt:30
4: file1.txt:40
and, in the case of TrailBlazerPeekMovePreviousUp command:
1: file1.txt:10 <--
2: file1.txt:20
3: file1.txt:30
4: file1.txt:40
Thus, switching to the previous or next mark closest to the actual cursor position, according to the mark navigation command. The trail mark list would be updated accordingly.
Maybe it wouldn't make sense to enable this optional mode for the chron trail mark selection modes, but for the remaining, yes.
N/A
No response
0.8.3
13
The auto load session features appears to be not working at all:
What I do in the video:
Manual loading works, auto-loading does not work. I am not doing any lazy loading.
Session is loaded automatically
0.8.1
macos
As described in steps to reproduce
jump position should be consistent with the shown content of mark list.
0.8.3
13
Stack ordering is exactly inverse after loading a session with multiple stacks:
Adding a new mark to the stack re-sorts the list and the order is correct again.
Correct sorting for all stacks.
0.9.0-dev-454+g6d7b94ea0
Windows 10 x64 Pro
Let's consider a config like this:
default_trail_mark_stacks = {
"Notes",
"Debug",
"Todo",
}When starting Neovim and executing one of the following commands:
TrailBlazerSwitchNextTrailMarkStackTrailBlazerSwitchPreviousTrailMarkStackThen the following error is thrown:
trailblazer.nvim default groups as shown above.TrailBlazerSwitchNextTrailMarkStackTrailBlazerSwitchPreviousTrailMarkStackThe proper behaviour would be to switch to the next/previous trail mark stack with no error.
With the addition of Mark Groups, sometimes when starting a new Neovim session it could happen that some marks have to be repeatedly placed at commonly visited locations, or some groups have to be created containing those common marks.
Doing this repetitive task after each Neovim startup could be tedious and time-consuming.
The problem is: how can we quickly access the placed marks across Neovim sessions, without losing them?
It would be extremely useful to add two commands:
TrailBlazerSave <path/to/file.ext>Export the current session of TrailBlazer to a file.
TrailBlazerLoad --append/replace <path/to/file.ext>Load a "session" of TrailBlazer from a file.
Some notes:
The file could be in JSON format.
When importing a session, two options could be available:
--append
--replace
At first, let consider a TrailBlazer session as follow:
{
"SelectMode" : "buffer_local_chron",
"Stacks" : {
"Name1" : {
"Marks" : {
"MarkPos1",
"MarkPos2"
},
"SortMode" : "alpha_asc"
},
"Name2" : {
"Marks" : {
"MarkPos1"
},
"SortMode" : "chron_dsc"
},
"Name3" : {
"Marks" : {},
"SortMode" : "alpha_asc"
}
}
}and a local file:
{
"SelectMode" : "global_chron_buf_switch_group_line_sorted",
"Stacks" : {
"Name1" : {
"Marks" : {
"MarkPos1",
"MarkPos3",
},
"SortMode" : "chron_asc"
},
"Name4" : {
"Marks" : {
"MarkPos1"
},
"SortMode" : "chron_dsc"
}
}
}With the --replace option, the local file would simply replace the currently active TrailBlazer "session".
With the --append option, the local file could be merged with the currently active session, and the resulting TrailBlazer status would be something as follow:
{
"SelectMode" : "global_chron_buf_switch_group_line_sorted", -- Replaces the current session select mode
"Stacks" : {
"Name1" : {
"Marks" : {
"MarkPos1",
"MarkPos2",
"MarkPos3" -- Merged with current marks of "Name1" stack
},
"SortMode" : "chron_asc" -- Replaces the current value for "Name1" stack
},
"Name2" : {
"Marks" : {
"MarkPos1"
},
"SortMode" : "chron_dsc"
},
"Name3" : {
"Marks" : {},
"SortMode" : "alpha_asc"
},
"Name4" : { -- Merged as new mark stack
"Marks" : {
"MarkPos1"
},
"SortMode" : "chron_dsc"
}
}
}N/A
No response
An option to disable the prints on stack change would be nice. Like it is for sort mode select:
verbose_trail_mark_selectverbose_trail_stack_selectin config would be nice.
--
No response
v0.9.0
Debian 11
When installed via lazy I receive the following message. All works fine also with this problem
Probably related to multiple init header in docs file.
Command related in lazy.nvim
https://github.com/folke/lazy.nvim/blob/809d67fcf0f6dd5dabdd1c2b88d451cef4695880/lua/lazy/manage/task/plugin.lua#L51
No error ;)
0.8.2 (release)
macOS 13.1
The docs say:
As soon as multiple mark symbols would be displayed in the same line, only the last one will be shown as well as the total number of mark symbols within that line that.
However, I observed the following behavior:
Maybe I don't understand yet what should be displayed—maybe some of the behavior is done on purpose. But intuitively it's quite confusing to me. I also wouldn't rule out that there could be some interplay with the rest of my neovim config.
Open a file that has no marks yet.
Create the first mark. Note how the count is "2" already.
Create another mark some lines down. Its count is already "2", just like for the very first mark a few lines above.
Create yet another mark, again its count is 2.
Now we navigate from the third mark back to the second mark.
We navigate to the very first mark. All marks have a count of 1 displayed now.
Let's navigate forwards again towards the newest, third mark. (We're on the second mark in the following screenshot.)
We're on the newest, third mark again.
Let's create additional marks on the same line. Here's what's displayed after we placed four additional marks on that line (total count is actually 5).
We navigate back to the previous mark. (The fully white block is the current cursor location.) Note the "2->4*" display in the sign column. As shown in the screenshot, which is my trailblazer configuration, "->" is the mark symbol for the current mark, whereas "*" is used for the newest mark.
We navigate back one more mark. We're on mark 3 in the line now. Now it displays "3↷4*", where "↷" is the symbol for the next mark.
We are now on the second mark on that line.
Now we're on the first mark on that line. The sign column says "2↷3*" here.
In this final screenshot we navigated to an earlier mark on a different line (this was the original second mark from the second screenshot in this comment).
The total number should match the actual number of marks on a given line. Notably, creating the very first mark on a line should not result in "2" being displayed.
.9.4
Mac newest
As the title really, there aren't many more details. I set a trailblazer mark, then save the file with :w and the trailblazer mark is now on the last line of the file instead of where I set it.
Mark stays where it was before save
0.8.3
13
When deleting the only custom stack, e.g. defs, I am not returned to the default stack and it is not available in the stack cycling. Additionally, when creating a new mark it is created in the deleted defs list.
require("trailblazer").switch_trail_mark_stack(name)require("trailblazer").delete_trail_mark_stack()The custom stack is removed and I am returned to the default stack.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.