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

Error window height depends on every error length #3662

Closed
wants to merge 1 commit into from

Conversation

juanpabloaj
Copy link

When I have got long length errors it has been difficult to read in a window with not enough width.

I have tried to set wrap over quickfix but it didn't work because the height of the window depends on the number of errors and it does not depend on the error length.

Until now it has been the best option for me.

any other option to read long-length errors inside of the window with not enough width?

Thanks

@bhcleek
Copy link
Collaborator

bhcleek commented Apr 28, 2024

Have you tried wrapping lines in the quickfix window? e.g.

augroup quickfix
    autocmd!
    autocmd FileType qf setlocal wrap
augroup END

@bhcleek
Copy link
Collaborator

bhcleek commented Apr 28, 2024

https://vi.stackexchange.com/questions/2843/how-to-automatically-set-wrapping-for-quickfix-window has information about the method I asked about as well as a cleaner alternative.

@juanpabloaj
Copy link
Author

@bhcleek , thanks for your answer.

yes, I have tried

autocmd FileType qf setlocal wrap

although it doesn't solve the issue, because if you have a long error text and the size of quickfix is 1 (copen 1 or lopen 1), it doesn't matter the wrap over the long text because you are going to have only size 1 to see the text, the rest of the text keeps hidden.

don't you have that issue with long error texts?

@juanpabloaj
Copy link
Author

juanpabloaj commented Apr 29, 2024

For example, If I have a terminal with 100 columns with this code

package main

import "fmt"

type LongestNameInterface interface {
	Longest() int
}

type TheLongestImplementationEver struct {
}

var _ LongestNameInterface = TheLongestImplementationEver{}

func main() {
	fmt.Println("vim-go")
}

I can see this error text

Cursor_y_nvim

But If I use the changes of this pull request I can see this text

Cursor_y_nvim

In both cases, I am using wrap over quickfix filetype.

In your case, how do you see the error message?

Maybe there is something wrong with my configuration, but I haven't found another way to read the long error messages.

At the same time, I am aware if this is the way to read long text messages, probably I going to need to apply this change over other calls of the function go#list#Window. (although the error case is the most annoying case for me)

Any advice is welcome. 

@bhcleek
Copy link
Collaborator

bhcleek commented Apr 29, 2024

In your case, how do you see the error message?

Mostly, I don't need to see the entire error message; the beginning of it and jumping to the line where it's relevant is normally all I need to spot the problem. In the rare case where there's a long error message that I need to read, I scroll right to read it.

Maybe there is something wrong with my configuration, but I haven't found another way to read the long error messages.

I don't think there's anything wrong with your configuration. However, this patch is probably insufficient to robustly handle the situation it intends to accommodate.

The effect of breakindent, showbreak, and linebreak are a few the options that one would need to consider. strdisplaywidth can certainly help, but even it alone isn't enough. One would also need to consider numberwidth and whether either relativenumber or number are set.

probably I going to need to apply this change over other calls of the function go#list#Window.

If we were to go ahead with this intent of this submission, it would probably need to be handled in one of the core list.vim functions; most likely go#list#Window.

@juanpabloaj
Copy link
Author

ok, I will close this pull request.

If in the future, I have a better proposal I will create another pull request.

thanks for the feedback 😊

@juanpabloaj juanpabloaj closed this May 1, 2024
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.

2 participants