linenums support for inline option

[lightxue]

Signed-off-by: lightxue [email protected]

linenums in codehilite only supports 3 options now:

• None
• True
• False

In fact, in pygments, linenos supports a string option: inline。

https://github.com/nex3/pygments/blob/df106dc8c0ff67fdc6369265f6cb4e6832698792/pygments/formatters/html.py#L352-L359

[waylan]

I wasn't aware of this option so I checked the docs:

If set to 'table', output line numbers as a table with two cells, one containing the line numbers, the other the whole code. This is copy-and-paste-friendly, but may cause alignment problems with some browsers or fonts. If set to 'inline', the line numbers will be integrated in the <pre> tag that contains the code (that setting is new in Pygments 0.8).

For compatibility with Pygments 0.7 and earlier, every true value except 'inline' means the same as 'table' (in particular, that means also True).

The default value is False, which means no line numbers at all.

I wonder if inline should be the new default. I very much dislike table.

[waylan]

If a change is necessary, then we need a test to go with it. And the docs need to be updated.

[waylan]

This should be completely unnecessary. The call to super(CodeHiliteExtension, self).__init__(**kwargs) should already pass on the value. In fact, I don't see any reason to make any changes at all. Did you check whether this works before making the change?

[lightxue]

markdown/markdown/extensions/__init__.py

Line 46 in a4d4b61

value = parseBoolValue(value, preserve_none=True)

I checked. It would raise a ValueError if linenums is a string.

[waylan]

Ah right. So then you should just need to change the type to accept strings.

[lightxue]

markdown/markdown/util.py

Lines 100 to 116 in a4d4b61

	def parseBoolValue(value, fail_on_errors=True, preserve_none=False):
	"""Parses a string representing bool value. If parsing was successful,
	returns True or False. If preserve_none=True, returns True, False,
	or None. If parsing was not successful, raises ValueError, or, if
	fail_on_errors=False, returns None."""
	if not isinstance(value, string_type):
	if preserve_none and value is None:
	return value
	return bool(value)
	elif preserve_none and value.lower() == 'none':
	return None
	elif value.lower() in ('true', 'yes', 'y', 'on', '1'):
	return True
	elif value.lower() in ('false', 'no', 'n', 'off', '0', 'none'):
	return False
	elif fail_on_errors:
	raise ValueError('Cannot parse bool value: %r' % value)

Only changing the type to be string would cause compatibility issue. Maybe someone wrote 'yes' in his code and expected linenums to be True.

But if you update the docs, only allow True, False, None, 'inline', it will be nice.

[waylan]

So I forgot how types were defined. But it's documented:

Sets a configuration setting for key with the given value. If key is unknown, a KeyError is raised. If the previous value of key was a Boolean value, then value is converted to a Boolean value. If the previous value of key is None, then value is converted to a Boolean value except when it is None. No conversion takes place when the previous value of key is a string.

So your change is a hack to change the existing value to a string and avoid calling parseBoolValue. I don't like the hack, but this is the problem with implied types.

[lightxue]

Yes, it is a ugly way to avoid compatibility issue. The root of all this is linenos in pygments accept two types. Maybe there is a elegant way to fix it.

[lightxue]

What about add a new parameter lineno_format with two options 'table' and 'inline'?

[waylan]

What about add a new parameter lineno_format with two options 'table' and 'inline'?

That might be a reasonable solution. And the value would be ignored except when linenums is True.

[mitya57]

I wonder if inline should be the new default. I very much dislike table.

With inline copy-pasting won't work properly. So I would rather leave the current default.

[facelessuser]

I've been experimenting with Pygments inline in SuperFences. I'm not suggesting we should or shouldn't include inline output in CodeHilite, only showcasing what I've been experimenting with (I myself am still debating whether to include in my own package).

Anyways, there is a way to do inline and still be able to select, and copy and paste in a sane manner. By default, Pygments does something like this for inline line numbers:

<span class="linenos">   1</span>

This means that when you copy and paste from the code block, you will pick up line numbers which can be annoying.

But if you alter the output to:

<span class="linenos" data-linenos="   1"></span>

You can use CSS and display line numbers that don't get included in a copy/paste.

[data-linenos]:before {
    content: attr(data-linenos);
    /* some additional padding and/or margin may be required. */
}

Now you can have inline output with sane selection and copy/paste:

The subclassing of the Pygments HtmlFormatter object is pretty straight forward: facelessuser/pymdown-extensions@a67a3e7#diff-e331ec6f621f208fd178913907efa563R118.

So, if inline was a preferred, or at least a desirable output option, it could be done in a similar fashion. I generally don't like Pygments default inline output because of the bad copy/paste side effects.

Just some food for thought while considering adding inline.

[waylan]

@facelessuser that’s really cool. The problem is that we suggest users use Pygments default styles which won’t work without modification. That being the case this should probably be an option rather than the default.

[facelessuser]

The problem is that we suggest users use Pygments default styles which won’t work without modification.

Understood, and when suggesting it, I realized this was probably the case. For those willing to tweak CSS, it's probably the only way to get copy/paste and inline. Figured at the very least it would be interested to some 🙂 .

[LennonChin]

@facelessuser that's a cool way, but I am puzzled that if some lines have no line number, the styles of these lines seem to be not easy to control.

[facelessuser]

@facelessuser that's a cool way, but I am puzzled that if some lines have no line number, the styles of these lines seem to be not easy to control.

I'm not sure exactly what you are referring to, but in general, they work just as well as the default inline, only the line numbers are easily excluded from copy/paste. You can have lines with no numbers just fine, and style them however you like:

You can see it just generates the empty lines with empty padded data:

<pre><span></span><span class="lineno" data-linenos="2 "></span>"""Some file."""
<span class="lineno" data-linenos="  "></span>import foo.bar
<span class="lineno" data-linenos="4 "></span>import boo.baz
<span class="lineno" data-linenos="  "></span>import foo.bar.baz
</pre>

[waylan]

What about add a new parameter lineno_format with two options table and inline?

That might be a reasonable solution. And the value would be ignored except when linenums is True.

I will merge this if the above change is made and some tests are added.

[waylan]

This is being closed in favor of #822 which adds support for all options, not just one.