Don't select line numbers on code blocks (Bug #194)

The current behavior comes directly from CodeRay iirc, so we would have to either change its behavior or write our own formatter / post filter.

The approach used by Pygments is to have a table with two columns and one row. Both columns contain <pre>-tags, such that no unintentional line break can occur. the left column then holds the line numbers, one per line, the right column contains the actual source code.

When you now select text, only the code is selected since you never leave the table cell containing the code. The downside is that you can't get the interleaved line-numbers.,

Alternatively, we could implement the model used by GitHub. They use one table row per line of source code. This would give us more flexibility but would probably be a bit harder to implement. Currently, I don't know if they use javascript magic to prevent the selection of full lines or if this is default behavior.

There is a related issue at http://www.redmine.org/issues/3382 and a somewhat working patch that probably needs some tweaking to have a smooth merge.

Holger Just wrote:

The current behavior comes directly from CodeRay iirc

I know, and I had somewhere in the back of my mind that it had already been discussed on redmine.org and that there was a possible solution with CodeRay, I didn't have a good enough connection to dig them out though :-)

Eric T: I patched my local instance with your pull request and noticed 2 things:

• There's an unmatched < /code > (spaces added for it to show) after the table,
• when previewing stuff with code in it, the part with the line numbers expands horizontally to fill what I think the browser assumes is the max width of a page or something like that.

All that tested on an uptodate Safari/OS X.

Felix,

Thank you for taking the time to review it. I see what you are saying about the first point and I've got a pretty good idea on how to fix that.
Could you post a screenshot for the the second point? I'm not sure if I'm following quite what you are saying.

Eric Thomas wrote:

Could you post a screenshot for the the second point? I'm not sure if I'm following quite what you are saying.

I'm not sure I have that branch still around. Could you just try to put code on a wiki page or an issue and preview it instead of saving it? Maybe with a webkit browser if you have one. The error is pretty obvious, if you don't see if by just doing that, I'll post a pagegrab :-)

I tried doing a preview on my browser (Firefox 3 on Fedora) and wasn't getting any issues. If webkit is Apple specific, then I don't have one. A screenshot would be helpful.

Eric Thomas wrote:

If webkit is Apple specific, then I don't have one.

Nope, Chrome is webkit too, and different KDE and Gnome browsers as well. If this is brittle to the point of browser specific problems, I'd like to have it tried on Firefox 3, IE8 or earlier, Safari, Chrome and Opera. I can test on Safari, and I think we have IE and Opera somewhere here in the office, could you test Chrome in addition to Firefox?

A screenshot would be helpful.

I'll post one later.

(Notice the scroll bar at the bottom, that should give you an indication of how large this blue part is…)

Felix Schäfer wrote:

This is what it looks like in Safari when trying to preview a new issue with a code block:

This happens on Chrome/Linux too, so I guess it's a webkit thing you could test with either Chrome or whatever webkit browser on Linux.

Felix,

Thanks for your feedback. I could not get this to work since having a <table> inside a < code > block seemed to always screw things up. So my approach was to replace < code > with <div>, see here. However, little did I realize that I only had access to the first < code > tag, but not the closing one, so that's why the <div> was not closed.

I have a fixed version that works in redcloth 4 (see #210),but the monkey patching involved is completely different, so I'd rather wait to see if ChiliProject can get upgraded.

Eric Thomas wrote:

I have a fixed version that works in redcloth 4 (see #210),but the monkey patching involved is completely different, so I'd rather wait to see if ChiliProject can get upgraded.

I don't think it will be before 2.0.0. Anyway, IIRC CodeRay 1.0 should make that particular point easier too, unless anyone needs this quickly, I'd prioritize it to low for 2.0.0.

It is a not-so-trivial annoyance for me personally, plus I just don't understand why coderay would have designed inline line numbers to begin with.

Eric,

I've installed your four changes from your pull request, and I'm noticing extra linebreaks before and after the text in the code blocks, but only when the language is not set.

But, I'm not seeing any problems with the WebKit browser I happened to have installed on my system (Epiphany 2.30.2).

Also, when no language is specified no line numbers are displayed. Is this behavior intended? I think this should at least be user-specified.

Ian, thanks for testing the patch. Since this patch would be rewritten by #210, this should be put off until 2.0.0.

Sorry, I didn't read the discussion. Did you consider using user-select? I use it in CodeRay 1.0.

Kornelius Kalnbach wrote:

Sorry, I didn't read the discussion. Did you consider using user-select? I use it in CodeRay 1.0.

Well, if CodeRay 1.0 provides everything needed for it, we won't need to do it ourselves ;-) Is 1.0 "near enough" that we can wait for it, or should we implement it ourselves until 1.0 is ready?