I don't know if this has been reported before - it's a bug that I've
become so used to that I almost don't notice myself working around it
any more...
Typing:
M-x woman RET ssh RET
should display the 'ssh' man page, but instead I see only parts of it,
strangely formatted. I just noticed
Eli Zaretskii [EMAIL PROTECTED] writes:
I have now added a primitive, called w32-window-exists-p, that you can
use to check whether the agent is running on Windows. To that end,
test whether w32-window-exists-p is fboundp, and if it is, see if the
expression `(w32-window-exists-p Pageant
On 12/17/06, Richard Stallman [EMAIL PROTECTED] wrote:
That is smart. Please install it.
I can install it, if you don't want to install Kim's change instead
right now. But I think his is the way to go.
/L/e/k/t/u
___
From: Leo [EMAIL PROTECTED]
Date: Wed, 13 Dec 2006 01:22:50 +
How to reproduce:
1. save the attachments to file1.txt and file2.txt
2. M-x ediff RET and choose file1.txt file2.txt respectively
3. Type 'D' in ediff panel window and you see
That man page is written in doc rather than in an.
With modern groff you have to pass -man-old to get the old an macros
w/o also supporting the newer doc macros. If you do that with ssh.1
you see the same results as woman shows.
This means that what woman needs is support for the doc macro set.
Michael Albinus wrote:
Eli Zaretskii [EMAIL PROTECTED] writes:
I have now added a primitive, called w32-window-exists-p, that you can
use to check whether the agent is running on Windows. To that end,
test whether w32-window-exists-p is fboundp, and if it is, see if the
expression
Thanks for the revised patch for emacsclient. It solves the problem I
reported.
Francis
- Original Message -
From: Juanma Barranquero [EMAIL PROTECTED]
To: Eli Zaretskii [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org;
emacs-devel@gnu.org
Sent: Friday, December
From: Eli Zaretskii [EMAIL PROTECTED]
To: Lennart Borgman [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org
Sent: Sunday, December 17, 2006 4:21 AM
Subject: Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Date: Sun, 17 Dec 2006 02:34:23 +0100
From: Lennart Borgman [EMAIL
Francis Wright wrote:
From: Eli Zaretskii [EMAIL PROTECTED]
To: Lennart Borgman [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org
Sent: Sunday, December 17, 2006 4:21 AM
Subject: Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Date: Sun, 17 Dec 2006 02:34:23 +0100
From:
Ronald writes:
see the title of the mini buffer window
It just looks like you've customised the face mode-line-highlight to have
something like a white foreground and a firebrick background. (If I'm
looking at the right place, actually mode-line of the buffer 4.c, not the
Lennart Borgman [EMAIL PROTECTED] writes:
Ok, I have uploaded a new unpatched version.
Thanks a lot, Lennart. It works as expected.
Best regards, Michael.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Date: Sun, 17 Dec 2006 19:26:30 +0100
From: Lennart Borgman [EMAIL PROTECTED]
CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
BTW I also think this page should mention the trouble with ALT-TAB
M-TAB is taken by many modern window managers, so this is not an
MS-Windows only
Eli Zaretskii wrote:
Date: Sun, 17 Dec 2006 19:26:30 +0100
From: Lennart Borgman [EMAIL PROTECTED]
CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
BTW I also think this page should mention the trouble with ALT-TAB
M-TAB is taken by many modern window managers, so this is
Chris Moore wrote:
I don't know if this has been reported before - it's a bug that I've
become so used to that I almost don't notice myself working around it
any more...
Ditto. I reported the issue with the very same manpage in May 2004:
From: Lennart Borgman [EMAIL PROTECTED]
To: Eli Zaretskii [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org
Sent: Sunday, December 17, 2006 9:23 PM
Subject: Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
The manual says that setting w32-pass-lwindow-to-system (and dito r)
Francis Wright wrote:
From: Lennart Borgman [EMAIL PROTECTED]
To: Eli Zaretskii [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org
Sent: Sunday, December 17, 2006 9:23 PM
Subject: Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
The manual says that setting
From: Eli Zaretskii [EMAIL PROTECTED]
To: Francis Wright [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Sent: Saturday, December 16, 2006 6:33 PM
Subject: Re: Menu tooltip error
From: Francis Wright [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Date: Sat, 16 Dec 2006 16:48:08 -
I have
Richard Stallman [EMAIL PROTECTED] writes:
I looked into this ... and it is because yes-or-no-p uses
read-from-minibuffer, and thus obeys all key bindings.
It could bind minibuffer-scroll-window around the call to
yes-or-no-p.
That would be a fix for C-x v u ... Stefan?
But I
From: Eli Zaretskii [EMAIL PROTECTED]
To: Francis Wright [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Sent: Saturday, December 16, 2006 6:35 PM
Subject: Re: Menu tooltip error
From: Francis Wright [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Date: Sat, 16 Dec 2006 16:48:08 -
I have
Francis Wright wrote:
I installed MinGW very recently using the installer from sourceforge,
although most of the files seem to be dated 2004, so perhaps they are
not as up-to-date as I thought.
The updating of the MinGW download table at
http://www.mingw.org/download.shtml does not work
On 11 Dec 2006, at 08:01, YAMAMOTO Mitsuharu wrote:
It seems like a problem that is specific to the Mac Carbon port.
Please try the following patch. If there's no problem with this for a
few days, I'll install it.
Your patch works as advertised and I it doesn't seem to cause any
problems
I'm not sure we can do any better here, unless we somehow know the
encoding of each of the two files.
[...]
This is also what I basically told Leo.
Clearly, we can take a look at each file, figure out their respective
encoding, and if both use the same, then use that encoding to decode the
Can you point to a single instance where doing a case-insensitve match
as a fallback would be harmful?
There are many patterns which are meant to apply to file names used
for specific conventional purposes in a GNU-like system, names
which are used with specific case patterns. Here's
Is it feasible to fix read-file-name to obey the predicate
in the completion case? It could be that the reason it doesn't
do so was the difficulty of implementing that case efficiently.
Since no one else seemed interested in this, I did it.
Since the Emacs 22 jump scrolling upon entering a RET does not appear
to serve any purpose, I suspect it is unintentional and, therefore, a
bug.
This is a feature, and it is controlled by comint-scroll-show-maximum-output.
___
In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes:
* Eli Zaretskii (2006-12-17 06:30 +0200) said:
^
From: Leo [EMAIL PROTECTED]
Date: Sun, 17 Dec 2006 03:15:59 +
But a file with eight-bit characters can have a correct diff
output. What makes ediff fail where
* Kenichi Handa (2006-12-18 10:17 +0900) said:
^
[...]
That's perhaps because Emacs reads the output of process while
decoding by a detected coding system. That method works for your
test case, but fails in a case that two files contain non-ascii
characters in different encoding
Date: Sun, 17 Dec 2006 22:23:26 +0100
From: Lennart Borgman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
The manual says that setting w32-pass-lwindow-to-system (and dito r) to
nil prevents that these keys are sent to MS Windows. I do not know how
many times I
From: Francis Wright [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Date: Sun, 17 Dec 2006 21:58:36 -
The documentation for the variable `w32-pass-lwindow-to-system' carries a
rider that key *combinations* involving the left windows key cannot be
handled by Emacs, but the manual
From: Francis Wright [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Date: Sun, 17 Dec 2006 22:37:34 -
According to the MinGW installed.ini file I am running the following:
runtime=mingw-runtime-3.11.tar.gz
w32api=w32api-3.8.tar.gz
binutils=binutils-2.15.91-20040904-1.tar.gz
From: Leo [EMAIL PROTECTED]
Date: Mon, 18 Dec 2006 02:02:55 +
All my files are in utf-8 encoding and that's why I am surprised to
see such output.
But that's a very special case. We cannot make Emacs work only in
special cases.
___
Richard Stallman wrote:
Since the Emacs 22 jump scrolling upon entering a RET does not appear
to serve any purpose, I suspect it is unintentional and, therefore, a
bug.
This is a feature, and it is controlled by comint-scroll-show-maximum-output.
Has someone been keeping a list
Has someone been keeping a list of Emacs 22 features which have default
behaviors different from the corresponding default behaviors in Emacs
21? This would be extremely helpful to pre-testers, like me, who have
just recently started to use the Emacs 22. Perhaps it is buried
In article [EMAIL PROTECTED], Felix Huang [EMAIL PROTECTED] writes:
I compiled the latest CVS version of emacs-unicode-2 branch in Ubuntu
Edgy, and run it in a zh_CN.UTF-8 environment. Emacs crashed at the
splash screen. If I turned off the splash (setq inhibit-splash-screen
t), it was normal
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing
list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
35 matches
Mail list logo
