From mboxrd@z Thu Jan 1 00:00:00 1970 From: tsd@tsdye.com (Thomas S. Dye) Subject: Re: Using org-mode for Research and Notetaking Date: Thu, 14 Jul 2011 08:59:47 -1000 Message-ID: References: <81d3hi75oj.fsf@gmail.com> <818vs674t7.fsf@gmail.com> <87liw582jg.fsf@gnu.org> <87zkkktwwk.fsf_-_@sophokles.streitblatt.de> <87bowy4l0j.fsf@gnu.org> <87hb6oso2y.fsf@sophokles.streitblatt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([140.186.70.92]:37095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhR8h-0000fu-At for emacs-orgmode@gnu.org; Thu, 14 Jul 2011 15:00:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QhR8c-0006kV-S9 for emacs-orgmode@gnu.org; Thu, 14 Jul 2011 14:59:59 -0400 Received: from oproxy3-pub.bluehost.com ([69.89.21.8]:49002) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QhR8c-0006kR-IU for emacs-orgmode@gnu.org; Thu, 14 Jul 2011 14:59:54 -0400 In-Reply-To: <87hb6oso2y.fsf@sophokles.streitblatt.de> (Florian Beck's message of "Thu, 14 Jul 2011 20:40:21 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Florian Beck Cc: Bastien , emacs-orgmode@gnu.org Florian Beck writes: > Bastien writes: > >>> 2. Tags are SLOW (no doubt due to my 8.5M file). Completion takes >>> minutes. I fixed that by adding all my (hundreds of) tags to >>> `org-tag-alist' and restricting capture to =C2=BB%g=C2=AB, checking on= ly the >>> current file. `org-id-find' is slow as well and so will be property >>> completions, I guess. How about caching the data and update on saving >>> an org-agenda file? >> >> We might consider this.=20=20 >> >> I doubt updating on saving is the right thing to do -- people tend to >> save very often, and for solving problems like yours, it will be as slow >> as the current interface. >> >> We need to be more clever in defining the update cycle for caches, and >> this depends on _what_ the cache is containing. > > I agree, updating on saving would not work for large files. Maybe you > could use a cache on a per file basis, creating it when org first > happens to collect the data and updating it on demand. Of course, it > might be out of date, which in my case would be no problem. > >> You will need to live with it for now. >> >>> 4. muse-mode has this nice feature that it easily allows you to define >>> your own like >>> =E2=80=A6 = or >>> =E2=80=A6; not only for expo= rt but also for >>> fontification. Can I do something similar in org-mode? >> >> What do you mean? >> >> What I can think of are "tag aliases": for example, the tag ":code:" >> would be an alias for ":code python lisp:". >> >> The buffer would display the alias. >> >> Tag search would match the expanded version. >> >> This adds a semantic layer for tags, so maybe there are complexities >> I cannot think of right now, but I think it might be interesting. >> >> What do you think? > > Actually, I meant =C2=BBtags=C2=AB in the HTML sense. For example<= /boxed> > would call a function during export, which returns, say, its LaTeX > interpretation, another function would be called by font lock (or > whatever you use) to determine its on screen display. That is, the user > has to provide two functions and org mode has to call them at the > appropriate place. Aloha Florian, This is partially implemented with Org-mode's link syntax. See http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-3 for an example that defines LaTeX and HTML exports for arbitrary tags. AFAIK, the link syntax lacks an easy way to change the function for screen display, but this would be a useful addition to Org-mode. Then, it would be a relatively simple matter to provide functions that differentiate on-screen between links used for different purposes. There was a discussion along these lines on list some time ago under the heading "text color + highlight". hth, Tom > >> >>> 5. According to the manual =C2=BBTODO items are an integral part of the >>> notes file=C2=AB. I like that, but I do not find it so. TODO items are >>> headings which I find somewhat confusing: My files are either articles >>> to be (with the appropriate headlines) or notes where headlines usually >>> formulate the topic the note is about. Todo items, on the other hand, >>> would be =C2=BBclarify the paragraph=C2=AB, =C2=BBcheck what X says ab= out Y=C2=AB, =C2=BBadd >>> more sources=C2=AB, etc. As it is TODOs are not integrated but stand o= ut, >>> breaking the structure of the file. How about allowing TODO items in >>> comments? This would seem much more natural to me: a TODO item should >>> not be part of your text but disappear when it is done. >> >> As suggested, you want to check inline tasks. > > I'll look into it. Thanks for your comments! > >> >> I really don't like the current syntax for inline tasks, I would much >> prefer something like special TODO keywords: >> >> * !TODO This would be an inline task, not a headline >> >> But perhaps I'm missing something about why the current inline task >> syntax is useful. I'd be interested in hearing more by people who are >> actually using them... >> >> Thanks for your input! --=20 Thomas S. Dye http://www.tsdye.com