headers
xgl99 | 2 Jul 2005 09:07
Picon

M-> cannot go to the end of buffer

hi,
    I am using the CVS version of emacs. I notice a problem that M->
cannot go to the end of buffer when the number of lines is larger than
35. I am not sure if it is a bug.
                                   Guanglei
Permalink | Reply | 0 comments |
headers
Marc Horowitz | 3 Jul 2005 01:19
Picon
Favicon

base64 behavior is not MIME compliant

(emacs-version)
"GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-03-17 on trouble, modified by Debian"

(gnus-version)
"No Gnus v0.4"

RFC 3548 has this to say about characters not part of the encoding
alphabet:

    Implementations MUST reject the encoding if it contains characters
    outside the base alphabet when interpreting base encoded data, unless
    the specification referring to this document explicitly states
    otherwise.  Such specifications may, as MIME does, instead state that
    characters outside the base encoding alphabet should simply be ignored
    when interpreting data ("be liberal in what you accept").

The second sentence is a reference to RFC 2045:

   Any characters outside of the base64 alphabet are to be ignored in
   base64-encoded data.

The base64-decode-region function is somewhere in the middle, and
therefore compliant with neither spec: in addition to the alphabet
characters, it seems to accept whitespace, but nothing else.

Gnus's mm-decode-content-transfer-encoding method, in mm-bodies.el,
both in No Gnus and in the verison shipped with emacs 21.4, uses
base64-decode-region, which means it does not conform to the MIME
standard.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Edi Weitz | 3 Jul 2005 12:22
Picon
Favicon

fill-paragraph bug in Lisp modes

In CVS Emacs (from May) if I have a function like this

(defun foo ()
  "Comment this is a long text.  Comment this is a long text.  Comment this is a long text."
  42)

in Lisp mode or Emacs Lisp mode and press M-q (fill-paragraph) while
within the documentation string the result looks like this:

(defun foo ()
  "Comment this is a long text.  Comment this is a long text.
  Comment this is a long text."  42)

So, the indentation for the documentation string is wrong and the 42
has moved up to a place where I don't want to have it.

If in lisp-mode.el I uncomment the line

  (set (make-local-variable 'adaptive-fill-mode) nil)

then the first problem goes away and the function after M-q looks like
this:

(defun foo ()
  "Comment this is a long text.  Comment this is a long text.
Comment this is a long text."  42)

That's better.  The 42 is still in the wrong place, though.

Cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Dwork | 8 Jul 2005 22:33
Picon
Favicon

facemenu-read-color should not be case-sensitive

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.3.1 (i686-pc-linux-gnu, X toolkit)
 of 2004-01-19 on flashbak
configured using `configure  --prefix=/tool/pandora/.package/emacs-21.3-a
--x-includes=/tool/pandora/include --x-libraries=/tool/pandora/lib --without-gif'
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:

$ emacs -q --no-site-file
M-x set-backgrond-color<return>mistyrose<return>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Jacobson | 8 Jul 2005 05:01
Favicon
Gravatar

no cpio mode

When one hits v in dired on a .cpio file, we don't automatically jump
into a index listing like we do on a .tar file.
Permalink | Reply | 0 comments |
headers
Dan Jacobson | 9 Jul 2005 04:18
Favicon
Gravatar

the -*-coding: -*- stuff doesn't check for invalid codings

No error is reported to the user if he uses
;-*-coding: utf8;-*-
instead of
;-*-coding: utf-8;-*-

I.e., the -*-coding: -*- stuff doesn't check for invalid codings.
Permalink | Reply | 3 comments |
headers
N. Raghavendra | 9 Jul 2005 07:43
Picon
Favicon

timezone-parse-date

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.3.1 (i386--freebsd, X toolkit, Xaw3d scroll bars)
 of 2005-07-02 on riemann.mri.ernet.in
configured using `configure  --x-libraries=/usr/X11R6/lib --x-includes=/usr/X11R6/include
--prefix=/usr/local i386--freebsd'
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: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

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

The form

  (timezone-parse-date "Fri, 17 Mar 89 4:01:33")
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard M. Stallman | 10 Jul 2005 07:19
Picon
Picon

Re: timezone-parse-date

Your fix is correct, and I will install it.  Thanks.
Permalink | Reply | 0 comments |
headers
Louis.Strous | 11 Jul 2005 16:32

compiled GNU Emacs 21.4.1 on IBM AIX 5.3 after small change to ./configure


L.S.,

I successfully compiled GNU Emacs 21.4.1 on IBM AIX 5.3, but only after making a small change to ./configure:
I changed

  rs6000-ibm-aix5.1* | powerpc-ibm-aix5.1*  )
    machine=ibmrs6000 opsys=aix4-2
  ;;

to

 rs6000-ibm-aix5.1* | powerpc-ibm-aix5.*  )
    machine=ibmrs6000 opsys=aix4-2
  ;;

i.e., I made the case apply not just to AIX 5.1.* but to AIX 5.*.  Otherwise, the build is done (on my AIX 5.3) as if it is for AIX 3.2, which causes many warnings and finally fails because HFT features (with associated header files) are expected to be available but are not.

Some possibly useful information:

$ uname -a
AIX apocalypse 3 5 00403C9C4C00

$ emacs --version
GNU Emacs 21.4.1



Best regards,

Louis Strous
Attachment (config.log): application/octet-stream, 52 KiB
Attachment (config.status): application/octet-stream, 33 KiB
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
Permalink | Reply | 0 comments |
headers
Kevin Rodgers | 11 Jul 2005 19:16
Picon
Favicon

Re: the -*-coding: -*- stuff doesn't check for invalid codings

Dan Jacobson wrote:
> No error is reported to the user if he uses
> ;-*-coding: utf8;-*-
> instead of
> ;-*-coding: utf-8;-*-
> 
> I.e., the -*-coding: -*- stuff doesn't check for invalid codings.

Sure it does, it just doesn't report it (see set-auto-coding):

	      (or (coding-system-p coding-system)
		  (setq coding-system nil))

Is (error "Invalid coding system: %s" coding-system) really what
we want?

--

-- 
Kevin Rodgers
Permalink | Reply | 2 comments |

Gmane