feat(functions): Mode aware functions #415

hinell · 2023-10-19T23:12:04Z

functions-demo-switched-mode.mov

Summary:

feat(functions): populate mode_mappings
feat(functions): add methods for UI display filtering
feat(functions): allow filtering by functions
feat(functions): display multi-mode functions
docs(functions): describe new mode=field

Note

I request to squash-rebase

How to Test

New funcs = { ... mode = 'n' } field for functions - its type should be either string or table<string>; that's it

Testing for Regressions

I have tested the following:

Triggering keymaps from legendary.nvim in all modes (normal, insert, visual)
Creating keymaps via legendary.nvim, then triggering via the keymap in all modes (normal, insert, visual)
Triggering commands from legendary.nvim in all modes (normal, insert, visual)
Creating commands via legendary.nvim, then running the command manually from the command line
augroup/autocmds created through legendary.nvim work correctly

Fixes mrjones2014#413

mrjones2014 · 2023-10-20T11:04:25Z

doc/table_structures/FUNCTIONS.md

+## Specifying mode
+
+By default, the funciton is shown and run in `*` (all) modes.
+You can use `mode` property to narrow function's scope, so it always run in specified mode:


Suggested change

You can use `mode` property to narrow function's scope, so it always run in specified mode:

You can use `mode` property to narrow function's scope, so it only appears in the specified mode(s):

mrjones2014 · 2023-10-20T11:06:50Z

lua/legendary/data/function.lua

+    mode = {
+      tbl.mode,
+      is_list_of_strings_or_string,
+      'item.mode should contain only strings of modes: n, i, v etc.',


Suggested change

'item.mode should contain only strings of modes: n, i, v etc.',

'item.mode must be a string or list of strings specifying modes: n, i, v etc.',

mrjones2014 · 2023-10-20T11:12:55Z

lua/legendary/data/function.lua

+      local modeCurrent = vim.fn.mode()
+      for _, modeInstance in ipairs(instance.mode_mappings) do
+        if modeCurrent == modeInstance then
+          impl()
+        end
+      end


Suggested change

local modeCurrent = vim.fn.mode()

for _, modeInstance in ipairs(instance.mode_mappings) do

if modeCurrent == modeInstance then

impl()

end

end

local current_mode = vim.fn.mode()

if not vim.tbl_contains(instance.mode_mappings, current_mode) then

return

end

impl()

mrjones2014 · 2023-10-20T11:16:13Z

lua/legendary/data/function.lua

+  -- mode_mapping is going to remain static during legendary runtime
+  -- so we can cache current mapping state
+  instance._mode_switched = vim.tbl_islist(instance.mode_mappings) and not vim.tbl_isempty(instance.mode_mappings)


It doesn't feel necessary to me to cache this.

Suggested change

-- mode_mapping is going to remain static during legendary runtime

-- so we can cache current mapping state

instance._mode_switched = vim.tbl_islist(instance.mode_mappings) and not vim.tbl_isempty(instance.mode_mappings)

It's used for displaying: 29513d1#r1366849251

; It's essential for both performance reason and readability

I really don't think it will have a noticeable impact on performance, and I don't see how it affects readability either, personally.

If you can show some benchmarks proving otherwise I'm all ears.

@mrjones2014 It's cheap to check once and leave, then checking whether the list is empty all the time when the list doesn't change. This is obvious.

It’s an extremely inexpensive check. It doesn’t need to be cached.

mrjones2014 · 2023-10-20T11:18:27Z

lua/legendary/data/function.lua

+--- Intended to be used by UI filters
+function Function:modeSwitched()
+  return self._mode_switched
+end
+


Based on the diff it looks like this function isn't needed either.

Suggested change

--- Intended to be used by UI filters

function Function:modeSwitched()

return self._mode_switched

end

It's used for displaying: 29513d1#r1366849251

Yeah, you don't have to do it that way though -- see the other comments.

Feel free to refactor it after a merge

mrjones2014 · 2023-10-20T11:19:46Z

lua/legendary/data/function.lua

+  if self:modeSwitched() then
+    return self.mode_mappings
+  else
+    -- Just use all modes for UI filtering
+    -- it's half-assed because UI filtering is ugly ¯\_(ツ)_/¯
+    return { 'n', 'V', 'v', 'x', 's', 'o', '' }
+  end


let's keep it consistent with how the mode_mappings API works for other items.

Suggested change

if self:modeSwitched() then

return self.mode_mappings

else

-- Just use all modes for UI filtering

-- it's half-assed because UI filtering is ugly ¯\_(ツ)_/¯

return { 'n', 'V', 'v', 'x', 's', 'o', '�' }

end

if vim.tbl_islist(self.mode_mappings) then

return self.mode_mappings

end

local modes = {}

for mode, mapping in pairs(self.mode_mappings) do

if mapping then

table.insert(modes, mode)

end

end

if #modes == 0 then

return { 'n', 'V', 'v', 'x', 's', 'o', '�' }

end

return modes

This will require a lot of changes in Function's constructor where mode_mappings is built . See my reply below.

let's keep it consistent

Well, mode-map is not consistent across keymaps, commands, autocommands, and functions.
This PR lays a groundwork for further extension; I personally see no reason for complicated mode-map. Again, see my reply below.

Not an intent of this PR; I'm fine if you refactor it further after merging it;

there is a lof of space for improvement in this project

mrjones2014 · 2023-10-20T11:23:23Z

lua/legendary/ui/format.lua

@@ -38,11 +38,15 @@ function M.default_format(item)
      item.description,
    }
  elseif Toolbox.is_function(item) then
