2html.vim support for dynamic folding
Benjamin Fritz
http://groups.google.com/group/vim_use/browse_thread/thread/8532e7236f113ab7/a88235ef57bd1b5c
I have a prototype of what I think the final product should look like
(see attached) but sticking it into the actual code is proving more
difficult than I originally thought.
I'll work on it some more this week, but if someone wants to comment
on the html/javascript/css that's good. If someone more familiar with
2html.vim wants to code this (or another) solution that's fine too.
Suggestions are also welcome :-)
Basically I'm trying to replicate the fold column in the html, using a
span around each folded area with the class attribute controlling
whether it is folded or not. The class is used by the css to hide or
show the text as appropriate. The javascript changes the class
attribute to indicate when the fold status changes. If the html
initializes the class to show the fold state when 2html.vim was
sourced, then the page will initially load with the folds in the same
state even if no javascript is available.
Problems I am running into include:
* handling the line number
* getting the fold text for folds that aren't currently closed
* handling multiple folds that open on the same line
I think it will be way more trouble than it is worth to do this
without using css, so I plan to just disable the feature if css is not
being used.
Ben Fritz
On Dec 16, 11:23 pm, "Benjamin Fritz" <fritzophre...@gmail.com> wrote:
> A response to this thread:
>
> I have a prototype of what I think the final product should look like
> (see attached)
Opera, Firefox 2, and IE 7. It passes the w3c validator and sticks to
stuff that _should_ work in other browsers, but obviously I can't test
them all. IE6 in particular might give it some trouble.
Tony Mechelynck
Well, I'm on Linux, and AFAICT it works in both SeaMonkey 2.0a3pre
(similar to Firefox 3.1) and in Konqueror 3.5.10. As you say, it ought
to work in the current versions of all web-compliant browsers. (I don't
have a Mac but I'd bet it works on Safari too.)
Best regards,
Tony.
--
"We are upping our standards ... so up yours."
-- Pat Paulsen for President, 1988.
Bram Moolenaar
Benjamin Fritz wrote:
It's a good start.
I think we don't need the foldcolumn in HTML. One can click on the fold
to open it, and on the text to close it again. That's a lot simpler and
removes the not-so-nice-looking fold column.
--
Veni, Vidi, VW -- I came, I saw, I drove around in a little car.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Ben Schmidt
>> (see attached) but sticking it into the actual code is proving more
>> difficult than I originally thought.
Hehe. That doesn't surprise me at all. That's why I was going to put it
on my to do list, and not attempt it for a while. :-)
>> I'll work on it some more this week, but if someone wants to comment
>> on the html/javascript/css that's good.
It's essentially the approach I would have taken, so it looks good to
me!
>> Problems I am running into include:
>> * handling the line number
I'm not sure what you mean by that.
>> * getting the fold text for folds that aren't currently closed
I thought of that. I think you'll have to :set foldlevel=0 at the start
of 2html to deal with this. The real difficulty is if you want to
preserve the current fold state; I wouldn't.
>> * handling multiple folds that open on the same line
And that. I think you have to solve that one by opening the folds one at
a time after you process each, until you've exhausted all the folds at a
given line.
>> I think it will be way more trouble than it is worth to do this
>> without using css, so I plan to just disable the feature if css is not
>> being used.
I agree.
> I think we don't need the foldcolumn in HTML. One can click on the fold
> to open it, and on the text to close it again. That's a lot simpler and
> removes the not-so-nice-looking fold column.
How do you solve the ambiguity problem when there are two folds starting
on the same line without the foldcolumn though (i.e. whether a click
should open the second fold or close the first)? If they can appear
beside each other in the foldcolumn, as in the prototype, that solves
that problem quite nicely. I think.
Are there other edge cases that need to be accounted for?
Ben.
Ben Fritz
On Dec 17, 6:46 am, Ben Schmidt <mail_ben_schm...@yahoo.com.au> wrote:
> >> Problems I am running into include:
> >> * handling the line number
>
> I'm not sure what you mean by that.
text after the line number, then duplicating the line number (with the
fold column) for any folded text. The current logic builds the entire
line left-to-right and (basically, thought not strictly true) doesn't
look back. I need to add logic that (for the opening line in a fold)
uses the line number and the line text multiple times.
>
> >> * getting the fold text for folds that aren't currently closed
>
> I thought of that. I think you'll have to :set foldlevel=0 at the start
> of 2html to deal with this. The real difficulty is if you want to
> preserve the current fold state; I wouldn't.
without a javascript-enable browser is to show the current fold state
(since you won't be able to toggle them). I think it can be done by
detecting if the fold is closed, and using "normal! zc" to close it
temporarily to get the fold text, immediately opening it once the fold
text is retrieved. It's just more logic to add. I think the first
working patch will just do as you suggest.
>
> >> * handling multiple folds that open on the same line
>
> And that. I think you have to solve that one by opening the folds one at
> a time after you process each, until you've exhausted all the folds at a
> given line.
close them back up later.
>
> > I think we don't need the foldcolumn in HTML. One can click on the fold
> > to open it, and on the text to close it again. That's a lot simpler and
> > removes the not-so-nice-looking fold column.
>
> How do you solve the ambiguity problem when there are two folds starting
> on the same line without the foldcolumn though (i.e. whether a click
> should open the second fold or close the first)? If they can appear
> beside each other in the foldcolumn, as in the prototype, that solves
> that problem quite nicely. I think.
>
> Are there other edge cases that need to be accounted for?
>
that URLs are automatically converted to links by the script. I
envision that if we use the text itself as the link to toggle the
fold, we'd just surround every line with an <a> tag. Since you can't
nest <a> elements, we'd need to break the link used to toggle the
fold, ending it just before the URL and beginning it again afterwards.
Completely doable, but it adds additional complexity.
I think the issue of 2 folds starting on the same line is more of a
problem. I'm not actually sure how we could handle that one.
David Fishburn
>
>
>
> On Dec 17, 6:46 am, Ben Schmidt <mail_ben_schm...@yahoo.com.au> wrote:
> The other problem I saw with not using the fold column was the fact
> that URLs are automatically converted to links by the script. I
> envision that if we use the text itself as the link to toggle the
> fold, we'd just surround every line with an <a> tag.
I would just use an onclick event on a SPAN tag (or something) to open
the fold rather than using <a>.
> Since you can't
> nest <a> elements, we'd need to break the link used to toggle the
> fold, ending it just before the URL and beginning it again afterwards.
> Completely doable, but it adds additional complexity.
That would get rid of this issue then, right?
Dave
Bram Moolenaar
Ben Schmidt wrote:
The same way it works for nested structures: first click opens the first
level, second click the second level, etc.
For closing you would have to click on the text of the opened fold, not
a closed fold at the start of that fold.
> Are there other edge cases that need to be accounted for?
--
Dreams are free, but there's a small charge for alterations.
Antony Scriven
2008/12/17 David Fishburn <dfishb...@gmail.com>:
Sounds good to me. You don't need to attach an onclick event
to each span either, you can delegate to a global handler:
<script>
document.body.onclick = function(e){
var target, fold;
e = e || window.event;
target = e.target || e.srcElement;
if(!(target.nodeName === 'SPAN' && 'fold-col' === target.className)){
return;
}
fold = target.parentNode.parentNode;
fold.className = (fold.className === 'fold-closed') ?
'fold-open' : 'fold-closed';
};
</script>
</body>
</html>
The above works with the original html if you replace the
<a>s with <span>s. And, I know this is only a proof of
concept, but adding `cursor: pointer;' to .fold-col helps
too. By the way it looked fine in IE6. --Antony
Markus Heidelberg
> > > I think we don't need the foldcolumn in HTML. One can click on the fold
> > > to open it, and on the text to close it again. That's a lot simpler and
> > > removes the not-so-nice-looking fold column.
> >
> > How do you solve the ambiguity problem when there are two folds starting
> > on the same line without the foldcolumn though (i.e. whether a click
> > should open the second fold or close the first)? If they can appear
> > beside each other in the foldcolumn, as in the prototype, that solves
> > that problem quite nicely. I think.
>
> The same way it works for nested structures: first click opens the first
> level, second click the second level, etc.
>
> For closing you would have to click on the text of the opened fold, not
> a closed fold at the start of that fold.
Imagine the scenario that a fold contains 2 folds and doesn't contain
other unfolded text anymore.
For example, a file with several lines: lines 1-2 are folded on the
second level, lines 3-4 are folded on the second level and lines 1-4 are
folded on the first level.
When fold 1-4 is open it cannot be closed with za (which is equivalent
to a left mouse click) anymore.
To reproduce with Vim: zfjjzfjzfk
displayed with foldcolumn=3:
-- line 1
|| line 2
|- line 2
|| line 4
Without a foldcolumn, there is also no hint, whether some text belongs
to an open fold or not.
Ben Schmidt
>>> to open it, and on the text to close it again. That's a lot simpler and
>>> removes the not-so-nice-looking fold column.
>> How do you solve the ambiguity problem when there are two folds starting
>> on the same line without the foldcolumn though (i.e. whether a click
>> should open the second fold or close the first)? If they can appear
>> beside each other in the foldcolumn, as in the prototype, that solves
>> that problem quite nicely. I think.
>
> The same way it works for nested structures: first click opens the first
> level, second click the second level, etc.
>
> For closing you would have to click on the text of the opened fold, not
> a closed fold at the start of that fold.
What about if there is no such text? I.e. if every line of a fold is
part of a subfold? Then you have the problem of an uncloseable fold with
this interface (unless I misunderstand). I don't know how common the
scenario would be for others, but it's certainly a very common case for
me.
Ben.
Markus Heidelberg
>
> >>> I think we don't need the foldcolumn in HTML. One can click on the fold
> >>> to open it, and on the text to close it again. That's a lot simpler and
> >>> removes the not-so-nice-looking fold column.
> >> How do you solve the ambiguity problem when there are two folds starting
> >> on the same line without the foldcolumn though (i.e. whether a click
> >> should open the second fold or close the first)? If they can appear
> >> beside each other in the foldcolumn, as in the prototype, that solves
> >> that problem quite nicely. I think.
> >
> > The same way it works for nested structures: first click opens the first
> > level, second click the second level, etc.
> >
> > For closing you would have to click on the text of the opened fold, not
> > a closed fold at the start of that fold.
>
> What about if there is no such text? I.e. if every line of a fold is
> part of a subfold? Then you have the problem of an uncloseable fold with
> this interface (unless I misunderstand).
Exactly what I have already written :)
Markus
Tony Mechelynck
[...]
> Without a foldcolumn, there is also no hint, whether some text belongs
> to an open fold or not.
I think that's the decisive argument. Something prettier might be found
though; maybe a squared plus or minus sign &x229E; &x229F; or circled
&x2295; &x2296; (plus for a closed fold that can be opened; minus for an
open fold that can be closed). This would look more similar to what is
used in other software for stuff that can be folded in or out. (I just
typed them into gvim using ^Vu and both pairs look OK to me for that
purpose.) Maybe even indent them according to the fold level, as with
nested subthreads in some mailers.
Best regards,
Tony.
--
I think that all good, right thinking people in this country are sick
and tired of being told that all good, right thinking people in this
country are fed up with being told that all good, right thinking people
in this country are fed up with being sick and tired. I'm certainly
not, and I'm sick and tired of being told that I am.
-- Monty Python
Markus Heidelberg
>
> On 17/12/08 18:27, Markus Heidelberg wrote:
> [...]
> > Without a foldcolumn, there is also no hint, whether some text belongs
> > to an open fold or not.
>
> I think that's the decisive argument. Something prettier might be found
> though; maybe a squared plus or minus sign &x229E; &x229F; or circled
> &x2295; &x2296; (plus for a closed fold that can be opened; minus for an
> open fold that can be closed). This would look more similar to what is
> used in other software for stuff that can be folded in or out.
Given that anything else in the HTML output (also the 'number' option)
pretty much reflects the appearance of Vim's window, maybe the
foldcolumn should also look the same as in Vim?
When typing ^Vu and the codes above in terminal Vim, I always get these
squares, i.e. the characters cannot be displayed, in vim -g it works. Is
this a font issue?
Also, Konqueror displays the squares, but Firefox and Opera get it
right.
Markus
Matt Wozniski
>
> When typing ^Vu and the codes above in terminal Vim, I always get these
> squares, i.e. the characters cannot be displayed, in vim -g it works. Is
> this a font issue?
Yes; your font just must be missing those glyphs.
> Also, Konqueror displays the squares, but Firefox and Opera get it
> right.
Again, just the font being used.
~Matt
Ben Fritz
On Dec 18, 7:01 am, Markus Heidelberg <markus.heidelb...@web.de>
wrote:
> > though; maybe a squared plus or minus sign &x229E; &x229F; or circled
> > &x2295; &x2296; (plus for a closed fold that can be opened; minus for an
> > open fold that can be closed). This would look more similar to what is
> > used in other software for stuff that can be folded in or out.
>
> Given that anything else in the HTML output (also the 'number' option)
> pretty much reflects the appearance of Vim's window, maybe the
> foldcolumn should also look the same as in Vim?
>
code (and potentially to interact with) if the foldcolumn width would
just grow to accommodate the highest fold level. What do people
think...should 'foldcolumn' be used for the width of the fold column,
complete with a duplication of Vim's foldcolumn text, or should it
just grow as needed?
> When typing ^Vu and the codes above in terminal Vim, I always get these
> squares, i.e. the characters cannot be displayed, in vim -g it works. Is
> this a font issue?
> Also, Konqueror displays the squares, but Firefox and Opera get it
> right.
>
being used (beyond the fact that it should be fixed-width, of course).
Tony Mechelynck
> Tony Mechelynck, 18.12.2008:
>> On 17/12/08 18:27, Markus Heidelberg wrote:
>> [...]
>>> Without a foldcolumn, there is also no hint, whether some text belongs
>>> to an open fold or not.
>> I think that's the decisive argument. Something prettier might be found
>> &x2295;&x2296; (plus for a closed fold that can be opened; minus for an
>> open fold that can be closed). This would look more similar to what is
>> used in other software for stuff that can be folded in or out.
>
> Given that anything else in the HTML output (also the 'number' option)
> pretty much reflects the appearance of Vim's window, maybe the
> foldcolumn should also look the same as in Vim?
>
> When typing ^Vu and the codes above in terminal Vim, I always get these
> squares, i.e. the characters cannot be displayed, in vim -g it works. Is
> this a font issue?
I think so, yes. I'm using gvim with GTK2 GUI so glyphs not found in my
'guifont' ("Bitstream Vera Sans Mono 8") are borrowed from other
installed fonts. In Console Vim you're dependent on the terminal for the
font, and a non-Unicode terminal can't display the above "special"
characters anyway.
> Also, Konqueror displays the squares, but Firefox and Opera get it
> right.
That proves you've got at least one font with the appropriate glyphs. I
don't know about Opera, but Firefox (like my gvim) uses GTK2, Pango, and
the like (as shown in about:buildconfig ) so it will "borrow" glyphs the
same way. KDE programs (like Konqueror), OTOH, use Qt to interface with
the screen, and I don't know how /that/ works. You might try to compare
the font settings of your various browsers.
Here too, I see the correct glyphs in SeaMonkey 2.0a3pre (based on the
same Gecko rendering engine as Firefox 3.1b3pre), but not in Konqueror
3.5.10.
>
> Markus
Best regards,
Tony.
--
Futility Factor: No experiment is ever a complete failure - it can always
serve as a negative example.
Markus Heidelberg
>
> On Dec 18, 7:01 am, Markus Heidelberg <markus.heidelb...@web.de>
> wrote:
> > Given that anything else in the HTML output (also the 'number' option)
> > pretty much reflects the appearance of Vim's window, maybe the
> > foldcolumn should also look the same as in Vim?
>
> That's what I was thinking. However, it would certainly be easier to
> code (and potentially to interact with) if the foldcolumn width would
> just grow to accommodate the highest fold level. What do people
> think...should 'foldcolumn' be used for the width of the fold column,
> complete with a duplication of Vim's foldcolumn text, or should it
> just grow as needed?
I didn't yet consider this case for the appearance reflection, but the
color and characters used.
It should grow. We need to have every fold level on the fold column,
else we can't solve the problem of "unknown" open folds.
Maybe foldcolumn=foldlevel+1 to have one space between the column and
the text.
> > When typing ^Vu and the codes above in terminal Vim, I always get these
> > squares, i.e. the characters cannot be displayed, in vim -g it works. Is
> > this a font issue?
> > Also, Konqueror displays the squares, but Firefox and Opera get it
> > right.
> >
>
> I think we should try to create a page that doesn't depend on the font
> being used (beyond the fact that it should be fixed-width, of course).
Yes, I also think so. Using '+' '-' '|' will work everywhere.
Markus
Markus Heidelberg
>
> On 18/12/08 14:01, Markus Heidelberg wrote:
> > When typing ^Vu and the codes above in terminal Vim, I always get these
> > squares, i.e. the characters cannot be displayed, in vim -g it works. Is
> > this a font issue?
>
> I think so, yes. I'm using gvim with GTK2 GUI so glyphs not found in my
> 'guifont' ("Bitstream Vera Sans Mono 8") are borrowed from other
> installed fonts.
Which fonts contain glyphs like the circled plus?
I tested switching fonts in gvim: the circled plus (0x2295) has two
different appearances. It looks the same with all tested monospace/sans
fonts and it looks the same with all tested serif fonts.
> In Console Vim you're dependent on the terminal for the
> font, and a non-Unicode terminal can't display the above "special"
> characters anyway.
It is Unicode-aware, I can display Japanese characters for example. Only
a few languages (dz,gu,km,ne,pa) from the
/usr/share/applications/*.desktop files can't be displayed, whether
opened with vim, gvim, kate, cat.
> > Also, Konqueror displays the squares, but Firefox and Opera get it
> > right.
>
> Here too, I see the correct glyphs in SeaMonkey 2.0a3pre (based on the
> same Gecko rendering engine as Firefox 3.1b3pre), but not in Konqueror
> 3.5.10.
I just tested using Vim in Xterm, there the circled square is displayed
correctly, in Konsole it's wrong. Seems to be related to KDE/Qt.
Markus
Ben Schmidt
> code (and potentially to interact with) if the foldcolumn width would
> just grow to accommodate the highest fold level. What do people
> think...should 'foldcolumn' be used for the width of the fold column,
> complete with a duplication of Vim's foldcolumn text, or should it
> just grow as needed?
I think grow as needed.
Ideally, in my eyes, it should not include it at all, though, if no
foldcolumn is visible in Vim (i.e. foldcolumn=0). In that case, you need
to resort to clicking the foldtext to open folds, and a double-click on
text to close one, or something like that.
> I think we should try to create a page that doesn't depend on the font
> being used (beyond the fact that it should be fixed-width, of course).
I agree. Stick to stuff in 7 bit ASCII, at least by default.
Ben.
Ben Fritz
attachment, without an actual message in my inbox.
So...
http://groups.google.com/group/vim_dev/browse_thread/thread/84bcdc1a7e56e14d