AW: (no subject)

2005-08-31 Thread klaus.berndl
Title: AW: (no subject) IMHO a very felicitous design... Klaus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] im Auftrag von David PONCE Gesendet: Mi 31.08.2005 12:14 An: [EMAIL PROTECTED] Cc: emacs-devel@gnu.org Betreff: (no subject) Lennart Borgman wrote: > I have added them t

problems with byte-compiling defcustoms

2005-08-14 Thread klaus.berndl
Hi all, please take a look at the following short elisp-example: (eval-when-compile (require 'cl)) (defcustom ecb-wget-setup (cons (if (fboundp 'executable-find) (executable-find "wget") "wget")

AW: AW: AW: Can't interrupt directory_files_internalrunfromtimer-event-handler

2005-08-12 Thread klaus.berndl
Title: AW: AW: AW: Can't interrupt directory_files_internalrunfromtimer-event-handler >>    >The best way to do this and make sure it is stealthy is by running a >>    >subprocess.  The subprocess can run in parallel with Emacs. >>    Hmm, i'm not sure if this is the best way?! >If the prim

AW: Can't interrupt directory_files_internal run fromtimer-event-handler

2005-08-12 Thread klaus.berndl
Title: AW: Can't interrupt directory_files_internal run fromtimer-event-handler >> With the current available elisp-tools (macos, functions etc.) ECB can run >> these tasks only pseudo-stealthy...therefore a way to make this really >> stealthy would be very important for ECB so users are not

AW: AW: Can't interrupt directory_files_internal runfromtimer-event-handler

2005-08-11 Thread klaus.berndl
Title: AW: AW: Can't interrupt directory_files_internal runfromtimer-event-handler     In fact: ECB has some tasks which should be run really(!) stealthy, like     checking if a dir is empty, getting the VC-state of all files in a dir,     checking which files in a dir are read-only... in ca

AW: Can't interrupt directory_files_internal run fromtimer-event-handler

2005-08-10 Thread klaus.berndl
Title: AW: Can't interrupt directory_files_internal run fromtimer-event-handler >> ECB encapslates ist "stealthy" tasks in a loop like: >> (while (and (not (input-pending-p)) >> ... >> So IMHO C-g should work >Only if each iteration takes a (small) finite time.

AW: Can't interrupt directory_files_internal runfromtimer-event-handler

2005-08-08 Thread klaus.berndl
Title: AW: Can't interrupt directory_files_internal runfromtimer-event-handler >> while-no-input is in the Lisp manual.  throw-on-input is not for users >> to use; perhaps we should rename it to while-no-input-throw-internal. >In its current form, a caller of while-no-input cannot differenti

AW: Can't interrupt directory_files_internal run fromtimer-event-handler

2005-08-08 Thread klaus.berndl
Title: AW: Can't interrupt directory_files_internal run fromtimer-event-handler >>> There's no need to run any program just to know if a directory is >>> empty.  Emacs has primitives which will tell that directly (e.g., >>> file-attributes) and do that faster. >>> >> How do you de

RE: Can't interrupt directory_files_internal runfromtimer-event-handler

2005-08-05 Thread klaus.berndl
Juanma Barranquero wrote: > On 8/5/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> AFAIK there is a new macro in CVS named `while-no-input' (there >> was a discussion some time ago) > > BTW, `while-no-input' and `throw-on-input' are not documented on the > Emacs Lisp Reference; and the

RE: Can't interrupt directory_files_internal run fromtimer-event-handler

2005-08-05 Thread klaus.berndl
Klaus Zeitler wrote: > The following problem occurs with CVS emacs + ECB under Solaris 5.8. > > While ECB performs its stealth update activities, emacs sometimes > seems to > hang for a long time. > gdb shows the following function and backtrace: > > directory_files_internal (directory=16076323,

RE: w32 does not have emacsclient/server

2005-07-15 Thread klaus.berndl
Lennart Borgman wrote: > Jason Rumney wrote: > >> >>> I have suggested that there might be too few developers on the w32 >>> side. In that sense it may actually be part of a strategy. >> >> >> >> There is no conspiracy here. The number of developers reflects the >> number of volunteers. > > I

RE: Inefficient code in xml.el

2005-06-06 Thread klaus.berndl
Well, i get the point, but how an elisp-programmer should know this?! The manual says: - Function: match-data This function returns a newly constructed list containing all the information on what text the last search matched. Element zero is the position of the beginning of the m