Re: [vim/vim] runtime(doc): Normalise formatting of builtin function descriptions (83eb1da)
h_east
@dkearns @chrisbra
It's over 78 columns.
- Move tags to the same line as the function signature
I don't understand the intention behind making the above changes.
I think the priority is to not exceed 78 columns.
Any other line containing a function signature and/or help tag that exceeds column 78:
instanceof({object}, {class}) *instanceof()* *E614* *E616* *E693*
libcall({libname}, {funcname}, {argument}) *libcall()* *E364* *E368*
*matchadd()* *E290* *E798* *E799* *E801* *E957*
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dkearns
It's under 78 columns when rendered, and that seems to be the general principle in a lot of files. I was considering documenting this once I had come to a better understanding about the most common approach.
When I saw you intentionally do the same in os_win32.txt in 6e28211 I assumed we were in silent agreement. :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
h_east
I've been using the following formatting plugin with the following settings for many years. (I installed it to translate Vim help into Japanese.)
https://github.com/vim-jp/autofmt
set formatexpr=autofmt#japanese#formatexpr() g:autofmt_allow_over_tw = 1
Recently, when I set g:autofmt_allow_over_tw = 1 in the above plugin, line breaks only occurred at column 80 and above, and not at column 79.
This caused the changes in the commit 6e28211.
So, I changed the English help to g:autofmt_allow_over_tw = 0, which ensures the same behavior as the original formatting.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
h_east
Personally, I think it's fine if it doesn't exceed 80 columns.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
There is also: https://github.com/vim/vim/blob/1b565eee6df194e2f842475299fd16793c714677/src/testdir/test_codestyle.vim#L154-L162
Perhaps we should enable this test and fix the remaining doc files?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
h_east
Ah, that's code I wrote a while ago! 😮
Shall we enable this and try it out?
However, since I want 80 columns to be OK and anything over 80 to be an error, L157 is lnum = search('\%>81v.*$').
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
That should be fine. But we need to fix a few remaining docs that violate this
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
h_east
Ah, I remember now. Many of the code samples in the documentation are unavoidably longer than 80 columns.
If possible, I think we should exclude code comments (helpExample) from the check.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dkearns
@h-east, do you mean that tw=78 should apply but an exception should apply to lines exceeding this due to concealed text, but only up to 80 characters?
This is starting to sound a bit complicated. The files are set to tw=78; I can't see any reason to not make that a hard limit.
A remaining question based on the current formatting is whether the concealed text lines should wrap at their concealed length or their unconcealed length. They can look a bit silly if doing that latter with half a dozen tags, or links in a line. My impression (I can dig up examples later) is that after the concealed feature was added and utilised in the help syntax file that wrapping was done at the concealed length. Which certainly looks better, unless you have highlighting off...
There are many code examples that exceed tw.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
h_east
@dkearns
I have no intention of changing tw=78, and I think the current behavior of formatting using gqq and {visual}gq is fine.
All I'm saying is that there are any parts of current document that have manual line breaks added using a method other than those described above, and that end up at column 79 or 80, I personally think it's acceptable (although strictly speaking, it would be better to fix it).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.