Apparently mail-abbrev-end-of-buffer does nothing special: it jumps to
the end of buffer but does not expand the abbreviation.
The code tries to expand:
(defun mail-abbrev-end-of-buffer (optional arg)
Expand any mail abbrev, then move point to end of buffer.
Leave mark at
Actually I think I found a safe fix. If there is no negative feedback,
I'll
add it to HEAD. I'm not sure who decides if it should go to the 22.1
branch.
I think it should go in 22.1
as well as in the trunk.
___
emacs-pretest-bug mailing
It used to work in dired buffers.
That seems incredible. Deleting the whole text of a directory listing
and reading it again is an operation that cannot preserve undo data.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
It used to work in dired buffers.
That seems incredible. Deleting the whole text of a directory listing
and reading it again is an operation that cannot preserve undo data.
Yet, this is easy to reproduce. Invoke emacs 21 with -q, then
C-x d /tmp RET
M-! touch 00a RET
g -- Now yu should
Richard Stallman skrev:
Actually I think I found a safe fix. If there is no negative feedback, I'll
add it to HEAD. I'm not sure who decides if it should go to the 22.1 branch.
I think it should go in 22.1
as well as in the trunk.
Checked in in 22.1 and branch.
Jan D.
Apparently mail-abbrev-end-of-buffer does nothing special: it jumps to
the end of buffer but does not expand the abbreviation.
The code tries to expand:
...
Why doesn't it work for you?
The problem is in mailabbrev.el, in sendmail-pre-abbrev-expand-hook,
where it does:
;; If the
Jan Djärv skrev:
Richard Stallman skrev:
Actually I think I found a safe fix. If there is no negative
feedback, I'll add it to HEAD. I'm not sure who decides if it
should go to the 22.1 branch.
I think it should go in 22.1
as well as in the trunk.
Checked in in 22.1 and
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 comments and
version numbers, the current python.el in
Francesco Potorti` [EMAIL PROTECTED] writes:
it was useful when I updated a dired buffer with 'g' without looking at
it first, and wanted to look at its old status. Very handy in some
situations.
Handy if you know what you are doing, but potentially very confusing
and dangerous for the
it was useful when I updated a dired buffer with 'g' without looking at
it first, and wanted to look at its old status. Very handy in some
situations.
Handy if you know what you are doing, but potentially very confusing
and dangerous for the average/naive user.
The user had to toggle the
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
Richard Stallman [EMAIL PROTECTED] writes:
Does this patch fix it?
There are still problems (but none that should delay the release! :).
In dabbrev--substitute-expansion `(search-backward old)' might find
the wrong place after the whichspace has been converted.
Consider a buffer containing
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.
The rest looks good,
Stefan
___
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?
output of top -o pid
please note:
Carbon Emacs cpu-usage is 81.2%.
609 502 256 20.3M 20.8M 28.4M 44.4M 181M 2 62 21.52s
0.3 Aquamacs Emacs
608 502 77 2.21M 3.21M 4.88M 32.6M 44.7M 7 75 0.60s
0.0 mdimport
606 502 206 16.0M- 14.2M 25.1M 37.1M 171M 2
in a program initiated from the shell initiated w/ M-x shell, an input
line of 512 characters results in a spurious EOF to the program. here
are three steps to reproduce the problem, and some additional actions to
compare the actual and expected behaviors:
(A) compile this C program:
cat
I run ./configure with FreeBSD 6.2 machine. It outputs following error:
% ./configure
as_func_failure succeeded.
as_func_failure succeeded.
No shell found that supports shell functions.
Please tell [EMAIL PROTECTED] about your system,
including any error possibly output before this
message
GNU Emacs 22.0.98.1 (i586-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2007-04-26 on GNU/Linux 2.2.16 compiles and runs using simple files and
tower of Hanoi in both windowed (X) and non-windowed modes.
--
# __ __Eric Ewanco
# IC | XC [EMAIL PROTECTED]
#
Livin Stephen Sharma wrote:
output of top -o pid
please note:
Carbon Emacs cpu-usage is 81.2%.
Minor modes in effect:
semantic-idle-scheduler-mode: t
have you pulled the latest semantic-idle.el from semantic's CVS, or are
you using the released version? The released one is known to cause
Consider a buffer containing the text
1 2 3
(that is 1 SPC SPC 2 SPC SPC SPC 3 SPC)
Then at the end of the buffer, type 1 SPC SPC M-/ SPC M-/.
This isn't a case it is really intended to handle.
So I won't worry about it now.
___
C-x d /tmp RET
M-! touch 00a RET
g -- Now yu should see a file named 00a
C-x C-q
undo -- Now you don't see the file 00a any more
The operation undone was the deletion of the old buffer contents and
insertion of the new contents. No wonder I turned off undo for that.
The
21 matches
Mail list logo
