TOhtml - select without linenr

105 views
Skip to first unread message

Tarlika Elisabeth Schmitz

unread,
May 10, 2012, 6:24:29 PM5/10/12
to vim_use, Ben Fritz
I just started looking into converting syntax highlighted code to
HTML (to be embedded on a web page).

Great feature! The only fly in the ointment is the fact that line
numbers are selectable.

I remember Ben Fritz tried to address this issue two months ago:
http://vim.1045645.n5.nabble.com/TOhtml-beta-release-unselectable-regions-td5560969.html

I have (manually) played around with the generated HTML and I have come
up with a solution that requires no javascript and the HTML code is a
bit more compact. I have attached a 5-line example.

The output is placed in a <table>, and the line numbers are in a
separate <td>. Consequently, it is possible to select the output code
without grabbing line numbers.

Although not essential in this set-up, it is possible to
make the line numbers unselectable just using CSS. I have enclosed a
cross-browser CSS solution for the unselectable line number area.
Disabling selectability might not work for every browser but this is
not crucial as it is possible to select the data content separately
anyway.
Internet Explorer versions <10 require a different approach: the tag
containing the line number needs to be given the "unselectable"
attribute. (This is not inherited and therefore cannot be added at
parent level!)

I also changed the cursor to pointer.


I made a point of keeping the CSS classes that reflext the vim colour
scheme (lnr, Identifier,...) separate from the generic CSS that
determines the page structure. This way one can easily paste in
additional syntax highlighting tags into an existing stylesheet.

I applied the lnr highlighting to the containing <pre> block rather
than every individual line so that the whole line number column has the
lnr background and it avoids gaps between rows.


The output validates with the exception of the IE "unselectable"
attribute.

PS: I don't have a Windows machine, so can't test this with IE.

--
Tarlika Elisabeth Schmitz, Scotland
vim2html.html.gz

Ben Fritz

unread,
May 10, 2012, 11:30:21 PM5/10/12
to vim...@googlegroups.com, Ben Fritz
On Thursday, May 10, 2012 5:24:29 PM UTC-5, Tarlika Elisabeth Schmitz wrote:
> I just started looking into converting syntax highlighted code to
> HTML (to be embedded on a web page).
>
> Great feature! The only fly in the ointment is the fact that line
> numbers are selectable.
>
> I remember Ben Fritz tried to address this issue two months ago:
> http://vim.1045645.n5.nabble.com/TOhtml-beta-release-unselectable-regions-td5560969.html
>
> I have (manually) played around with the generated HTML and I have come
> up with a solution that requires no javascript and the HTML code is a
> bit more compact. I have attached a 5-line example.
>

First of all, thank you very much for looking into this. I'd love to have a
lot of minds sit down and think up a good standards or "mostly-standards"
way of doing this. Please take all of my comments below in the sense of
"let's work out a good solution" and not "my solution is better." I don't
think that. I think my solution, abusing input elements and inserting
invalid markup to fake out MS Word, is a terrible way of doing it. But this
is a very difficult problem and I'm afraid the proposed solution only works
in some cases.

First, though, congratulations on making a simple test page that "works" on
all 4 browsers I primarily test on: Chrome, Firefox, IE8, and Opera. I
sometimes test on Safari as well, but not this time. Mostly it just acts
like Chrome anyway.

Your test page renders fine in each browser (with some 1px issues which I
can ignore) and the ability to only select and copy the main text works as
advertised, as it should, because it's all in a <td> by itself. I can also,
if I try to, select the entire text WITH line numbers, which is pretty
awesome. The only thing that doesn't seem to work, is that the text is for
some reason pasted into MS Word unformatted from Opera and Firefox. And only
Chrome pastes the background color. One of my primary goals of this feature
was to be able to generate HTML with dynamic folding and line numbers
enabled, and copy-paste just the formatted text into my email client at work
(Lotus Notes...ugh). So, the formatted text is important to me.

> The output is placed in a <table>, and the line numbers are in a
> separate <td>. Consequently, it is possible to select the output code
> without grabbing line numbers.
>

