Various clarifications / hopes

[jmcaine]

FIrst, thank you; I'm excited about making flow my main editor. I'm in the process of evaluating, and need some help with several questions:

1. When I've made a mistake in the keybinding json file, I get "error in input handler: error SyntaxError" - it would be nice if a line number could be provided with that. Is it especially hard to grab that, from the JSON parser?
2. It would be great if the buffer references could be maintained in a stack, so that next_tab_stack and previous_tab_stack could be mappable commands. I'd like to map Ctrl+tab to cycle through, in LIFO order.
3. My testing of goto_implementation hasn't indicated that it's working. Is that just WIP? Or am I in the wrong context. I was hoping that it would take me to the file&line in which the cursor'd function (for example) is implemented (even potentially in another file). I'm talking about editing, here, not debugging.
4. open_project seems to open the most recently edited file, but not the whole collection of files that might have been open from that directory. Now, the find_file function works extremely well, so it almost doesn't matter, as it's so quick to find-and-open-files that I'm not sure there'd be a real benefit to having several open at once, as a saved project. But I am interested in whether I've misunderstood the concept of "project"...
5. enable_auto_save seems to result in saving happening every second, causing a flicker in the info bar, where the filename shows, at least when editing ("edited" status goes on and off). Can this be fixed?

Thanks again. I look forward to this journey.

[jmcaine]

I think I found the answer to number 4, actually, from your post two days ago, where you said:

There is a project state system, yes. At the moment it stores the access times of files in the project to restore the order of files in the fuzzy file finder and the current location in each file to restore the cursor position. It could be extended to restore the previously open files.

Yes, to clarify, I was interested in "restoring previously open files", but perhaps your explanation indicates why the file finder is so good - it brings up files of interest to me near the top because of these smarts. I could imagine that being "plenty good 'nuff", honestly. And, truly, if I have a hundred files, using the fuzzy file finder is plenty sufficient for hopping around, especially if I can Ctrl+Tab between the most recent in the stack of accessed opened files, to make the "most recently edited" ones even closer. I'd never Ctrl+tab more than twice, I don't think, with as good as the fuzzy file finder is; typing a few letters of the filename is as fast as anything.

[neurocyte]

You can also hold down ctrl and tap ctrl+e multiple times to quickly jump down the find_file list in most-recently-used order. Releasing ctrl will then select the file that you are on.

Note that this requires good kitty-keyboard-protocol support for the ctrl key press/release keyevents.

[jmcaine]

Great, thanks. For the record, that's the "palette_menu_down" command. (I've remapped quite a lot, so....) Likewise, there's a palette_menu_up, which probably defaults to Ctrl+Shift+e. Good stuff. I've tried it out some, and it's helpful to have this, in addition to the arrows, as long as I map the original (find_file or open_recent) commands to the same, or am careful, anyway, about my palette_menu_down/up keymap assignments in conjunction.

[jmcaine]

And I missed a couple:
6. You've given us delete_to_begin and delete_to_end; is there a plan for delete_line?
7. Do you plan to highlight brace/paren/etc. pairs, visually (that is, when the cursor travels past one, highlighting the other)?
Thank you, again!

[neurocyte]

Do you plan to highlight brace/paren/etc. pairs, visually (that is, when the cursor travels past one, highlighting the other)?

