Add bufnr to prop_list() and prop_find()#8647
Conversation
Getting properties with prop_list() don't return a buffer number:
:echo prop_list(line('.'))[0]
{'id': 0, 'col': 2, 'end': 1, 'type': 'keyword', 'length': 5, 'start': 1}
Getting this property fails as it's defined for this buffer:
:echo prop_type_get('keyword')
{}
So I need to do:
:echo prop_type_get('keyword', #{bufnr: bufnr('')})
{'highlight': 'Keyword', 'end_incl': 0, 'start_incl': 0, 'priority': 0, 'bufnr': 1, 'combine': 1}
But it's not clear from the prop_list() return value that this is the
case: I need to try both.
The same issue exists with prop_find():
:echo prop_find(#{type: 'keyword'})
{'lnum': 10, 'id': 0, 'col': 2, 'end': 1, 'type': 'keyword', 'length': 5, 'start': 1}
This fixes the issue by adding the type_bufnr to the return value of
both functions. I used type_bufnr because I thought that was a lot
clearer than just bufnr, as "bufnr" can refer to either the bufnr of the
property or of the property type (adding the bufnr of the property
itself in the return value doesn't make much sense, but it's easy to get
the two mixed up).
There is still a bit of an issue with this as this will fail:
# E158: Invalid buffer name: 0
var props = prop_list(line('.'))
echo props->mapnew((_, v) => prop_type_get(v.type, {bufnr: v.type_bufnr}))
You need to do:
echo props->mapnew((_, v) => prop_type_get(v.type, (v.type_bufnr ? {bufnr: v.type_bufnr} : {})))
Not sure what the best fix for that would be; on one hand you *want* to
get an error if you pass an invalid bufnr, but on the other hand being
able to get the prop types from the prop_list() output without a lot of
if/else checks. Maybe just leaving it as-is is fine.
Codecov Report
@@ Coverage Diff @@
## master #8647 +/- ##
==========================================
- Coverage 90.08% 90.02% -0.06%
==========================================
Files 150 146 -4
Lines 169497 169176 -321
==========================================
- Hits 152686 152302 -384
- Misses 16811 16874 +63
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Actually, this would not work all the time, because we can't use a number as a boolean. So, So, we need: As for the issue, I'm not sure to have fully understood, but couldn't we make |
|
Yeah, that example is slightly off and only works for bufnr=1; I discovered that later as well when I used it, just didn't update this.
Yeah, could do that; problem is that if you accidentally pass |
|
A similar issue exists with
|
|
> couldn't we make prop_type_get() handle 0 specially? That is,
> {bufnr: 0} would be the same as {}. We would still get an error for
> other invalid buffer numbers, like {bufnr: -1}.
Yeah, could do that; problem is that if you accidentally pass `0` you
won't get an error. A case could be made for both behaviours; I
figured I'd just put it here and see what folks think.
We do use zero for "no buffer number" in a few other places, and in this
case it's a nice solution that avoids the check for zero (which you
already had a type error in, also indicating it's not obvious).
Also, I would not know why you would accidentally have a zero buffer
number.
…--
hundred-and-one symptoms of being an internet addict:
248. You sign your letters with your e-mail address instead of your name.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Was mostly thinking about erroneous user input, logic errors, stuff like that. At any rate, I changed it now. |
Problem: prop_list() and prop_find() do not indicate the buffer for the
used type.
Solution: Add "type_bufnr" to the results. (closes vim#8647)
Getting properties with prop_list() don't return a buffer number:
Getting this property fails as it's defined for this buffer:
So I need to do:
But it's not clear from the prop_list() return value that this is the
case: I need to try both.
The same issue exists with prop_find():
This fixes the issue by adding the type_bufnr to the return value of
both functions. I used type_bufnr because I thought that was a lot
clearer than just bufnr, as "bufnr" can refer to either the bufnr of the
property or of the property type (adding the bufnr of the property
itself in the return value doesn't make much sense, but it's easy to get
the two mixed up).
There is still a bit of an issue with this as this will fail:
You need to do:
Not sure what the best fix for that would be; on one hand you want to
get an error if you pass an invalid bufnr, but on the other hand being
able to get the prop types from the prop_list() output without a lot of
if/else checks. Maybe just leaving it as-is is fine.