Re: [Zim-wiki] Evernote/Footnote-like UI change?
> On Wed, 25 Jan 2012 14:34:16 +0100 > Jaap Karssenberg wrote: > > * How many levels of sub-headings do you typically use ? 3 to 4 > * How many levels of sub-pages do you typically use ? 4 to many (?). > * On what level would you want to split it up for export ? don't want. > * Do you have a strong use-case for having both sub-pages and > headings ? Sub pages serve me either as TOC, either as Part (I, II, III, etc.) Headings serve me as page section, sub-sec, subsub-sec, paragraph. That's great to have both, and the style.conf is a threat to customize the headings. I don't follow this discussion, but why is Evernote even mentioned on the list of a desktop wiki for Linux? For me, this is as much garbage for spoiled tablet kids, as M$ OneNote is to fatties in cubicles. I get sick just browsing their web page, but it could be only me? -- nomnex Freenode: nomnex Registered Linux user #505281. Be counted at: http://linuxcounter.net ___ 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] Metadata; Pandoc <=> Zim (Was: Link friendly Markdown editor?)
It seems possible that there are communications problems caused by the fact that I'm cross-posting to both lists, so it might be best for anyone with more specific questions or comments to continue the conversation by posting directly. FYR again here are the links to the relevant threads: https://groups.google.com/forum/#!topic/pandoc-discuss/B0rIgV_CKto/discussion https://groups.google.com/forum/#!topic/pandoc-discuss/ASTjSB_4gnM/discussion On Wednesday, January 25, 2012 9:41:49 PM UTC+7, HansBKK wrote: > > > On Wed, Jan 25, 2012 at 5:29 PM, Jaap Karssenberg wrote: > >> >> meta-data header >> Consider this a zim specific wrapper around the actual content of the >> page. Just using email headers (rfc 822) with a few custom fields. Other >> media could use different wrapper to communicate the same meta-data. >> > > Exactly - I was simply pointing out that to the extent this > meta-information is useful and similarly supported in one or more of the > target output formats, it should be converted along with the content - for > example, I believe EPUB has something similar. . .. > > >> Quick question - I was told before that markdown+extensions is the >> preferred format for pandoc. But now it sounds like you consider reST the >> default format. Which of the two should we focus on? >> > > Back to my question why we are talking about reST/Spinx, and not Markdow >> with pandoc extensions. >> > > It turns out now there are actually three choices for your "entry point" > syntax into Pandoc 8-) > > - markdown + extensions > - a subset of standard reST (all the relevant bits) > - json syntax > > John recommended reST based on the fact that Zim's a Python project. > Pandoc supports all the reST features with corresponding markdown+ > elements, and I'm confident that support would expand if needed in the > future (more on that below). > > I'm sure if you'd prefer markdown+ that would also work perfectly well, > but note that reST is more of an "open standard" supported by the huge > Python dev-docs community, while Pandoc's extensions are specific to Pandoc. > > I personally know very little about json (not being a programmer), but > apparently that would most reliably represent the internal/native pandoc > data structures; however its syntax isn't documented, so would require a > fair bit of experimentation with pandocs itself. > > My long term goal is for zim to support multiple syntaxes to store it's >> data. Markdown is on my list for that feature, looks like I'll need >> extensions like the ones in pandoc to make all zim features work. >> > > Note that however you get the data structured properly for Pandoc, you get > "for free" not only markdown/reST, but: > > - HTML, textile/LaTeX (hence PDF), ConTeXt, S5, DocBook XML, > OpenDocumentXML, ODT, RTF, MediaWiki, Emacs org-mode, EPUB > > and many more as well. The only reason Pandoc has added its own extensions > is to allow for features supported by these other target output formats but > not by the core markdown syntax, like: > > - inline LaTeX math, tables, definition lists, superscripts and > subscripts, smart quotes and dashes, and footnotes. > > I'm starting to feel like the amazing Ginsu knife salesman here - but > wait! there's more! 8-) > >> >> My understanding is that I can generate markdown with extension and call >> pandoc to convert it to any of the formats supported by pandoc. This means >> some coding for me, but does not require any change in pandoc, correct ? >> > > Correct. > > My (at this stage somewhat premature) point was that if you choose to > follow John's primary recommendation - to output standard reST/Sphinx path > rather than markdown+pandoc-specific-extensions, you now also have the > ability to use the standard Python docutils+Sphinx conversion tools for say > HTML and PDF (usually via LaTeX). > > You may find that some Zim features (current or future) such as > hierarchical table of contents, cross-reference links, glossary terms, > topic-tagging and end-matter indexes, citation/biblio references could make > use - within that context - of some of the Sphinx extensions to reST that > aren't supported by Pandoc. > > From Zim's point of view, that's not an issue, you're not dependent on > Pandoc. However, from what I've seen of the rapid dev cycle around here, I > reckon it's very likely that John would in fact quickly enhance Pandoc's > support of the rest/Sphinx syntax - I'm no coder, but I've been frankly > amazed at the speed he's turned around what seem to me to be pretty > non-trivial feature requests posted to the pandoc list. > > However this is more work then just export, because I need both export >> and import, and make sure all data from import is preserved in the internal >> model such that export reconstructs the import. >> > > AFAICT you won't need to do your own import - just let Pandoc handle the > many-to-many complexity, including the changes constantly coming in various > output formats - you only need
Re: [Zim-wiki] Zim (personal desktop wiki) looking to possibly support "pandoc syntax"
On Wed, Jan 25, 2012 at 5:29 PM, Jaap Karssenberg wrote: > >> meta-data header > Consider this a zim specific wrapper around the actual content of the > page. Just using email headers (rfc 822) with a few custom fields. Other > media could use different wrapper to communicate the same meta-data. > Exactly - I was simply pointing out that to the extent this meta-information is useful and similarly supported in one or more of the target output formats, it should be converted along with the content - for example, I believe EPUB has something similar. . .. > Quick question - I was told before that markdown+extensions is the > preferred format for pandoc. But now it sounds like you consider reST the > default format. Which of the two should we focus on? > Back to my question why we are talking about reST/Spinx, and not Markdow > with pandoc extensions. > It turns out now there are actually three choices for your "entry point" syntax into Pandoc 8-) - markdown + extensions - a subset of standard reST (all the relevant bits) - json syntax John recommended reST based on the fact that Zim's a Python project. Pandoc supports all the reST features with corresponding markdown+ elements, and I'm confident that support would expand if needed in the future (more on that below). I'm sure if you'd prefer markdown+ that would also work perfectly well, but note that reST is more of an "open standard" supported by the huge Python dev-docs community, while Pandoc's extensions are specific to Pandoc. I personally know very little about json (not being a programmer), but apparently that would most reliably represent the internal/native pandoc data structures; however its syntax isn't documented, so would require a fair bit of experimentation with pandocs itself. My long term goal is for zim to support multiple syntaxes to store it's > data. Markdown is on my list for that feature, looks like I'll need > extensions like the ones in pandoc to make all zim features work. > Note that however you get the data structured properly for Pandoc, you get "for free" not only markdown/reST, but: - HTML, textile/LaTeX (hence PDF), ConTeXt, S5, DocBook XML, OpenDocumentXML, ODT, RTF, MediaWiki, Emacs org-mode, EPUB and many more as well. The only reason Pandoc has added its own extensions is to allow for features supported by these other target output formats but not by the core markdown syntax, like: - inline LaTeX math, tables, definition lists, superscripts and subscripts, smart quotes and dashes, and footnotes. I'm starting to feel like the amazing Ginsu knife salesman here - but wait! there's more! 8-) > > My understanding is that I can generate markdown with extension and call > pandoc to convert it to any of the formats supported by pandoc. This means > some coding for me, but does not require any change in pandoc, correct ? > Correct. My (at this stage somewhat premature) point was that if you choose to follow John's primary recommendation - to output standard reST/Sphinx path rather than markdown+pandoc-specific-extensions, you now also have the ability to use the standard Python docutils+Sphinx conversion tools for say HTML and PDF (usually via LaTeX). You may find that some Zim features (current or future) such as hierarchical table of contents, cross-reference links, glossary terms, topic-tagging and end-matter indexes, citation/biblio references could make use - within that context - of some of the Sphinx extensions to reST that aren't supported by Pandoc. >From Zim's point of view, that's not an issue, you're not dependent on Pandoc. However, from what I've seen of the rapid dev cycle around here, I reckon it's very likely that John would in fact quickly enhance Pandoc's support of the rest/Sphinx syntax - I'm no coder, but I've been frankly amazed at the speed he's turned around what seem to me to be pretty non-trivial feature requests posted to the pandoc list. However this is more work then just export, because I need both export and > import, and make sure all data from import is preserved in the internal > model such that export reconstructs the import. > AFAICT you won't need to do your own import - just let Pandoc handle the many-to-many complexity, including the changes constantly coming in various output formats - you only need to track the one "entry point" syntax. And by selecting reST/Sphinx as that syntax, you've still got the few biggest mainstream output formats directly supported by the Python doc/devs even if Pandocs were to disappear. Seems like a slam-dunk to me 8-) PS once again emphasizing that I'm a total noob to both projects, so to the extent any of the above contains errors I hope those more knowledgeable than me will jump in - obviously any comments welcome from anyone. ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net
Re: [Zim-wiki] Evernote/Footnote-like UI change?
Hi, here you are my answers. >> * How many levels of sub-headings do you typically use ? I use a maximum of 3 levels for headings. >> * How many levels of sub-pages do you typically use ? The structure of my current main notebook is: PERSONAL -Projects --Project1 --Project2 --etc. PROFESSIONAL -Projects (same as above) REFERENCE --Reference1 --Reference2 --etc. Depending on the project, I may have 2 o 3 additional sub-page levels. >> * On what level would you want to split it up for export ? The current HTML export works fine for me. >> * Do you have a strong use-case for having both sub-pages and headings ? Not sure I understand the question correctly. If you have a notebook with bibliographical references, you might have a main page for each author with the corresponding Titles as subheadings, while each subheading is also a subpage (where you put further info for each book). Just an idea. Kind regards Marco > > On 01/25/2012 02:34 PM, Jaap Karssenberg wrote: >> >> All, >> >> Related to this discussion I have a question to get some feedback on >> how people use their notebook. >> >> Reason is that with this kind of interface the difference between >> sub-pages and sub-headings starts to blur. Maybe this is a good thing >> and we should avoid headings anyway - just make everything a page and >> show them inline as sub-sections. But maybe there is a good reason to >> keep some distinction for various use cases. Point being is that both >> sub-headings and sub-pages are part of the same hierarchy, and the >> difference now is based on what you can see in a single screen. But if >> we show sub-pages in the same screen, that starts to be much less of a >> difference. >> >> In addition when I think about HTML export, now the sub-page division >> determines what HTML pages you get. There is a request to allow >> exporting the whole notebook to a single HTML file. But maybe a more >> sophisticated way to handle this is to say that you want to export a >> whole notebook and create an single HTML page for each toplevel page >> that includes all sub pages, or for each level 2 page (so make the >> cut-off depth an user input). >> >> So my questions are: >> * How many levels of sub-headings do you typically use ? >> * How many levels of sub-pages do you typically use ? >> * On what level would you want to split it up for export ? >> * Do you have a strong use-case for having both sub-pages and headings ? >> >> Thanks, >> >> Jaap >> >> ___ >> 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 >> > > > -- > *** > * Frank Van Geirt * > * fvange...@gmail.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 ___ 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] Evernote/Footnote-like UI change?
Hello, Sub-headings I only use the first heading for the title of the page, as standard. When I want to identify sections/paragraphs on a page, I just use a strong text format. For me that's enough. Sub-pages Often about 3 levels deep, but I found examples where I go to 6-7 levels deep. This is very important for me. I prefer extra smaller sub-pages above a big page with sections and headings. I also need to easily re-arrange pages and sub-pages. Export I rarely use export, but I would go for next options: complete notebook, single page, page with all its sub-pages. I have no strong use-case for using both sub-headings and sub-pages. Regards, Frank On 01/25/2012 02:34 PM, Jaap Karssenberg wrote: All, Related to this discussion I have a question to get some feedback on how people use their notebook. Reason is that with this kind of interface the difference between sub-pages and sub-headings starts to blur. Maybe this is a good thing and we should avoid headings anyway - just make everything a page and show them inline as sub-sections. But maybe there is a good reason to keep some distinction for various use cases. Point being is that both sub-headings and sub-pages are part of the same hierarchy, and the difference now is based on what you can see in a single screen. But if we show sub-pages in the same screen, that starts to be much less of a difference. In addition when I think about HTML export, now the sub-page division determines what HTML pages you get. There is a request to allow exporting the whole notebook to a single HTML file. But maybe a more sophisticated way to handle this is to say that you want to export a whole notebook and create an single HTML page for each toplevel page that includes all sub pages, or for each level 2 page (so make the cut-off depth an user input). So my questions are: * How many levels of sub-headings do you typically use ? * How many levels of sub-pages do you typically use ? * On what level would you want to split it up for export ? * Do you have a strong use-case for having both sub-pages and headings ? Thanks, Jaap ___ 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 -- *** * Frank Van Geirt * * fvange...@gmail.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] Evernote/Footnote-like UI change?
All, Related to this discussion I have a question to get some feedback on how people use their notebook. Reason is that with this kind of interface the difference between sub-pages and sub-headings starts to blur. Maybe this is a good thing and we should avoid headings anyway - just make everything a page and show them inline as sub-sections. But maybe there is a good reason to keep some distinction for various use cases. Point being is that both sub-headings and sub-pages are part of the same hierarchy, and the difference now is based on what you can see in a single screen. But if we show sub-pages in the same screen, that starts to be much less of a difference. In addition when I think about HTML export, now the sub-page division determines what HTML pages you get. There is a request to allow exporting the whole notebook to a single HTML file. But maybe a more sophisticated way to handle this is to say that you want to export a whole notebook and create an single HTML page for each toplevel page that includes all sub pages, or for each level 2 page (so make the cut-off depth an user input). So my questions are: * How many levels of sub-headings do you typically use ? * How many levels of sub-pages do you typically use ? * On what level would you want to split it up for export ? * Do you have a strong use-case for having both sub-pages and headings ? Thanks, Jaap ___ 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] Metadata; Pandoc <=> Zim (Was: Link friendly Markdown editor?)
Resending because mailing list bounced first message On Wed, Jan 25, 2012 at 7:46 AM, HansBKK wrote: > On Wednesday, January 25, 2012 3:40:30 AM UTC+7, Joseph Reagle wrote: >> I'll also note that Zim uses a meta-data header (see below) and, as John >> knows all too well, the markup community can't really come to consensus on >> how to support this widely. >> >> ~~~ >> Content-Type: text/x-zim-wiki >> Wiki-Format: zim 0.4 >> Creation-Date: 2011-03-16T16:08:32-04:00 Consider this a zim specific wrapper around the actual content of the page. Just using email headers (rfc 822) with a few custom fields. Other media could use different wrapper to communicate the same meta-data. > Where would Jaap go to see how this data could be usefully transformed, for > example if reST is the target output? Quick question - I was told before that markdown+extensions is the preferred format for pandoc. But now it sounds like you consider reST the default format. Which of the two should we focus on? >> 1. Zim will continue using it's format, but perhaps come up with a plugin >> to export to markdown and ... >> 2. then execute pandoc (as an external utility) for other format >> conversions. > > Something like this is Jaap's current intention as I understand it. Yes, adding an export format is easy, because I only need to transform my data to a specific output. >> In my perfect world: >> >> 1. Zim would use a subset of pandoc markdown as it's native format. (With >> the subset being as large as possible :) .) >> 2. Pandoc and Zim could agree on a a meta-data format. >> 3. Pandoc and Zim import/export nicely amongst each other. My long term goal is for zim to support multiple syntaxes to store it's data. Markdown is on my list for that feature, looks like I'll need extensions like the ones in pandoc to make all zim features work. However this is more work then just export, because I need both export and import, and make sure all data from import is preserved in the internal model such that export reconstructs the import. > Here are my tweaks to the above "ideal" scenario, with the proviso that I > have a very limited understanding of all this, just thinking out loud ... 8< ... Let me worry about preferences etc. later - first need to sort out syntax requirements. > - starting out by limiting to the subset of reST supported by Pandoc > - a canonical listing would be useful here > > - eventually that could possibly evolve to broader (as full as possible) > support for the Sphinx extensions > - so that Zim could alternatively develop a direct "full" site-/book- > level export/generate facility > > Ideally, to the extent possible/appropriate Pandoc will be able to continue > to accept this as input, in order to facilitate output to targets not > supported by Sphinx directly. > > To the extent this is not the case, then the export/conversion tool would in > the meantime need to accept an option to select either full-reST/Sphinx > syntax export or the Pandoc-specific reST subset. Back to my question why we are no talking about reST/Spinx, and not Markdow with pandoc extensions. My understanding is that I can generate markdown with extension and call pandoc to convert it to any of the formats supported by pandoc. This means some coding for me, but does not require any change in pandoc, correct ? Regards, Jaap ___ 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] Metadata; Pandoc <=> Zim (Was: Link friendly Markdown editor?)
On Wed, Jan 25, 2012 at 7:46 AM, HansBKK wrote: > On Wednesday, January 25, 2012 3:40:30 AM UTC+7, Joseph Reagle wrote: >> I'll also note that Zim uses a meta-data header (see below) and, as John >> knows all too well, the markup community can't really come to consensus on >> how to support this widely. >> >> ~~~ >> Content-Type: text/x-zim-wiki >> Wiki-Format: zim 0.4 >> Creation-Date: 2011-03-16T16:08:32-04:00 Consider this a zim specific wrapper around the actual content of the page. Just using email headers (rfc 822) with a few custom fields. Other media could use different wrapper to communicate the same meta-data. > Where would Jaap go to see how this data could be usefully transformed, for > example if reST is the target output? Quick question - I was told before that markdown+extensions is the preferred format for pandoc. But now it sounds like you consider reST the default format. Which of the two should we focus on? >> 1. Zim will continue using it's format, but perhaps come up with a plugin >> to export to markdown and ... >> 2. then execute pandoc (as an external utility) for other format >> conversions. > > Something like this is Jaap's current intention as I understand it. Yes, adding an export format is easy, because I only need to transform my data to a specific output. >> In my perfect world: >> >> 1. Zim would use a subset of pandoc markdown as it's native format. (With >> the subset being as large as possible :) .) >> 2. Pandoc and Zim could agree on a a meta-data format. >> 3. Pandoc and Zim import/export nicely amongst each other. My long term goal is for zim to support multiple syntaxes to store it's data. Markdown is on my list for that feature, looks like I'll need extensions like the ones in pandoc to make all zim features work. However this is more work then just export, because I need both export and import, and make sure all data from import is preserved in the internal model such that export reconstructs the import. > Here are my tweaks to the above "ideal" scenario, with the proviso that I > have a very limited understanding of all this, just thinking out loud > ... 8< ... Let me worry about preferences etc. later - first need to sort out syntax requirements. > - starting out by limiting to the subset of reST supported by Pandoc > - a canonical listing would be useful here > > - eventually that could possibly evolve to broader (as full as possible) > support for the Sphinx extensions > - so that Zim could alternatively develop a direct "full" site-/book- > level export/generate facility > > Ideally, to the extent possible/appropriate Pandoc will be able to continue > to accept this as input, in order to facilitate output to targets not > supported by Sphinx directly. > > To the extent this is not the case, then the export/conversion tool would in > the meantime need to accept an option to select either full-reST/Sphinx > syntax export or the Pandoc-specific reST subset. Back to my question why we are no talking about reST/Spinx, and not Markdow with pandoc extensions. My understanding is that I can generate markdown with extension and call pandoc to convert it to any of the formats supported by pandoc. This means some coding for me, but does not require any change in pandoc, correct ? Regards, Jaap ___ 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
