Re: [Zim-wiki] Call for user cases ?
Am 05.03.2012 14:43, schrieb Dotan Cohen: Can you please mention support for adding an option to disable wiki-syntax parsing here: https://bugs.launchpad.net/zim/+bug/585300 Ok, I have added a link to the new ticket https://bugs.launchpad.net/zim/+bug/946229 where it is already mentioned. The old ticket does not need to reopened, it is all covered by the new one. -- Christoph ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
Am 04.03.2012 07:19, schrieb Ulf Bro: The editor I use in everyday life is Vim (Vi). Here you switch between modes all the time. But you do so without taking your fingers off the keyboard. A similar edit mode in Zim would be no harm so long as one could keep the mouse out of the business. That's true, but the big difference is that in vi, the data and its rendering doesn't change at all when you switch between modes. vi doesn't show any rendered data, it only changes the accepted keyboard commands. But when you switch between rendered display and raw data, the content of your editor window changes, and usually it's not even possible to adapt the cursor position. So when you spot a typo in view mode, and then switch to edit mode, you need to find the location of that typo in the markup again. This is what makes separate edit/view modes so unproductive for everyday use in a personal wiki in my opionon. I think switching to raw mode should only be used as a last resort in zim, not be encouraged as the standard way of editing content. But speaking of vi, it's a perfect example for great and mature software that is still not usable for the casual user. Without getting aquainted with the two input modes and the keyboard commands, users will only be frustrated with vi. One thing that surely should be added is a way to easily switch the editor to raw mode where it does not do any rendering. It should not be understood or used as the default edit mode, but it may be sometimes useful to see or edit the raw version of a page. That is the point I'd like to support. With one key, and this could be a function key like F2 for example, you could open an external editor in a new window of course on the currently displayed page (im my case that would be Vim) and do whatever editing you find suitable. Then after saving, do a reload with Ctrl-R and that's it. On the other hand you mostly really shouldn't need to do that. Therefore there is no need to waste time doing revolutionary development on Zim's code to enable raw editing. Just a key to open an external editor and that's it. Agree. Except opening an external editor can be dangerous because then you have two disconnected editing windows open for the same content, and you can easily loose data when you save at the wrong time in the wrong editor. Better to include a real raw editing *mode* which can also have a keyboard shortcut. It would be a bit more work, but I don't think revolutionary development work will be needed for that. -- Christoph ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
On Sun, Mar 4, 2012 at 00:49, Christoph Zwerschke c...@online.de wrote: Am 03.03.2012 18:41, schrieb Dotan Cohen: And why would casual users know this? Well, to be honest I don't think zim is intended for casual users and never will because it is not intended to be a wysiwyg editor. People who want that wysiwyg stlye should use applications like OneNote or Evernote or MyBase or MyInfo or MyNotesKeeper. The special thing about zim is that it knows wiki syntax, and knowing the basics of that syntax is simply required to use it. It's explained very well in the online help. The other special thing about zim is that edit and view mode are not separated. People who want that separation of modes should use applications like ConnectedText or WikidPad or RedNoteBook. If this is the case than that should be made clear. As it is, Zim cannot handle arbitrary input and users are not likely to expect that. 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. The fact that I don't need to switch between edit and view mode is what makes zim so unique, and that paradigm really should be kept. 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. Thanks. I do agree with this benefit of Zim as you mention. But of course, this paradigm also has some disadvantages like the one you mention. I'm sure a lot can and will be done to attenuate these and make the tool even more usable. But you need to understand that they are somewhat inherent to the edit/view paradigm zim is using. One thing that surely should be added is a way to easily switch the editor to raw mode where it does not do any rendering. It should not be understood or used as the default edit mode, but it may be sometimes useful to see or edit the raw version of a page. See the aforementioned Edit Source mode. I see. Although I agree with your assessment that the data could be recovered, it is still lost for Zim users. You and I might be able to open the source file and retrieve the data. I would not expect that of the casual user. That is quite the reason that I think that it is a bit early to promote Zim to the casual user. See above regarding casual users. A raw editing mode could help, but even that might not be found or understood by a casual user. Just like copying the data with Copy as... - Wiki to get the raw data. How about Python code, which maycontain triple quotes? Zim itself is written in Python. But zim's triple quotes must be on a line for themselves, which rarely happens in Python snippets, and you can always indent your Python snippets to guarantee no triple quotes are at the beginning of a line. Also, Python normally uses triple double quotes for docstrings, not single quotes. So in reality, it's not much of an issue. 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. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
Am 04.03.2012 11:15, schrieb Christoph Zwerschke: Agree. Except opening an external editor can be dangerous because then you have two disconnected editing windows open for the same content, and you can easily loose data when you save at the wrong time in the wrong editor. Better to include a real raw editing *mode* which can also have a keyboard shortcut. It would be a bit more work, but I don't think revolutionary development work will be needed for that. By the way, as Dotan just pointed out, the possiblity to open the raw text with an external editor (of your choice) already exists, under the tools menu. I totally overlooked that. The reason is that I'm not using zim on a daily basis yet, because there is no practicable way to import my old data as html/rtf. That's for me the only larger issue. But I expect this will be solved in future versions, or maybe I will work on that issue myself if I find the time. -- Christoph ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
Here are two issues to help improve the situation: RFE: Edit source in Zim window https://bugs.launchpad.net/zim/+bug/946224 Escape input when translating to Source https://bugs.launchpad.net/zim/+bug/946229 -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
On Sun, Mar 4, 2012 at 12:15, Christoph Zwerschke c...@online.de wrote: Am 04.03.2012 07:19, schrieb Ulf Bro: The editor I use in everyday life is Vim (Vi). Here you switch between modes all the time. But you do so without taking your fingers off the keyboard. A similar edit mode in Zim would be no harm so long as one could keep the mouse out of the business. That's true, but the big difference is that in vi, the data and its rendering doesn't change at all when you switch between modes. vi doesn't show any rendered data, it only changes the accepted keyboard commands. But when you switch between rendered display and raw data, the content of your editor window changes, and usually it's not even possible to adapt the cursor position. So when you spot a typo in view mode, and then switch to edit mode, you need to find the location of that typo in the markup again. This is what makes separate edit/view modes so unproductive for everyday use in a personal wiki in my opionon. I have filed in RFE to make this easier: when switching to Edit Source mode Zim should keep the cursor in the same location as it was in normal mode: https://bugs.launchpad.net/zim/+bug/946224 I think switching to raw mode should only be used as a last resort in zim, not be encouraged as the standard way of editing content. Then why do you prefer that you can type //some text// to have it italicized in the normal window? What is wrong with Ctrl-I before and after? It is exactly the confusion between raw/source mode and normal mode that hinders Zim from handling arbitrary input. In other words, there already exists shortcuts for headings and formating in Zim, with the Ctrl modifiers just like in any other formatted editor. If one wants to type wiki-syntax directly, then have an easy way to switch to wiki-syntax / raw / source mode. But speaking of vi, it's a perfect example for great and mature software that is still not usable for the casual user. Without getting aquainted with the two input modes and the keyboard commands, users will only be frustrated with vi. Agreed, even as a heavy VIM user myself (typing even now in GVIM!). That is exactly why having the wiki syntax active in the normal mode is confusing. Casual users will not already know the wiki syntax. One thing that surely should be added is a way to easily switch the editor to raw mode where it does not do any rendering. It should not be understood or used as the default edit mode, but it may be sometimes useful to see or edit the raw version of a page. That is the point I'd like to support. With one key, and this could be a function key like F2 for example, you could open an external editor in a new window of course on the currently displayed page (im my case that would be Vim) and do whatever editing you find suitable. Then after saving, do a reload with Ctrl-R and that's it. On the other hand you mostly really shouldn't need to do that. Therefore there is no need to waste time doing revolutionary development on Zim's code to enable raw editing. Just a key to open an external editor and that's it. Agree. Except opening an external editor can be dangerous because then you have two disconnected editing windows open for the same content, and you can easily loose data when you save at the wrong time in the wrong editor. Better to include a real raw editing *mode* which can also have a keyboard shortcut. It would be a bit more work, but I don't think revolutionary development work will be needed for that. Exactly what I had proposed! Please comment on that RFE mentiond above. Thanks! -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] 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 ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
Am 04.03.2012 11:48, schrieb Dotan Cohen: Then why do you prefer that you can type //some text// to have it italicized in the normal window? What is wrong with Ctrl-I before and after? It is exactly the confusion between raw/source mode and normal mode that hinders Zim from handling arbitrary input. In other words, there already exists shortcuts for headings and formating in Zim, with the Ctrl modifiers just like in any other formatted editor. If one wants to type wiki-syntax directly, then have an easy way to switch to wiki-syntax / raw / source mode. The advantage is that you can write wiki syntax everywhere, not only in zim, and if you are accustomed to that syntax, it's easier to use than having to remember all these Ctrl/Alt-keyboard shortcuts. Ok, Ctrl-I for italics is easy, but what's the shortcut for code again? And how do you enter a bulleted list? I like the idea that my data is stored in a very simple format that can be exported and converted easily, and that is so simple that I can edit it directly. I have tried both wysiwyg tools and tools with a strict separation of edit/view modes in the past, and I had problems with both. Zim appeared to me as a middle ground combining advantages of both approaches. But ok, maybe the problems I experienced with other tools are only based on shortcomings in the software, not in the paradigms themselves. For instance, Evernote is great. But there is no simple way to enter code snippets or shell commands inside a page. I have to manually mark the snippet, select a monospaced font, maybe change the size or color. Similarly, there is no way to mark a level 1 or 2 heading. Again, I have to mark the heading, and change the font size. And then all you have is formatted text, no semantic markup that could be used when exporting to other systems. Maybe this could be solved by Evernote adding simple semantic markup and ways to export that, but they never implement such things because they want to be attractive to the casual user who doesn't care about such things. Likewise, ConnectedText is great. But having to switch between edit and view mode gives me headaches because the text looks completely different in both modes and it's often difficult to find the right location. Maybe this could be solved by automatically mapping the cursor location between modes, but I think switching view modes is still inconvenient in everyday use, I want to have living data that can be easily accessed and altered without switching modes. -- Christoph ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
On Sun, Mar 4, 2012 at 13:07, Christoph Zwerschke c...@online.de wrote: 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*. The idea of entered text should be automatically escaped means that **bold** will not be made bold. Rather, users who want to enter Wiki syntax would do that in source / raw mode. Isn't that what **bold** is (wiki source code)? Why does Source mode exist otherwise? Of course, there would ideally be a keyboard shortcut to easily enable source / raw mode and to switch back to normal mode. To make text bold in normal mode without entering source / raw mode, one has the Ctrl-B shortcut. Maybe a solution would be to allow different modes for pasting text to zim, similar to the different modes for copying text from zim. Right, that would be normal mode and source / raw mode. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
Am 04.03.2012 16:59, schrieb Dotan Cohen: The idea of entered text should be automatically escaped means that **bold** will not be made bold. Rather, users who want to enter Wiki syntax would do that in source / raw mode. Isn't that what **bold** is (wiki source code)? Why does Source mode exist otherwise? Of course, there would ideally be a keyboard shortcut to easily enable source / raw mode and to switch back to normal mode. To make text bold in normal mode without entering source / raw mode, one has the Ctrl-B shortcut. Ok, thanks for the clarification. I think I understand your reasoning much better now :-) Anyway, I still like the idea that I can type in wiki syntax, because I'm doing that in a lot of other places already, e.g. when writing ascii emails or google+ posts or whatever. I also mentioned bullet lists which can be input more easily in wiki syntax. I know my argument is a bit weak because Zim uses DokuWiki syntax which is a bit more obscure than e.g. Markdown which is more universal and follows more closely the way people format ASCII emails etc. anyway e.g. *bold* instead of **bold**. In fact the idea behind Markdown is that it is easy-to-read *and* easy-to-write. The whole idea is that you don't need a different mode or editor when writing text. These articles explain the idea very well: http://hiltmon.com/blog/2012/02/20/the-markdown-mindset/ http://512pixels.net/markdown-new-word51/ Therefore, from my point of view it would make sense to change Zim to be based on Markdown instead of Dokuwiki syntax. I think Markdown is also better supported as source language by Pandoc. But I'm aware that this is a very big change that requires a lot of work. A request for Markdown already exists: https://bugs.launchpad.net/zim/+bug/495898 Concerning your original issue, I guess the best solution would be to add an *option* for disabling/enabling escaping of wiki style input, so everybody can be happy. One issue that needs to be solved before is to implement a way of escaping wiki syntax besides triple quoting. I have mentioned that in your RFE already. Markdown has escape mechanisms, e.g. you can write \*notbold\*, but I think Zim and DokuWiki can't do that yet. -- Christoph ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
On Fri, Mar 2, 2012 at 11:29, Christoph Zwerschke c...@online.de wrote: Am 02.03.2012 08:53, schrieb Dotan Cohen: This bug has a real-life example: https://bugs.launchpad.net/zim/+bug/585300 Dotan, I think the problem is that what you are labeling a data loss issue is no data loss issue at all. In your example, the data is displayed without the **, because these are interpreted as bold. But the ** are still there in the text file, nothing is lost. I see. Although I agree with your assessment that the data could be recovered, it is still lost for Zim users. You and I might be able to open the source file and retrieve the data. I would not expect that of the casual user. That is quite the reason that I think that it is a bit early to promote Zim to the casual user. If you do an ordinary copy of that example snippet, the ** will not be copied, but if you copy as wiki syntax, and paste it into an editor, the ** will be pasted as well. The text is question was copied from a web page in Firefox and pasted into Zim. You can and should also surround such code snippets with triple quotes, then they will be treated as verbatim blocks. And why would casual users know this? How about Python code, which may contain triple quotes? Zim itself is written in Python. This has all been pointed out on the bug tracker, so I don't understand why you're still talking about data loss. Because it affects casual users. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
On Fri, Mar 2, 2012 at 16:17, Adam Porter a...@alphapapa.net wrote: On Wed, Feb 29, 2012 at 13:33, Dotan Cohen dotanco...@gmail.com wrote: However, Zim is a bit unpolished in some key areas and I feel that these paper cuts should be addressed before actively promoting the application. Respectfully, I disagree. I generally support the idea, Release early, release often. Zim is more a project than a product--and being a project, what we need are more interested parties who may contribute in whatever ways they can, including spreading the word. Zim is far beyond the point of being vaporware that needs to have something to show before releasing--it's a great tool right now. :) If is to be promoted as a project in look of parties who may contribute in whatever ways they can, then I agree. If Zim is to be promoted as a product ready for end users, then I disagree. I reiterate that my motivation is constructive criticism. I love and appreciate Zim very much. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
On Fri, Mar 2, 2012 at 17:38, hans...@gmail.com wrote: On Fri, Mar 2, 2012 at 2:53 PM, Dotan Cohen dotanco...@gmail.com wrote: Possibly, and I appreciate your telling me that. I don't see where I have been forceful but I'm sure that you're right. I am certainly no diplomat! It's quite possible to be fully honest and brutal about objective facts, while expressing one's opinions with courtesy and tact, not least by clearly distinguishing between the two domains. Thanks. Would you mind pointing out where I was without courtesy or tact? I agree that my approach could be improved. My own language has much less adjectives and synonyms than English, so I may be using words with negative connotation where words with positive connotation exist but I don't realise the difference. Thank you for identifying that the problem is with my style, and not with my intent. Like Chris, I think you'll find if you look at the original file itself outside of Zim, you'll find that your original content is intact (other than the meta-header) It's just the rendering within Zim that makes it look different. Do let us know if that's not the case. Thank you. I address this in my on-list reply a few minutes ago. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
Am 03.03.2012 18:41, schrieb Dotan Cohen: And why would casual users know this? Well, to be honest I don't think zim is intended for casual users and never will because it is not intended to be a wysiwyg editor. People who want that wysiwyg stlye should use applications like OneNote or Evernote or MyBase or MyInfo or MyNotesKeeper. The special thing about zim is that it knows wiki syntax, and knowing the basics of that syntax is simply required to use it. It's explained very well in the online help. The other special thing about zim is that edit and view mode are not separated. People who want that separation of modes should use applications like ConnectedText or WikidPad or RedNoteBook. The fact that I don't need to switch between edit and view mode is what makes zim so unique, and that paradigm really should be kept. 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. But of course, this paradigm also has some disadvantages like the one you mention. I'm sure a lot can and will be done to attenuate these and make the tool even more usable. But you need to understand that they are somewhat inherent to the edit/view paradigm zim is using. One thing that surely should be added is a way to easily switch the editor to raw mode where it does not do any rendering. It should not be understood or used as the default edit mode, but it may be sometimes useful to see or edit the raw version of a page. I see. Although I agree with your assessment that the data could be recovered, it is still lost for Zim users. You and I might be able to open the source file and retrieve the data. I would not expect that of the casual user. That is quite the reason that I think that it is a bit early to promote Zim to the casual user. See above regarding casual users. A raw editing mode could help, but even that might not be found or understood by a casual user. Just like copying the data with Copy as... - Wiki to get the raw data. How about Python code, which maycontain triple quotes? Zim itself is written in Python. But zim's triple quotes must be on a line for themselves, which rarely happens in Python snippets, and you can always indent your Python snippets to guarantee no triple quotes are at the beginning of a line. Also, Python normally uses triple double quotes for docstrings, not single quotes. So in reality, it's not much of an issue. -- Christoph ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
... The other special thing about zim is that edit and view mode are not separated... The fact that I don't need to switch between edit and view mode is what makes zim so unique, and that paradigm really should be kept. 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. The editor I use in everyday life is Vim (Vi). Here you switch between modes all the time. But you do so without taking your fingers off the keyboard. A similar edit mode in Zim would be no harm so long as one could keep the mouse out of the business. One thing that surely should be added is a way to easily switch the editor to raw mode where it does not do any rendering. It should not be understood or used as the default edit mode, but it may be sometimes useful to see or edit the raw version of a page. That is the point I'd like to support. With one key, and this could be a function key like F2 for example, you could open an external editor in a new window of course on the currently displayed page (im my case that would be Vim) and do whatever editing you find suitable. Then after saving, do a reload with Ctrl-R and that's it. On the other hand you mostly really shouldn't need to do that. Therefore there is no need to waste time doing revolutionary development on Zim's code to enable raw editing. Just a key to open an external editor and that's it. Ulf ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
Am 02.03.2012 08:53, schrieb Dotan Cohen: This bug has a real-life example: https://bugs.launchpad.net/zim/+bug/585300 Dotan, I think the problem is that what you are labeling a data loss issue is no data loss issue at all. In your example, the data is displayed without the **, because these are interpreted as bold. But the ** are still there in the text file, nothing is lost. If you do an ordinary copy of that example snippet, the ** will not be copied, but if you copy as wiki syntax, and paste it into an editor, the ** will be pasted as well. You can and should also surround such code snippets with triple quotes, then they will be treated as verbatim blocks. This has all been pointed out on the bug tracker, so I don't understand why you're still talking about data loss. -- Christoph ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
On Fri, Mar 2, 2012 at 2:53 PM, Dotan Cohen dotanco...@gmail.com wrote: Possibly, and I appreciate your telling me that. I don't see where I have been forceful but I'm sure that you're right. I am certainly no diplomat! It's quite possible to be fully honest and brutal about objective facts, while expressing one's opinions with courtesy and tact, not least by clearly distinguishing between the two domains. This bug has a real-life example: https://bugs.launchpad.net/zim/+bug/585300 Like Chris, I think you'll find if you look at the original file itself outside of Zim, you'll find that your original content is intact (other than the meta-header) It's just the rendering within Zim that makes it look different. Do let us know if that's not the case. ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
On Thu, Mar 1, 2012 at 4:49 PM, Dotan Cohen dotanco...@gmail.com wrote: The dataloss and the fact that Zim cannot handle arbitrary text for input are the reasons why Zim is unsuitable for use. The mislabel icon and reappearing links are reasons why Zim seems only half-baked. One of my many use cases is storing code samples. If this is considered a valid use case then the two primary issues that I mention must be addressed. It is possible that your IMO overly forceful style of expressing your ideas will work against your goals. cannot handle arbitrary text While I'm not storing code in the normal sense at this point, many of my source file trees **are** marked up with other syntaxes, so in those cases I'd prefer to be able to turn off Zim's rendering. However I haven't yet come across any arbitrary **changes** to my data or actual data loss - so far they're just issues visual appearance - could you be more specific about any issues where Zim actually changes your data against your wishes (other than the headers of course)? ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
On Fri, Mar 2, 2012 at 03:29, hans...@gmail.com wrote: On Thu, Mar 1, 2012 at 4:49 PM, Dotan Cohen dotanco...@gmail.com wrote: The dataloss and the fact that Zim cannot handle arbitrary text for input are the reasons why Zim is unsuitable for use. The mislabel icon and reappearing links are reasons why Zim seems only half-baked. One of my many use cases is storing code samples. If this is considered a valid use case then the two primary issues that I mention must be addressed. It is possible that your IMO overly forceful style of expressing your ideas will work against your goals. Possibly, and I appreciate your telling me that. I don't see where I have been forceful but I'm sure that you're right. I am certainly no diplomat! cannot handle arbitrary text While I'm not storing code in the normal sense at this point, many of my source file trees **are** marked up with other syntaxes, so in those cases I'd prefer to be able to turn off Zim's rendering. However I haven't yet come across any arbitrary **changes** to my data or actual data loss - so far they're just issues visual appearance - could you be more specific about any issues where Zim actually changes your data against your wishes (other than the headers of course)? This bug has a real-life example: https://bugs.launchpad.net/zim/+bug/585300 -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
possibilities. So I was wondering that perhaps we can start to collect all users' cases, that is a small description about how you use Zim Wiki in your daily routine. I agree with you. No problem. I can make a description any time. Ulf ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Call for user cases ?
One more issue that I should have mentioned that needs to be addressed as it makes Zim seem as immature software: Links come back after closing Zim https://bugs.launchpad.net/zim/+bug/678250 -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
