zim-wiki team mailing list archive

[Dotan Cohen <dotancohen@xxxxxxxxx>]

On 8 June 2010 14:44, Fabian Moser <e-mail@xxxxxxxxxxxxxx> wrote:
> On Tue, 8 Jun 2010 13:01:25 +0300
> Dotan Cohen <dotancohen@xxxxxxxxx> wrote:
>
>> 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.
>
> Good point, but you suggested to change that:
> https://bugs.launchpad.net/zim/+bug/373280
>

Yes, I _hope_ to see Zim as a semantic editor.


>> 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.
>
> On the other hand I love being able to copy-paste text containing
> markup and see Zim render it with the markup actually being parsed.
> Users will share this love.
>

I agree, I never suggested that the ability to paste formatted text be
taken away. Rather, I suggested an option that Zim not parse the
litteral characters of the paste as so-called "wiki markup". Paste
buld text from OOo or Firefox into Zim, have it be bold. But paste
__pythoncode___ and don't parse that into an underline.


>> 3) I personally like some code to be fixed-width (Python snippets, for
>> instance) but others to be variable, such as bash.
>> ...
>
> What you are basically saying is, that you want to put your code
> (verbatim, escaped whatever) into any format you choose. This could be
> achieved by something similar to the %% (double percent) in dokuwiki.
> If that is what you mean, I agree that this is useful.
>

Non-parsed blocks is the idea, but it would not be blocks. My usage
scenario cannot have autoformatting _at_all_. If I press Ctrl-I or
click on the Italic button, then I expect Italic text. But if I type
_text_ it should not parse.

Note that OOo also has thes options, and the autoformatting can be
disabled. That is waht I require of Zim.


>> 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.
>
> This is a duplicate of 2) as I see it.
>

It is a generalization. My problem is code. Yulia's problem might be
mathematical text. Marina might have chemical formulas.


>> The argument for exporting to Latex is again the semantic argument.
>
> And how would that make it less valid? Adds to my comment for 1).
>
>
> Please allow me to sum it up slightly different:
>
> 1) You (and supposedly several others) want Zim to ignore wiki markup
> and display whatever you type as-is in any font and formatting you
> choose for that particular data. There is no way to achieve this right
> now.
>

Correct.

> 2) To me (and supposedly several others) wiki is not only about links,
> but a whole lot about markup as well.

This ability should be kept.


> In fact, I could live with a
> non-wiki link mechanism as long as the markup was still there. If I
> want something to be printed bold, I type **something** and don't care
> about formatting shortcuts, menus or toolbars. And I don't want to
> care. If I want to print **something** (with the stars kept) in-line
> with my text, I have to resort to typing ''**something**'' and live
> with the monospace. I cannot keep the same font if I wanted to.
>

This is the problem.


> It is not possible to fully satisfy 1) and 2) at the same time,

Sure it is, take a look at OpenOffice.org Writer. the user can
configure **text** to bold, and can disable that as well.

Firthermore, do you really need the ability to type **text**? What is
wrong with {Ctrl-B}text{Ctrl-B}? Wikimarkup ws invented to work around
the fact that one could not type rich text into an HTML textarea in a
web browser in 2001. Zim and other local GTK apps do not have this
limitation.


> but
> introducing a way of escaping markup no matter where the parser picks
> it up (e.g. by %% like dokuwiki), would make 1) and 2) possible. We
> would only have to agree on whether Ctrl-V behaviour remains as-is or
> is changed to "escaped paste", and give e.g. Ctrl-Shift-V the respective
> other meaning.
>

I agree that in addition to the ability to disable auto-parsing of
"wiki syntax" their should be an option to have the default paste be
either formatted or nonformatted. But that is a separate issue.


-- 
Dotan Cohen

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