Do not convert spaces to tabs in verbatim

Bug #1363556 reported by Sparhawk on 2014-08-31
This bug affects 5 people
Affects Status Importance Assigned to Milestone

Bug Description

In a verbatim block, zim automatically converts four spaces to a tab character.

In a verbatim block, nothing should be converted.

Also, in verbatim blocks, zim displays tabs as eight spaces, which is inconsistent with the four spaces above. I'm not sure how to change this. (I can see the config file allows specification by pixels, but not by fixed-width spaces.)

Related: https://bugs.launchpad.net/zim/+bug/1275334
which refers to on-the-fly conversion from tab back to spaces, but IMO zim should never convert spaces to tabs in the first place.

zim 0.61
Arch Linux
gtk2 2.24.24-1
pygtk 2.24.0-4

Sparhawk (sparhawkthesecond) wrote :

I should mention this is only seen in leading spaces.

Also, the discrepancy in source (4 spaces) and display (8 spaces) makes it impossible to line up text in verbatim blocks that need 8n+m leading spaces, for integers 0≤n and 4≤m≤7.

Brian V. (brianvanderburg2) wrote :

I can confirm this in Zim 0.62 on Debian 7. I frequenlty use Zim to store code and configuration snips pasted from other files. I use 4 space indentation with spaces in my files and find myself constantly adjusting how it looks in Zim just to get it to look okay. Recently I've started using Vim to retab the contents before pasting into Zim. I might would consider using the code plugin, but it doesn't seem to have a plain text choice.

Changed in zim:
status: New → Confirmed
importance: Undecided → Medium
Robert (pv-ubuntuone) wrote :

I think that the bug description contains a vital clue to both the issue and (IMO) the solution.

Both the OP and myself think of 'verbatim' in terms of *blocks*... in fact, it sooo does not make sense to me that verbatim might be applied to *part* of a line that I had to test it before writing this comment.

Relatedly, I think the issue with the leading space is actually a workaround to satisfy the wiki markup parser, which would not like "<verbatim><whitespace>"... so we use "<whitespace><verbatim>".

Particularly if you take into account any workflow which might need to get *BACK* verbatim output (e.g. from the *.txt file, like log entries, etc)... the correct implementation should be to manage verbatim regions as *blocks* instead of spans.

I also checked, and using a three-single-quote (on their own line) *DOES* currently yield a block quote; with a side effect of indentation... but (at a wiki-source level) it *already-works* as expected! :)

That means that the only real issue, IMO, is that the verbatim tool uses the two-single quotes rather than the whole-block-of-lines block quote.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.