Support optional return of error if

longthanhtran commented

2025-11-22 00:23:24 -06:00

(Migrated from github.com)

Via recent issue #7 comment, I think it's useful to provide an option via user config to allow the block without return. Please consider to add this feature in coming release. Thanks

Via recent issue #7 [comment](https://github.com/TheNoeTrevino/no-go.nvim/issues/7#issuecomment-3565475200), I think it's useful to provide an option via user config to allow the block without `return`. Please consider to add this feature in coming release. Thanks

👍 2 👀 1

noe.trevino commented

2025-11-22 12:14:06 -06:00

Owner

Just FYI, I will be taking this week off maintaining this plugin due to thanksgiving in the US. I am planning to get to this though!

👍 1

noe.trevino commented

2025-12-06 05:02:09 -06:00

Owner

@longthanhtran
What do you think it should say/do when this happens? It has to be different then when there is a return, since it does have the return for the arrow, or the var name to use. Let me know

@longthanhtran What do you think it should say/do when this happens? It has to be different then when there is a return, since it does have the return for the arrow, or the var name to use. Let me know

longthanhtran commented

2025-12-06 18:02:18 -06:00

(Migrated from github.com)

I think the behaviour should stay the same, as the if err != nil block contains the error handling logic for case like middleware pattern for net/http. The whole idea is to collapse the block when skimming through the file.

If anything more than that, it would be more useful to have additional +n before the (current) inverted arrow (n line in the block just like import block) but this would increase the complexity.

I think the behaviour should stay the same, as the `if err != nil` block contains the error handling logic for case like middleware pattern for net/http. The whole idea is to collapse the block when skimming through the file. If anything more than that, it would be more useful to have additional +n before the (current) inverted arrow (n line in the block just like import block) but this would increase the complexity.

👍 1 👀 1

noe.trevino commented

2026-01-19 00:25:25 -06:00

Owner

@longthanhtran
Sorry for not getting around to this. This has been on my mind for a while. I have the query written out but i still dont understand what exactly you mean. Could you give me something like this:
Original text:

	err := validate.RegisterValidation("role", validations.UserRole)
	if err != nil {
		handleErr(err)
	}

What I want the plugin to collapse this into:

	err := validate.RegisterValidation("role", validations.UserRole)
	if err != nil { handleErr(err) }

With the logic you would like.

What confuses me about your request is that the inverted arrow represents the return. But you dont want the return to be in this query! So, in my strong opinion, there should be no arrow in this change. let me know! Ill try to get to this once you response.

@longthanhtran Sorry for not getting around to this. This has been on my mind for a while. I have the query written out but i still dont understand what exactly you mean. Could you give me something like this: Original text: ``` go err := validate.RegisterValidation("role", validations.UserRole) if err != nil { handleErr(err) } ``` What I want the plugin to collapse this into: ``` go err := validate.RegisterValidation("role", validations.UserRole) if err != nil { handleErr(err) } ``` With the logic you would like. What confuses me about your request is that the inverted arrow represents the return. But you dont want the return to be in this query! So, in my strong opinion, there should be no arrow in this change. let me know! Ill try to get to this once you response.

👍 1

longthanhtran commented

2026-01-19 17:25:28 -06:00

(Migrated from github.com)

Ah, I got your concern now, so in case the if err != nil .. block comes without return then there is no inverted arrow. Yes, this is correct.

Ah, I got your concern now, so in case the `if err != nil ..` block comes without `return` then there is no inverted arrow. Yes, this is correct.

noe.trevino commented

2026-01-19 17:53:02 -06:00

Owner

Cool, what do you think about this:

configurable property to show x amount of lines stacked on top of eachother
configurable property to show x amount of characters (overrides the lines)
So this:
configurable eol_seperator

err := validate.RegisterValidation("role", validations.UserRole)
	if err != nil {
		Logic.this(that)
		handleErr(err)
		Logic.this(that)
		Logic.this(that)
		Logic.this(that)
		Logic.this(that)
	}

will become:

err := validate.RegisterValidation("role", validations.UserRole)
	if err != nil { Logic.this(that); handleErr(err); Logic.thi...	}

What do you think? This is actually more complex that I initially though.

Cool, what do you think about this: - configurable property to show x amount of lines stacked on top of eachother - configurable property to show x amount of _characters_ (overrides the lines) So this: - configurable `eol_seperator` ``` go err := validate.RegisterValidation("role", validations.UserRole) if err != nil { Logic.this(that) handleErr(err) Logic.this(that) Logic.this(that) Logic.this(that) Logic.this(that) } ``` will become: ``` go err := validate.RegisterValidation("role", validations.UserRole) if err != nil { Logic.this(that); handleErr(err); Logic.thi... } ``` What do you think? This is actually more complex that I initially though.

longthanhtran commented

2026-01-19 20:58:33 -06:00

(Migrated from github.com)

I think the block should be collaped as single line (even better with number of line in replacement of the inverted arrow) so the logic will stay the same with just one configuration property without too many case no matter how many lines in the block.

Rows
Columns

Support optional return of error if #19