Re: [Zim-wiki] Folder structure

2013-08-20 Thread Jaap Karssenberg
On Mon, Aug 19, 2013 at 8:22 PM, Svenn Are Bjerkem 
svenn.bjer...@googlemail.com wrote:

 The issue about not being able to have attachments with .txt has been
 discussed in a thread some time back. Using .txt for magic purposes in Zim
 has negative side effects. To my knowledge, all files named .txt are
 captured by Zim for page use. The same problem was encountered by Asciidoc.
 They used .txt as standard suffix, but it seems like things like github
 forced the use of .asciidoc in order to know what to do with the file. I
 think the same is kind of valid for Zim. In my opinion, Zim-formatted pages
 should have .zimwiki or .zimdoc or .zimtxt suffix to make them explicitly
 belonging to zim.

 I have issues with naming attachment directories AA-attachment as this
 prevent the possibility to put a zim notebook on top of an already existing
 directory structure. But this feature is crippled as soon as zim finds a
 .txt file not being an actual zim .txt, so I cannot currently use it that
 way. Redefining the zim suffix would help here.

 I once put some effort into changing zim to use .zimwiki instead of .zim,
 but the structure I wanted to zimify had to be restructured a bit anyway,
 so I started from scratch on the structure and skipped the patching, as I
 expected this to be a local change I had to rewind on every update of zim.



I think the folder structure and the suffix solve two different issues.

The folder structure changes puts the actual page in the same folder as
it's attachments and sub-pages. Rationale is to have all in one view when
you look with the file browser.

The suffix, or the -attachments folders solve a problem for indexing.
This is a problem I will solve differently when refactoring the index. The
idea is that zim will inspect the content of text files to determine
whether or not it are pages. I don't mind allowing alternative suffix as
well if that makes interoperability easier, but for default will stick to
.txt.

As I understand it, this discussion started out with the first issue.
Second issue requires different solutions.

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] I registered an IRC channel on FreeNode for Zim