Did you just hand-code this, or did you actually get a modified script to
generate it? Modifying the script to do this will take a lot of work,
because it currently processes entire lines, one at a time. I suppose it
could maintain multiple lists, one for each column, rather than one big list
for the entire line text, but it will be a big change to do so. Right now
each line in the buffer gets (for the most part, anyway) one line of HTML
(one giant unwieldy line sometimes, but one line nonetheless).

This brings up the other main problem with the table method. Dynamic folding
relies on looking up a single element by ID in a javascript event, and then
modifying the class of that on the fly to show/hide the element. This single
element must therefore span parts of the foldcolumn, the entire line number,
and the entire line text. Doing this would not be possible in the table
layout.

Perhaps, we can look it up by class instead of by ID. Or prepend a prefix
like LineText_ and LineNr_ and FoldC_ to the ID for each section. That is
certainly something to think about. It may be tricky but I think having
individual columns might be the best way to go forward.

The other difficulty, however, is in the fact that wrapping may be turned
on. I can not think of a good way to get text wrapping to work in the table
so that the line numbers continue to align with the beginning of their
respective line. It might be possible to simply declare that unselectable
areas only work for non-wrapping text, but that would mean 2 completely
separate output methods. I would like to avoid that if possible.

> Although not essential in this set-up, it is possible to
> make the line numbers unselectable just using CSS. I have enclosed a
> cross-browser CSS solution for the unselectable line number area.
> Disabling selectability might not work for every browser but this is
> not crucial as it is possible to select the data content separately
> anyway.

I agree it is not needed to have the content unselectable, as long as the
different content areas can be selected independently.

