Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat!: Pattern/function-defined modifications. #113

Merged
merged 64 commits into from
Aug 5, 2022
Merged

Conversation

kylechui
Copy link
Owner

No description provided.

["["] = { "[ ", " ]" },
["]"] = { "[", "]" },
["i"] = function()
["("] = {
Copy link
Contributor

@smjonas smjonas Jul 28, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will it be possible to simply set ( (or maybe the add key) to a table of characters here? While that's basically just syntactic sugar, I think that makes the API look a bit nicer for simple cases like this.

Copy link
Owner Author

@kylechui kylechui Jul 28, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default configuration has to "look complicated" (unless I translate the default on every run, which seems non-ideal), since it uses the internal representation that every function in the program assumes exists. That being said, user configuration will be simpler, as I will write a "translation" function that will convert user-provided configuration into the internal form, and then merge to provide the proper feature set. I think I plan on the add key being a table of characters, as it would provide a better "mix-and-match" for syntactic sugar between add/delete/change functions instead of tying everything together into an "all or nothing".

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initial work has been done; if the surrounding pair is "static" then you may provide a pair instead of a function. Furthermore, strings will be auto-converted to tables with one string (i.e. multi-line form). For example, I have this in my ftplugin/lua.lua for printing (via yssp):

["p"] = {
    add = { "vim.pretty_print(", ")" },
},

if not (opts and opts.delimiters) then
return opts
end
local invalid = opts.delimiters.invalid_key_behavior or M.default_opts.delimiters.invalid_key_behavior
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you maybe add another deprecation warning for invalid_key_behavior? (there was an error for me because I still had it set to a function). Something like this:

if type(invalid) == "function" then
    local invalid_key_warning = {
        "The old way of configuring `invalid_key_behavior` has been deprecated;",
        "see :h nvim-surround.config.delimiters for details.",
    }
    vim.notify_once(table.concat(invalid_key_warning, "\n"), vim.log.levels.WARN)
end


There is a special key in the `delimiters` table, `invalid_key_behavior`, that
defines how |nvim-surround| behaves when a given key in the delimiter table is
omitted. It takes the same form as all other delimiter tables. The default
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I think a better default is to simply delete / change the character specified. At least that's what I would expect as a user coming from other surround plugins. Curious what other users think here (cc @andrewferrier, @jonatan-branting, @akinsho).

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason I was under the impression that vim-surround NOOP'd for everything; I've personally been using a setup that does just that. I'll probably change the default behavior for this then.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed by 502a430.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tested my claim with vim-sandwich and vim-surround and I must say I wasn't completely correct, sorry! vim-sandwich works as I have described but vim-surround doesn't: e.g. for dsx nothing happens but for non-letter characters such as * the characters are deleted. There seem to be special cases though such as:

  • *word*, action: ds* => result: word
*
word
*

action ds* => result: nothing changed

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the current setup is easy enough to understand; I don't really want to bother with adding more special cases to handle everything. I don't think it's that hard to disable the built-in behavior and add your own keys into the delimiter table for *, $, -, etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine, just pointing out the difference to existing plugins because it seemed like you agreed that you want to match their behavior :) I don't think it makes sense to try to match their behavior exactly if it makes things too complicated.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes of course, I always appreciate extra feedback. Also thank you so much for taking the time to review the code! I still haven't gotten around to writing a short blurb that introduces the code structure, so I apologize for that 😄

@smjonas
Copy link
Contributor

smjonas commented Aug 3, 2022

Just noticed I get an error now when I run css / dss on a line:

E5108: Error executing lua ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:100: start is higher than end                                                                                                                    
stack traceback:                                                                                                                                                                                                                        
        [C]: in function 'get_text'                                                                                                                                                                                                     
        ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:100: in function 'target'                                                                                                                                           
        ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:142: in function 'get_nearest_selections'                                                                                                                           
        ...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:270: in function <...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:263>        

I also get an error with dsq:

E5108: Error executing lua ...acker/start/nvim-surround/lua/nvim-surround/patterns.lua:115: attempt to perform arithmetic on local 'first_index' (a nil value)                                                                          
stack traceback:                                                                                                                                                                                                                        
        ...acker/start/nvim-surround/lua/nvim-surround/patterns.lua:115: in function 'get_selections'                                                                                                                                   
        ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:98: in function <...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:81>                                                                                    
        ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:142: in function 'get_nearest_selections'                                                                                                                           
        ...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:147: in function 'delete_surround'                                                                                                                                  
        ...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:257: in function <...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:248>   

@kylechui
Copy link
Owner Author

kylechui commented Aug 3, 2022

Just noticed I get an error now when I run css / dss on a line:

E5108: Error executing lua ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:100: start is higher than end                                                                                                                    
stack traceback:                                                                                                                                                                                                                        
        [C]: in function 'get_text'                                                                                                                                                                                                     
        ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:100: in function 'target'                                                                                                                                           
        ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:142: in function 'get_nearest_selections'                                                                                                                           
        ...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:270: in function <...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:263>        

I also get an error with dsq:

E5108: Error executing lua ...acker/start/nvim-surround/lua/nvim-surround/patterns.lua:115: attempt to perform arithmetic on local 'first_index' (a nil value)                                                                          
stack traceback:                                                                                                                                                                                                                        
        ...acker/start/nvim-surround/lua/nvim-surround/patterns.lua:115: in function 'get_selections'                                                                                                                                   
        ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:98: in function <...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:81>                                                                                    
        ...k/packer/start/nvim-surround/lua/nvim-surround/utils.lua:142: in function 'get_nearest_selections'                                                                                                                           
        ...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:147: in function 'delete_surround'                                                                                                                                  
        ...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:257: in function <...ck/packer/start/nvim-surround/lua/nvim-surround/init.lua:248>   

Do you mind reporting this here, and providing a buffer to re-create it? Also make sure to update to the latest version of the plugin, thanks!

---@return selections @The selections for the left and right delimiters.
M.get_selections = function(offset, str, pattern)
-- Get the surrounding pair, and the start/end indices
local _, _, left_delimiter, first_index, right_delimiter, last_index = str:find(pattern)
Copy link
Contributor

@smjonas smjonas Aug 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks problematic to me: if str is an empty string, first_index and last_index will always be nil so adding to it will fail. There should be a check that str:find actually found something.

Also, I think you should handle the case when pattern only contains one pair of () instead of the expected two (if that's not already done elsewhere).

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point; I should be handling errors here in case of an invalid Lua pattern. With respect to your first point, first_index and last_index can potentially be empty strings instead of nil, but I agree that error-handling should be done to ensure that the program doesn't arbitrarily crash.

As for your second point, there are actually four sets of () required, see :h nvim-surround.config.get_selections(). I think it would make sense here to put a warning about it, rather than NOOP-ing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I agree, a warning definitely makes sense here.

Copy link
Owner Author

@kylechui kylechui Aug 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Introduced this in 12c0338 (but update to the most recent one since I broke tests), if you would like to try it out. I'm going to re-read through the help docs/code to see if I can find any more improper uses of the words surrounds/delimiters

@kylechui kylechui merged commit a06dea1 into main Aug 5, 2022
@kylechui kylechui deleted the pattern-matching branch August 6, 2022 03:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Custom deletions based on patterns/Tree-sitter
3 participants