GNU bug report logs - #17284
24.3.90; Host name completion in shell mode take 45 seconds

Previous Next

Package: emacs;

Reported by: Svend Sorensen <svend <at> ciffer.net>

Date: Thu, 17 Apr 2014 17:49:02 UTC

Severity: normal

Found in version 24.3.90

Done: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>

Bug is archived. No further changes may be made.

Full log


Message #46 received at 17284 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, Svend Sorensen <svend <at> ciffer.net>,
 Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 17284 <at> debbugs.gnu.org
Subject: RE: bug#17284: Host name completion in shell mode take 45 seconds
Date: Sat, 4 Apr 2015 07:46:40 -0700 (PDT)
> (defun string-before-p (string)
>    "Return t if string before `point' equals STRING."
>    (let ((start (- (point) (length string))))
>      (and (>= start (point-min))
> 	 (string-equal
> 	  (buffer-substring-no-properties start (point))
> 	  string))))

`buffer-substring-no-properties' is defined in C.  I can't tell
whether this is more efficient because of that or less efficient
because it creates a potentially giant string before starting to
compare.  I was trying to compare starting from the far end,
thinking that that might lead to earlier failure detection.

But I'll take your word for it that this is probably better.

(I guess if we were really worried about the long-string case we
could do what Isearch does, for the comparison.)

I didn't mention this before, because my implementation of
`chars-before' uses `char-before'.  But with such a function,
if it is defined without using `char-before' then the latter
function could be eliminated: (chars-before "a") instead of
(char-before ?a).

> And for simpler cases giving `char-before' a second argument
> to specify the position of the character before `point' might help too.

Yes.  (And that could apply as well to `chars-before', aka
`string-before-p' - optionally specify the start or end position.)

> But many occurrences of `looking-back' in the code base are inherently
> tied to regexps specified via defcustoms or passed as arguments and it
> doesn't seem easy to get rid of them.  Hence we should probably add a
> TODO item to fix all occurrences of `looking-back' either via the LIMIT
> argument, by string or character comparison.  An appetizing formulation
> of such an item would be very welcome.

Yes.  And I think you just formulated it, appetizingly enough. ;-)




This bug report was last modified 9 years and 144 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.