Hi,
In some cases, `texinfo-format-buffer' doesn't fold long lines.
For example, try the following and you can see how it does.
;--8<---cut here---start->8---
(with-temp-buffer
(insert "@setfilename testing
@node Top
@itemize @bullet
@item
foo
@enumerate 1
@i
Lute Kamstra <[EMAIL PROTECTED]> writes:
[...]
> I investigated this problem a bit more. It seems that the bug only
> happens when the body of a function contains just one sexp. For
> example, when I do:
>
> (defun fun (a) "Docstring." (interactive) (1+ a))
> (debug-on-entry 'fun)
> (fun
Forwarded here. Can anyone make use of this information?
--- Begin Message ---
David Kastrup <[EMAIL PROTECTED]> wrote:
>> [...]
>> Is there an approximate date for the 22.1 release?
>
> When the
> http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/admin/FOR-RELEASE?rev=HEAD>
> file has been s
I've updated lispref/debugging.texi. Shall I commit my changes?
Lute.
2005-02-28 Lute Kamstra <[EMAIL PROTECTED]>
* debugging.texi (Debugging): Fix typo.
(Error Debugging): Document eval-expression-debug-on-error.
(Function Debugging): Update example.
(Using D
"Jan D." <[EMAIL PROTECTED]> writes:
>>
>> 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 except th
What I don't understand in why debug-on-entry and
cancel-debug-on-entry call debugger-reenable as well (thus causing the
strange behavior in the example above). What am I missing?
I am not certain. Perhaps the idea was in case you do
debugger-jump but you don't reenter the debugger.
I don't have time to find out.
Will you have time in the future?
Can you tell us some advice?
I think nobody but you really understands this code.]
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Wait for around five seconds. You will see:
Foo: .emacs
You need to have font-lock enabled, and there has to be a long fontified
buffer lurking around somewhere. My guess is that the font-lock engine is
doing stuff while waiting for input, which causes current-buffer to be
Richard Stallman <[EMAIL PROTECTED]> writes:
> I don't have time to find out.
>
> Will you have time in the future?
Things I don't do right away tend not to be done at all, or many years
later.
> Can you tell us some advice?
> I think nobody but you really understands this code.]
My advice
Werner LEMBERG <[EMAIL PROTECTED]> writes:
>> Can you give a full procedure starting with emacs -Q that exhibits
>> the error.
>
> Execute this in a fresh buffer:
>
> (setq buffer-display-table (make-display-table))
>
> then copy
>
> SGVsbG8sDQogICBJIHdhbnQgdG8gYW5kIEdCMjMxMiB0byBhIGZvbnQgZmlsZS
For debugging purposes, I have been using the following:
struct trbuf { void* pc; int value; } trbuf[256];
unsigned char trptr;
#define RECORD_INPUT do { __label__ woozle; \
woozle: trbuf[trptr++] = (struct trbuf) \
{ &&woozle, interrupt
David Kastrup <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Kim F. Storm) writes:
>
>> It also improves handling of menu bar entries in two ways:
>>
>> 1) If menu-bar-mode is disabled, it doesn't mention menu bar bindings.
>>
>> 2) It pretty prints menu bar entries like this:
>> e.g. "File
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] (Kim F. Storm) writes:
>>
>>> It also improves handling of menu bar entries in two ways:
>>>
>>> 1) If menu-bar-mode is disabled, it doesn't mention menu bar bindings.
>>>
>>> 2) It pretty p
Title: l
Opt-in Email Special Offer unsubscribe
me
SEARCH
> I.e. now is entirely the wrong time to start improving the customize UI.
Couldn't agree more,
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> Pong ought to be fixed to avoid depending on this,
> but it wouldn't hurt to remove this source of unpredictability.
> Does this patch do the job?
Yes.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Hello,
Is there someone using TLA over proxy to access GNU Emacs repositories? I
changed my job and have now landed myself in a company with a stricter
firewall! I have access to internet (which is not given to all!!) and can
make use of HTTP port only over a PROXY server. I never imagined
> Is there someone using TLA over proxy to access GNU Emacs repositories? I
> changed my job and have now landed myself in a company with a stricter
> firewall! I have access to internet (which is not given to all!!) and can
> make use of HTTP port only over a PROXY server. I never imagined
[ Sorry I do not speak Japanese and neither do I read the macemacsjp-dev
mailing-list, so please reply to [EMAIL PROTECTED] ]
Hi, I'm an Emacs maintainer and I was recently reminded of the existence of
separate development branches for Carbon Emacs code.
As an Emacs maintainer, I'd just like to
David Kastrup <[EMAIL PROTECTED]> writes:
> For debugging purposes, I have been using the following:
>
> struct trbuf { void* pc; int value; } trbuf[256];
> unsigned char trptr;
> #define RECORD_INPUT do { __label__ woozle; \
> woozle: trbuf[trptr++] = (struct trbuf)
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 except the main thread will ever run
code
Katsumi Yamaoka <[EMAIL PROTECTED]> wrote,
In some cases, `texinfo-format-buffer' doesn't fold long lines.
... It happens because someone added "itemize\\|" to
`texinfo-no-refill-regexp' as follows:
(defvar texinfo-no-refill-regexp
Yes, the inclusion of "itemize\\|" tells Emacs not
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> For debugging purposes, I have been using the following:
>>
>> struct trbuf { void* pc; int value; } trbuf[256];
>> unsigned char trptr;
>> #define RECORD_INPUT do { __label__ woozle; \
>> woozle: trbuf[trp
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> For debugging purposes, I have been using the following:
>>
>> struct trbuf { void* pc; int value; } trbuf[256];
>> unsigned char trptr;
>> #define RECORD_INPUT do { __label__ woozle; \
>> woozle: trbuf[trp
- Original Message -
From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> > However I can
> > not see how hourglass support can be implemented at all if those places
> > where you hide or show the hourglass is ifdef:ed away. Both
start_hourglass
> > and cancel_hourglass are ifdef:ed away (unless H
Andreas Schwab <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Kim F. Storm) writes:
>
>> David Kastrup <[EMAIL PROTECTED]> writes:
>>
>>> For debugging purposes, I have been using the following:
>>>
>>> struct trbuf { void* pc; int value; } trbuf[256];
>>> unsigned char trptr;
>>> #define RECORD
Richard Stallman <[EMAIL PROTECTED]> writes:
> What I don't understand in why debug-on-entry and
> cancel-debug-on-entry call debugger-reenable as well (thus causing the
> strange behavior in the example above). What am I missing?
>
> I am not certain. Perhaps the idea was in case yo
You can set the variable debugger to your homebrew debugger to use
that instead of the default 'debug. However, this works only when the
debugger is invoked from C. The lisp functions
{cancel-,}debug-on-entry still use debug. What about setting
debug-entry-code to this?
'(unless inhibit-debug
"Jan D." <[EMAIL PROTECTED]> writes:
>>
>> 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 except th
"Jan D." <[EMAIL PROTECTED]> writes:
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 except the main thread w
"Jan D." <[EMAIL PROTECTED]> writes:
>> "Jan D." <[EMAIL PROTECTED]> writes:
>>
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 va
>> Meanwhile, it would be nice and clean if redefining a function
>> with defun, defmacro, defsubst or defalias were smart enough
>> to turn debug-on-entry back on if it was on before.
>> Want to do that?
> Ok, I'll look into it.
IIRC defadvice has some support for such things (e.g. you can add an
Hello Stefan,
> CVSROOT: /cvsroot/emacs
> Module name: emacs
> Branch:
> Changes by: Stefan Monnier <[EMAIL PROTECTED]> 05/02/28 14:33:50
>
> Modified files:
> lisp/emacs-lisp: debug.el
>
> Log message:
> (inhibit-debug-on-entry): New var.
> (debug): Use it.
Hi Kenichi Handa,
Kenichi Handa writes:
> I've just installed these fixes.
Thanks.
> but we must set 4 for XXX-with-signature.
Really? I thought XXX-with-signature just adds 2 additional bytes,
regardless how long the string is. That should be covered by "+
CONVERSION_BUFFER_EXTRA_ROOM" (==
But xmalloc and all related routines use BLOCK_INPUT nevertheless. So
it is obvious that although malloc seemingly can be used (given _BOTH_
PTHREAD and GTK) without problems, all uses of xmalloc still are
flawed in the old way.
So we still can't allow using xmalloc except in the main thread. Wha
"Jan D." <[EMAIL PROTECTED]> writes:
>> But xmalloc and all related routines use BLOCK_INPUT nevertheless. So
>> it is obvious that although malloc seemingly can be used (given _BOTH_
>> PTHREAD and GTK) without problems, all uses of xmalloc still are
>> flawed in the old way.
>>
>> So we still c
"Jan D." <[EMAIL PROTECTED]> writes:
But xmalloc and all related routines use BLOCK_INPUT nevertheless.
So
it is obvious that although malloc seemingly can be used (given
_BOTH_
PTHREAD and GTK) without problems, all uses of xmalloc still are
flawed in the old way.
So we still can't allow using
"Jan D." <[EMAIL PROTECTED]> writes:
>> You wish.
>
> No. I know. The only way the other threads can call xmalloc is if a
> signal handler is called in a non-main thread and then calls xmalloc.
> This should not happen, but if it does there is a bug somewhere.
>>
>
>> I am putting appropriate ass
Richard Stallman wrote:
Can anyone think of a non-obsolete use for keyboard-translate-table,
> to put in the example?
If you want C-x, C-c and C-v do cut, copy and paste without the IMHO
confusing overloading done by CUA-mode, you can simply do
(keyboard-translate ?\C-x 'control-x)
(keyboard-tran
In some cases, `texinfo-format-buffer' doesn't fold long lines.
texinfo-format-buffer is more or less obsolete; you should use
makeinfo instead.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Would people please take a look at this and tell me what they think of it?
I would like to hear the opinions of more than one person.
--- Start of forwarded message ---
Content-class: urn:content-classes:message
Date: Mon, 28 Feb 2005 10:13:28 +0100
X-MS-Has-Attach: yes
Thread-Topic: dired
My advice would be to delay any improvement (except for fixing
regressions) until you are at the *start* of a development phase.
We're talking about three kinds of cases: fixing old bugs, fixing new
bugs, and changes that are not bug fixes. You're grouping the first
case with the third; I
Since this is implemented in key-description, it will show the new
format in all contexts, e.g. for C-h a, C-h k, C-h w, etc.
Another example:
Old:
New:
Options=>Mule (Multilingual Environment)=>Set Coding Systems=>For Next
Command
Shall I install this?
> In some cases, `texinfo-format-buffer' doesn't fold long lines.
> texinfo-format-buffer is more or less obsolete; you should use
> makeinfo instead.
Should we move it lisp/obsolete?
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.or
Richard Stallman <[EMAIL PROTECTED]> writes:
> My advice would be to delay any improvement (except for fixing
> regressions) until you are at the *start* of a development phase.
>
> We're talking about three kinds of cases: fixing old bugs, fixing new
> bugs, and changes that are not bug f
> In <[EMAIL PROTECTED]> Stefan Monnier wrote:
>> In some cases, `texinfo-format-buffer' doesn't fold long lines.
>> texinfo-format-buffer is more or less obsolete; you should use
>> makeinfo instead.
> Should we move it lisp/obsolete?
No, please never do so! The makeinfo command doesn'
> From: "Lennart Borgman" <[EMAIL PROTECTED]>
> Cc:
> Date: Mon, 28 Feb 2005 16:57:26 +0100
>
> What I was trying to say was this (that it probably are conditioned for X)
> and that it is a problem because with
> #ifdef HAVE_X_WINDOWS
> around hourglass activation/deactivation you can only ge
Richard Stallman <[EMAIL PROTECTED]> writes:
> Old:
>
>
> New:
>Options=>Mule (Multilingual Environment)=>Set Coding Systems=>For Next
> Command
> It seems like marginally an improvement, but since this isn't fixing a bug,
> I'd rather not install this change now.
I'll respect th
> In <[EMAIL PROTECTED]> Robert J. Chassell wrote:
> I have commented out that inclusion and committed the change.
> So `texinfo-format-buffer' should work again as you expect.
Thank you very much for that. It works fine now.
> As I wrote at the time I included it
> ... I don't think t
- Original Message -
From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> > From: "Lennart Borgman" <[EMAIL PROTECTED]>
> > I suggest removing the "#ifdef HAVE_X_WINDOWS" completely or (which I
> > believe most would like better - but not I) replacing them with
something
> > like
> >
> > #ifde
To some people, for instance me, having to watch a blinking cursor
produces real discomfort. I do not know what percentage of people
react the same way to it, but I know from other people's reactions
that I am not the only person like that. Anybody just starting to
learn Emacs should be able to d
After all the hassle of BLOCK_INPUT/UNBLOCK_INPUT and my inability to
figure out the problem, I finally noticed that all xasserts in the
routine in question get folded into the same abort call. The debugger
chooses an arbitrary xassert when I go up the stack frame and claims
that it is the culpri
> Date: Tue, 01 Mar 2005 08:57:07 +0900
> From: Katsumi Yamaoka <[EMAIL PROTECTED]>
> Cc: emacs-devel@gnu.org
>
> > ... I don't think this fix should be used as is.
>
> > Evidentally, back in November 2001, a user in FSF India could not
> > format the then new edition of `emacs-lisp-intro.tex
With -fno-crossjumping, the real assert came to light.
It is xdisp.c in line 6122:
/* The function move_it_vertically_backward may move over more
than the specified y-distance. If it->w is small, e.g. a
mini-buffer window, we may end up in front of the window's
display area. S
> In <[EMAIL PROTECTED]> Eli Zaretskii wrote:
>> I see, and I will have to keep in mind that there might still be
>> need to fix the [EMAIL PROTECTED] [EMAIL PROTECTED]' problem.
> I'd rather not have us fix a problem by reintroducing another problem
> that we fixed in the past. Isn't there
55 matches
Mail list logo
