In article <[EMAIL PROTECTED]>, Luc Teirlinck <[EMAIL PROTECTED]> writes:
> There is something that has not been pointed out in the summary Handa
> gave, but which I believe may be relevant. If I understood correctly,
> the problem in question will automatically completely disappear with
> Unicod
First I got this:
NMAKE temacs
CFLAGS="-I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -nologo -D_X86_=1 -c
-Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 -Zi -Di386 -D_CRTAPI1=_cdecl -Demacs=1
-DWINDOWSNT -DDOS_NT -
DHAVE_CONFIG_H -I../nt/inc -D_UCHAR_T -DHAVE_NTGUI=1 -DPURESIZE=500"
Mic
MJ Chan <[EMAIL PROTECTED]> writes:
> ... When the window is wider than the image itself,
> cursor moving has no problem (see the first attachment). However, if I
> resize the window to make it smaller than the image (red arrows will
> be shown in the right fringe area, see the second attachment),
> On the slowest machine that I have access to, a 500MHz P3 the
> xterm.elc load time (as reported by elp) goes from 2.2 seconds to 0.3
> seconds if all the substitute-key-definition calls are moved before
> (let ((map (make-sparse-keymap)))
This change makes Emacs load much more quickly.
Th
> There is something that has not been pointed out in the summary Handa
> gave, but which I believe may be relevant. If I understood correctly,
> the problem in question will automatically completely disappear with
> Unicode and hence with Emacs 23. (Unless I misunderstood.)
Indeed,
St
I fixed this. Thanks.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
> As of a few days ago, the cc-mode in cvs emacs seems to preprocess the
> source file in order to determine the C macros present.
>
> There are two things wrong with this:
> 1) it uses /lib/cpp unconditionally, but the use of the -dM switch
> suggests it currently requires gcc (at least, /l
> "Nick" == Nick Roberts <[EMAIL PROTECTED]> writes:
> xterm.el makes Emacs take about seven times as long to load for me (about 14
> seconds on my 200MHz PC). I have tested this by setting term-file-prefix to
> nil as described in startup.el
> I think this is due to the recent changes in xte
This is a little strange.
(assq 'copy (lookup-key global-map [menu-bar edit]))
--> (copy "Copy" "Copy text in region to the clipboard" ([16777315] . "
(H-c)") . clipboard-kill-ring-save)
What does this 16777315 do there? Is it supposed to be there??
Interestingly, it doesn't happen consistently.
Symptoms:
I built Emacs from CVS by doing
cd mac
./make-package
I removed my .emacs.el file
I started Emacs by clicking the icon from the Applications
folder
I typed "ho ho ho" into the scratch buffer, then C-x h M-w
I then saw the error that I mentioned in the Subject.
In G
There is something that has not been pointed out in the summary Handa
gave, but which I believe may be relevant. If I understood correctly,
the problem in question will automatically completely disappear with
Unicode and hence with Emacs 23. (Unless I misunderstood.)
Sincerely,
Luc.
_
(I'm not on the list so please CC replies)
When I press C-g in gnus, emacs almost always aborts (pretty much
crashing). I'm not sure exactly why waiting_for_input is 1, or the
meaning of it being 1 at this instance.
This is really annoying because whenever I use gnus, I have to be
careful about n
mkdir obj-spd
mkdir "obj-spd/i386"
cl -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -nologo -D_X86_=1
-c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 -Zi -Di386 -D_CRTAPI1=_cdecl -Demacs=1
-DWINDOWSNT -DDOS_NT -DHAVE_CONFIG_H -I..
/nt/inc -D_UCHAR_T -DHAVE_NTGUI=1 -DPURESIZE=50
On 4/29/05, Johan Bockgård <[EMAIL PROTECTED]> wrote:
> What's the rationale behind how the commands beginning-of-line,
> end-of-line, move-beginning-of-line and move-end-of-line deal with
> fields?
To make fields seem like "fields" -- that is, a coherent "input
region" in the midst of non-input t
Richard Stallman <[EMAIL PROTECTED]> writes:
> Side note: one thing that would be nice is if emacs would always crash
> instead of aborting...sometimes I run it outside of gdb and
> aborting is like exiting cleanly (I think?) so there is no way
> to figure out what went
Title: PayPal
You're
Billing Information!
Dear PayPal Member,
It has come to our attention that your PayPal Billing Information
records are out of date. That r
Nick Roberts <[EMAIL PROTECTED]> writes:
> xterm.el makes Emacs take about seven times as long to load for me (about 14
> seconds on my 200MHz PC). I have tested this by setting term-file-prefix to
> nil as described in startup.el
>
> I think this is due to the recent changes in xterm.e
> On the slowest machine that I have access to, a 500MHz P3 the
> xterm.elc load time (as reported by elp) goes from 2.2 seconds to 0.3
> seconds if all the substitute-key-definition calls are moved before
> (let ((map (make-sparse-keymap)))
That's a good point: the keys we want to substitute are
Suppose I start with a single window called W1 (window names are
fictional)
W1
split W1 horizontally
W1 | W2
split W2 vertically
| W2
W1 |---
| W3
delete W1
W2
--
W3
split W2 horizontally
W2 | W4
---
W3
split W4 vertically
| W4
W2 |---
| W5
---
W3
and delete W2
W4
--
W5
--
I fixed this. Thanks.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Since the list server is down this weekend, I'm sending this to you
FYI. The effect is very robust and very annoying, because after
changing some menu items, stuff in the Edit menu doesn't work any more
and gives me an error (wrong argument commandp).
I've been poking around trying to trace thi
$B"v!&!yL5NAEPO?%-%c%s%Z!<%sCf!y!&"v(B
$B!!$d$C$Q$j=P0)$&$J$i$46a=j$G2q$($kAjhttp://www.jumpb2.net/?imasugu
$B!!%3%3$K%"%I8x3+$GBT$C$F$$$k$46a=jL<$,$$$C$Q$$(B(o^$B"O(B^o)[EMAIL
PROTECTED]&!&(B
$BEPO?8e(B5$BJ,0JFb$K$46a=j$G2q$([EMAIL PROTECTED]>R2pCW$7$^$
From the Elisp manual:
-- Function: add-to-invisibility-spec element
This function adds the element ELEMENT to
`buffer-invisibility-spec' (if it is not already present in that
list). ...
But the element is added unconditionally:
(defun add-to-invisibility-spec (arg)
...
(setq bu
23 matches
Mail list logo
