I noticed the same thing and did it today.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I do not like the idea of making it hang.
It would be nice to detect the lack of file name arguments
and output some sort of error message, but I am not sure
how to detect that condition reliably.
___
emacs-pretest-bug mailing list
Hi, I noticed during my weekly cvs update that cyd applied my recent patch
for Font-lock fontifies C/C++ case keyword as a constant, thanks.
The below earlier patch for another bug hasn't been applied, was it missed?
Thanks, Simon.
-Original Message-
From: Marshall, Simon
Sent: 02
Juanma Barranquero wrote:
On 11/13/06, Jason Rumney [EMAIL PROTECTED] wrote:
Have you tested the emacsclientw.exe build with MSVC?
No, I have not set up a build enviroment for MSVC. Did you try it?
BTW, Lennart's got a bunch of changes to emacsclient that would allow
emacsclient's error
Dan Jacobson [EMAIL PROTECTED] writes:
M-x shell
$ ssh bla.bla.bla
whereupon we are cleverly prompted for the password in the minibuffer.
Well, the password Bob sent me was in a different buffer, which one
needs to use C-x b to get to. But no, every darn character,
including C-x, is
Introducing another environment variable like INSIDE_EMACS=t to replace
EMACS=t doesn't cure the breakage to the nice programs.
I'd hate to release Emacs 22 which works worse than Emacs 21 with the
nice programs, just to make it work better in the rare cases where
someone build a specific
Reiner Steib wrote:
As Elias Oltmanns already has pointed out, the problem is that
nnfolder often does re-searches for X-Gnus-Article-Number:
(`nnfolder-article-marker'). Wrapping these calls inside ...
(with-case-table some-case-table-without-dotless-i/dotted-I
(re-search-forward
On Thu, Nov 09 2006, Alexandre Oliva wrote:
Ultimately, I'm a bit concerned about messing with the case table of
an nnfolder buffer for the entire duration of the buffer. It's hard
to tell whether there'd be any less visible fallouts.
Richard has eliminated the peculiar upcasing dotless-i to
I do not like the idea of making it hang.
It would be nice to detect the lack of file name arguments
and output some sort of error message, but I am not sure
how to detect that condition reliably.
It's very easy if done at the right place: inside GNU grep (rather than
inside Emacs). And it
Can you send a single precise test case for this problem?
Please read the Bugs section in the Emacs manual, which provides
guidelines on how to write a bug report to give us the
necessary information so we can fix the bug.
___
emacs-pretest-bug mailing
You can test like this:
Test case 1:
In *scratch* buffer, erase the buffer, and choose TeX input method,
input two multibyte characters, such as «», which can display in my
emacs. Then change to hexl-mode. Use C-f to move point. You can see
the cursor can't arrive to the last byte. Use C-h v
Dan Jacobson [EMAIL PROTECTED] writes:
Better yet, implement vi's tildes. Maybe the code can be copied from
one of those vi emulation modes. Of course allow different favorite
strings, not just ~.
(setq ol (make-overlay (point-min) (point-max) (current-buffer) t t))
(overlay-put ol
On Mon, 2006-11-13 at 14:25 -0500, Stefan Monnier wrote:
It's very easy if done at the right place: inside GNU grep (rather than
inside Emacs). And it sure should complain: the user specified a search in
0 files, so there's obviously something odd.
From grep(1):
DESCRIPTION
grep
On 11/10/06, Tim Van Holder [EMAIL PROTECTED] wrote:
On 11/10/06, Chong Yidong [EMAIL PROTECTED] wrote:
I was committing a set of changes using vc-directory, and v-= caused
the emacs window to disappear. Re-ran from the commandline, crash was
reproducible as a segfault. Re-ran under
14 matches
Mail list logo
