David Kastrup [EMAIL PROTECTED] writes:
When I have overlapping frames and issue a command in the lower frame
that will cause the minibuffer to be extended in size (here:
emacs-version), then after the resize, there is redraw cruft in the
lower frame (which disappears once the minibuffer is
Katsumi Yamaoka [EMAIL PROTECTED] writes:
When I run `customize-option', I don't see the Set button in
the Custom buffer. Maybe this is caused by the recent changes
in cus-edit.el.
It's been moved to the toolbar.
___
emacs-pretest-bug mailing
Nick Roberts [EMAIL PROTECTED] writes:
Jason Rumney writes:
Peter Wisnovsky wrote:
In GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600)
Loading semantic-edit...done
Loading semanticdb-file...done
Emacs 21.1 has been released, so please use that rather than a pretest
Juanma Barranquero [EMAIL PROTECTED] writes:
On 6/6/07, YAMAMOTO Mitsuharu [EMAIL PROTECTED] wrote:
In xpm_load (if HAVE_XPM and ALLOC_XPM_COLORS), xpm_init_color_cache
is called twice without an intervening xpm_free_color_cache call, and
that causes a memory leak ~4KB per XPM image
Dan Nicolaescu [EMAIL PROTECTED] writes:
Is this really desirable? With this change, ChangeLog.sh (for
instance) opens in change-log-mode rather than shell script mode.
Maybe we should either revert this change (and use file variables to
specify the mode for ChangeLog.unicode and
The following patch, which was only checked into the trunk, changed
the change-log-mode entry in auto-mode-alist:
2007-05-19 Dan Nicolaescu [EMAIL PROTECTED]
* files.el (auto-mode-alist): Change the regexp so that
ChangeLog.unicode and ChangeLog.multi-tty use change-log-mode.
Richard Stallman [EMAIL PROTECTED] writes:
So I propose undoing the latest change for x_set_name_internal for
now.
If my change broke something, then please undo it; but in that case,
please put in whatever GCPROs are needed for x_encode_text.
The GCPRO you added in x_encode_text
MIYOSHI Masanori [EMAIL PROTECTED] writes:
In GNU Emacs 22.0.990 on Windows, when the cursor is moved up to
the taller line, it sometimes jumps back to the center of the
window.
This is due to a small change in paren.el that I made in April to work
around the recentering-on-continued-lines
Richard Stallman [EMAIL PROTECTED] writes:
Thanks for guessing this.
After your change, there was another similar bug:
x_encode_text can call Lisp code, which would have needed a GCPRO.
After looking at it, I realized there was no need to call
x_encode_text in the GTK case. So I separated
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes:
On Fri, 01 Jun 2007 10:51:12 -0400, Richard Stallman [EMAIL PROTECTED]
said:
After looking at it, I realized there was no need to call
x_encode_text in the GTK case. So I separated the two cases
completely, which should improve things.
I'm
Chong Yidong [EMAIL PROTECTED] writes:
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes:
After looking at it, I realized there was no need to call
x_encode_text in the GTK case. So I separated the two cases
completely, which should improve things.
I'm not so familiar with GTK+, but is the call
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes:
I looked at the GTK+ sources. Apparently, if we don't set
WM_ICON_NAME ourselves, gtk_window_set_icon_name sets WM_ICON_NAME
for us. So I think we are perfectly safe.
But now we can't set the icon title separately from the frame title
using the
Richard Stallman [EMAIL PROTECTED] writes:
Should this fix be installed in Emacs 22.1?
Or is it safer for us to leave that bug unfixed?
I suggest not patching Emacs 22.1 at this time.
First, this only affects setting font-lock-keywords in local
variables, which is an advanced user activity
martin rudalics [EMAIL PROTECTED] writes:
(set (make-local-variable 'font-lock-keywords)
! (font-lock-eval-keywords (or keywords font-lock-keywords)))
Wouldn't this mean that old keywords survive a major-mode change?
What about the companions in `font-lock-defaults'? In
Reiner Steib [EMAIL PROTECTED] writes:
report-emacs-bug wrote:
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
My Emacs session which has been already running for several days
(notebook with suspend to disk) crashed. I don't recall which command
Richard Stallman [EMAIL PROTECTED] writes:
I think it should instead say something like:
`fontified'
This property says whether the text is ready for display. If nil,
Emacs's redisplay routine will call the `fontification-function' (which
see) to prepare this
Richard Stallman [EMAIL PROTECTED] writes:
Font-lock-keywords can not be set any more in the local variables
section of a file. Use font-lock-defaults instead.
I find the change in behavior sufficiently mysterious that I'm
not even sure this characterization is
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes:
On Fri, 01 Jun 2007 10:05:41 +0900, YAMAMOTO Mitsuharu [EMAIL
PROTECTED] said:
I think this is due to string data relocation caused by ENCODE_UTF_8
in x_set_name_internal (GTK+ only).
GCPRO was missing in the previous patch. Below is a revised
martin rudalics [EMAIL PROTECTED] writes:
I couldn't reproduce it on Mac OS X. It only shows an error like
forward-list: Scan error: Containing expression ends prematurely
OK. To prevent this I'd apply something like the attached patch (low
priority).
I think it's cleaner to put the
martin rudalics [EMAIL PROTECTED] writes:
I think it's cleaner to put the condition-case outside. Does this
work for you?
Good. Eventually, someone could try to avoid theses scans when it's
easy to determine that they fail.
I've checked it into the branch.
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes:
Maybe you need to use specbind for the `current_column' call in
redisplay_internal instead.
*** src/xdisp.c.~1.1149.2.2.~ Fri May 25 11:00:00 2007
--- src/xdisp.c Sun May 27 22:48:48 2007
*** redisplay_internal
Chong Yidong [EMAIL PROTECTED] writes:
Maybe you need to use specbind for the `current_column' call in
redisplay_internal instead.
*** src/xdisp.c.~1.1149.2.2.~Fri May 25 11:00:00 2007
--- src/xdisp.c Sun May 27 22:48:48 2007
*** redisplay_internal
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes:
I meant the only direct call to `current_column' from
redisplay_internal:
/* If %c is in the mode line, update it if needed. */
if (!NILP (w-column_number_displayed)
/* This alternative quickly identifies a common case
where no
MIYOSHI Masanori [EMAIL PROTECTED] writes:
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
martin rudalics [EMAIL PROTECTED] writes:
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html/html
jpff [EMAIL PROTECTED] writes:
I reverted to the previous version of xterm and it runs.
With the newer xterm it crashed when using X bit ran in -nw mode in an
xterm. Suggests that the last change for Yet Another Uncaught X
Error Crash is the cause but this is beyond my expertise
I reverted
Eli Zaretskii [EMAIL PROTECTED] writes:
From: Romain Francoise [EMAIL PROTECTED]
Date: Sun, 06 May 2007 01:06:31 +0200
Cc: emacs-pretest-bug@gnu.org
Chong Yidong [EMAIL PROTECTED] writes:
Is it on the branch? If so, that would be extremely annoying. This
kind of change obviously
Richard Stallman [EMAIL PROTECTED] writes:
Is it on the branch? If so, that would be extremely annoying. This
kind of change obviously shouldn't be made without discussion.
The reason I have mostly stopped discussing changes with people is
that I expect them to respond mechanically
Nick Roberts [EMAIL PROTECTED] writes:
2007-05-03 Per Cederqvist
* process.c (Faccept_process_output): Revert 2006-03-22 change so
that the third argument once again is in microseconds (not
milliseconds). This makes it compatible with Emacs 21 and
earlier. Problem
Juanma Barranquero [EMAIL PROTECTED] writes:
On 4/27/07, Stefan Monnier [EMAIL PROTECTED] wrote:
While I can imagine myself doing it, I don't remember taking anything from
the version of your website. Did anybody else do that?
Excluding lines by you, and removing trivial changes to
Stefan Monnier [EMAIL PROTECTED] writes:
However, 1.40 (2006-08-20) by you is extensive and the changelog says
Update to Dave Love's latest version. Was this directly from him?
Ahh... I guess my memory failed. We should revert this change, then.
Could you do this?
Anyway, back to the topic at hand: there's a potential legal problem
with python.el. Is all the code you wrote for python.el affected, or
just the 2006-08-20 changes? Before that, there are no changes from
python.el from you until we get to 2004-12-02.
Only more recent stuff, I reckon, but
Richard Stallman [EMAIL PROTECTED] writes:
Please install your patch.
I installed the patch.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Nick Roberts [EMAIL PROTECTED] writes:
Info-scroll-up/down are bound on the mode-line (over the node name) to
mouse-1 and mouse-3. However, in a split window configuaration with Info at
the top and the bottom window selected, clicking there scrolls the _bottom_
window, and Emacs gets
Glenn Morris [EMAIL PROTECTED] writes:
Anyway, back to the topic at hand: there's a potential legal problem
with python.el. Is all the code you wrote for python.el affected, or
just the 2006-08-20 changes? Before that, there are no changes from
python.el from you until we get to 2004-12-02.
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
In the attached images I have one overlay one character long that has
a red underline.
In the code you provide, the overlay is two characters long, not one.
If you make the overlay span 3 to 4, everything works fine.
(defun test-me()
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
In the attached images I have one overlay one character long that has
a red underline.
In the code you provide, the overlay is two characters long, not one.
If you make
Luc Teirlinck [EMAIL PROTECTED] writes:
I suggest the following small changes to the Changelog (mainly for the
benefit of people who might want to find out when the optional arg for
locate was introduced), as well as the adding of an additional comment
to locate.el
Checked in, thanks.
There are potential problems due to my previous employer with things I
wrote until I left in April 2006. I'm contractually obliged to inform
the FSF about that, whether or not I consider it spurious or actually
care about GNU.
Do these potential problems apply also to, e.g., this patch that
Francesco Potorti` [EMAIL PROTECTED] writes:
Calling C-u M-x locate RET gives no results, whatever the command line.
A bug was apparently introduced in locate.el, but I did not check when
and why. I found the problem in 22.0.96, but, by looking at the source,
it is still there in 22.0.98.
Francesco Potorti` [EMAIL PROTECTED] writes:
Now, when desktop.el loads it, it asks if I want to apply the
font-lock-keywords customisation, because it is risky (is it?).
Font-lock can modify arbitrary text properties, such as display
strings, and not just faces. So one can imagine a trojan
Francesco Potorti` [EMAIL PROTECTED] writes:
I answer y, but I get the message: Toggling font-lock-mode off;
better pass an explicit argument.
This is done in `hack-one-local-variable' where
(funcall mode)
simply executes `font-lock-mode' which toggles font-lock mode off since
Luc Teirlinck [EMAIL PROTECTED] writes:
Francesco Potorti` [EMAIL PROTECTED] wrote:
A bug was apparently introduced in locate.el, but I did not check when
and why.
That was not the only bug introduced by the following change:
2006-09-09 Matt Hodges [EMAIL PROTECTED]
*
Stefan Monnier [EMAIL PROTECTED] writes:
Now, when desktop.el loads it, it asks if I want to apply the
font-lock-keywords customisation, because it is risky (is it?).
Font-lock can modify arbitrary text properties, such as display
strings, and not just faces.
And it can also directly run
Luc Teirlinck [EMAIL PROTECTED] writes:
Undo no longer works in a locate buffer. This is a serious bug and a
regression in Emacs 22 if it does not get fixed. You are supposed to
be able to do essentially everything you can do in a dired buffer
(including undo) in a locate buffer. That is
Luc Teirlinck [EMAIL PROTECTED] writes:
What I did test was that reverting the changes in revisions 1.38 and
1.40 (the one from today) and then applying the patch below, not only
solves the three bugs reported today, but also solves the three
problems described in the above paragraph. The
Kevin Ryde [EMAIL PROTECTED] writes:
With my recent cvs build or the debian snapshot, and starting from
emacs -Q, visiting the file foo.c below with
C-x C-f foo.c
leaves the first line in the kill ring,
C-y
= inserts /* hello */
where I hoped it would leave the kill
Glenn Morris [EMAIL PROTECTED] writes:
It seems bad form to abort in the middle of the build though. A small
addition to configure.in makes it clearer IMO:
I agree.
I checked this in. Thanks.
(I also added an Xaw3d-without-Xaw item to TODO.)
Glenn Morris [EMAIL PROTECTED] writes:
Ulrich Mueller wrote:
libXaw Xaw3d
0 0 fails in lwlib.c due to missing X11/Xaw/Paned.h
0 1 OK, links against libXaw3d.so.8
I think it's also going to fail in this case if you configure
--without-toolkit-scroll-bars
Jason Rumney [EMAIL PROTECTED] writes:
Chong Yidong wrote:
Convert filename name to absolute, and canonicalize it.
All your examples are consistent with this behavior. The important
thing is that DEFAULT-DIRECTORY is only consulted if the filename is
relative.
But shouldn't
Ulrich Mueller [EMAIL PROTECTED] writes:
Hi,
not entirely sure if this is really an Emacs bug (or if X.Org is to
blame):
Emacs 22.0.97 compilation fails on a system where:
- Xaw3d is installed,
- libXaw is not installed.
Thanks for the bug report.
Could you test the following patch?
If
[EMAIL PROTECTED] (Kim F. Storm) writes:
Richard Stallman [EMAIL PROTECTED] writes:
Does drawing cursor in the wrong position on multi-line before-strings
cause real trouble?
Yes. Whenever the cursor is in the wrong position, that is real trouble.
Is the display of
Richard Stallman [EMAIL PROTECTED] writes:
It forces a glyph matrix reallocation after each call to
enlarge_window. The slowdown will be undetectable since redisplay is
so fast on text terminals anyway.
I think this is a good solution, if it works. It is simple, and it is
Diane Murray [EMAIL PROTECTED] writes:
I have no idea if this is a bug or not, but sometimes
`expand-file-name' returns a path with /../ at the beginning of it.
Below are a few simple examples.
C-h f expand-file-name RET
expand-file-name is a built-in function in `C source code'.
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Here is a version that I believe works. It just does local changes to
cursor_row_p. I seems to me that is sufficient. I have not seen any
problems with the display of 'display property parts, only with cursor
positioning.
Thanks for the
Richard Stallman [EMAIL PROTECTED] writes:
It seems that you and I define serious in a different way. My
criterion says that a bug where an important feature does something
that is indisputably wrong and that causes real trouble is a serious
bug.
Does drawing cursor in the wrong position on
Richard Stallman [EMAIL PROTECTED] writes:
You could add code inside a conditional which tests for that case.
Then you know it won't affect any other cases.
I don't have a clue to how to write the conditional which tests for that
case.
Have you tried to figure out how?
To
Chong Yidong [EMAIL PROTECTED] writes:
I managed to reproduce the bug.
emacs -nw
M-: (set-window-margins (selected-window) 1) RET
C-x 2
C-x ^
Pressing left and right button and inserting text now makes it clear
that redisplay is broken.
The call to enlarge-window and set-window-margins
Eli Zaretskii [EMAIL PROTECTED] writes:
It forces a glyph matrix reallocation after each call to
enlarge_window. The slowdown will be undetectable since redisplay is
so fast on text terminals anyway.
Are you sure redisplay is ``so fast''? what about remote connections
via a slow link?
I
[EMAIL PROTECTED] (Kim F. Storm) writes:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
(overlay-put ov 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the
[EMAIL PROTECTED] (Kim F. Storm) writes:
Chong Yidong [EMAIL PROTECTED] writes:
Eli Zaretskii [EMAIL PROTECTED] writes:
It forces a glyph matrix reallocation after each call to
enlarge_window. The slowdown will be undetectable since redisplay is
so fast on text terminals anyway.
Are you
Richard Stallman [EMAIL PROTECTED] writes:
At this stage of the release cycle, a grave bug is one that makes Emacs
crash, or causes really bad redisplay behaviour.
I think redisplay bugs are serious bugs.
In this case, I know what the fix is (see attached patch). The
trouble is that
[EMAIL PROTECTED] (Kim F. Storm) writes:
Can you track down the bug report(s) which lead up to the fix I
installed, so you can confirm that your change also fixes the old bug(s).
I must be close to the date in the ChangeLog.
The original bug report was at
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
(overlay-put ov
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline.
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Lennart Borgman (gmail) wrote:
This works for me and for Kim's test case as far as I can
see. However as can be seen from the fprintf output with my test
case it starts looping when I go to the first character and then
press left arrow.
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
With current CVS, I do not observe any infloop for the test case you
sent. If you think you have observed one, please send a precise
recipe.
Could you please recompile with the fprint part of the code I sent
before? Then start with emacs
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I trust you that it does not solve the underlying problem, but it
works in my case and in the test case Kim supplied. That said I of
course believe there can be problems with this solution, but I hope
for your comments on that.
Like I said,
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
However, it is dangerous to change string_buffer_position right
now, because it's called from several places in xdisp.c. Changing
its behavior runs a serious risk of introducing subtle bugs.
Maybe. They are either in set_cursor_from_row or
Leo [EMAIL PROTECTED] writes:
`outline-backward-same-level' will move from a heading line to a
non-heading line when on the first level-1 heading.
I checked in a (hopefully pretty safe) fix.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
Nick Roberts [EMAIL PROTECTED] writes:
I don't see this.
But I cannot use the mouse when emacs -nw is running in an xterm
(xterm seems to own the mouse) - is it necessary to use the mouse to
see the problem?
Yes, that's strange. It seems to have something to do with
I managed to reproduce the bug.
emacs -nw
M-: (set-window-margins (selected-window) 1) RET
C-x 2
C-x ^
Pressing left and right button and inserting text now makes it clear
that redisplay is broken.
The call to enlarge-window and set-window-margins appears to be
essential to producing this bug.
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1 with a
before-string property to do this... the cursor is displayed at the
end of the first line of the
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
graphist [EMAIL PROTECTED] writes:
I'm using NTemacs22 and have found one small bug.
If you add the following statement in .emacs file:
(setq-default case-fold-search nil)
you can't drag and drop some files to emacs (eg: with : in its full path).
I haven't been able to reproduce this,
[EMAIL PROTECTED] (Kim F. Storm) writes:
Chong Yidong [EMAIL PROTECTED] writes:
Kim, could you study this patch and tell me what you think?
Looks alright to me.
I've checked it in.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Sven Joachim [EMAIL PROTECTED] writes:
It seems that WoMan can no longer handle the case where a manpage
loads another one with a .so request. At least I got the error
WoMan can only format man pages written with the usual `-man' macros
when trying to view the manpage for
David Reitter [EMAIL PROTECTED] writes:
This crash occurred with a (slightly modified) CVS version
(2007-04-04), Carbon build.
I was trying out tabbar.el (providing tabbar-mode) using PNG files
for `tabbar-home-button-enabled-image' and the other tabbar buttons.
I think I clicked on the
Eli Zaretskii [EMAIL PROTECTED] writes:
Following my last bug report on W32 display error, I noticed that
the image didn't get through. So I tried various stuff to decode
the base64 stuff in various ways like this:
- copy it to a new file buffer named x.gif, mark it, do
Benjamin Rutt [EMAIL PROTECTED] writes:
Emacs infloops when I press the key at the end of this line (to the right of
the last '(':
matching_dbs = commands.getoutput(cat
//xx/x/x.xxx | grep ^%s | grep -v xxx %
region).strip().split(
I can't reproduce this at
Benjamin Rutt [EMAIL PROTECTED] writes:
Benjamin Rutt rutt.4 at osu.edu writes:
Is there anything I can do to make this report more useful? It
doesn't happen with emacs -q unfortunately.
hoorah, I can now dupe it with command line
emacs -q --eval '(add-hook (quote python-mode-hook)
Benjamin Rutt [EMAIL PROTECTED] writes:
Benjamin Rutt rutt.4 at osu.edu writes:
Is there anything I can do to make this report more useful? It
doesn't happen with emacs -q unfortunately.
hoorah, I can now dupe it with command line
emacs -q --eval '(add-hook (quote python-mode-hook)
Ah yes, now I can replicate it. The trouble was that your test
program had long lines that were automatically snipped by Gnus.
Here is a simpler test case:
#!/usr/bin/env python
def foo(bar):
foo = foo(foo).bar(
cmd = foo
bar
emacs -q foo.py
M-:
jpff [EMAIL PROTECTED] writes:
I attempted to create a new frame from the File menu.
The frame is created but I always get this error:
Debugger entered--Lisp error: (wrong-number-of-arguments #[nil
=8c0=8c1!=83
=8c1=8c2!=88=8c0=8c3!=85=8c3=8c2!=87 [functionp tool-bar-mode -1
It's unlikely that such a bug would have gone undetected over the last
few pretests. Could you me help check the last few checkins to the
src directory for any obvious bugs?
2007-04-07 Chong Yidong [EMAIL PROTECTED]
* editfns.c (Ftranspose_regions): Validate interval before setting
emacs user [EMAIL PROTECTED] writes:
using GNU/linux (redhat enterprise 4), most recent cvs Emacs 22.0.97.3 ,
trying to mail using smtp results in the error message
(invalid-function with-case-table). traceback attached. thanks, EU
You need to recompile your lisp directory and dump Emacs
Alan Mackenzie [EMAIL PROTECTED] writes:
Hi, everybody!
I've just committed a fix (cc-engine.el, cc-fonts.el) to savannah. I
hope that it fixes the problem. Certainly, labels now get fontified as
labels, and keywords (e.g. case:, private:, default:, and also QT's
macros, slots:, signals:)
Matzi Kratzi [EMAIL PROTECTED] writes:
If I open process.c (1.510) in the distribution, case on line 2565
(or is it the next case on line 2574) has the wrong colour. It would
be nice if this could be fixed before the release.
I think this is fixed with the latest CVS.
Jeffrey C Honig [EMAIL PROTECTED] writes:
This happens with CVS emacs from two hours ago on both FC6 and FC4.
Both compiled with (./configure --with-gtk; make bootstrap).
This appears to be the result of Kim Storm's recent change to
set_text_properties_1.
Chong Yidong [EMAIL PROTECTED] writes:
Jeffrey C Honig [EMAIL PROTECTED] writes:
This happens with CVS emacs from two hours ago on both FC6 and FC4.
Both compiled with (./configure --with-gtk; make bootstrap).
This appears to be the result of Kim Storm's recent change
Chong Yidong [EMAIL PROTECTED] writes:
Chong Yidong [EMAIL PROTECTED] writes:
Jeffrey C Honig [EMAIL PROTECTED] writes:
This happens with CVS emacs from two hours ago on both FC6 and FC4.
Both compiled with (./configure --with-gtk; make bootstrap).
This appears to be the result of Kim
intrigeri [EMAIL PROTECTED] writes:
after upgrading from my one-month-old Romain Françoise's
emacs-snapshot (1:20070302-1) + Debian sid's ERC (5.1.4-4) to the
brand new Romain's package (1:20051124-1) with ERC 5.2 included, I can
not connect to IRC anymore ; running erc-ssl fails, saying :
martin rudalics [EMAIL PROTECTED] writes:
emacs-22.0.90 -Q
c-xc-f /etc/termcap
c-xc-q To make it writable
c-kc-kc-y kill the first line and put it back.It will
not do it without this line kill
c-s thedo this until you leave the first screen displayed. This will
martin rudalics [EMAIL PROTECTED] writes:
emacs-22.0.90 -Q
c-xc-f /etc/termcap
c-xc-q To make it writable
c-kc-kc-y kill the first line and put it back.It will
not do it without this line kill
c-s thedo this until you leave the first screen displayed. This will
Chris Moore [EMAIL PROTECTED] writes:
$ cp ../pic.png pic1.png
open the first file
rename pic1.png to pic3.png:
p R pic3.png RET
revisit the first file (now called pic3.png):
f
The image isn't displayed because pic1.png, which is the file
associated with this buffer, doesn't exist
[EMAIL PROTECTED] (Kim F. Storm) writes:
Stefan Monnier [EMAIL PROTECTED] writes:
The trouble is that when where_is_internal checks whether the command
you entered is remapped, it does so using Fcommand_remapping, which
looks at all currently-active keymaps. The alternative is to scan
Kai Grossjohann [EMAIL PROTECTED] writes:
In eshell, kill -HUP 42 works to send the HUP signal to process 42,
but kill -USR1 42 does not work to send the USR1 signal.
I guess this is because of the regex in line 185 of esh-proc.el:
(if (string-match ^-\\([A-Z]+\\)$ id)
Yeah.
Chris Moore [EMAIL PROTECTED] writes:
I've not found a way to reproduce this error, but it happens
repeatably in the session I currently have running.
I was working on a C++ source file for a few hours, then narrowed it
to a region and attempted to undo the last change. The last change
was
[EMAIL PROTECTED] (Johan Bockgård) writes:
$ emacs -Q +2956 .../emacs/src/eval.c
The `retry:' label is not highlighted. It is fontified correctly by
`M-o M-o' though.
Simon, this appears to be the result of your change. Could you try to
fix your patch?
2006-11-10 Simon Marshall [EMAIL
Stephen Berman [EMAIL PROTECTED] writes:
3. Make a header line in the window of the Gnus Summary buffer,
e.g. by doing `M-x ruler-mode' (other header lines will also do,
e.g. `M-: (setq header-line-format default-mode-line-format)'). Then
do 'C-x o' to switch to the Gnus Article buffer and
1 - 100 of 245 matches
Mail list logo