I'm personally not a fan of brace highlighting, so I haven't added it. It should be fairly easy to do though. You are welcome to add a feature request. (if there isn't one already)

[jmcaine]

Great. I might be able to do even better than that and work on implementing a delete_line to submit for approval. It's a good candidate because, as you say, with the ctrl+x (with no selection) as a model, implementation should be quite easy. Indeed, that's what I've been using, too, and, indeed, often want the line on the clipboard, so... perhaps none of us will ever find value in implementing delete_line, after all. Sorry for the distraction.

Re: brace highlighting - I encourage your authorship; this is your baby, and of course it makes sense to do the stuff you're a fan of, and even resist the stuff you're not. I'm still undecided on brace highlighting, but do occasionally like the quick visual feedback. Indeed, from what you say, this would at least have to be configurable/toggle-able. Perhaps I'll make it a request and/or try to tackle it... I'll give it thought first. Thanks for the reply.

[neurocyte]

On a side note, flow has expand_selection which expands the selection up the AST tree. This is a nice general replacement for commands like "goto opening brace" (which flow doesn't have). I run expand_selection until the section of code I am interested in is fully selected, and the use left or right arrow to jump to the beginning or end. This can be used to jump to the beginning of pretty much any code structure.

[neurocyte]

I might be able to do even better than that and work on implementing a delete_line to submit for approval.

PRs are very welcome! Just because I haven't needed/used a function doesn't mean I'm somehow against adding it. I just might not be the one to do it. 😅

[jmcaine]

expand_selection looks great; thank you, I'll try it!

[neurocyte]

1. When I've made a mistake in the keybinding json file, I get "error in input handler: error SyntaxError" - it would be nice if a line number could be provided with that. Is it especially hard to grab that, from the JSON parser?

The zig json parser doesn't provide any diagnostic info. I recommend you install vscode-json-language-server and you should get diagnostics in the editor while editing json files. Alternatively you can filter the file through jq to check that it is well formatted.

Note that I just fixed an issue if flow with the latest vscode-json-language-server, so you should use the latest nightly build or build it from latest master.

[jmcaine]

Perfect, thank you.

[neurocyte]

2. It would be great if the buffer references could be maintained in a stack, so that next_tab_stack and previous_tab_stack could be mappable commands. I'd like to map Ctrl+tab to cycle through, in LIFO order.

I'm not quite sure what you mean by this. Tabs are already stacked in LIFO order and you can cycle through them with ctrl+tab and ctrl+shift+tab. Check that your terminal is not stealing these keybinds, or remap them to something else.

As of last week you can also re-order tabs to your liking with the move_tab_next and 'move_tab_previous` commands and drag them to a new position with the mouse.

[jmcaine]

Interesting; Ctrl+tab / C+S+tab do not cycle in the expected order (that is, Ctrl+tab doesn't always go to the "most-recently-visited... it doesn't even quite go "in visual tab order", according to the lineup of tabs at the top of the editor). My kitty isn't stealing these; I've "fixed" kitty to keep it from stealing. No need to reply yet; I'll try to update and see if my version is old enough to have a bug that is now gone.

[neurocyte]

Ctrl+tab / C+S+tab do not cycle in the expected order (that is, Ctrl+tab doesn't always go to the "most-recently-visited...

We have support for MRU ordering (for the file finder and buffer list), but there is no command to select the previous tab based on that. Should be fairly easy to add, although, now that I think about it it might not be exactly the same thing.

[neurocyte]

goto_implementation should be working. What LSP, terminal and version of flow are you using?

[jmcaine]

:) I don't have an LSP yet, there... will add, and report back if something still doesn't work. Thank you.

[neurocyte]

5. enable_auto_save seems to result in saving happening every second, causing a flicker in the info bar, where the filename shows, at least when editing ("edited" status goes on and off). Can this be fixed?

Define "fixed". Do you want to hide the modified status icon if enable_auto_save is true? I'm not sure everyone would want that, so it might have to be optional.

[jmcaine]

It's just that the "flicker" is "always flickering", which can be a distraction when typing. I agree that "simply" hiding the modified status icon looses useful information. But, I guess when auto-saving is always happening, the "modified" status is not meaningful... or perhaps just should be a different color, indicating "never 'modified' - saving constantly, every keystroke". When I first tried this feature, I just expected that it might save to a "backup buffer" every so often, so that after a crash or kill, upon reload, a preserved modified buffer might be chosen over the saved version of a file. So I was first surprised that it was saving so constantly, and then intrigued by the status indicator constantly blinking with every keystroke.

I have to say thank you again. I'm a bother, but with hope for a great thing, here. I'm very excited about using this editor regularly.

[neurocyte]

You are correct. The indicator is not useful when auto save is enabled and a bit annoying. At very least, it should not jump around. Perhaps it should rather just display the status of the most recent save attempt. Like a green dot for "autosave is enabled and functioning" and a red dot for "enabled, but the last attempt to save this file failed". Suggestions welcome.