How to Start Using Xiki in Emacs

Setup a personal wiki in Emacs Org-mode

Having only one note file is, in my opinion, more flexible and compatible. It tends, however, to get slow for even moderatly sized files. Multiple small files are quick, but they need more effort to set up, and they only work within that setup.

Single File Solution

To speed things up, consider setting org-startup-with-latex-preview to nil (or add #+STARTUP: nolatexpreview to your file).

Tags not only get messy when used for keywords, using them also gets rather slow as your file grows. I've played around with some custom functions, but now avoid tags most of the time. Instead I use flat hierarchies, categories and otherwise rely on occur and org-occur (e.g. M-x org-occur begin_proof).

Multiple Files

The org syntax for linking to other files is rather simple: [[./this idea.org][this idea]]. If that is too much hassle, it should be easy to write a function that replaces the active region with an appropriate link.

If you want to link [[this idea]] to a file "this idea.org", you could add a function to org-open-at-point-functions and handle it yourself.

As for tags, you don't tag a file itself, but rather a single top level headline. This of course means that all your troubles with tags a back as well.
Again, I would recommend not using tags. Just make sure the file contains the right keywords at the right places and use occur and friends.

Edit: An Example `org-open-at-point-function'

If you want to search for a fuzzy link in all files in a directory instead of only the current buffer, you can do this by using the org-open-at-point-functions hook. Here is an example:

(defvar my-link-search-directory "/my/notes/directory/")

(defun my-open-link-function ()
  "Open link, interpreting it a the name of a headline."
  (let* ((el (org-element-context))
         (type (first el))
         (link-type (plist-get (cadr el) :type))
         (path (let ((path-1 (plist-get (cadr el) :path)))
                 (when (stringp path-1)
                   (org-link-unescape path-1)))))
    (when (and (eql type 'link)
               path
               (string= link-type "fuzzy"))
      (let* ((path (regexp-quote path))
             (result
                 (delq nil
                       (org-map-entries
                        (lambda ()
                          (when (string-match
                                 path
                                 (org-get-heading))
                            (list (buffer-file-name) (point))))
                        nil
                        ;; Here we set the scope.
                        ;; 'agenda would search in all agenda files.
                        ;; We want a list of all org files in `my-link-search-directory'.
                        (directory-files
                         my-link-search-directory
                         t "[.]org\\'")))))
        (when result
          (when (> (length result) 1)
            (message "Warning: multiple search results for %s" path))
          (let ((file (caar result))
                (pos (cadar result)))
            (find-file file)
            (goto-char pos)))))))

(add-hook 
 'org-open-at-point-functions
 'my-open-link-function)

Note that I haven't tested this much.

Actually, I would recommend against using this unless you really need it. While making fancy extensions is tempting, keeping your notes as simple as possible is preferably. If you have everything in one file, you could edit your notes with notepad or google docs or whatever, should you ever need to.

edit github wikis with emacs like confluence-mode?

Considering a GitHub wiki is simply a git repo, you can clone it locally, modify it, make new commits and push back.

See "How do I clone a github wiki?".

With a package like magit, you can do all that from your Emacs (see magit documentation).

For instance, once the commits are done:

Typing P P will only push the current branch to the remote. In other words, it will run git push <remote> <branch>.

What's in your .emacs?

Use the ultimate dotfiles site. Add your '.emacs' here. Read the '.emacs' of others.

What do you expect from a package manager for Emacs?

Automatic publishing from version control

I'd love to see a standard, central, and single Emacs package manager. Right now, I'd put my money on ELPA, but there is still a long way to go.

The biggest thing that would help an Emacs package manager would be to make it super trivial to publish packages. In my opinion, I'd like to see this happen in combination with a version control system like git on a central hosted platform like GitHub -- something that would make it easy for authors to publish their packages and would make it easy for others to contribute back.

Similar to how GitHub (used to) make it easy to publish RubyGems, I'd like to see something similar in an Emacs package manager. For example, tag your repository with "vX.Y.Z" and have your elisp goodness automatically available to all.

The added benefit of using a popular backend like GitHub is that you'd immediately get a lot of exposure which should help drive its success.

How to effectively use the self-documenting system of Emacs?

You are better off with Google until you know the terminology and maybe even after that. I've used the emacs documentation system a lot, but mainly for looking up something which I already knew about, or something for which I already knew the exact terminology.

If you are unsure how to search for something in the documentation then Google is much more effective, because it also takes synoyms into account and it finds questions similar to yours from forums and stuff. It does not only apply to Emacs, but to any other software as well. Regardless of the software I always try a Google search first, because in most cases Google throws out the answer much more quickly than browsing the documentation,

---

Related Topics