+    -- stylua: ignore start


Why is this here?

Stylua makes lines in-between ugly otherwise

I'd rather just have the formatter format it than stray from the style of everything else in the entire codebase.

mrjones2014 · 2023-10-20T11:23:35Z

lua/legendary/ui/format.lua

      '<function>',
      item.description,
    }
+    -- stylua: ignore end


We shouldn't be ignoring formatting unless there's a good reason.

mrjones2014 · 2023-10-20T11:27:24Z

lua/legendary/ui/format.lua

+      item--[[@as keymap ]]:modeSwitched()
+        and table.concat(item--[[@as Keymap]]:modes(), ', ')
+        or Config.icons.fn,


Suggested change

item--[[@as keymap ]]:modeSwitched()

and table.concat(item--[[@as Keymap]]:modes(), ', ')

or Config.icons.fn,

table.concat(item--[[@as Function]]:modes() or { Config.icons.fn }, ', '),

Please, look carefully what you suggest; this introduces a bug; item:modeSwitched() is essential here.

It doesn't introduce a bug if you also tweak the implementation of modes() as I suggested.

mrjones2014 · 2023-10-20T11:28:57Z

lua/legendary/data/function.lua

 ---@class Function
 ---@field implementation function
+---@field mode_mappings string[]


We shouldn't have the mode_mappings be a different type for functions than for everything else.

Take a look at how Keymap handles it. The type should be something similar to ModeKeymap, but you'll just need to modify it slightly to take different options (the options for a Function).

Quite a lot for an overnight PR which I made without a prior knowledge of this project, isn't it?

I didn't intend to implement fully keymap-compatible mode-map, cuz:

Nobody is going to drop funcs items into legendary.keymap({ ... })

Even if they do, current modemap type is fully forward compatible with legendary.keymap({ ... });

Zero use cases

No need for complicated ways of mode-map declaration

Ambiguities

you need just slightly

Only to make things more complicated: validation (see below) requires that item's [1]-field is provided with a function, so introduction of keymaps-like node-map will likely break something - you have to figure you what to do with that function; it's subject for further discussion.

I suggest you take care of map enhancement further after merging this PR.

legendary.nvim/lua/legendary/data/function.lua

Lines 15 to 20 in 6ea46c2

function Function:parse(tbl) -- luacheck: no unused

vim.validate({

['1'] = { tbl[1], { 'function' } },

description = { util.get_desc(tbl), { 'string' } },

opts = { tbl.opts, { 'table' }, true },

})

Quite a lot for an overnight PR which I made without a prior knowledge of the project, isn't it?

Not sure what you mean. There's no deadline on the PR.

Regarding your 3 bullets, addressing in-order:

That's not what I said and it's not what my comment is meant to support

See above

The use case is to support the alternate declaration syntax (2nd code block here)

Only to make things more complicated: validation (see below) requires that item's [1]-field is provided with a function, so introduction of keymaps-like node-map will likely break something - you have to figure you what to do with that function; it's subject of further discussion.

It's not really more complicated. You can copy the validator from keymap.lua only for the options, validate that they're Function options instead of Keymap options. Then just update executor.lua to pull the right implementation out of the item based on the mode.

It we're going to introduce mode_mappings for Functions, then they're going to work the same as they do for Keymaps.

(2nd code block here)
then they're going to work the same as they do for Keymaps.

As I said, this PR is about functions, not keymaps; if you want to unify mode-map apis for both, I would suggest you to take care of further mode-map improvement yourself taking the laid groundwork as basis; for me, it's more than enough to have mode = { 'n', 'v', 'x' } per one function; for more - i would just create more items with different mode; cheap and quick

And as I said, I see no reason to introduce that complicated approach, cause there are going to be ambiguities you will have to resolve as project owner

mrjones2014 · 2023-10-20T11:29:45Z

Also, please update the PR title per CONTRIBUTING.md

mrjones2014 · 2023-10-20T15:02:33Z

Since it seems like you're totally unwilling to work with me to address the issues in the PR, I'm just going to close it. Feel free to reopen or open a new PR if you decide you're willing to follow the project guidelines and code reviews from project maintainers.

hinell · 2023-10-20T15:20:47Z

If you want more features - go ahead, I'm fine;

My point is: I suggest the laid ground work for futher improvement, it's obviously beneficial to have half of the job done, then doing it yourself

It's also faster to merge and improve, than bogging down this discussion in very vague, or obviously incorrect suggestions

It's sad that I have to maintain a separate fork of this project; anyway

mrjones2014 · 2023-10-20T15:31:32Z

it's obviously beneficial to have half of the job done

Sure, you're definitely right about that. That doesn't mean I'm going to merge the feature in its current half-baked state.

