← Back to team overview

zim-wiki team mailing list archive

Re: Two critical issues for me in Zim

 

On 8 June 2010 10:05, Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx> wrote:
> Well, the way to escape the things is by using the verbatim style.
> Since all wiki syntax uses double characters (so **asterisks** are
> bold but *asterisk* is normal, idem for __underscore__ verus
> _underscore_, :colon: will be turned into a link when typed, not when
> pasted, use ^Z to ignore it when typing) the assumption is that this
> will only happen in code snippets and similar text. For these types of
> text verbatim gives the proper formatting and escapes all wiki syntax.
>

To sum it up, there are two appreaches:
1) To require that all code be in a special formatting (currently
called Verbatim, probably better called Code).
2) To allow code to be in any arbitrary place in the page.

The current behaviour is the former, do we want the latter to be allow as well?

I argue that yes, code should be allowed anywhere, based on these points:
1) Currently, there is no semantic usage of markup anywhere in Zim.
For instance, there is no Table of Contents, no searching only
headers, no functions for interacting with the markup in any way.
2) Users _will_ be sloppy and paste code without marking it as such.
Causing dataloss in this case is beyond forbidden. It is a real reason
that I have been looking for a Zim alternative for the past week or
so.
3) I personally like some code to be fixed-width (Python snippets, for
instance) but others to be variable, such as bash. English lettering
is not my natural lettering, and fixed-width is very difficult for me
to read. That said, I do want to use it in some special cases.
Therefore, there is no "code" but rather "this-type-of-code" and
"that-type-of-code" and Zim should not force the user to display it
all in the same way. This is one of MS's biggest criticisms: my way or
the highway. Don't make Zim like this too.
4) The real issue is not code, but whether the user can trust Zim not
to alter his precious data. Currently, the answer is no.


> There are two arguments to keep it like this, the first being that by
> using a special style for this type of text it can be formatted
> accordingly when exporting to e.g. latex or html. Second argument is
> that adding an escape character to allow un-parsed wiki text
> everywhere makes the parse quite a bit more complex. That said it
> could be implemented. My main discussion point is when to actually use
> such an escape during editing.
>

The argument for exporting to Latex is again the semantic argument. As
for code complexity, the user doesn't care. _I_ care, and I really
appreciate the work that it would take to fix this, but frankly users
don't. But I'll be a man and put my wallet where my mouth is: I cannot
code this, but someone will expend a lot of time to fix this. I'll put
a $10USD (via Paypal) bounty on it. I really cannot pay more, I am in
the minus and we're resorting to reusable diapers for the past few
weeks (seriously, it's that bad) but I offer the bounty not as payment
for coding time (that would be insulting) but rather as an expression
of appreciation and to show that I do understand that effort is being
expended to fix this.


> Keep in mind that you can change the visual style of the verbatim
> blocks quite easily. E.g. if you don't like the monospace font you can
> set any other font for this style.
>

Yes, I changed the Heading styles to fit me. I do use the Verbatim as
monospace in some places.


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com



Follow ups

References