Your CSS solution relies on the user-select property, which was
provisionally in CSS3 for a long time (appearing in this document, for
instance: http://www.w3.org/TR/2000/WD-css3-userint-20000216 ), but was then
removed and is no longer in the spec that I have been able to find (
http://www.w3.org/TR/2012/WD-css3-ui-20120117/ is the latest version of the
aforementioned document and it has no mention of user-select). The last time
I checked it, at least two major browsers (I forget which) did not support
it, and I don't think they will be in the future since it isn't in the spec.
Perhaps they will surprise me though.

As stated, however, the primary goal is making the region uncopyable. I
don't care too much about selectability.

> Internet Explorer versions <10 require a different approach: the tag
> containing the line number needs to be given the "unselectable"
> attribute. (This is not inherited and therefore cannot be added at
> parent level!)
>
> I also changed the cursor to pointer.

Are you saying IE10 supports user-select? Perhaps I am being proven wrong
about that after all... Anyway, I want to avoid non-standard markup where
possible, and "unselectable" is certainly that.

> I made a point of keeping the CSS classes that reflext the vim colour
> scheme (lnr, Identifier,...) separate from the generic CSS that
> determines the page structure. This way one can easily paste in
> additional syntax highlighting tags into an existing stylesheet.
>

Good call. Next on the list is external stylesheets, for which there's
another patch out on vim_dev somewhere I think.

> I applied the lnr highlighting to the containing

> block rather
> than every individual line so that the whole line number column has the
> lnr background and it avoids gaps between rows.
>

If we can address dynamic folding and line wrapping, I agree this is the way
to go. I learned more than I cared to know about the line-height and default
(differing by element) font sizes for the different browsers, and none of it
ended up working anyway to fix the gaps, so I had to cheat with a 1px
border. Placing it in a real table column with its own background is much
cleaner.

>
> The output validates with the exception of the IE "unselectable"
> attribute.
>
> PS: I don't have a Windows machine, so can't test this with IE.
>

It works fine on IE8, except for not copying the background color; I
normally paste formatted text on a white background anyway, so that's kind
of a don't-care. I assume it works on other IEs as well.


The other idea I had, is abandoning the idea of getting it working on IE8,
and using inline SVG to create an image that had the line number text. I'm
not sure whether this will work or not, but I suspect it might, since it's
an image. I did not try it at first because at the time Opera did not
support inline SVG, and IE8 doesn't. Also I couldn't get the width to be
correct for browsers without the 'ch' unit, but now I've got some javascript
figured out to handle that (since Webkit and Gecko do weird things to the
width of input elements). I know absolutely nothing about SVG, if you or
someone else knows SVG and can put together a working test page which copies
regular text but not SVG text, that would be awesome. If I understand inline
SVG, IE8 and other browsers which don't support it would fall back to
showing the text.

Ben Fritz

unread,
May 10, 2012, 11:42:41 PM5/10/12
to vim...@googlegroups.com, Ben Fritz
On Thursday, May 10, 2012 10:30:21 PM UTC-5, Ben Fritz wrote:
>
> The other idea I had, is abandoning the idea of getting it working on IE8,
> and using inline SVG to create an image that had the line number text. I'm
> not sure whether this will work or not, but I suspect it might, since it's
> an image. I did not try it at first because at the time Opera did not
> support inline SVG, and IE8 doesn't. Also I couldn't get the width to be
> correct for browsers without the 'ch' unit, but now I've got some javascript
> figured out to handle that (since Webkit and Gecko do weird things to the
> width of input elements). I know absolutely nothing about SVG, if you or
> someone else knows SVG and can put together a working test page which copies
> regular text but not SVG text, that would be awesome. If I understand inline
> SVG, IE8 and other browsers which don't support it would fall back to
> showing the text.

Meant to post this, too:

http://caniuse.com/svg-html5

Ben Fritz

unread,
May 10, 2012, 11:46:58 PM5/10/12
to vim...@googlegroups.com, Ben Fritz
On Thursday, May 10, 2012 10:30:21 PM UTC-5, Ben Fritz wrote:
> On Thursday, May 10, 2012 5:24:29 PM UTC-5, Tarlika Elisabeth Schmitz wrote:
> > The output is placed in a <table>, and the line numbers are in a
> > separate <td>. Consequently, it is possible to select the output code
> > without grabbing line numbers.
> >
>
>
> This brings up the other main problem with the table method. Dynamic folding
> relies on looking up a single element by ID in a javascript event, and then
> modifying the class of that on the fly to show/hide the element. This single
> element must therefore span parts of the foldcolumn, the entire line number,
> and the entire line text. Doing this would not be possible in the table
> layout.
>
> Perhaps, we can look it up by class instead of by ID. Or prepend a prefix
> like LineText_ and LineNr_ and FoldC_ to the ID for each section. That is
> certainly something to think about. It may be tricky but I think having
> individual columns might be the best way to go forward.
>
> The other difficulty, however, is in the fact that wrapping may be turned
> on. I can not think of a good way to get text wrapping to work in the table
> so that the line numbers continue to align with the beginning of their
> respective line. It might be possible to simply declare that unselectable
> areas only work for non-wrapping text, but that would mean 2 completely
> separate output methods. I would like to avoid that if possible.
>

Also, I'd like to optionally make the fold text and diff filler uncopyable. But only if the chosen method readily supports it. The main problem is line numbers and fold column, I can live without fold text and diff filler.

Tarlika Elisabeth Schmitz

unread,
May 11, 2012, 1:11:13 PM5/11/12
to vim...@googlegroups.com
On Thu, 10 May 2012 20:30:21 -0700 (PDT)
Ben Fritz <fritzo...@gmail.com> wrote:

>Your CSS solution relies on the user-select property, which was
>provisionally in CSS3 for a long time (appearing in this document, for
>instance: http://www.w3.org/TR/2000/WD-css3-userint-20000216 ), but
>was then removed and is no longer in the spec that I have been able to
>find ( http://www.w3.org/TR/2012/WD-css3-ui-20120117/ is the latest
>version of the aforementioned document and it has no mention of
>user-select). The last time I checked it, at least two major browsers
>(I forget which) did not support it

IE + Opera

I can't find where I saw this now, but I read that -ms-user-select will
be supported by IE 10.

-o-user-select isn't [yet] implemented in Opera. Opera implements IE's
"unselectable" attribute instead.

Tarlika Elisabeth Schmitz

unread,
May 11, 2012, 6:43:44 PM5/11/12
to vim...@googlegroups.com
On Thu, 10 May 2012 20:30:21 -0700 (PDT)
Ben Fritz <fritzo...@gmail.com> wrote:

>On Thursday, May 10, 2012 5:24:29 PM UTC-5, Tarlika Elisabeth Schmitz
>wrote:
>> I just started looking into converting syntax highlighted code to
>> HTML (to be embedded on a web page).
>>
>> Great feature! The only fly in the ointment is the fact that line
>> numbers are selectable.
>Your test page renders fine in each browser (with some 1px issues
>which I can ignore)

Where the hell did they appear?!

>The only thing that doesn't seem to
>work, is that the text is for some reason pasted into MS Word
>unformatted from Opera and Firefox.

I am surprised! I never thought you could paste a formatted web page
into LibreOffice.
I tried this with Chrome (to LibreOffice) using YOUR TOhtml page -
result formatted exactly as on web page incl. bg.
It did not work with FF 9 (neither your nor my vim output). Correct
font but no colours, neither fg nor bg.

>> The output is placed in a <table>, and the line numbers are in a
>> separate <td>. Consequently, it is possible to select the output code
>> without grabbing line numbers.
>>
>
>Did you just hand-code this

yes

>Dynamic folding [...]

Could you attach an example?
I don't use folding, not even in vim. Maybe I get an idea if I see the
HTML output in action.

>wrapping may be turned on.

That's clever! Didn't realize TOhtml reacted to the current wrapping.

I can think of two code prettifier which deal with wrapping using a
horizontal scrollbar. Always annoying, I know.
TOhtml with wrap wraps through the linenr coloumn though. Not 100%
ideal either.

>> Although not essential in this set-up, it is possible to
>> make the line numbers unselectable just using CSS.
>
>As stated, however, the primary goal is making the region uncopyable. I
>don't care too much about selectability.

As long as the copied/pasted code is ready to use (without linenr),
that's objective achieved for me.

>Are you saying IE10 supports user-select?

I read that somewhere, can't find it now. (-ms-user-select)

> Anyway, I want to avoid non-standard
>markup where possible, and "unselectable" is certainly that.

I'm afraid catering for x different browsers times y versions is a
dirty business. It may offend your sense of tidiness but if it works
I'd go for it.

I am always keen to find a soution that still works ok without
javascript. My default is no JS (I use NoScript).

>> I made a point of keeping the CSS classes that reflext the vim colour
>> scheme (lnr, Identifier,...) separate
>
>Good call. Next on the list is external stylesheets, for which there's
>another patch out on vim_dev somewhere I think.

As each TOhtml output only includes the styles used, I thought this is
essential. This way one can build up an external style sheet by adding
to it. (I am thinking of a separate style sheet for embedded "pretty
printed" code.)

>The other idea I had, is abandoning the idea of getting it working on
>IE8

Not sure how many peole use which browesers. Haven't seen any stats
recently.

> using inline SVG to create an image that had the line number
>text.

intersting but discounts loads of old browsers.


Anyway, there's scope for improvement but it is a pretty cool vim
feature as it is already!

Benjamin Fritz

unread,
May 14, 2012, 12:45:00 PM5/14/12
to vim...@googlegroups.com
On Fri, May 11, 2012 at 5:43 PM, Tarlika Elisabeth Schmitz
<v...@numerixtechnology.de> wrote:
>
> >Dynamic folding [...]
>
> Could you attach an example?
> I don't use folding, not even in vim. Maybe I get an idea if I see the
> HTML output in action.

Attached is the output of TOhtml on the netrwPlugin.vim code with:

g:html_dynamic_folds=1
g:html_hover_unfold=1

The second option there is quite annoying in my opinion for this small
file, but you said you don't have javascript enabled, and dynamic
folding relies entirely on javascript by default. The hover_unfold
options lets you at least view the fold content with CSS only, even if
you still can't persistently toggle them open/closed without
javascript.

See :help :TOhtml for a full list of options in the current version
(it's a bit long-winded currently but covers them all).
netrwPlugin.vim.html

Tarlika Elisabeth Schmitz

unread,
Jun 20, 2012, 4:09:23 PM6/20/12
to vim...@googlegroups.com, fritzo...@gmail.com
Hello Ben,

I am sorry it has taken me so long to get back to this thread. Just in
case anyone is wondering what it is about, here's a link to the
archived threads:

http://groups.google.com/group/vim_use/browse_thread/thread/aa400607d493a63e
and
http://groups.google.com/group/vim_use/browse_thread/thread/ba698d5c61afae05


REQUIREMENTS
=============

From our previous conversation, here's a list of requirements in
(roughly in order of importance?)

1) line numbers not copyable
2) HTML output surrounded by PRE block
3) folding possible
4) wrapping possible
5) wrapping not through line number column
6) W3C compliant
7) browser support IE8+, Chrome, Firefox, Opera
8) still viewable with JavaScript switched off
9) separable CSS (for embedding in web site)
10) diff filler uncopyable
11) line numbers unselectable