It's also faster to merge and improve

Yes it's faster, that doesn't mean I'm okay with merging half-baked features that don't align with existing features for other item types.

than bogging down this discussion in very vague, or obviously incorrect suggestions

Please explain to me how you, who by your own admission doesn't have any prior knowledge of the project, would be able to identify that better than the project maintainer, and point me to a suggestion I made that is "obviously incorrect".

It's sad that I have to maintain a separate fork of this project; anyway

I'm more than willing to work with you to get the PR into a mergeable state, however you don't seem willing to accept any of the feedback or address any of the problems with the PR.

If you'd rather maintain your own fork than actually collaborate, then go ahead, but open source collaboration doesn't mean merging incomplete PRs just because you say so.

Maybe you could try being a little less rude next time 🙂

mrjones2014 · 2023-10-20T18:10:30Z

Deleted a bunch of useless vile rudeness comments.

Hinell added 6 commits October 20, 2023 01:53

feat(functions): validate new mode= field

243372e

feat(functions): populate mode_mappings

a2363e3

feat(functions): add methods for UI display filtering

5d3a59f

feat(functions): allow filtering by functions

cf3a2a9

feat(functions): display multi-mode functions

29513d1

docs(functions): describe new mode=field

f0caf2e

Fixes mrjones2014#413

hinell mentioned this pull request Oct 19, 2023

refactor(commands): move util function to toolbox #416

Closed

5 tasks

mrjones2014 requested changes Oct 20, 2023

View reviewed changes

hinell changed the title ~~Mode aware functions~~ feat(functions): Mode aware functions Oct 20, 2023

mrjones2014 closed this Oct 20, 2023

mrjones2014 mentioned this pull request Oct 20, 2023

[Feature]: per-mode implementations for functions (funcs) #413

Open

1 task

Repository owner deleted a comment from hinell Oct 20, 2023

hinell deleted the functions-switched-mode branch October 20, 2023 18:32

alex-courtis mentioned this pull request Nov 28, 2023

refactor(git): common code to a generic git cll nvim-tree/nvim-tree.lua#2551

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(functions): Mode aware functions #415

feat(functions): Mode aware functions #415

hinell commented Oct 19, 2023

mrjones2014 Oct 20, 2023

mrjones2014 Oct 20, 2023

mrjones2014 Oct 20, 2023

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023 •

edited

Loading

mrjones2014 Oct 20, 2023

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023 •

edited

Loading

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023

mrjones2014 Oct 20, 2023

mrjones2014 Oct 20, 2023

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023

mrjones2014 Oct 20, 2023

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023 •

edited

Loading

mrjones2014 Oct 20, 2023

hinell Oct 20, 2023

mrjones2014 commented Oct 20, 2023

mrjones2014 commented Oct 20, 2023

hinell commented Oct 20, 2023

mrjones2014 commented Oct 20, 2023

mrjones2014 commented Oct 20, 2023

	You can use `mode` property to narrow function's scope, so it always run in specified mode:
	You can use `mode` property to narrow function's scope, so it only appears in the specified mode(s):

	'item.mode should contain only strings of modes: n, i, v etc.',
	'item.mode must be a string or list of strings specifying modes: n, i, v etc.',

	-- mode_mapping is going to remain static during legendary runtime
	-- so we can cache current mapping state
	instance._mode_switched = vim.tbl_islist(instance.mode_mappings) and not vim.tbl_isempty(instance.mode_mappings)

-  if self:modeSwitched() then
-    return self.mode_mappings
-  else
-    -- Just use all modes for UI filtering
-    -- it's half-assed because UI filtering is ugly ¯\_(ツ)_/¯
-    return { 'n', 'V', 'v', 'x', 's', 'o', '�' }
-  end
+  if vim.tbl_islist(self.mode_mappings) then
+    return self.mode_mappings
+  end
+  local modes = {}
+  for mode, mapping in pairs(self.mode_mappings) do
+    if mapping then
+      table.insert(modes, mode)
+    end
+  end
+  if #modes == 0 then
+    return { 'n', 'V', 'v', 'x', 's', 'o', '�' }
+  end
+  return modes

	function Function:parse(tbl) -- luacheck: no unused
	vim.validate({
	['1'] = { tbl[1], { 'function' } },
	description = { util.get_desc(tbl), { 'string' } },
	opts = { tbl.opts, { 'table' }, true },
	})

feat(functions): Mode aware functions #415

feat(functions): Mode aware functions #415

Conversation

hinell commented Oct 19, 2023

How to Test

Testing for Regressions

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hinell Oct 20, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hinell Oct 20, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hinell Oct 20, 2023 • edited Loading

Choose a reason for hiding this comment

Ambiguities

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mrjones2014 commented Oct 20, 2023

mrjones2014 commented Oct 20, 2023

hinell commented Oct 20, 2023

mrjones2014 commented Oct 20, 2023

mrjones2014 commented Oct 20, 2023

hinell Oct 20, 2023 •

edited

Loading

hinell Oct 20, 2023 •

edited

Loading

hinell Oct 20, 2023 •

edited

Loading