-
-
Notifications
You must be signed in to change notification settings - Fork 63
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
Conversation
* TODO: Write translation layer.
* For better accuracy/to avoid edge cases, probably use `it/at`.
["["] = { "[ ", " ]" }, | ||
["]"] = { "[", "]" }, | ||
["i"] = function() | ||
["("] = { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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(", ")" },
},
f407eac
to
686ad38
Compare
6bc0487
to
366e83a
Compare
e73695a
to
9b863e2
Compare
lua/nvim-surround/config.lua
Outdated
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 |
There was a problem hiding this comment.
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
doc/nvim-surround.txt
Outdated
|
||
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 |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed by 502a430.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 😄
Just noticed I get an error now when I run
I also get an error with
|
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! |
lua/nvim-surround/patterns.lua
Outdated
---@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) |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
* Fix a few left-over places where `delimiters` is still used. * Add deprecation warning about using `surrounds` for configuration.
* When querying the user for input, the column gets clamped to the nearest valid column, i.e. #line. This fix grabs the cursor position before clamping occurs, allowing for proper insertion at the end of the line.
No description provided.