MY TESTS
=============

1) FOLDING: I looked at your folding example (with JavaScript
enabled)
- that is really awesome! I don't use vim folding myself, so hadn't
appreciated this TOhtml feature before.

2) YOUR INPUT METHOD: I had go at making the HTML more compact
and the CSS more cross-browser capable;

3) ALTERNATIVE METHOD I played around with ordered lists.

4) I am leaving the URL to link conversion issue aside for the moment
to focus on the above.

CONCLUSIONS
=============

** TABLE METHOD **

Firstly, the table method I suggested last month is not suitable
because it wouldn't cater for folding and wrapping with any ease.

** INPUT METHOD **

Although your invalid <input> field approach seems a bit clumsy,
it is the most cross-browser capable down to IE6! What I didn't like
about it was the fact that it was so wordy and made the HTML output
rather unreadable. It doesn't cope well with wrapping, which goes
through the line number "column".

My modifications to <input> method:
- onclick etc pulled out, which means less code and therefore better
readability
- separated Vim-derived styles from those needed for creating the
layout
- defined CSS classes with higher specificity so they won't collide
with other styles when embedded in a web page
- eliminated 1px problem between line numbers, which occerred in some
browsers
- I have not yet produced HTML/CSS for folding
- all tests done via changing your output manually
- tested in IE6, FF 3.5, FF10, Chrome, viewed IE7,8,9 via screenshot
service
- CSS W3C validated
- HTML did not because of invalid <input> type

