Richard Stallman [EMAIL PROTECTED] writes:
Also exiting an emacs that contains such shells still alive (merely
sitting at their prompts), sends the signal to them to get wacko.
That sounds like a shell bug to me.
Does it happen with Emacs 21.4 too?
Yes, I can reproduce this with
Glenn Morris [EMAIL PROTECTED] writes:
Sven Joachim wrote:
Yes, I can reproduce this with Emacs 21.4.
How about outside Emacs?
Outside Emacs suspending a su'ed bash works fine.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http
[EMAIL PROTECTED] writes:
At least you perhaps can reproduce in an emacs *shell* buffer:
---
[EMAIL PROTECTED]:~$ su
Password:
[EMAIL PROTECTED]:/tmp# suspend
[1]+ Stopped su
[EMAIL PROTECTED]:~$ fg
su
[EMAIL PROTECTED]:/tmp# exit ---I did not type exit!
I
On several manpages (one of them is attached) WoMan complains:
Invalid search bound (wrong side of point) and leaves point at the end
of the buffer and the buffer status modified and writable. The
backtrace looks as following:
Debugger entered--Lisp error: (error Invalid search bound (wrong
Stefan Monnier [EMAIL PROTECTED] writes:
Can you confirm that the patch below fixes the problem for you?
I've installed it in the 22 branch,
Tested with three manpages that used to trigger the error, all work
fine now.
Thank you. :-)
___
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 dpkg-buildpackage, which consists
of a single line:
.so
Richard Stallman writes:
Do you get correct results with this change?
Yes, seems good. :-)
Thanks,
Sven
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Suppose there are two Dired buffers, say ~/foo and ~/bar, which look
as follows:
/home/sven/foo:
total used in directory 16 available 2005008
drwxr-xr-x 2 sven sven 4096 Nov 4 08:18 .
drwxr-xr-x 51 sven sven 4096 Nov 4 08:16 ..
-rw-r--r-- 1 sven sven9 Nov 4 08:18 a
-rw-r--r--
When visiting etc/grep.txt, I was asked about the variable
buffer-read-only. Although I answered 'n', the buffer was made
read-only anyway, so the local variable seems superfluous.
In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2006-10-04 on debian, modified by
Richard Stallman wrote:
Anyway, I think I fixed the confusing `29 out of 2 files' message.
Please try this:
It leads to an error, e.g. trying to copy /etc/shadow:
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (shadow
shadow))
dired-plural-s((shadow shadow))
Richard Stallman wrote:
However, there's still no indication of failed copies in the
echo area or the *Messages* buffer. :-(
Can you debug why not? The cond at the end of dired-create-files is
supposed to call dired-log-summary, which should call message. Please
debug the code in
Richard Stallman wrote:
Please try this patch instead.
*** dired-aux.el17 Jul 2006 16:31:56 -0400 1.146
--- dired-aux.el05 Sep 2006 11:20:50 -0400
***
*** 39,44
--- 39,49
;; We need macros in dired.el to compile properly.
(eval-when-compile
Richard Stallman wrote:
How about this patch, instead of the other?
It should display an indication that there was a problem.
I tested that it compiles, but it isn't convenient for me to try running it;
could you please?
Again I tried to copy the /etc directory to my home directory, but when
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
* Start an async shell command: M-! sleep 100 RET
* Switch to the buffer *Async Shell Command*
* Type C-c C-c
I got the error: Marker does not point anywhere
Backtrace looks as follows:
Debugger
Richard Stallman wrote:
I think this fix ought to work, but it is not easy for me to test it.
Would you please test it?
*** dired-aux.el17 Jul 2006 16:31:56 -0400 1.146
--- dired-aux.el28 Aug 2006 14:35:01 -0400
***
*** 1165,1174
(or top
Recursive copies in dired fail rather ungracefully: if an error occurs
for one file the whole operation is aborted, leaving the remaining
files unprocessed. See the following example: A dired buffer looks
like this:
,
| /tmp/foo:
| total used in directory 15 available 265502
|
Reading chapter 27 of the Emacs Manual, I noticed two typos in
man/mule.texi. The following patch gets rid of them:
*** mule.texi~ 2006-07-05 00:05:31.0 +0200
--- mule.texi 2006-08-08 21:32:17.0 +0200
***
*** 785,791
correspondence. There is a special
In Dired, if both an uncompressed file (say foo) and a compressed
version of it (foo.gz) exist, typing 'Z' (dired-do-compress) with
point at the 'foo' file has the dangerous effect of overwriting
'foo.gz' without asking. OTOH, typing 'Z' with point at 'foo.gz'
fails to uncompress the file,
Kenichi Handa wrote:
At the header of po-compat.el, this comment is written.
;; Emacs 21.2 and newer already contain this file, under the name po.el,
;; and without portability hassles.
So, there's no need of loading this file in the current
version.
Indeed, I think I'll have to move it out
Kenichi Handa wrote:
Do you mean that, po-compat.el was able to detect a coding
system of compressed PO file correctly before my change?
No, it wasn't. But at least it was able to visit the file
without getting an error. ;-)
___
emacs-pretest-bug
Kenichi Handa wrote:
At last we reached an agreement on how to solve this
problem, and I've just installed a fix. Could you please
try the latest CVS code?
Your changes work well in `emacs -Q'. However, there is a bad
interference with the Elisp files from the GNU gettext distribution
which
On Mon, Mar 13 2006, Kenichi Handa wrote:
In article [EMAIL PROTECTED], Sven Joachim [EMAIL PROTECTED] writes:
It seems that Emacs has a problem detecting the correct encoding of
compressed PO files. Attached is a compressed PO file de.po.gz in
utf-8 encoding which Emacs failed to display
Eli Zaretskii wrote:
Not even a week passed since then, please be a bit more patient.
Please read more carefully, I wrote:
On Mon, Mar 13 2006, Kenichi Handa wrote:
^^^
As you can see, I actually waited _five_ weeks.
___
emacs-pretest-bug
Line 424 of etc/refcard.tex looks like this:
\threecol{display buffer in other window}{C-x 4 C-o}{C-x 5 C-o}
From the context of this, I concluded that C-x 5 C-o would display a
buffer in another frame, but actually C-x 5 C-o is undefined. And
there is no command like
It seems that Emacs has a problem detecting the correct encoding of
compressed PO files. Attached is a compressed PO file de.po.gz in
utf-8 encoding which Emacs failed to display correctly. The German
umlauts were displayed as octal sequences. This problem does not
occur if the file is either
Richard M. Stallman wrote:
I am not convinced this is a wrong outcome for quitting in the middle
of saving.
However, pressing C-g is a natural panic reaction when the *Warning*
buffer pops up. And the warning says:
[...]
Select one of the following safe coding systems, or edit the buffer:
I wrote:
Here is a summary of what Emacs does in the scenario:
(a) Before saving bar, Emacs renames bar to bar~, overwriting the old
backup in the process, and sets `buffer-backed-up' to t. This is
documented in the manual.
(b) Emacs tries to save bar but fails to do so, because the
Richard M. Stallman wrote:
I am going through mail that I failed to deal with earlier.
Please forgive the delay.
$ echo foo bar ; cp bar bar~
$ emacs -Q -f view-hello-file bar
In Emacs, in the bar buffer, type
M-x insert-buffer RET
C-x C-s
Emacs should display a
If saving a buffer with the current or preferred coding system is not
possible, Emacs displays a `*Warning*' buffer which tells to select a
safe coding system or to edit the buffer. If you quit then, you will
lose the backup file for the buffer. Take the following steps to
reproduce the
Changing the variable `ediff-ignore-similar-regions', either by typing
## in the Ediff frame or by evaluating
(setq-default ediff-ignore-similar-regions t)
does not have the desired (and documented) effect of skipping regions
that differ only in whitespace; they are displayed anyway.
In GNU
In shell-mode, when point is on the second line (no matter which
column), C-p (`previous-line') moves point to the beginning of the
buffer. How comes that?
In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2005-09-30 on debian, modified by Debian
X server distributor
Pressing RET in woman-mode when point is on a reference word (e.g. in the
SEE ALSO section of the man page) invokes man, not woman, on the manpage.
The same applies to mouse-1 and mouse-2. Pressing C-h k in woman-mode gives
the following information:
mouse-1 at that spot is remapped to mouse-2
I just tried to build Emacs on a legacy operating system with DJGPP,
but that did not really work out of the box. After config msdos,
make bootstrap successfully compiled the .elc files but then failed
in the lib-src directory with the following error message:
make.exe[1]: *** No rule to make
didn't specify `--no-splash' or `-Q'.
Regards,
Sven Joachim
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Richard M. Stallman wrote:
It used to be that the startup screen was not shown if the startup
arguments visited a file, and perhaps it made sense to treat the starting
of a server like the visiting of a file.
True, but IMHO only if the process started by the server has actually
a buffer
Jan D. wrote:
There is some bug in IceWM or GTK. IceWM doesn't like what ediff tries
to do when it redirects focus so it sends FocusOut. But GTK reasserts
the focus change, so we get FocusIn, and then IceWM sends yet another
FocusOut, and so on until we run out of stack. I don't think I
Running ediff reprodrucibly crashes the GTK+-enabled version of Emacs
under X. Simply try M-x ediff-files or M-x ediff-buffers and the
Emacs window disappears as soon as ediff starts. Or try the command
emacs -Q -D --eval '(ediff-files /etc/passwd /etc/group)'
in a terminal, which should
why I only noticed the missing splash screen under X is
that my ~/.emacs only starts the Emacs server under X. :-)
Can anybody explain to me what the reason is to suppress the startup
message if Emacs starts a process on startup? I don' quite understand
it.
Regards,
--
Sven Joachim
. Press . in that popup and a drop down menu of matching
files will be shown.
Jan D.
Thank you, that indeed worked. But it also firmly convinced me that I better
stick to C-x C-f and C-x d ;-).
Regards,
--
Sven Joachim
___
Emacs-pretest
Recently I wrote:
Running ediff reprodrucibly crashes the GTK+-enabled version of Emacs
under X. Simply try M-x ediff-files or M-x ediff-buffers and the
Emacs window disappears as soon as ediff starts. Or try the command
emacs -Q -D --eval '(ediff-files /etc/passwd /etc/group)'
in a terminal,
, modified by Debian
Regards,
--
Sven Joachim
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
in the NEWS file and the Emacs manual.
My Emacs version is:
GNU Emacs 22.0.50.1 (i386-pc-linux-gnu, GTK+ Version 2.6.4)
of 2005-08-13 on debian, modified by Debian
Recent messages:
dired-get-filename: Cannot operate on `.' or `..' [4 times]
Regards,
--
Sven Joachim
I experience a strange bug with this pretest version:
Emacs no longer displays the initial splash screen and the scratch
message (This buffer is for notes...) under X. I say strange
because I really don't understand what is going on here. My
observations are:
- The problem does not occur if
43 matches
Mail list logo
