zim-wiki team mailing list archive

[Christoph Zwerschke <cito@xxxxxxxxx>]

Am 04.03.2012 11:17, schrieb Dotan Cohen:
> Also, you might like to note that there is an Edit Source function in
> the Tools menu. That is the place where one should be entering data in
> raw format, not in the standard main window. A possible improvement
> would be to have the Edit Source function edit the source in the Zim
> window, with the cursor placed right where it was when in the standard
> mode. Text entered in the standard mode should be automatically
> escaped by Zim when converted to Source. That would solve all the
> mentioned issues. I will write an RFE for this, give me a few minutes.

Thanks for mentioning the "edit source" function, I overlooked that. My 
only issue with that function is that opening content in another editing 
window is somewhat problematic as it really may cause data loss. It's 
still great that it is *possible*, because the external editor may have 
some advantages for some people, e.g. you may prefer editing text in vi 
or a distraction less text editor or whatever. But it should not be the 
standard way of usage. Therefore the possibility to switch into a raw 
editing mode in the same zim window would still be desirable.

Your idea that the cursor should be "placed right where it was when in 
the standard mode" is also desirable, and it looks easy, but it's very 
difficult to implement programmatically. The closest thing I have seen 
was ConnectedText where you can mark a part of the text, and then 
ConnectedText would search the same text in the editor window and place 
the cursor at that location. But of course that's not really foolproof 
(e.g. when the search text exists several times) and still a bit 
inconvenient because you need to mark an appropriate text passage first.

Also, it's not clear to me what you mean when you say that "entered text 
should be automatically escaped by zim". The problem is that if you 
enter **bold** then you want your asterisks be interpreted by zim, not 
escaped, but if you enter 2**3 + 2**4 then you probably don't want them 
to be interpreted, but it's impossible for zim to distinguish these 
cases *automatically*.

Maybe a solution would be to allow different modes for pasting text to 
zim, similar to the different modes for copying text from zim.

>> For instance, if you see a mistake or type on a page, you simply go
>> and correct it. You don't need to switch to an edit mode, search
>> for the place with the error there, fix it, and switch back to view
>> mode.
>
> That could still be possible with the suggestion that I made above.

Yes, it the problem of mapping cursor positions in source text and 
rendered view could be solved, but as I said it's a really difficult 
thing. And even then, you will still have to switch editing modes which 
is not so convenient.

> Python code was just an example. How about ASCII art? The fact is that
> Zim should handle arbitrary input. Any argument to the contrary means
> that Zim will be inappropriate for some use case or another.

If you use triple quotes and indent your content, I think you can 
include arbitary input already, though I agree that's not so convenient.

One solution that comes to my mind is to allow embedding external text 
files (similar to embedding images) which would be rendered literally in 
a monospaced font, maybe with syntax highlighting depending on the file 
type.

-- Christoph