+ 1) line numbers not copyable
+ 2) HTML output surrounded by PRE block
+ 3) folding possible (CSS/HTML not yet implemented)
+ 4) wrapping possible
- 5) wrapping not through line number column
+/- 6) W3C compliant: CSS yes, HTML no because of invalid <input>type
+ 7) browser support IE8+, Chrome, Firefox, Opera
+ 8) still viewable with JavaScript switched off
+ 9) separable CSS (for embedding in web site)
? 10) diff filler uncopyable
+ 11) line numbers unselectable (if JS switched on)


** ORDERED LIST METHOD **

Advantages: less wordy (line numbers automatic), wrapping of
data column only possible, line numbers always unselectable
Disadvantages: dot after line number (work-around possible), IE6,7
incompatible (possibly fixable)

+ 1) line numbers not copyable
+ 2) HTML output surrounded by PRE block
+ 3) folding possible (not tested)
+ 4) wrapping possible
+ 5) wrapping not through line number column
+/- 6) W3C compliant: CSS yes, HTML no because of <div> in <pre>
(work-around possible)
+ 7) browser support IE8+, Chrome, Firefox, Opera
+ 8) still viewable with JavaScript switched off
+ 9) separable CSS (for embedding in web site)
? 10) diff filler uncopyable
+ 11) line numbers unselectable (if JS switched on)

--

