RE: should locate-file-completion filter out "./" and "../"?
> It's true that the completion candidates themselves are just
> strings, but the completion alist passed to completing-read
> or read-file-name can have key-value pairs, and those values
> can be exploited. I track which candidate is chosen, so I
> can tell which of any duplicate candidate strings is picked.
> Then I can use the associated value.
So the duplicate removal can still be in
display-completion-list because the
"duplicates" aren't quite duplicates.
If display-completion-list removes duplicate candidate strings, then I will
be very upset. The argument to display-completion-list is not the alist
TABLE argument to completing-read, so it will not be finding, say, that
("foo" 2378) is different from ("foo" 945). Those are the key-value pairs I
use, but display-completion-list never sees them.
The argument to display-completion-list is a list of candidate strings or
symbols (or a list of pairs of strings) to be displayed. I don't know what
functions pass a list of string pairs to display-completion-list, but I'm
pretty sure that having display-completion-list remove duplicates would not
work for me.
As I said, however, the duplicate removal is in `minibuffer-completion-help'
today (before the call to display_completion_list_1), and I don't care about
that, because I don't use `minibuffer-completion-help'.
Regardless of whether `minibuffer-completion-help' removes duplicates and
sorts, I would appreciate it if all callers of completing-read do so, when
they expect a sorted display of candidates with no duplicates. If they
don't, that's a minor inconvenience for me (my code will display the
duplicates). If you change all-completions or display-completion-list so
they remove duplicates, that's a major problem for me.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: [EMAIL PROTECTED]: quitting ediff with pop-up-frames non-nil gives wrong-type arg error]
Can't reproduce. This is on Windows. May have something to do with a broken port. OK, but it's 100% reproducible in the build I have (from March 2006). Perhaps it was fixed since then, or perhaps it's a bug only for Windows. IIRC, there might have been some changes in balance-windows since the build I have. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible memory problem and crashes on cygwin
> thanks so I get "nil" in the echo area and the memory usage does not > change at all when I try this. I didnt try leaving emacs for 1/2 an hour. > it normally crashes with a "segmentation something" much earlier. Spontaneously? If you post a backtrace as Eli suggested (as described with M-x report-emacs-bug), someone might be able to understand the problem. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible memory problem and crashes on cygwin
From: Luc Teirlinck <[EMAIL PROTECTED]> emacs user wrote: I'll take your word for that, I hardly know what GC is... I did not follow this thread and I do not know whether this has already been pointed out to you, but you can force a garbage collection using M-: (garbage-collect) If by any chance you then see `nil' in the echo area, we know what the problem is (pure space overflow). Actually, you can do `M-x garbage-collect' to force garbage collection, but then you do not see the return value in the echo area. thanks for this... so when I do this after killing the image buffers I get in the echo area: ((201785 . 16002) (29710 . 0) (1424 . 383) 3020224 374951 (873 . 247) (676 . 67) (57159 . 8298)) but the memory use does not change. _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: should locate-file-completion filter out "./" and "../"?
> It's true that the completion candidates themselves are just strings, but > the completion alist passed to completing-read or read-file-name can have > key-value pairs, and those values can be exploited. I track which candidate > is chosen, so I can tell which of any duplicate candidate strings is picked. > Then I can use the associated value. So the duplicate removal can still be in display-completion-list because the "duplicates" aren't quite duplicates. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible memory problem and crashes on cygwin
emacs user wrote: I'll take your word for that, I hardly know what GC is... I did not follow this thread and I do not know whether this has already been pointed out to you, but you can force a garbage collection using M-: (garbage-collect) If by any chance you then see `nil' in the echo area, we know what the problem is (pure space overflow). Actually, you can do `M-x garbage-collect' to force garbage collection, but then you do not see the return value in the echo area. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible memory problem and crashes on cygwin
From: [EMAIL PROTECTED] (Kim F. Storm) Jason Rumney <[EMAIL PROTECTED]> writes: > emacs user wrote: >> an example: >> >> before editing the image: 33Mb >> during: 39Mb >> after killing the buffer: 39Mb >> image file is 186263 bytes large (jpeg) > > Emacs needs to decompress your jpeg image to display it, and rather > than do that every time it gets displayed, it caches the decompressed > image for image-cache-eviction-delay seconds after it was last > displayed. By default, image-cache-eviction-delay is 1800, so what > happens to the memory usage if you leave Emacs for half an hour? Or try this: M-: (clear-image-cache t) RET thanks so I get "nil" in the echo area and the memory usage does not change at all when I try this. I didnt try leaving emacs for 1/2 an hour. it normally crashes with a "segmentation something" much earlier. EU _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible memory problem and crashes on cygwin
Jason Rumney <[EMAIL PROTECTED]> writes: > emacs user wrote: >> an example: >> >> before editing the image: 33Mb >> during: 39Mb >> after killing the buffer: 39Mb >> image file is 186263 bytes large (jpeg) > > Emacs needs to decompress your jpeg image to display it, and rather > than do that every time it gets displayed, it caches the decompressed > image for image-cache-eviction-delay seconds after it was last > displayed. By default, image-cache-eviction-delay is 1800, so what > happens to the memory usage if you leave Emacs for half an hour? Or try this: M-: (clear-image-cache t) RET -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: timer error
> I should say, I deleted the emacs source file from my home directory, which > is supposed to be OK, because the package is supposed to be self-contained. > But maybe that messes up debugging? Yes. You don'tneed the source for just running Emacs but you need it for debugging. When execution stops at a breakpoint it displays the current source line, allows you to see the source code from where the current routine was called etc. > I can recompile and not delete the source files and/or recompile but not use > make-package. I'm not familiar with make-package, but you can just follow the instructions "BUILDING EMACS ON MAC OS X" in INSTALL in the mac directory: ./configure --enable-carbon-app make You don't need to do "make install" but you may have to also look at INSTALL.CVS in the emacs directory. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible memory problem and crashes on cygwin
emacs user wrote: an example: before editing the image: 33Mb during: 39Mb after killing the buffer: 39Mb image file is 186263 bytes large (jpeg) Emacs needs to decompress your jpeg image to display it, and rather than do that every time it gets displayed, it caches the decompressed image for image-cache-eviction-delay seconds after it was last displayed. By default, image-cache-eviction-delay is 1800, so what happens to the memory usage if you leave Emacs for half an hour? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible memory problem and crashes on cygwin
From: Eli Zaretskii <[EMAIL PROTECTED]> > From: "emacs user" <[EMAIL PROTECTED]> Thank you for your report. > this problem leads to consistent and reproducible crashes of emacs. You didn't show any crashes. Please do (with meaningful backtraces). so emacs uses more and more memory, and eventually slows down my laptop so much that I either have to kill it (OK, not exactly a crash, I suppose), or that it somehow dies. wouldnt this be sufficient information to the cygwin maintainer to work with? even without the crash, this seems like a fairly significant bug...? > using latest cvs gnu emacs (22.0.50) on latest cygwin. Which version of Cygwin is that? We had in the past reports about various problems in specific versions; please try to search the archives of this list and of emacs-devel, and see if your crashes resemble some reported in the past. the cygwin home page suggests that Latest Cygwin DLL release version is 1.5.20-1 is this what you were looking for? how do I find the cygwin version number? I am trying to be well intentioned but am certainly a total ignorant as a non fortran programmer I did follow the links you suggested in a previous email, but couldnt understand if they are relevant or not to this specific problem, or the previous one I reported. > start with > emacs -q --no-site-file& > edit a jpeg file > kill buffer > edit another jpeg file > kill buffer again. > > every such jpeg file edited and exited leaves the memory used by emacs (as > seen in the list of processes of the windows task manager) increased. Please report the numbers: the memory usage figures reported by the Task Manager before, during, and after the image buffer is killed. an example: before editing the image: 33Mb during: 39Mb after killing the buffer: 39Mb image file is 186263 bytes large (jpeg) > Memory does not decrease once buffer with image is killed. when a text file > is edited and exited, the memory does return to its original size. I don't think Emacs returns the memory to the OS immediately, but GC should cause that. I'll take your word for that, I hardly know what GC is... _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bootstrapping error (autoloads error 255)
Luc Teirlinck <[EMAIL PROTECTED]> writes: > Dieter Wilhelm wrote: > >just updated my emacs directory from CVS, typed: make bootstrap and >got the following messages: > > I can not reproduce this. Does the error still occur if you do: > > make maintainer-clean > ./configure > > before `make bootstrap'? No it doesn't 8-). Since ./configure make bootstrap alone worked so far for me, I probably had the misty notion that somehow 'bootstrap' would take charge of the cleaning up. Thank you very much. Dieter -- Best wishes Dieter Wilhelm Darmstadt, Germany ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible memory problem and crashes on cygwin
> From: "emacs user" <[EMAIL PROTECTED]> > Bcc: > Date: Mon, 10 Jul 2006 01:05:40 -0400 Thank you for your report. > this problem leads to consistent and reproducible crashes of emacs. You didn't show any crashes. Please do (with meaningful backtraces). > using latest cvs gnu emacs (22.0.50) on latest cygwin. Which version of Cygwin is that? We had in the past reports about various problems in specific versions; please try to search the archives of this list and of emacs-devel, and see if your crashes resemble some reported in the past. > start with > emacs -q --no-site-file& > edit a jpeg file > kill buffer > edit another jpeg file > kill buffer again. > > every such jpeg file edited and exited leaves the memory used by emacs (as > seen in the list of processes of the windows task manager) increased. Please report the numbers: the memory usage figures reported by the Task Manager before, during, and after the image buffer is killed. > Memory does not decrease once buffer with image is killed. when a text file > is edited and exited, the memory does return to its original size. I don't think Emacs returns the memory to the OS immediately, but GC should cause that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Fwd: Re: beginning-of-defun]
Thien-Thi Nguyen schrieb: From: Andreas Roehler <[EMAIL PROTECTED]> Date: Mon, 10 Jul 2006 15:46:02 +0200 It's not just for fun I entered this matter. `beginning-of-defun' is buggy - and a lot of forms which rely on it. given the discussion so far i remain unconvinced there is a bug. note however: i'm not stopping you from continuing, personally. if you post code as the way to propose the bug fix, it that will be easier to evaluate its merits. remember to not break callers (both included w/ emacs and external) of `beginning-of-defun'. thi There are not many, but some cases, where `beginning-of-defun' fails To use a real existing inner form (cursor at roof-sign): (when (boundp 'bar) (defun e-r-t-l () (let ((starting-point (point))) (end-of-defun) (beginning-of-defun) (prog1 (edebug-read-and-maybe-wrap-form) ;; Recover point, but only if no error occurred. (goto-char starting-point) ^ M-x eval-defun ==> nil Evaluation fails caused by failure of (beginning-of-defun) (defun e-r-t-l () (let ((starting-point (point))) (end-of-defun) (beginning-of-defun) (prog1 (edebug-read-and-maybe-wrap-form) ;; Recover point, but only if no error occurred. (goto-char starting-point ^ M-x eval-defun ==> e-r-t-l However, it should also work in the first case. As I need it to call from programs, it should be possible to rely on. Hopeful to send some scratch next days. __ Andreas Roehler ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Stack overflow in regexp matcher
Should semantic.cache even be in directory src? There is no such file in my directory src. What is it? I don't know. It turns out that it was in a distribution I got from nqemacs a year and a half ago. No bug; sorry. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: should locate-file-completion filter out "./" and "../"?
1. Is it at all useful to have "./" and "../" in this list? They are files, so it would be wrong for them not to appear. They are not files that could possibly be libraries. Likewise, for .cvsignore. This patch should avoid the duplications; how much better is it? Perfect. Thx. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Stack overflow in regexp matcher
Should semantic.cache even be in directory src? There is no such file in my directory src. What is it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bootstrapping error (autoloads error 255)
I made a change in ldefs-boot.el that I think will fix this. Does it work now? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: should locate-file-completion filter out "./" and "../"?
1. Is it at all useful to have "./" and "../" in this list? They are files, so it would be wrong for them not to appear. This patch should avoid the duplications; how much better is it? *** files.el08 Jul 2006 16:59:45 -0400 1.851 --- files.el10 Jul 2006 12:45:48 -0400 *** *** 691,697 (when (file-directory-p dir) (dolist (file (file-name-all-completions (file-name-nondirectory string) dir)) ! (push (if string-dir (concat string-dir file) file) names) (when (string-match suffix file) (setq file (substring file 0 (match-beginning 0))) (push (if string-dir (concat string-dir file) file) names) --- 691,697 (when (file-directory-p dir) (dolist (file (file-name-all-completions (file-name-nondirectory string) dir)) ! (add-to-list 'names (if string-dir (concat string-dir file) file)) (when (string-match suffix file) (setq file (substring file 0 (match-beginning 0))) (push (if string-dir (concat string-dir file) file) names) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: should locate-file-completion filter out "./" and "../"?
> Thankfully (), duplicates are *not* being removed from > the result of `all-completions', because I rely upon that > fact to give me an unordered set of completions, with > duplicates if they are available. I have code that lets > users take advantage of completion candidates that might be identical > strings but have different meanings (e.g. occurrences of the > same string in a buffer). Could you expand on this? I have a hard time imagining why it would be useful to have duplicates if they are truly identical. And if they're not really identical, how does the user know the difference? It shouldn't be important for this bug report - `all-completions' works just fine as is. The real question is why not fix callers of `completing-read', so they pass a TABLE arg that doesn't have duplicates (unless they want duplicates)? It makes sense for a calling program to do any duplicate removal or sorting of completion candidates, as it deems appropriate; only the caller knows what it needs. `all-completions' should not get involved with sorting or duplicate removal (which it doesn't, thank goodness). FYI, if you're just curious (though I'm sure this is TMI) - It's true that the completion candidates themselves are just strings, but the completion alist passed to completing-read or read-file-name can have key-value pairs, and those values can be exploited. I track which candidate is chosen, so I can tell which of any duplicate candidate strings is picked. Then I can use the associated value. For this to be helpful to the user, s?he generally needs to be able to see more than just the candidates in *Completions*. For this kind of functionality, I display whatever is appropriate at the same time. An example: I have a search functionality that lets you input a regexp to search for in some buffer. That regexp determines the matching occurrences in the buffer being searched (like `occur', but not limited to searches within a line). Each match is also used as a completion candidate, in *Completions*. And each match is highlighted in the buffer searched. IOW, searching determines a set of matching hits, and those are treated as completion candidates. You can complete to any candidate and hit RET to go to it. Or, you can cycle among candidates, browsing the hits in context (in the buffer searched); that is, cycling can navigate to each candidate in turn (or to specific candidates). After entering the original regexp, which determines the set of completion candidates, you can type another string (possibly another regexp) in the minibuffer. This matches only within each candidate - i.e. within each of the original hits. This match is also highlighted (in a different color) within the hits in the buffer searched. That second search string refines the search - it typically means that fewer of the original candidate set match (i.e. match also the second regexp). All of the original candidates remain highlighted in the buffer searched, but the set of completion candidates is reduced to those that match also the second regexp. When you complete, it is to one of these candidates. When you cycle among candidates, you browse among these candidates that match both regexps. You can dynamically change the second search string - a la isearch; whatever you type is reflected in an updated *Completions*. If you delete the second input altogether, so the minibuffer is empty again, then *Completions* is back to the original set of candidates. You browse among candidate hits by using C-next and C-prior. This moves you around the buffer among the various hits, so you can see them in context. The order of candidates is the order of the hits in the buffer - candidates are not sorted (another reason for, say, all-completions not to impose sorting). There are also ways to move around among selected candidates; you need not cycle through each one, in order. Of course, some of the original hits might be identical candidate strings. If there are multiple hits for the same original input, those hits might not be identical (the regexp might match them each differently), but some of them might be identical. The user might thus see some duplicates in *Completions*. When s?he navigates, the hits are in order in the buffer (and they are in order in *Completions*), and the navigation to each hit shows you its context (where it is in the buffer). So there is no disorientation, even though the strings in *Completions* are the same. If I had more control over the *Completions* display (e.g. from Lisp), then I might try to put an indicator next to each candidate in *Completions* - perhaps the position of the hit (point) or the line number (though hits need not be lines, because the inital regexp can match anything). I have several features that exploit the order (or lack of it) of *Completions* candidates and their possible multiple occurrence; search is one of them. Here is an explanation of the sear
Re: [Fwd: Re: beginning-of-defun]
From: Andreas Roehler <[EMAIL PROTECTED]> Date: Mon, 10 Jul 2006 15:46:02 +0200 It's not just for fun I entered this matter. `beginning-of-defun' is buggy - and a lot of forms which rely on it. given the discussion so far i remain unconvinced there is a bug. note however: i'm not stopping you from continuing, personally. if you post code as the way to propose the bug fix, it that will be easier to evaluate its merits. remember to not break callers (both included w/ emacs and external) of `beginning-of-defun'. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Stack overflow in regexp matcher
> Debugger entered--Lisp error: (error "Stack overflow in
regexp matcher")
> re-search-forward(": \\(.+\\): \\(?:Permission denied\\|No such
> \\(?:file or directory\\|device or address\\)\\)$" 69633 t)
The only way for this regexp to cause a stack overflow is if
there's a *very*
long line.
We could maybe reduce the stack use by replacing ".+" with
something like
"\\([^:\n]*:\\)*[^:\n]*".
Yes, it was a **very** long line. For some reason, there was a
semantic.cache file in the src directory I got from nqemacs. - Drew
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Stack overflow in regexp matcher
> Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
> re-search-forward(": \\(.+\\): \\(?:Permission denied\\|No such
> \\(?:file or directory\\|device or address\\)\\)$" 69633 t)
The only way for this regexp to cause a stack overflow is if there's a *very*
long line.
We could maybe reduce the stack use by replacing ".+" with something like
"\\([^:\n]*:\\)*[^:\n]*".
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: should locate-file-completion filter out "./" and "../"?
> Thankfully (), duplicates are *not* being removed from the result of > `all-completions', because I rely upon that fact to give me an unordered set > of completions, with duplicates if they are available. I have code that lets > users take advantage of completion candidates that might be identical > strings but have different meanings (e.g. occurrences of the same string in > a buffer). Could you expand on this? I have a hard time imagining why it would be useful to have duplicates if they are truly identical. And if they're not really identical, how does the user know the difference? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Fwd: Re: beginning-of-defun]
Thien-Thi Nguyen schrieb: Andreas Roehler <[EMAIL PROTECTED]> writes: `defun' is a special form with a special meaning in emacs-lisp yes, but "defun" is also in common parlance a "top-level form". these two meanings are congruent but not identical. you have to sort of alternatively squint and relax your ears to hear the similarity... If you don't discriminate between termini top-level-form, function (which is a known name in many programing languages but not in all) and the special Emacs Lisp form defun, you will run into confusion when the difference matters. Think it's disturbing to introduce a different meaning employing the same name. you get used to being disturbed w/ a little practice. What about to take it as a chance, not being used to? Certainly a function `beginning-of-top-level-form' is useful. However, it should be callable separate from `beginning-of-defun' and vice versa. here is a (self-testable in the right context ;-) toy: (global-set-key "\C-\M-a" (defun beginning-of-defun-just-defun-really-i-mean-it! () (interactive) (let ((beginning-of-defun-function (lambda () (search-backward "(defun" (point-min) t (beginning-of-defun This form will fail, should there be a string "(defun" somewhere in a docu or other included text before the real beginning of function. Also its focus is on the less general form in this context. Propose a top-down proceeding while re-designing venerable `beginning-of-defun' function. beginning-of-top-level-form beginning-of-form ;; before and under point beginning-of-function The latter would - if in Emacs Lisp-mode - be provided with a spec to indentify the defun-form `beginning-of-defun' should work right out of the box at least in Emacs Lisp. That's easily to be done - if the need is recognised so far. it works for my understanding of "defun". more importantly, my understanding of "defun" is shared by many people, most of whom are probably uninclined to add something like the above function to emacs. thi The author of edebug.el at least seems conscious of the problem. Doesn't seem an accident he named it edebug-eval-top-level-form providing just an alias (defalias 'edebug-defun 'edebug-eval-top-level-form) Also I read there (defun edebug-read-top-level-form () (let ((starting-point (point))) (end-of-defun) (beginning-of-defun) ... It's not just for fun I entered this matter. `beginning-of-defun' is buggy - and a lot of forms which rely on it. (unless t (defun foo () "Explore the right \"(defun-funktion\" " (interactive) (message "%s" "baz"))) ^ M-x beginning-of-defun ==> (unless t ^ (defun foo () "Explore the right \"(defun-funktion\" " (interactive) (message "%s" "baz"))) When the [ \t]* as regexp-prefix is set M-x beginning-of-defun ==> (unless t (defun foo () "Explore the right \"(defun-funktion\" " (interactive) (message "%s" "baz"))) ^ __ Andreas Roehler ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: timer error
I should say, I deleted the emacs source file from my home directory, which is supposed to be OK, because the package is supposed to be self-contained. But maybe that messes up debugging? I can recompile and not delete the source files and/or recompile but not use make-package. Gil > Gilbert Harman writes: >> If I directly evaluate that expression, >> (timer-relative-time '(17583 46528 355684) 0.5 0) >> I too get (17583 46528 855684). >> >> So, I am not sure what I should try next? > > I guess what Richard suggested initially: run under GDB, with a breakpoint at > the line in floor which signals this error. I think it's enough to put a > breakpoint on Fsignal. You can look at the lisp backtrace with `xbacktrace' > but this way you can also examine values in the C backtrace to see what's > going wrong. Maybe there's some memory corruption. See the DEBUG file for > further help. > OK I put a breakpoint on Fsignal and this resulted. It's looking for emacs/mac/src/eval.c, which isn't there. It is probably relevant that I used emacs/mac/make-package to compile emacs? Gil ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: timer error
> Gilbert Harman writes: >> If I directly evaluate that expression, >> (timer-relative-time '(17583 46528 355684) 0.5 0) >> I too get (17583 46528 855684). >> >> So, I am not sure what I should try next? > > I guess what Richard suggested initially: run under GDB, with a breakpoint at > the line in floor which signals this error. I think it's enough to put a > breakpoint on Fsignal. You can look at the lisp backtrace with `xbacktrace' > but this way you can also examine values in the C backtrace to see what's > going wrong. Maybe there's some memory corruption. See the DEBUG file for > further help. > OK I put a breakpoint on Fsignal and this resulted. It's looking for emacs/mac/src/eval.c, which isn't there. It is probably relevant that I used emacs/mac/make-package to compile emacs? Gil [GH-iMAC:~] gilberth% > gdb /Applications/Emacs.app/Contents/MacOS/Emacs GNU gdb 6.1-20040303 (Apple version gdb-437) (Sun Dec 25 08:26:53 GMT 2005) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries . done (gdb) break Fsignal Breakpoint 1 at 0xe3a36: file /Users/gilbertharman/emacs/mac/../src/eval.c, line 1606. (gdb) run Starting program: /Applications/Emacs.app/Contents/MacOS/Emacs Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Breakpoint 1, Fsignal (error_symbol=58838601, data=20849805) at /Users/gilbertharman/emacs/mac/../src/eval.c:1606 1606/Users/gilbertharman/emacs/mac/../src/eval.c: No such file or directory. in /Users/gilbertharman/emacs/mac/../src/eval.c (gdb) backtrace #0 Fsignal (error_symbol=58838601, data=20849805) at /Users/gilbertharman/emacs/mac/../src/eval.c:1606 #1 0x000a3f7f in report_file_error (string=0x167234 "Removing old name", data=20849829) at /Users/gilbertharman/emacs/mac/../src/fileio.c:290 #2 0x000a6c0c in Fdelete_file (filename=77336931) at /Users/gilbertharman/emacs/mac/../src/fileio.c:2706 #3 0x000e2c92 in Feval (form=1826709) at /Users/gilbertharman/emacs/mac/../src/eval.c:2250 #4 0x000e51b1 in internal_lisp_condition_case (var=58721289, bodyform=1826709, handlers=1826725) at /Users/gilbertharman/emacs/mac/../src/eval.c:1421 #5 0x001138e8 in Fbyte_code (bytestr=1826603, vector=1826660, maxdepth=3) at /Users/gilbertharman/emacs/mac/../src/bytecode.c:884 #6 0x000e316c in funcall_lambda (fun=1826556, nargs=1, arg_vector=0xbfffeed4) at /Users/gilbertharman/emacs/mac/../src/eval.c:3091 #7 0x000e372a in Ffuncall (nargs=2, args=0xbfffeed0) at /Users/gilbertharman/emacs/mac/../src/eval.c:2959 #8 0x001149d0 in Fbyte_code (bytestr=1827235, vector=1827540, maxdepth=5) at /Users/gilbertharman/emacs/mac/../src/bytecode.c:694 #9 0x000e316c in funcall_lambda (fun=1827204, nargs=0, arg_vector=0xb074) at /Users/gilbertharman/emacs/mac/../src/eval.c:3091 #10 0x000e372a in Ffuncall (nargs=1, args=0xb070) at /Users/gilbertharman/emacs/mac/../src/eval.c:2959 #11 0x001149d0 in Fbyte_code (bytestr=1826211, vector=1826308, maxdepth=5) at /Users/gilbertharman/emacs/mac/../src/bytecode.c:694 #12 0x000e316c in funcall_lambda (fun=1826164, nargs=1, arg_vector=0xb284) at /Users/gilbertharman/emacs/mac/../src/eval.c:3091 #13 0x000e372a in Ffuncall (nargs=2, args=0xb280) at /Users/gilbertharman/emacs/mac/../src/eval.c:2959 #14 0x000e07a0 in Fcall_interactively (function=59120417, record_flag=58721289, keys=22023964) at /Users/gilbertharman/emacs/mac/../src/callint.c:884 #15 0x0007d635 in Fcommand_execute (cmd=59120417, record_flag=58721289, keys=58721289, special=58721289) at /Users/gilbertharman/emacs/mac/../src/keyboard.c:9759 #16 0x00085070 in command_loop_1 () at /Users/gilbertharman/emacs/mac/../src/keyboard.c:1791 #17 0x000e19d2 in internal_condition_case (bfun=0x84c9d , handlers=58767529, hfun=0x7e200 ) at /Users/gilbertharman/emacs/mac/../src/eval.c:1476 #18 0x00077de0 in command_loop_2 () at /Users/gilbertharman/emacs/mac/../src/keyboard.c:1328 #19 0x000e18c3 in internal_catch (tag=58763833, func=0x77d9c , arg=58721289) at /Users/gilbertharman/emacs/mac/../src/eval.c:1214 #20 0x00077b87 in command_loop () at /Users/gilbertharman/emacs/mac/../src/keyboard.c:1307 #21 0x00077c3b in recursive_edit_1 () at /Users/gilbertharman/emacs/mac/../src/keyboard.c:1000 #22 0x00077d5d in Frecursive_edit () at /Users/gilbertharman/emacs/mac/../src/keyboard.c:1061 #23 0x00076f0e in main (argc=1, argv=0xb914) at /Users/gilbertharman/emacs/mac/../src/emacs.c:1794 (gdb) step 1615in /Users/gilbertharman/emacs/mac/../src/eva
Elisp texi 2.3.13 Function Type
Having difficulties of understanding, I ask, if it could be said another way (proposals below with `-' to cancel, `+~' added/changed text) , | 2.3.13 Function Type | | | Just as functions in other programming languages are executable, "Lisp | function" objects are pieces of executable code. However, functions in | Lisp are primarily Lisp objects, and only secondarily the text which | represents them. ` - Just as functions in other programming languages ;; Doesn't contribute real information IMO; if at all, ;; the point that some other languages don't use this ;; terminus should be mentioned here +~ Regarding functions we have always to decide if we referring to them as the printed representation of a execution routine--i.e. as pieces of executable code defining a function when evaluated--or if we speak of the behavior of an already read-in (evaluated and interned) function, which might be called for execution. - However, functions in Lisp are primarily Lisp objects, and only secondarily the text which represents them. ;; IMO that remark makes no sense: while editing, it's ;; the textual representation which matters. Internals ;; of computation are fairly not the same as writing ;; programs; however, would not employ `primarily' here ;; to mark the difference. __ Andreas Roehler ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tumme messages in the echo area
Nick Roberts <[EMAIL PROTECTED]> writes: > If you replace the calls to shell-command with calls to call-process does > that do what you want? > > (shell-command COMMAND) -> > (call-process shell-file-name nil nil nil "-c" COMMAND) Yes it does! Thank you very much for your help. This is the patch that implements your suggested change: --- orig/lisp/tumme.el +++ mod/lisp/tumme.el @@ -1776,7 +1776,7 @@ (cons ?h height) (cons ?f file) (cons ?t new-file - (setq ret (shell-command command nil)) + (setq ret (call-process shell-file-name nil nil nil "-c" command)) (if (not (= 0 ret)) (error "Could not resize image"))) (copy-file file new-file t)) Thanks, Andrea. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tumme messages in the echo area
> when I'm in the *tumme* buffer, if I use > `tumme-display-next-thumbnail-original' or > `tumme-display-previous-thumbnail-original' the handy imformation > (like the image filename and its tags) these commands displays in the > echo area, is replaced by the message: > > (Shell command succeeded with no output) > > which isn't useful. If you replace the calls to shell-command with calls to call-process does that do what you want? (shell-command COMMAND) -> (call-process shell-file-name nil nil nil "-c" COMMAND) -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Rectangles are not explained or cross-referenced in Elisp manual
Agreed; we don't need to document them there. But, since we mention them, we could usefully cross-reference the doc that explains what they are. Where precisely in the Emacs Lisp Manual are editing rectangles referred to? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Rectangles are not explained or cross-referenced in Elisp manual
Just search for "rectangle" - 1. (elisp) Frame Type 2. (elisp) Frames Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
