Re: Updating release version to 22.1

ch "." t t name))) name) (if (string-match "\\`[$]Revision: *\\([^ ]+\\) *[$]\\'" rev) (format "CVS-%s" (match-string 1 rev))) "unknown"))) "AUCTeX version. If not a regular release, CVS revis

Re: Updating release version to 22.1

and the question was whether one should invalidate this without concrete reason. There has been no previous talk about 21.5, in contrast, and in view of the facts it would be foolish to make the same mistake again. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Will CVS emacs need the Emacs-21.3 -> 21.4 patch or similar?

so if your operating setup does not use movemail (namely, if you don't use Emacs for reading mail). The Emacs executable is not involved in this problem. Anyway: the fix is in the trunk. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emac

Re: DONE: Updating release version to 22.1

n from 21.4 to 22.1 throughout. > > Change development version from 21.3.50 to 22.0.50. I have a release of preview-latex coming up the next days. Where this is an issue, I'll use a wording like "should be available with Emacs 22" now.

Re: Mention darwin as a possible value for system-type?

So even if we try to be semi-"politically correct" by deliberately making using unfree software more complicated with buggy documentation, more likely window-system rather than system-type should be affected. If there was a rationale, I'd prefer hearing instead of guessing it. -- David

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

subset that works. It is a bad idea to suggest to the user that he is gaining anything by tampering around himself: missing or too many parens, additional or missing quoting and so on can render a .emacs file completely inoperative. The whole story is there in the Emcas Lisp manual if you d

Re: texinfo.tex change.

should this turn out to make problems. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Should Emacs Setup Utilities for MS Windows be in Emacs CVS?

, also leading to increased feedback. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Updating release version to 22.1

t matter has been said and more than that. There is no use debating this further until Richard has the time and means to catch up. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

ue. The information is not encrypted, it is not binary. I have done so on occasion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs carbon crash, and beginner question...

ntly or if some OS function is the source of problem would be > very useful. I guess what I'm asking for is pointer to docs to > read, tips, etc, with the goal of getting a quick start into more > serious Emacs debugging. You could try looking into the etc/DEBUG f

Re: Mention darwin as a possible value for system-type?

"Eli Zaretskii" <[EMAIL PROTECTED]> writes: >> Cc: Nick Roberts <[EMAIL PROTECTED]>, emacs-devel@gnu.org >> From: David Kastrup <[EMAIL PROTECTED]> >> Date: Thu, 10 Feb 2005 11:10:54 +0100 >> >> > If `darwin' is the value on some

Re: Popup when buffer file is changed on disk

I think that in this case "modified buffers" was much more likely the intended meaning, and this should be changed accordingly. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: 21.4 not tagged in CVS

appen again. The solution would seem to have one branch where critical fixes are applied to regardless of whether a release is anticipated. I am not sure this would be something that in general would warrant the effort. This would have to be estimated by those that are capable

Re: IEEE single precision float values

r pointless (not to mention bug-prone) to go through all that Elisp when just typecasting the bit patterns should be enough. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Help with partial line needed

problem with fluxbox could be wrapped in a bug report and sent to the maintainers, this _could_ help. For me, the effect is not overly tragic since I usually don't use the toolbar, let alone detach it. Detached, I'd consider it quite more useful if it would be vertically

decode-coding-string gone awry?

m the process-sentinel, it mostly works, so it would appear to be dependent on some uninitialized stuff or similar that is different in the process sentinel. Anybody have a clue what might go wrong here? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: lisp-outline-level.

egexp) (- (match-end 0) (match-beginning 0))) as the last lines. This will return "nil" instead of a nonsensical value in case there is no match at point. I don't know how and where lisp-outline-level is used, so maybe some other value (1000?) would be more appropri

Re: lisp-outline-level.

Lute Kamstra <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> Lute Kamstra <[EMAIL PROTECTED]> writes: >> >>> In (Emacs) Lisp mode, outline-regexp is "* [^ \t\n]\\|(" and >>> outline-level is lisp-outl

Re: lisp-outline-level.

ing 0 or even (if preservation of match data is definitely not required) (defun lisp-outline-level (let ((len (- (match-end 0) (match-beginning 0 (if (looking-at ...) 1000 len))) -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: decode-coding-string gone awry?

Kenichi Handa <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, David Kastrup <[EMAIL PROTECTED]> writes: >> I have the problem that within preview-latex there is a function >> that assembles UTF-8 strings from single characters. This >> fun

Re: Tooltips on w32 slow and strange

s, nothing. So if there is a function for popping them up in the system, I can't see what we could lose by using it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: decode-coding-string gone awry?

> want EOL-conversion). I already mentioned that this _is_ exactly what we do already: the problem is that some TeX systems are set up to quote _some_ bytes from utf-8 in the ^^xx hexadecimal notation, and let some bytes through unchanged. It is completely braindead. The funny thing is

Re: Tooltips on w32 slow and strange

Miles Bader <[EMAIL PROTECTED]> writes: > On Mon, 14 Feb 2005 13:26:46 +0100, David Kastrup <[EMAIL PROTECTED]> wrote: >> At least the X11 tooltips on Emacs provide no functionality >> whatsoever except popping up some text in a single font AFAICS. No >> face sup

Re: Tooltips on w32 slow and strange

Ralf Angeli <[EMAIL PROTECTED]> writes: > * David Kastrup (2005-02-14) writes: > >> Miles Bader <[EMAIL PROTECTED]> writes: >> >>> Hmmm; here's a simple example: >>> >>>(x-show-tip >>> (propertize &q

Re: decode-coding-string gone awry?

cular, on a system that has all its language-environment set to accommodate utf-8? At what time does the decision whether a buffer is unibyte or multibyte get made? I guess that in the long run we will have to install something directly at filter level, with some CCL program processing the TeX ou

Re: decode-coding-string gone awry?

g into a multibyte buffer? 'raw-text is a reconstructible encoding, isn't it, so the stuff will get converted into some prefix byte indicating "isolated single-byte entity instead of utf-8 char" and the byte itself or something, right? And decode-encoding-string does not want

Re: Tooltips on w32 slow and strange

several platforms already, and it might also be possible for tooltips. However, I don't know how hard such a conversion would turn out, and I don't know whether there exist any serious applications that indeed require the interpretation of text properties for tooltips. -- D

Re: decode-coding-string gone awry?

to actually encode raw-text? >(regexp-quote (string-make-unibyte > (substring string 0 (match-beginning 1 > > which is basically equivalent except that you lose control over > which coding-system is used. I have to admit to being befuddled. I'l

Re: Tooltips on w32 slow and strange

onsidered. In my experience, X11 tooltips are currently fine in that regard, but the report from Windows users sounded alarming to me. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: decode-coding-string gone awry?

quot; utf-8 buffers I had, those that were created by decoding raw-text, there appeared latin-1 characters like the infamous à character. But maybe I am mistaken about that. I'll just experiment with the stuff a bit and probably use C-x = a lot. Thanks, -- David Kastrup, Kriemhildstr. 15, 4479

Re: decode-coding-string gone awry?

"encoding" raw-text, interpreting the escapes, and decoding to utf-8 or whatever else... But that's a secondary issue. We can try making something more sensible once we have the merger behind us. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: decode-coding-string gone awry?

al setup). That I was right now seeing the _expected_ \xxx sequences is quite likely entirely the fault of my X11 environment which for some completely unfathomable reason has LC_CTYPE=C set. I suspect a recent change to fluxbox, but have yet to find the culprit. -- David Kastrup, Kriemhildstr. 1

Re: Tooltips on w32 slow and strange

ing just why the machine does not react immediately. > But the other problem of focus changing when tooltips pop up is more > urgent, I think. That too... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: M-Tab on w32 (and other window systems?)

TAB a simple enough operation. Even though I am at the moment using Blackbox which does not intercept M-TAB at all. But I am used to Esc TAB, and don't find it hard to reach. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: decode-coding-string gone awry?

o make head or tails of the error at first, but without the error I would have looked elsewhere for the problem. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Printing menu hierarchies...

hierarchy for the use in manuals, too. But at the moment I am just interested in getting to separate the wheat from the chaff in active menu keymaps. What one can later make from it is another question. Thanks, -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: decode-coding-string gone awry?

ror contexts should really match (or I'll start weeping). It currently appears to work with all sane and insane combination of TeX quoting schemes, system language environments and Emacs language settings. Thanks for all the help here. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Popup when buffer file is changed on disk

ing like "Thus, Emacs might be non-responsive at times." Something like that. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Popup when buffer file is changed on disk

Luc Teirlinck <[EMAIL PROTECTED]> writes: > David Kastrup wrote: > >Well, Eli suggested "sluggish" instead of the negatively >connotated "hung" (which usually is used for a terminal error >condition), but I think that is misleading. I'd

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

buffer remains intact) for options. That would enable options to be changed temporarily, it would make the default of option changes permanent (like users are accustomed to), but if one is unsure about a setting, one simply does not save the option buff

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

of my own about how to do this consistently, but I won't argue them now: no point. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

xasserts and vertical motion.

flags for optimization, anyway). Those xasserts that replace visual cues with an aborting Emacs do not just make using Emacs for serious work harder, but they also actively _hinder_ debugging possibly occuring display problems. -- David Kastrup, Kriemhildstr. 15, 44

Wouldn't that be needed?

) gtk_widget_destroy (wfixed); + UNBLOCK_INPUT; + return 0; } -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: follow-link in grep buffer

utton for longer. That avoids following the link. How to teach this best is a different question. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: follow-link in grep buffer

uess that is less tragic than losing the obvious way of setting point? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: follow-link in grep buffer

have to set it to 'double. Actually, I was not talking about _configurable_ behaviors (though it is nice to know that it is configurable) but about the possibly best default setting. This "double click to launch" used to be a pretty common idiom at one time, though browsers have wat

Re: follow-link in grep buffer

Jason Rumney <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> I forgot: when we discussed the possible desirable behaviors, was >> follow-link-on-double-click among it? Isn't that sort of common >> for launching something?

Re: Parital scrolling of image

[EMAIL PROTECTED] (Kim F. Storm) writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >>>> a) an "open preview" that starts on a line of its own in preview-latex >>>> has an overlay starting at the beginning of the line. This overlay >>&g

Re: Request for site-lisp-directory

ions (probably with a newer version). I don't think there is much within Emacs itself that can be provided and result in consistently being of help here. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: tweak to apropos-command display

ather than " " Uh, how is it an improvement to leave off the "New file" information from the menu? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Request for site-lisp-directory

Piet van Oostrum <[EMAIL PROTECTED]> writes: >>>>>> David Kastrup <[EMAIL PROTECTED]> (DK) wrote: > >>DK> Piet van Oostrum <[EMAIL PROTECTED]> writes: >>>> I want to make a plea for a new lisp-level variable >>>> `site-lisp

Re: follow-link in grep buffer

hich case he'd know about them. That is the default behavior of most applications, and I don't see that the alternatives we have tried so far would be so much better as to warrant getting people used to them instead. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: follow-link in grep buffer

00 milliseconds if you want to follow the link, and it won't work if you have not the focus" will kill the "Emacs is usable for common human" proposition dead. Telling people "double click to follow some possible cross connection" will make them feel at home. -- David

Re: follow-link in grep buffer

the window-manager > would take care of those things (it should eat the "click-to-focus" > and not pass it on to the application). You are confusing frame and window. Changing the selected window is also necessary at times. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _

Re: follow-link in grep buffer

click action can be executed immediately, without delay or other disturbances. > - It should be at least as easy to follow a link as to set > point. For a button-like link. But not for whole lines. > In buffers that are primarily "view" buffers, as opposed to "edit", > it is tolerable if setting point is not quite as easy as following a > link. dired buffers are used for quite more than just selecting a file to view. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: follow-link in grep buffer

laced by dragging. But you are right in that one does not _need_ to teach it to people, and they are not worse off than with any other editor. It is ok if people discover the joys of Emacs not all at once. But we should try to avoid hitting them with unpleasant surprises right aw

Re: follow-link in grep buffer

f the meaning of a double click somehow "builds on" the meaning of a single click--which is recommended user interface design practice for double clicks. So it is rather obvious that even if there were not "prior art" for having a double click invoke an object-related action, and a single click just set point inside of an addressable area, the choice between those assignments is not arbitrary. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: follow-link in grep buffer

se in this proposal, in contrast to the complex, timing-dependent, rule-intensive, trick-requiring (like drag-if-you-don't-want-to-trigger-action) policy-violating, delayed-action-requiring other schemes that have both been proposed as well as implemented, I find somewhat surp

Re: follow-link in grep buffer

ated with customization possibilities. > Bad generalization. A better generalization is "Whenever David > discusses something, he screams like Howard Dean in Iowa." But > neither generalization is very good. Whatever. Enough people have pointed out by now that they

Re: follow-link in grep buffer

;t save time if he tries completing my sentences for me. And similar rules hold with computers, unless we are talking about seriously disabled users for which any correcting action takes lots of time. Only in that setting make complicated second-guessin

Re: Proposed alias.

Romain Francoise <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> I have quite often used `find-grep-dired' and it has been a >> nuisance that the more often needed `find-grep' is not available. >> I only discovered by

Core dumps in redisplay.

includes restoration of interrupt_input_blocked. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Possible bug in xfns.c

ing to dig for an abort. The above certainly is not involved in the abort, but while I am at it... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Another BLOCK_INPUT/record_unwind_protect/UNBLOCK_INPUT nesting

that is annoying me. Still... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Possible bug in xfns.c

"Jan D." <[EMAIL PROTECTED]> writes: > 2005-02-26 kl. 15.47 skrev David Kastrup: > >> >> Throwing a signal restores interrupt_input_blocked to the state of >> the recording of the stack frame. > > How does it do that? I can't find that in th

Re: Mysterious buffer switching

uence of breaking Pong. Which would be the fault of whatever Pong is. run-with-timer does not guarantee you any particular buffer. You can always make do with (run-with-timer 0.1 0.1 `(lambda () (with-current-buffer ,(current-buffer) (whateverfunction -- David Kastrup, Kriemhildstr. 15

Re: Another BLOCK_INPUT/record_unwind_protect/UNBLOCK_INPUT nesting

catch/throw. Sorry for that. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Core dumps in redisplay.

ly have to implement some kind of trace buffering for interrupt_input_block in order to get a hold of what is happening here. I already disassembled stuff because I thought the compiler might be at fault. Maybe I should also try without optimization. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum __

Re: Core dumps in redisplay.

ther variable is nonzero. Only a per-thread variable can be reset to a meaningful value. Could you elaborate on what happens here in parallel threads? I can't imagine that one can execute Lisp sanely in two threads, so one thread would be likely C-only? Why would

Re: Core dumps in redisplay.

riable, but rather make sure that no thread except the main thread will ever run code touching it. Correct? A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a bug. Correct? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Core dumps in redisplay.

i].adr = &&zap; tb[i].value = ++interrupt_input_blocked; \ while (0) into a header file. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

[gnu.emacs.help] Re: Compiling Emacs with GTK

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-RELEAS

Re: Core dumps in redisplay.

gt;> rather make sure that no thread except the main thread will ever run >> code touching it. Correct? >> >> A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a >> bug. Correct? > > Yes times three. xmalloc uses BLOCK_INPUT. BLOCK_INPUT is rath

Ok, somebody give me a clue.

that the problem is elsewhere, likely that the data structures I use above confuse the garbage collector. What kind of data structures are allowed, and how can I hide data structures that would confuse it from the garbarge collector? -- David Kastrup, Kriemhildstr. 15, 4479

Re: Tweak to key-description for menu bindings

[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 does

Re: Ok, somebody give me a clue.

[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 d

Re: Ok, somebody give me a clue.

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

Re: Core dumps in redisplay.

plains when we are in anything but the main thread. And then see whether we can get rid of all the resulting aborts in a sane manner. If we don't do this, I am afraid that we will be plagued with occasional unreproduceable aborts and/or problems. I also doubt that it is a good idea to have m

Re: Core dumps in redisplay.

. 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. What is the design? Should xmalloc be usable outside of the m

Re: Core dumps in redisplay.

conference Saturday and a workshop at a major TeX conference next week without having the demos crash. That's simply uncool. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Core dumps in redisplay.

hat calls xmalloc. Apparently a signal handler. I'd have an assertion get thrown if it were another thread. But I get my aborts not on the comparisons of the thread id. Ok, what is the beef with signal handlers? Are they supposed to ever throw a lo

Re: `face' widget type

e necessary to actually fix a minor bug properly. It might make sense to move that kind of fix to after the next release, and instead document the problem for the current release. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing

Disgusted...

culprit. That shall teach me to debug with optimizations on... Source code debugging is deceptive. You would not believe the amount of trace/debug code I inserted everywhere... Ok, let's see whether I find the real culprit. -- David Kastrup, Kriemhildstr. 15, 44793 B

Ok, here is the bug I have been looking for. Kim, not Jan...

= 0; } I suppose that the reseat_1 in move_it_vertically_backward will move forward again. Something like that. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Putting blink-cursor-mode in Options menu.

nds? They could then read the man-page before even starting Emacs. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Putting blink-cursor-mode in Options menu.

This would probably be something for which a poll would be required. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: xasserts and vertical motion.

#x27;ll mention that option in the debugging instructions if it is not already there. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

UNBLOCK_INPUT again...

somebody with somewhat more of a clue than myself say something soothing? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

xassert in dispextern.h

y see no purpose why the xasserts are enabled by default. It does not look like they are giving us better debuggable or reproducible error symptoms than leaving them off, and they are keeping people from being able to help pretesting Emacs. -- David Kastrup, Kriemhilds

Re: Putting blink-cursor-mode in Options menu.

only safe way people will have a chance to arrive at a working Emacs without suffering a heart attack or epilepsy or blindness or whatever beforehand. > _Every_ option is supposed to be completely irrelevant to the > majority of people. If not, the default is wrong. So you say that a car nee

Re: xassert in dispextern.h

David Kastrup <[EMAIL PROTECTED]> writes: > Would it be possible to change the default of xassert to a noop in > dispextern.h again? This would be the following one-liner coupling the xasserts with GLYPH_DEBUG. --- dispextern.h 26 Feb 2005 02:26:33 +0100 1.197 +++ dispextern.h 01 Ma

Re: xassert in dispextern.h

David Kastrup <[EMAIL PROTECTED]> writes: > Would it be possible to change the default of xassert to a noop in > dispextern.h again? I am asking this because of the following > reasons: I forgot reason e): I hear from developers that they actually turn this off in order to have

Re: Putting blink-cursor-mode in Options menu.

Luc Teirlinck <[EMAIL PROTECTED]> writes: > David Kastrup wrote: > >Because it is a visual feature that you want to see or not. > > So are "Syntax Highlighting", "Active Region Highlighting" and > "Paren Match Highlighting". But they

Re: Putting blink-cursor-mode in Options menu.

rm has a static block cursor, and practically all other editing applications have a blinking vertical line. > only a few experienced Emacs users who use nothing else will be > offended by the blinking, and they can easily figure out how to > disable it. I think it belongs in the same category

Re: xassert in dispextern.h

Jason Rumney <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> That's completely backwards. > > What's completely backwards is to turn off a feature that helps us > find bugs so that people can treat the CVS HEAD as a stable re

Re: xassert in dispextern.h

not make progress, it is easy enough to use another one. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: xassert in dispextern.h

[EMAIL PROTECTED] (Kim F. Storm) writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> Feel free to volunteer any differing information if you have it >> available. If you know of any problem in the last 4 weeks that has >> been discovered and fixed due to th

Re: Key binding M-g should really be goto-line

r much (The Esc M-: binding is available as M-:, anyway). I think that would be a good escape route for text processing commands. I certainly would like to see M-g for goto-line. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Ok, here is the bug I have been looking for. Kim, not Jan...

[EMAIL PROTECTED] (Kim F. Storm) writes: > [EMAIL PROTECTED] (Kim F. Storm) writes: > >> David Kastrup <[EMAIL PROTECTED]> writes: >> >>> With -fno-crossjumping, the real assert came to light. >>> >>> It is xdisp.c in line 6122: > > In

  1   2   3   4   5   6   >