robcowie / SublimeTODO

**[DEPRECATED]** - See https://github.com/jonathandelgado/SublimeTodoReview - Extract TODO-type comments from open files and project folders
295 stars 54 forks source link

Keybindings to navigate results and jump to file #6

Closed kgrossjo closed 12 years ago

kgrossjo commented 12 years ago

It would be cool if there was a default keymap that allowed easy browsing of the to do list.

For example, n/p could go to the next/previous item. j/k could also do the same, for vi aficionados.

Slash could invoke incremental find or regular find.

Enter could open the current item.

kgrossjo commented 12 years ago

I wish I understood how to use the "command_mode" setting. I think I have to set it to False to make single-key keybindings work with Vintage.

robcowie commented 12 years ago

I've been playing with command_mode this morning; When set to true for a view, key presses are not sent to the buffer; Well, letter keys aren't. It seems keys such as enter are, which is annoying.

So, if a plugin provides key bindings with the context {"setting.command_mode", "operand": true}, it's easy to build single-key commands.

I have result navigation working. n and p step through the results, highlighting the selection. Navigating to the actual file and line however seems difficult. There is nowhere (obvious) to store that info for each result. If only arbitrary data could be stored in a sublime.Region instance.

kgrossjo commented 12 years ago

Interesting. For Dired and Tablist, I set command_mode to false and then bound n/p and j/k, and it didn't work for command_mode being true... But I think the problem only happens when you use Vintage -- which I sometimes do.

For Dired and Tablist, I tried a few things. One idea was to put data into the buffer and then hide that data via the tmLanguage settings. But I couldn't make the data completely. Then I had the idea of using folding to hide the data. But when I did that, the result that I was seeing the "ellipsis icon" that Sublime Text uses to indicate that there is something invisible.

Another idea I had was to programmatically assign syntax to the buffer, and perhaps it works to smuggle arbitrary data in this way. But when I add syntax using View.add_regions, then the visual display is wrong -- foreground color and background color are swapped. But aside from the visual, it might work: You assign a syntax like "comment./foo/bar/baz.c:42", and then you can always retrieve the syntax and then you strip off the "comment." prefix, and there you go.

What I ended up doing was to store an array in the settings. I then added a number to the start of every line and used tmLanguage to assign the syntax "comment" to it, which means that it's displayed in a slightly faded way, which is nice. The number, of course, is the index into the array, and when the user hits Enter, I parse that number from the buffer and then I know which entry from the array to use.

Another idea I had was to key off of the line number, then I wouldn't have to prepend a number to every line. But I felt that was fragile -- if I add a header to the buffer, it can easily grow or shrink by a line and then all the line numbers would be off.

But maybe it works to dynamically compute the line number offset: Programmatically insert the header, then record the current line number in a setting. That would be the line number of the first data row. Then proceed to insert the actual data.

I wonder if Jon would be willing to provide a nice API for plugins like yours and mine...

Kai

On 15 Jan 2012, at 14:14, Rob Cowie wrote:

I've been playing with command_mode this morning; When set to true for a view, key presses are not sent to the buffer; Well, letter keys aren't. It seems keys such as enter are, which is annoying.

So, if a plugin provides key bindings with the context {"setting.command_mode", "operand": true}, it's easy to build single-key commands.

I have result navigation working. n and p step through the results, highlighting the selection. Navigating to the actual file and line however seems difficult. There is nowhere (obvious) to store that info for each result. If only arbitrary data could be stored in a Region() instance.


Reply to this email directly or view it on GitHub: https://github.com/robcowie/SublimeTODO/issues/6#issuecomment-3498814

robcowie commented 12 years ago

Interesting, thanks.

I've had some ideas similar to yours. I was planning to stuff filepath/linenum data into a dict in settings, keyed on either line number of region boundary (each result line is a region). As you said though, it's fragile as region boundaries can be modified by the user.

Instead, I think I'll key the path info on (filename, item number). On select, I can parse the line and pull the full file path. This is still fragile (perhaps myfile.ext occurs in position 1. in both NOTE and TODO sections), but it's likely to be rare. If a user renumbers an entry, then I guess the only thing I can do is show an error message explaining why we can't go to the comment.

Another option is to put the full file path in the line and parse it. I don't like that though as paths can be very long, making the results unreadable.

It would be great if there were a simple data api, on view, region or both. Something like:

view.data('key', value)
view.data('key')

r = Region()
r.data('key', value)

Might be worth a feature request on http://sublimetext.userecho.com/

kgrossjo commented 12 years ago

The view-related API exists: view.settings().set('key', value)

Dired does view.settings().set('dired_entries', entries) where entries is an array of strings (the file/directory names). As I mentioned before, the index into this array is part of each line.

Kai

On 15 Jan 2012, at 16:36, Rob Cowie wrote:

Interesting, thanks.

I've had some ideas similar to yours. I was planning to stuff filepath/linenum data into a dict in settings, keyed on either line number of region boundary (each result line is a region). As you said though, it's fragile as region boundaries can be modified by the user.

Instead, I think I'll key the path info on (filename, item number). On select, I can parse the line and pull the full file path. This is still fragile (perhaps myfile.ext occurs in position 1. in both NOTE and TODO sections), but it's likely to be rare. If a user renumbers an entry, then I guess the only thing I can do is show an error message explaining why we can't go to the comment.

Another option is to put the full file path in the line and parse it. I don't like that though as paths can be very long, making the results unreadable.

It would be great if there were a simple data api, on view, region or both. Something like:

view.data('key', value) view.data('key')

r = Region() r.data('key', value)

Might be worth a feature request on http://sublimetext.userecho.com/


Reply to this email directly or view it on GitHub: https://github.com/robcowie/SublimeTODO/issues/6#issuecomment-3499624