2013-08-20 Thread Jaap Karssenberg
On Tue, Aug 20, 2013 at 3:19 AM, Brendan Kidwell sn...@glump.net wrote:

 In the last few months I've become one of those people who hangs out on a
 handful of IRC channels during most of the work day, using a remote client
 connected to a core IRC gateway (Quassel IRC) that keeps me always online
 on the various IRC networks I use.

 I took the initiative to create a channel #zim-wiki for Zim support and
 other Zim-related conversations. We will follow the How to be a Good
 Catalyst document ( http://freenode.net/catalysts.shtml ) and Channel
 Guidelines ( http://freenode.net/channel_guidelines.shtml ) and generally
 try to make sure that anyone who shows up plays nice, just the same as on
 this mailing list.

 Jaap: Would you endorse this channel and list it on http://zim-wiki.orgon the 
 appropriate page? (If not, I'll change the name to ##zim-wiki to
 indicate that it's unofficial.)

 All: Do you think YOU could be a good op (moderator) and want to be one,
 in addition to myself?

 If you don't know what all this is, read the docs (
 https://www.freenode.net/using_the_network.shtml ), log on to FreeNode,
 and join the channel #zim-wiki.


Afraid I won't be able to join this channel. I can not justify having more
distractions during my working day. In the evening time spent behind a
computer is scarce lately and when I do, I want to focus on the tasks at
hand.

If there are others that want to pick it up and maintain such a channel I
have no problem to list it on the website.

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] Folder structure

2013-08-20 Thread Klaus-Dieter Bauer
2013/8/20 Jaap Karssenberg jaap.karssenb...@gmail.com:
 [...]

 The suffix, or the -attachments folders solve a problem for indexing. This
 is a problem I will solve differently when refactoring the index. The idea
 is that zim will inspect the content of text files to determine whether or
 not it are pages. I don't mind allowing alternative suffix as well if that
 makes interoperability easier, but for default will stick to .txt.

 [...]

 Regards,

 Jaap

Just a quick list of issues that are raised by the ambigous file
extension and would require major (probably OS-dependent) pains to fix
without changing the extension:

  + No distinction from plain text files by icon (inconvenient e.g.
when viewing results of desktop search).
  + No double-click-to-open in file browsers / search results without
breaking the behaviour for non-zim .txt files.
  + ZIM must check .txt files for ZIM page format,
  - when indexing
  - when listing attachments
  - ... ?
  + When processing notebooks through an interactive shell,
distinguishing normal text files from zim page files is unviable
and inconvenient when processing them with shell scripts.

Is there some reason, why you want to keep the .txt extension? I
can't see much of an advantage.

  - Klaus

___
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] File extension (was: Folder structure)

2013-08-20 Thread Jaap Karssenberg
On Tue, Aug 20, 2013 at 11:29 AM, Klaus-Dieter Bauer 
bauer.klaus.die...@gmail.com wrote:

 2013/8/20 Jaap Karssenberg jaap.karssenb...@gmail.com:
  [...]
 
  The suffix, or the -attachments folders solve a problem for indexing.
 This
  is a problem I will solve differently when refactoring the index. The
 idea
  is that zim will inspect the content of text files to determine whether
 or
  not it are pages. I don't mind allowing alternative suffix as well if
 that
  makes interoperability easier, but for default will stick to .txt.
 
  [...]
 
  Regards,
 
  Jaap

 Just a quick list of issues that are raised by the ambigous file
 extension and would require major (probably OS-dependent) pains to fix
 without changing the extension:

   + No distinction from plain text files by icon (inconvenient e.g.
 when viewing results of desktop search).
   + No double-click-to-open in file browsers / search results without
 breaking the behaviour for non-zim .txt files.
   + ZIM must check .txt files for ZIM page format,
   - when indexing
   - when listing attachments
   - ... ?
   + When processing notebooks through an interactive shell,
 distinguishing normal text files from zim page files is unviable
 and inconvenient when processing them with shell scripts.

 Is there some reason, why you want to keep the .txt extension? I
 can't see much of an advantage.


I'm sorry to be a bit blunt, but the point in the previous mail was not to
hijack the previous topic with this discussion - so see my changed topic
line for this mail.

The topic on the file extension has been discussed several times on this
list. I do not deny that there are issues with the current format, but I
have not yet seen a workable solution that I could apply without much work
on my side.

In short, when you change the extension you will still need to support
existing notebooks with .txt files. This means you have still have to solve
detection of txt files in zim + you need to deal with multiple extensions.
How do you deal with conflicts where there are two pages with the same
name but different file extension - which one is the real page ?

I do have thinks on my roadmap to put things in place to ready the way to
allow multiple extensions. Ones we can support multiple, we can support
switching.

Admitted, this is a slow process, especially as I have not been able to do
much coding in the last few months. If you want it faster, please help out
with implementing an upgrade path for existing notebooks.

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] I finally found an easy solution to sync my zim notebook across computers

2013-08-20 Thread Svenn Are Bjerkem
On 20 August 2013 05:30, Brendan Kidwell sn...@glump.net wrote:

 Keep an eye on https://prism-break.org/ for answers to questions like
 this for networking and storage needs. The site lists some FOSS-only
 live/online file sync tools; it looks like they all require a central
 coordination server (one that you control or one that you rent capacity
 on), or optionally more than one server for fault tolerance.

 If you can provide a central point of contact upon which to run the sync
 software you choose, something like ownCloud or SparkleShare should do the
 trick for you.


I switched to seafile earlier this year, and I am so far very satisfied
with its syncing abilities.

-- 
Svenn
___
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] I finally found an easy solution to sync my zim notebook across computers

2013-08-20 Thread Charles Medcoff
➢ I wonder if their is anything else available for peer-to-peer sync'ing - 
apart from SFTP and SSH?

Why not use the built in support for version control?  I'm using Bazzar with an 
SVN backend.


___
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] I finally found an easy solution to sync my zim notebook across computers

2013-08-20 Thread Svenn Are Bjerkem
On 20 August 2013 20:47, Charles Medcoff cmedc...@hotmail.com wrote:

 ➢ I wonder if their is anything else available for peer-to-peer sync'ing -
 apart from SFTP and SSH?

 Why not use the built in support for version control?  I'm using Bazzar
 with an SVN backend.


seafile can be configured to delete changes older than a specified number
of days and by this keep the overhead on the server down.

-- 
Svenn
___
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