← Back to team overview

zim-wiki team mailing list archive

Re: Call for user cases ?


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

Follow ups