From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John Niekrasz" Subject: Re: maximum number of radio targets? Date: Mon, 15 Sep 2008 11:38:44 +0100 Message-ID: References: <4BDC1BAF-3C21-4F70-9D02-A00DCECFF1DB@uva.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KfBTl-0007kd-A4 for emacs-orgmode@gnu.org; Mon, 15 Sep 2008 06:38:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KfBTi-0007jd-SQ for emacs-orgmode@gnu.org; Mon, 15 Sep 2008 06:38:48 -0400 Received: from [199.232.76.173] (port=50836 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KfBTi-0007jU-8M for emacs-orgmode@gnu.org; Mon, 15 Sep 2008 06:38:46 -0400 Received: from mail-gx0-f12.google.com ([209.85.217.12]:47019) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KfBTh-0004Ys-Qw for emacs-orgmode@gnu.org; Mon, 15 Sep 2008 06:38:46 -0400 Received: by gxk5 with SMTP id 5so23267244gxk.18 for ; Mon, 15 Sep 2008 03:38:44 -0700 (PDT) In-Reply-To: <4BDC1BAF-3C21-4F70-9D02-A00DCECFF1DB@uva.nl> Content-Disposition: inline List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: emacs-orgmode@gnu.org Hi Carsten, I'm not an emacs lisp programmer, but I figured out how to evaluate emacs lisp variables at least. If I create a file with a ton of automatically generated numeric radio targets and then evaluate the variable "org-target-link-regexp", I get this message: Error during redisplay: (invalid-regexp Regular expression too big) [28 times] Whereas if I do it with a reasonable amount, I get something reasonable like this: "\\<\\(2999\\|2998\\|2997\\|2996\\|2995\\|2994\\|2993\\|... So it seems to me that emacs has a regular expression length limit, and that this is indeed the cause of the problem. I can also suggest that the slowness you have hypothesized has not occurred for me...at least not up to the regular expression max length, which allows me to have about 2000 5-character radio tags. I'm going to investigate whether the regular expression length can be changed and will report back. John On Sun, Sep 7, 2008 at 4:18 PM, Carsten Dominik wrote: > Hi John, I think you are *clearly* overdoing the radiolink feature. The > problem is that the implementation uses font-lock to activate matches, so > that these are always up to date. This clearly means that the number of > links must be limited. I am not sure what the limitation is in Emacs, but I > would also suspect that, with this many radio targets, you should be feeling > the speed impact with every single character you type - oy you must either > have a *very* fast machine - or be a sloooow typist :-) ? > > With this many links, I guess a different implementation for radio links > would be needed, one that does not use font-lock, but some mechanism that > uses idle time. > > We don't have such a mechanism yet. There are some plans, in particular to > support automatic inter-file links like HOWM does it, by these have not > moved beyond the "wishful thinking" stage. > > This could be a nice extension! Anyone feels challenged to implement it? > > - Carsten > > On Sep 6, 2008, at 6:41 PM, John Niekrasz wrote: > >> Hello org-mode folks, >> >> I really like the radio targets feature. Perhaps too much. I seem to >> have encountered a case where using too many of them means that they >> don't work. We're talking about 2k of them, with an average length of >> 15 characters or so. Is it possible that the orgmode internal regexps >> are getting too long? Is there a general emacs string variable size >> limit I can change to make things work? >> >> I'm using GNU Emacs 23.0.60.4 (i686-pc-linux-gnu, GTK+ Version >> 2.10.13) and orgmode 6.06b. >> >> I've attached a file as an example. The links don't come up on >> loading. But if you erase everything after line 1500 (or alternately >> before line 1500), it works. >> John >> > >