BUG in scroll-lock-mode?

[Leo]

Dear all,

I put (scroll-lock-mode t) in ~/.emacs, but it is still disabled after
restart emacs. Is this a bug in scroll-lock-mode?

HTH,
-- 
Leo  (GPG Key: 9283AA3F)



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: memory leak in xpm_load

[Richard Stallman]

Can you fix this, in Emacs 22 and the trunk?


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: memory leak in xpm_load

[Chong Yidong]

"Juanma Barranquero" <[EMAIL PROTECTED]> writes:

> On 6/6/07, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> wrote:
>
>> In xpm_load (if HAVE_XPM and ALLOC_XPM_COLORS), xpm_init_color_cache
>> is called twice without an intervening xpm_free_color_cache call, and
>> that causes a memory leak ~4KB per XPM image creation.
>
> Try removing the second one; I think it's a leftover from a patch by Chong.

Actually, I think I added the first call by mistake.  I removed it.
Thanks for spotting the problem.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: old web page

[Glenn Morris]

Francesco Potorti` wrote:

> At  a link is provided to the
> source tarball of Emacs 21.4a, rather than 22.1.

The emacs developers have no direct access to this page. As it says at
the end of the page, problems should be reported to bug-directory at
gnu.org. I already sent a patch to update the page for Emacs 22, but
for some reason it was only partially applied. I will send the rest
again.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

old web page

[Francesco Potorti`]

At  a link is provided to the
source tarball of Emacs 21.4a, rather than 22.1.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: cannot activate font-lock-mode

[Francesco Potorti`]

>Why didn't you try the very first solution I proposed?  You have to
>activate font-lock-mode _after_ setting the defaults, like this
>
># Local Variables:
># font-lock-defaults: (("^\\s-*:0" "##+"))
># mode: font-lock
># End:

I had not understood this suggestion.  As soon as I build emacs 22 I'll
try again and report.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: memory leak in xpm_load

[Juanma Barranquero]

On 6/6/07, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> wrote:


I don't think I fully understand the code


I don't, either. I said it seemed like a leftover because the second
call was already in place when Chong installed his patch.


but attr->numsymbols in
xpm_init_color_cache becomes always 0 if the second call is removed.
Is that right?


I don't think so. Time to ask Chong :)

Juanma


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: memory leak in xpm_load

[YAMAMOTO Mitsuharu]

> On Wed, 6 Jun 2007 11:41:24 +0200, "Juanma Barranquero" <[EMAIL 
> PROTECTED]> said:

> On 6/6/07, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> wrote:
>> In xpm_load (if HAVE_XPM and ALLOC_XPM_COLORS),
>> xpm_init_color_cache is called twice without an intervening
>> xpm_free_color_cache call, and that causes a memory leak ~4KB per
>> XPM image creation.

> Try removing the second one; I think it's a leftover from a patch by
> Chong.

I don't think I fully understand the code, but attr->numsymbols in
xpm_init_color_cache becomes always 0 if the second call is removed.
Is that right?

 YAMAMOTO Mitsuharu
[EMAIL PROTECTED]


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: memory leak in xpm_load

[Juanma Barranquero]

On 6/6/07, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> wrote:


In xpm_load (if HAVE_XPM and ALLOC_XPM_COLORS), xpm_init_color_cache
is called twice without an intervening xpm_free_color_cache call, and
that causes a memory leak ~4KB per XPM image creation.


Try removing the second one; I think it's a leftover from a patch by Chong.

Juanma


Index: src/image.c
===
RCS file: /cvsroot/emacs/emacs/src/image.c,v
retrieving revision 1.70
diff -u -2 -r1.70 image.c
--- src/image.c 3 Jun 2007 00:23:33 -   1.70
+++ src/image.c 6 Jun 2007 09:38:34 -
@@ -3968,4 +3968,5 @@
  attrs.free_colors = xpm_free_colors;
  attrs.valuemask |= XpmAllocColor | XpmFreeColors | XpmColorClosure;
+  xpm_init_color_cache (f, &attrs);
#else /* not ALLOC_XPM_COLORS */
  /* Let the XPM lib allocate colors.  */
@@ -3979,7 +3980,4 @@
#endif /* not XpmAllocCloseColors */
#endif /* ALLOC_XPM_COLORS */
-#ifdef ALLOC_XPM_COLORS
-  xpm_init_color_cache (f, &attrs);
-#endif

  /* If image specification contains symbolic color definitions, add
@@ -4021,8 +4019,4 @@
  /* Create a pixmap for the image, either from a file, or from a
 string buffer containing data in the same format as an XPM file.  */
-#ifdef ALLOC_XPM_COLORS
-  xpm_init_color_cache (f, &attrs);
-#endif
-
  specified_file = image_spec_value (img->spec, QCfile, NULL);


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug