headers
Geoff Odhner | 2 May 2005 14:54

Re: regex bug with pattern "\\*/" matching end of buffer */

Thank you.  I am relieved to find the bug is in my code.  Indeed, it works 
correctly when I recode it thus:
         (while (and (re-search-forward "\\*/"  nil t) (replace-match 
"*-/" nil nil)) (not (eobp))))

Geoff Odhner

Richard Stallman <rms <at> gnu.org> wrote on 04/30/2005 07:18:50 PM:

>          (while (and (re-search-forward "\\*/"  nil t) (not (eobp)))
>       (replace-match "*-/" nil nil)))
> 
>     it will give me the following line as the result:
> 
>        char   ch;   /-* sample comment */
> 
> That's because (eobp) returns t when you're at the end of the
> accessible portion of the buffer.  So the bug is in your code,
> I think.
>
Permalink | Reply | 0 comments |
headers
Olaf Dietrich | 2 May 2005 09:36
Picon
Favicon

viper-mode: viper-replace-char-subr

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.4.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-04-20 on gracvn
configured using `configure  --prefix=/var/autofs/misc/apps/DIR/emacs-21.4'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

This may be a bug of viper-mode:

Inserting a new line break in an existing line by "r <Return>"
(more exactly: replacing the current character by a newline)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Jacobson | 2 May 2005 07:17
Favicon
Gravatar

M-x man default prompt was supposed to be fixed?

Put your cursor anywhere on a|b or c.d and type M-x man.
At least in emacs-version "21.4.1" I still am prompted with all of the
first and half of the last.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 2 May 2005 23:04
Picon
Picon

Re: problem making emacs

    I'm having trouble installing emacs on a Linux box.

I think you mean a machine running GNU/Linux, right?

    Wrote /home/mike.skymarx.com/emacs-21.3/lib-src/fns-21.3.1.el
    Dumping under names emacs and emacs-21.3.1
    make[1]: *** [emacs] Segmentation fault
    make[1]: *** Deleting file `emacs'

This seems to be a problem in dumping.  Maybe it has to do with
InstallShield.  In the latest Emacs, in CVS on savannah.gnu.org, we
have some suggestions for how to avoid such problems.  See
etc/PROBLEMS.
Permalink | Reply | 0 comments |
headers
Daniel Barrett | 4 May 2005 01:05
Favicon

Re: Help debugging an Emacs crash


On April 13, 2005, Richard Stallman wrote:
>>I am experiencing emacs segmentation faults under X. They occur at
>>random times, but always at the moment I press a key.
>Can you see if the problem still happens in the latest development Emacs 
>from CVS on savannah.gnu.org?

I've now been running the latest dev Emacs for 2 weeks and the problem has
not occurred.

--
Dan Barrett
dbarrett <at> blazemonger.com
Permalink | Reply | 1 comment |
headers
Richard Stallman | 5 May 2005 00:05
Picon
Picon

Re: Help debugging an Emacs crash

    I've now been running the latest dev Emacs for 2 weeks and the problem has
    not occurred.

That is good news.
Permalink | Reply | 0 comments |
headers
Olaf Dietrich | 6 May 2005 09:43
Picon
Favicon

Re: viper-mode: viper-replace-char-subr

The problem described below (inserting a new line break in an existing
line by "r <Return>" in viper-mode, GNU Emacs 21.4.1) can be solved
by a patch to viper-cmd.el distributed with the currently stable
Emacs 21.4.1.

The patch is derived from a comparison of the current CVS version
of viper (viper-version "3.11.4 of February 19, 2005") and the one
distributed with Emacs 21.4.1 (viper-version "3.11.1 of September 9,
2001"); only the fourth insertion seems to be necessary to remove
the described problem, but all four deal with similar ^M stuff.

Thanks to Kevin Rodgers and to Michael Kifer for their help,
Olaf

--- emacs-21.4/lisp/emulation/viper-cmd.el	2002-06-10 15:05:03.000000000 +0200
+++ viper-cmd.el	2005-05-03 10:22:57.860007000 +0200
 <at>  <at>  -789,6 +789,13  <at>  <at> 
 		 ;; The next 2 cmds are intended to prevent the input method
 		 ;; from swallowing ^M, ^Q and other special characters
 		 (setq ch (read-char))
+;; start copy from viper 3.11.4 (2005-02-19)
+		 ;; replace ^M with the newline
+		 (if (eq ch ?\C-m) (setq ch ?\n))
+		 ;; Make sure ^V and ^Q work as quotation chars
+		 (if (memq ch '(?\C-v ?\C-q))
+		     (setq ch (read-char)))
+;; end copy from viper 3.11.4 (2005-02-19)
 		 (viper-set-unread-command-events ch)
 		 (quail-input-method nil)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Wardle | 7 May 2005 06:30

sh-indent-for-do wrong

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.4.1 (i386-pc-linux-gnu)
 of 2005-03-18 on trouble, modified by Debian
configured using `configure '--build=i386-linux' '--host=i386-linux' '--prefix=/usr'
'--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--with-x=no'
'CFLAGS=-DDEBIAN -g -O2' 'build_alias=i386-linux' 'host_alias=i386-linux''
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU.utf8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

When entering a while..do..done block with the do on a separate line,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Wardle | 7 May 2005 07:58

customize -> save for future disrespects symlinks

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.4.1 (i386-pc-linux-gnu)
 of 2005-03-18 on trouble, modified by Debian
configured using `configure '--build=i386-linux' '--host=i386-linux' '--prefix=/usr'
'--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--with-x=no'
'CFLAGS=-DDEBIAN -g -O2' 'build_alias=i386-linux' 'host_alias=i386-linux''
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU.utf8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

My Emacs initialization file $HOME/.emacs is a symbolic link to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eli Zaretskii | 7 May 2005 17:53
Picon

Re: [jirka <at> kosek.cz: Bug in mule.el/sgml-xml-auto-coding-function]

> Date: Thu, 28 Apr 2005 13:48:15 +0200
> From: Jirka Kosek <jirka <at> kosek.cz>
> To: bug-gnu-emacs <at> gnu.org
> Subject: Bug in mule.el/sgml-xml-auto-coding-function
> 
> function sgml-xml-auto-coding-function tries to detect encoding of XML
> file. XML specification allows encoding name to be surrounded by quotes
> or apostrophes. Current code expect only quotes so it won't detect
> encoding if specified as:
> 
> <?xml version="1.0" encoding='windows-1250'?>
> 
> The following function has corrected RE in order to deal with both
> delimiters.

Thanks, I installed this.
Permalink | Reply | 0 comments |

Gmane