Tarlika Elisabeth Schmitz, Scotland
http://my.mutterings.co.uk/
vim2html_input_compact.html
vim2html_ol.html

Tarlika Elisabeth Schmitz

unread,
Jun 20, 2012, 6:06:09 PM6/20/12
to vim...@googlegroups.com, fritzo...@gmail.com
On Wed, 20 Jun 2012 21:09:23 +0100
Tarlika Elisabeth Schmitz <v...@numerixtechnology.de> wrote:

>REQUIREMENTS
>=============

another one:

12*) code snippet with line number starting at 1


* I'd rate that fairly high


>My modifications to <input> method:

- line number column is solid (no top/bottom padding)

Tarlika Elisabeth Schmitz

unread,
Jun 20, 2012, 7:35:50 PM6/20/12
to vim...@googlegroups.com, fritzo...@gmail.com
On Mon, 14 May 2012 11:45:00 -0500
Benjamin Fritz <fritzo...@gmail.com> wrote:

>> >Dynamic folding [...]
>>
>> Could you attach an example?
>> I don't use folding, not even in vim. Maybe I get an idea if I see
>> the HTML output in action.
>
>Attached is the output of TOhtml on the netrwPlugin.vim


It gets very complex once you take into consideration display/nodisplay
of line numbers in combination with dynamic folding/no folding.


Just to confirm briefly: folding can be nested, hence the column is of
dynamic width?

Is the line number column of dynamic width depending on number of total
lines?



--

Tarlika Elisabeth Schmitz, Scotland
http://my.mutterings.co.uk/

Ben Fritz

unread,
Jun 21, 2012, 10:37:34 AM6/21/12
to vim...@googlegroups.com, fritzo...@gmail.com
On Wednesday, June 20, 2012 6:35:50 PM UTC-5, Tarlika Elisabeth Schmitz wrote:
> On Mon, 14 May 2012 11:45:00 -0500
> Benjamin Fritz <fritzo...@gmail.com> wrote:
>
> >> >Dynamic folding [...]
> >>
> >> Could you attach an example?
> >> I don't use folding, not even in vim. Maybe I get an idea if I see
> >> the HTML output in action.
> >
> >Attached is the output of TOhtml on the netrwPlugin.vim
>
>
> It gets very complex once you take into consideration display/nodisplay
> of line numbers in combination with dynamic folding/no folding.
>

Yes, that's one of the problems the design must be able to solve. I'm not sure that putting the lines in an <ol> and using the list index as the line number as in your example will work in combination with folding, and it will take some doing for conversions starting in the middle of the file. Plus this will only make the line numbers uncopyable, when I also want the fold column.

>
> Just to confirm briefly: folding can be nested, hence the column is of
> dynamic width?
>

Yes, folding can be nested, and the width in the generated HTML depends on the greater of the max foldlevel in the document, and the 'foldcolumn' setting in Vim. In Vim in is just the 'foldcolumn' setting.

> Is the line number column of dynamic width depending on number of total
> lines?
>

Yes. With a minimum width (in characters) equal to the 'numberwidth' option in Vim.

Thanks for looking into this some more. If you come up with an alternative do let me know, but as soon as I get a chance to run some tests and look over the results, I'll have a release candidate based on the <input> method. To make the page render faster I modified it to not use one <input> per character, but to size a single <input> according to the number of characters, with the 'ch' unit if supported or a fallback to calculate the size with javascript.

I'll put that out no later than this weekend. Did you have a problem with the functionality of the <input> method? I mentioned I don't like it because it feels like such a hack, but I've yet to see a viable alternative.

By the way, I tried inline SVG as an alternative, but even though it's an "image", all the browsers supporting it allow selecting it as text, so that's not a solution. Interestingly, SVG pulled in from an external file in an <object> tag is NOT selectable. But I don't want to generate dozens of files for a single page with :TOhtml; part of the idea is for it to generate a self-contained easily share-able file.

Tarlika Elisabeth Schmitz

