Tag folding poses a few difficulties. Many elements, e.g.
"blockquote", are always delimited by start and end tags;
end tags for some elements, e.g. "p", can be omitted in
certain contexts; void elements, e.g. "hr", have no end tag.
Although the rules for supporting omissible end tags are
ad-hoc and involved, they apply to elements in scope.
Assuming syntactical wellformedness, an end tag can be
associated with its nearest matching start tag discoverable
in scope and towards the beginning of a file, whereas all
unbalanced tags and inlined tags can be disregarded.
For example:
------------------------------------------------------------
<!DOCTYPE html>
<html lang="en"> <!-- >1 : 1 -->
<body> <!-- >2 : 2 -->
<p>Paragraph #1. <!-- = : 2 -->
<p> <!-- >3 : 3 -->
Paragraph #2. <!-- = : 3 -->
</p> <!-- <3 : 3 -->
<p>Paragraph #3.</p> <!-- = : 2 -->
</body> <!-- <2 : 2 -->
</html> <!-- <1 : 1 -->
------------------------------------------------------------
(HTML comments here, "<!-- ... -->", record two values for
each folded line that are separated by ":", a value obtained
from "&foldexpr" and a value obtained from "foldlevel()".)
Innermost foldedable tags will be flattened. For example:
------------------------------------------------------------
<!DOCTYPE html>
<html lang="en"> <!-- >1 : 1 -->
<body> <!-- >2 : 2 -->
<div class="block"> <!-- >3 : 3 -->
<pre><code> <!-- >4 : 4 -->
[CODE SNIPPET] <!-- = : 4 -->
</code></pre> <!-- <4 : 4 -->
</div> <!-- <3 : 3 -->
</body> <!-- <2 : 2 -->
</html> <!-- <1 : 1 -->
------------------------------------------------------------
No folding will be requested for the "<code>"-"</code>" tag
pair and reflected by "&foldexpr" because such a fold would
have claimed the same lines that the immediate fold of the
"<pre>"-"</pre>" tag already claims.
Run-on folded tags may confuse Vim. When a file such as:
------------------------------------------------------------
<!DOCTYPE html>
<html lang="en"> <!-- >1 : 1 -->
<body> <!-- >2 : 2 -->
<div class="block"> <!-- >3 : 3 -->
<pre> <!-- >4 : 4 -->
<code> <!-- >5 : 5 -->
[CODE SNIPPET #1] <!-- = : 5 -->
</code> <!-- <5 : 5 -->
</pre> <!-- <4 : 4 -->
</div> <!-- <3 : 3 -->
<!-- = : 3 -->
<div class="block"> <!-- >3 : 3 -->
<pre> <!-- >4 : 4 -->
<code> <!-- >5 : 5 -->
[CODE SNIPPET #2] <!-- = : 5 -->
</code> <!-- <5 : 5 -->
</pre> <!-- <4 : 4 -->
</div> <!-- <3 : 3 -->
</body> <!-- <2 : 2 -->
</html> <!-- <1 : 1 -->
------------------------------------------------------------
is reformatted as follows:
------------------------------------------------------------
<!DOCTYPE html>
<html lang="en"> <!-- >1 : 1 -->
<body> <!-- >2 : 2 -->
<div class="block"> <!-- >3 : 3 -->
<pre> <!-- >4 : 4 -->
<code> <!-- >5 : 5 -->
[CODE SNIPPET #1] <!-- = : 5 -->
</code> <!-- <5 : 5 -->
</pre> <!-- <4 : 4 -->
</div><div class="block"><pre><code> <!-- <3 : 3 -->
[CODE SNIPPET #2] <!-- = : 2 ? -->
</code> <!-- <5 : 2 ? -->
</pre> <!-- <4 : 2 ? -->
</div> <!-- <3 : 2 ? -->
</body> <!-- <2 : 2 -->
</html> <!-- <1 : 1 -->
------------------------------------------------------------
"&foldexpr" values will not be used as is for the lines
between (and including) "[CODE SNIPPET #2]" and "</div>".
(Cf. v9.1.0002.)
Having syntax highlighting in effect, tag folding using the
"fold-expr" method can be enabled with:
------------------------------------------------------------
let g:html_expr_folding = 1
------------------------------------------------------------
By default, tag folding will be redone from scratch after
each occurrence of a TextChanged or an InsertLeave event.
Such frequency may not be desired, especially for large
files, and this recomputation can be disabled with:
------------------------------------------------------------
let g:html_expr_folding_without_recomputation = 1
doautocmd FileType
------------------------------------------------------------
To force another recomputation, do:
------------------------------------------------------------
unlet! b:foldsmap
normal zx
------------------------------------------------------------
References:
https://web.archive.org/web/20250328105626/https://html.spec.whatwg.org/multipage/syntax.html#optional-tagshttps://en.wikipedia.org/wiki/Dangling_elsecloses: #17141
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: no whitespace padding in commentstring option in ftplugins
Solution: Change default to include whitespace padding, update
existing filetype plugins with the new default value
(Riley Bruins)
closes: #14843
Signed-off-by: Riley Bruins <ribru17@hotmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: The "*.*" browsefilter pattern only matches all files on
Windows (Daryl Lee)
Solution: Use "*" to filter on all platforms but keep "*.*" as the label
text on Windows. (Fixes#12685, Doug Kearns)
The *.* browsefilter pattern used to match "All Files" on Windows is a
legacy of the DOS 8.3 filename wildcard matching algorithm. For reasons
of backward compatibility this still works on Windows to match all
files, even those without an extension.
However, this pattern only matches filenames containing a dot on other
platforms. This often makes files without an extension difficult to
access from the file dialog, e.g., "Makefile"
On Windows it is still standard practice to use "*.*" for the filter
label so ftplugins should use "All Files (*.*)" on Windows and "All
Files (*)" on other platforms. This matches Vim's default browsefilter
values.
This commit also normalises the browsefilter conditional test to check
for the Win32 and GTK GUI features and an unset b:browsefilter.
closes: #12759
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
