Does anyone know the difference between stack-trace-on-error and
debug-on-error?
,[ C-h v stack-trace-on-error RET ]
| stack-trace-on-error's value is nil
|
| *Non-nil means errors display a backtrace buffer.
| More precisely, this happens for any error that is handled
| by the editor command
"Chong Yidong" <[EMAIL PROTECTED]> writes:
>> BTW, longlines.el seems to be fairly widely used; is there a reason
>> it hasn't been added to the Emacs distribution?
>
> The main reason is the feature freeze. RMS contacted me about
> putting it into Emacs a couple months back, and my guess is that
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Does anyone know the difference between stack-trace-on-error and
> debug-on-error?
[...]
> On first inspection they seem to do exactly the same.
Silly me: I was testing it in a *scratch* buffer with
eval-expression-debug-on-error on, so errors always t
Lute Kamstra <[EMAIL PROTECTED]> writes:
> I'll document it in the Lisp manual.
Here it is:
*** lispref/debugging.texi 3 Mar 2005 16:28:32 - 1.27
--- lispref/debugging.texi 4 Mar 2005 11:02:19 -
***
*** 166,171
--- 166,185
(lambda () (set
I just installed some changes for the Carbon build on Mac OS 9. The
command
make Emacs -f makefile.MPW > Emacs.MakeScript && Emacs.MakeScript
now creates the Carbon build. The non-Carbon build can still be
compiled with
make NonCarbon -f makefile.MPW > NonCarbon.MakeScript && NonCarbon.Mak
> Date: Fri, 04 Mar 2005 20:48:32 +0900
> From: YAMAMOTO Mitsuharu <[EMAIL PROTECTED]>
>
> I just installed some changes for the Carbon build on Mac OS 9.
Thanks.
I think this warrants an entry in etc/NEWS (I didn't see such an entry
among the changes you installed). It should go into the "Inst
Miles Bader wrote,
... I've read the info file now, and it seems pretty explicit and
clear about the distinction between the two types of logs.
Yes. I wrote that text years and years ago with wording intended to
create such a distinction. At that time, when people referred to a
`change lo
On Tue, Mar 01 2005, Stefan Monnier wrote:
> Reiner Steib wrote:
>> I propose to add autoloads for all iso-8859-* and windows-125* coding
>> systems. With these autoload, Gnus (and probably also other Emacs
>> based mail and news readers) are able to display articles with the
>> corresponding MIM
> Lute Kamstra wrote:
> drkm <[EMAIL PROTECTED]> writes:
> > M-: (setq debug-on-error nil
> > stack-trace-on-error t)
> > C-f
> > ;; Open a new window and show the stack trace
> > M-: (setq debug-on-error t
> > stack-trace-on-error nil)
> >
I am trying to get hourglass code working on w32. Currently I need to know
why a timer for show_hourglass does not get through.
Can someone please explain to me if start_atimer works on w32? It seems to
me I do not get the show_hourglass timer even if I comment out the
cancel_hourglass code in w32
Kim F. Storm wrote:
/configure CFLAGS="-g -O0 -DXASSERTS=1"
If somebody would refine that to
/configure --with-asserts
it would be great!!
./configure --enable-asserts
now adds -DXASSERTS=1 to cflags.
Jan D.
___
Emacs-devel mailing list
Emacs-devel
Can someone please tell me when an hourglass is shown on X Emacs? Is it
shown for an operation like ediff-buffers (that takes a long time on my pc)?
Is it shown for indent-region?
Not for indent-region (it should be IMHO). Ediff-buffer is quite fast
on my machines, so I can't tell. Constructing
David Kastrup wrote:
Hi,
I mentioned that throws already restore the value of
interrupt_input_blocked and so that doing so manually in keyboard.c
would seem unnecessary. That would suggest the following patch:
--- keyboard.c 16 Feb 2005 02:07:09 +0100 1.811
+++ keyboard.c 01 Mar 2005 06
Wed, 2 Mar 2005 15:14:59 -0800: <[EMAIL PROTECTED]> wrote:
> Tak Ota <[EMAIL PROTECTED]> writes:
>
> > Sat, 26 Feb 2005 15:19:03 -0800: <[EMAIL PROTECTED]> wrote:
> >
> >> Tak Ota <[EMAIL PROTECTED]> writes:
> >>
> >> > Hi Kim,
> >> >
> >> > Sorry I neglected having my homework done before repor
2005-02-28 kl. 15.49 skrev Richard Stallman:
This sounds like normally only the main thread should ever be
touching
interrupt_input_blocked, unless we have a bug. Correct? So we
need
not think about how to synchronize accesses to the variable, but
rather make sure that no thread
>> Can someone please tell me when an hourglass is shown on X Emacs? Is it
>> shown for an operation like ediff-buffers (that takes a long time on my pc)?
>> Is it shown for indent-region?
> Not for indent-region (it should be IMHO).
Are you sure? I thought it was command-agnostic (i.e. it simpl
> I think we should try to get SYNC_INPUT to work.
Works for me.
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Be the center of their Attention
I've never seen so many different pheromone products on one site! Your
pheromone perfume is the most thoughtful product I have seen yet - and one
of the only ones I've seen made with women in mind. It's great to know that
I can use this product and no one else know
2005-03-04 kl. 20.36 skrev Stefan Monnier:
I think we should try to get SYNC_INPUT to work.
Works for me.
For me too. But it is probably too untested to turn on by default for
this release?
Jan D.
___
Emacs-devel mailing list
Emacs-devel@gnu.o
Stefan Monnier wrote:
Can someone please tell me when an hourglass is shown on X Emacs? Is it
shown for an operation like ediff-buffers (that takes a long time on my pc)?
Is it shown for indent-region?
Not for indent-region (it should be IMHO).
Are you sure? I thought it was command
I am curious if there's a chance GNU Emacs will ever have an embedded
web browser object through the Mozilla GTK support:
top-level docs:
http://www.mozilla.org/unix/gtk-embedding.html
specific embedding example:
http://lxr.mozilla.org/seamonkey/source/embedding/browser/gtk/tests/TestGtkEmbed.cpp
"Jan D." <[EMAIL PROTECTED]> writes:
> 2005-03-04 kl. 20.36 skrev Stefan Monnier:
>
>>> I think we should try to get SYNC_INPUT to work.
>>
>> Works for me.
>>
>
> For me too. But it is probably too untested to turn on by default for
> this release?
I think it would be madness to turn it on just
I think we should try to get SYNC_INPUT to work.
Works for me.
For me too. But it is probably too untested to turn on by default for
this release?
I think it would be madness to turn it on just because I have some
problems understanding the code and all its implications. At least if
we have no pr
That's interesting because the entry below (Types of Log File) that you
wrote
(RMS) is only recorded in the CVS log.
Until a year or two ago, we did not keep track of documentation changes
in ChangeLog. Nowadays we do.
___
Emacs-devel mailin
In Emacs, the approach we use is that all changes are listed in
ChangeLog.
Which ChangeLog?
In the ChangeLog in the directory where you made the change; or, if
there is none in that directory, in its parent directory.
(emacs)Types of Log File
the Emacs manual says
BTW, longlines.el seems to be fairly widely used; is there a reason it
hasn't been added to the Emacs distribution?
It would be useful for a few experienced Emacs developers to look it
over and make suggestions.
___
Emacs-devel mailing list
Em
First, recall that soft newlines
are equivalent to spaces, so fill-paragraph can delete a soft newline or
replace it with one or more spaces.
Now if you have a paragraph
foo foo\n
bar bar\n
\N
foo bar\n
...
where \n deno
How about making goto-line suggest the number at point
as its default argument?
(defun goto-line (arg &optional buffer)
"Goto line ARG, counting from line 1 at beginning of buffer.
With just C-u as argument, move point in the most recently displayed
other buffer, and display it."
(interactive
A google search on "emacs turn off blinking cursor (without the quotes)
gives around 1 hits. That is 10 times more than a similar search
with "blinking cursor" replaced by "fringe", but only a fifth than the
search for "tool bar" or "menu bar".
That is persuasive evidence; I a
i'm doing some emacs-on-vms munging, and see a big "do not disturb"
block in fileio.c.
I don't know what you mean; I searched for the string
"do not disturb" but did not find it in fileio.c.
Would you please show me the message you're talking about?
__
On Fri, 04 Mar 2005 18:45:32 -0500, Richard Stallman <[EMAIL PROTECTED]> wrote:
> How about making goto-line suggest the number at point
> as its default argument?
That seems very convenient!
I think it may also be convenient if, point is not on a number, use
the first number on the current line
> How about making goto-line suggest the number at point
> as its default argument?
That seems very convenient!
I haven't yet received RMS's email, but yes, why not?
I think it may also be convenient if, point is not on a number, use
the first number on the current line as a
Richard Stallman wrote:
That is persuasive evidence; I am convinced. Since this does not
fit in the Show/Hide menu, let's add it at top level.
Would someone please do that?
Done.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gn
On Fri, 4 Mar 2005 16:49:13 -0800, Drew Adams <[EMAIL PROTECTED]> wrote:
> FYI - I don't suggest that `goto-line' itself should be changed this way,
> but the code I sent for `goto-line-at-point'
I think goto-line should do it. Remember, rms's suggestion is that
goto-line use the line number from
> FYI - I don't suggest that `goto-line' itself should be
> changed this way, but the code I sent for `goto-line-at-point'
I think goto-line should do it.
What is "it"? You cut off the rest of my sentence where I said what I meant
by "changed this way": use `number-nearest-point'. I
> Anyway, if it is a fact that both of these newlines are normally
> hard, then it seems to me that there is no way of telling
> whether the user wants a hard newline or a soft one
> when require-final-newline adds a newline.
> A user might save the file with an unfinished paragraph,
> then go back
Miles Bader wrote:
Also it looks like `goto-line' will get a convenient key-binding (M-o)...
In that case, it might confuse the user that this binding will be
shadowed in gnus (gnus-server-open-all-servers), dired-x
(dired-omit-mode), ibuffer (ibuffer-visit-buffer-1-window) ans ses
(ses-insert
On Fri, 4 Mar 2005 18:00:51 -0800, Drew Adams <[EMAIL PROTECTED]> wrote:
> Your suggestion to pick up the line number at bol might be acceptable to
> RMS, however. I think that the main pb he had with the "nearest" stuff was
> that its scope was not sufficiently constrained. That is not a pb with b
> On Fri, 04 Mar 2005 14:42:23 +0200, "Eli Zaretskii" <[EMAIL PROTECTED]>
> said:
>> I just installed some changes for the Carbon build on Mac OS 9.
> I think this warrants an entry in etc/NEWS (I didn't see such an
> entry among the changes you installed). It should go into the
> "Inst
39 matches
Mail list logo