unread,
Jun 21, 2012, 11:04:40 AM6/21/12
to vim...@googlegroups.com, fritzo...@gmail.com
On Thu, 21 Jun 2012 07:37:34 -0700 (PDT)
Ben Fritz <fritzo...@gmail.com> wrote:

>On Wednesday, June 20, 2012 6:35:50 PM UTC-5, Tarlika Elisabeth
>Schmitz wrote:
>> On Mon, 14 May 2012 11:45:00 -0500
>> Benjamin Fritz <fritzo...@gmail.com> wrote:
>>
>> >> >Dynamic folding [...]
>>
>> It gets very complex once you take into consideration
>> display/nodisplay of line numbers in combination with dynamic
>> folding/no folding.
>>
>
>not sure that putting the lines in an <ol> and using the list index as
>the line number as in your example will work in combination with
>folding, [...] this will only make the line numbers
>uncopyable, when I also want the fold column.

Do you ever want the line numbers to be copyable?
Do you ever want to copy characters from the fold column?
Is the fold column always to the left of the line numbers?

Is this correct ? :

[fold col] [line nos] code [fold text]


>I'll put that out no later than this weekend. Did you have a problem
>with the functionality of the <input> method?

no - seems to work fine and is the most browser compatible

>I mentioned I don't like
>it because it feels like such a hack, but I've yet to see a viable
>alternative.

Do you want to support IE6+7?

Ben Fritz

unread,
Jun 21, 2012, 2:00:17 PM6/21/12
to vim...@googlegroups.com, fritzo...@gmail.com
On Thursday, June 21, 2012 10:04:40 AM UTC-5, Tarlika Elisabeth Schmitz wrote:
> On Thu, 21 Jun 2012 07:37:34 -0700 (PDT)
> Ben Fritz <fritzo...@gmail.com> wrote:
>
> >On Wednesday, June 20, 2012 6:35:50 PM UTC-5, Tarlika Elisabeth
> >Schmitz wrote:
> >> On Mon, 14 May 2012 11:45:00 -0500
> >> Benjamin Fritz <fritzo...@gmail.com> wrote:
> >>
> >> >> >Dynamic folding [...]
> >>
> >> It gets very complex once you take into consideration
> >> display/nodisplay of line numbers in combination with dynamic
> >> folding/no folding.
> >>
> >
> >not sure that putting the lines in an <ol> and using the list index as
> >the line number as in your example will work in combination with
> >folding, [...] this will only make the line numbers
> >uncopyable, when I also want the fold column.
>
> Do you ever want the line numbers to be copyable?

I sometimes want to copy line numbers, for those who may have access to the source file to be able to easily get their bearings.

> Do you ever want to copy characters from the fold column?

No, I cannot think of a time this might be useful.

> Is the fold column always to the left of the line numbers?
>
> Is this correct ? :
>
> [fold col] [line nos] code [fold text]
>

Mostly. The fold text will appear INSTEAD OF the code, when present.

>
> >I'll put that out no later than this weekend. Did you have a problem
> >with the functionality of the <input> method?
>
> no - seems to work fine and is the most browser compatible
>

OK, that's good.

> >I mentioned I don't like
> >it because it feels like such a hack, but I've yet to see a viable
> >alternative.
>
> Do you want to support IE6+7?
>

I want to support IE7. I will make every effort not to break IE6 for existing features, but it is too hard to develop/test new features on IE6; I'll respond to bug reports, but won't actively test on IE6, which now has less than 1% usage share ( http://www.w3schools.com/browsers/browsers_explorer.asp ).

Ben Fritz

unread,
Jun 25, 2012, 1:21:10 AM6/25/12
to vim...@googlegroups.com, fritzo...@gmail.com
On Thursday, June 21, 2012 9:37:34 AM UTC-5, Ben Fritz wrote:
> ...as soon as I get a chance to run some tests and look over the results, I'll have a release candidate...
>
> I'll put that out no later than this weekend.

The annoying thing about running tests is they occasionally turn up bugs.

I'll put it out sometime this week once I have a test run without bugs.
Reply all
Reply to author
Forward
0 new messages