Re: Weird memory consumption libnked to frame font spec

>> There's something funny with our memory consumption.
>> Here is a recipe to show the problem, tho it uses mpc.el (and requires
>> an mpd daemon running), so you may find it rather inconvenient to try
>> and reproduce it.  Hopefully I'll find a way to get rid of this mpc.el
>> dependency to reproduce the bug, but for now, that's what we have:

>> - emacs -Q --eval '(dotimes (i 10 (other-frame 1)) (make-frame (quote ((font . "Sans")))))' -l
~/src/elisp/mpc/mpc.el -f mpc

> Do you see the same memory increase with an actual font
> family (e.g. "dejavu sans") instead of such a generic
> family name?

Yes, that makes no difference.

        Stefan

Re: M-x compile and window splitting

Frank Schmitt <ich <at> frank-schmitt.net> writes:

Hi Frank,

>>> In Emacs 23, the window is split vertically instead of horizontally
>>
>> No, it's split horizontally instead of vertically in Emacs speach,
>> see `C-h k C-x 3'.
>
> Rather un-intuitive IMO but however.

Well, yes.  I remember it by asking myself how the two windows are
positioned to each other after the split has been done.

>>> - the change doesn't seem to be mentioned in NEWS (at least I couldn't
>>>   find it)
>>
>> ,----[ /usr/share/emacs/23.0.92/etc/NEWS ]
>> | *** New value nil for split-height-threshold inhibits vertical splitting
>> | unless there's no other window.
>> | 
>> | +++
>> | *** New option split-width-threshold controls horizontal splitting.
>> | 
>> | +++
>> | *** A window can be split horizontally even when it's not full-width.
>> | 
>> | +++
>> | *** New option split-window-preferred-function can be set to a function
>> | to override the default splitting mechanism of display-buffer.

load_charset warning

Hi,

gcc emits the following warning for charset.c:load_charset:

charset.c: In function 'load_charset':
charset.c:649: warning: comparisons like X<=Y<=Z do not have their mathematical meaning

Since the code seems correct, i'd suggest the attached patch to
improve readability (and avoid the warning).

Emanuele Giaquinta

Re: load_charset warning

In article <20090501104053.GB37259 <at> orion.local>, Emanuele Giaquinta
<emanuele.giaquinta <at> gmail.com> writes:

> gcc emits the following warning for charset.c:load_charset:

> charset.c: In function 'load_charset':
> charset.c:649: warning: comparisons like X<=Y<=Z do not have their mathematical meaning

> Since the code seems correct, i'd suggest the attached patch to
> improve readability (and avoid the warning).

Thank you.  I committed your change.

---
Kenichi Handa
handa <at> m17n.org

> diff --git a/src/charset.c b/src/charset.c
> index 15975a4..107647f 100644
> --- a/src/charset.c
> +++ b/src/charset.c
>  <at>  <at>  -646,7 +646,7  <at>  <at>  load_charset (charset, control_flag)
>    if (inhibit_load_charset_map
>        && temp_charset_work
>        && charset == temp_charset_work->current
> -      && (control_flag == 2 == temp_charset_work->for_encoder))
> +      && ((control_flag == 2) == temp_charset_work->for_encoder))
>      return;

>    if (CHARSET_METHOD (charset) == CHARSET_METHOD_MAP)

Re: load_charset warning

On Fri, May 01, 2009 at 07:56:23PM +0900, Kenichi Handa wrote:

> In article <20090501104053.GB37259 <at> orion.local>, Emanuele Giaquinta
<emanuele.giaquinta <at> gmail.com> writes:
> 
> > gcc emits the following warning for charset.c:load_charset:
> 
> > charset.c: In function 'load_charset':
> > charset.c:649: warning: comparisons like X<=Y<=Z do not have their mathematical meaning
> 
> > Since the code seems correct, i'd suggest the attached patch to
> > improve readability (and avoid the warning).
> 
> Thank you.  I committed your change.

I also noticed a useless assignment to for_encoder, see attached patch.

Emanuele Giaquinta

Re: Weird memory consumption libnked to frame font spec

In article <jwvskjpzg0x.fsf-monnier+emacs <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> There's something funny with our memory consumption.
>>> Here is a recipe to show the problem, tho it uses mpc.el (and requires
>>> an mpd daemon running), so you may find it rather inconvenient to try
>>> and reproduce it.  Hopefully I'll find a way to get rid of this mpc.el
>>> dependency to reproduce the bug, but for now, that's what we have:

>>> - emacs -Q --eval '(dotimes (i 10 (other-frame 1)) (make-frame (quote ((font . "Sans")))))' -l
~/src/elisp/mpc/mpc.el -f mpc

> > Do you see the same memory increase with an actual font
> > family (e.g. "dejavu sans") instead of such a generic
> > family name?

> Yes, that makes no difference.

Ummm, I can't reproduce the case of huge memory increase by
make-frame.  Can't you find a testcase to reproduce it
without your mpc.el?

By the way, I can observe about 1M memory increase, but at
the moment, I don't know where that memory is used.  At
least, font-objects and font-entities are shared by frames.

---
Kenichi Handa
handa <at> m17n.org

Re: load_charset warning

In article <20090501110629.GC37259 <at> orion.local>, Emanuele Giaquinta
<emanuele.giaquinta <at> gmail.com> writes:

> I also noticed a useless assignment to for_encoder, see attached patch.

> Emanuele Giaquinta

> --WhfpMioaduB5tiZL
> Content-Type: text/x-diff; charset=us-ascii
> Content-Disposition: attachment; filename="load_charset_map.diff"

> diff --git a/src/charset.c b/src/charset.c
> index 15975a4..7d9bc2f 100644
> --- a/src/charset.c
> +++ b/src/charset.c
>  <at>  <at>  -319,7 +319,6  <at>  <at>  load_charset_map (charset, entries, n_entries, control_flag)
>  	    {
>  	      memset (temp_charset_work->table.decoder, -1,
>  		      sizeof (int) * 0x10000);
> -	      temp_charset_work->for_encoder = 0;
>  	    }
>  	  else
>  	    {

Thank you.  I committed that change too.

---
Kenichi Handa
handa <at> m17n.org

Possible emacs bug when type password fields

Emacs 23.0.93 pretest

Emacs pretest 23.0.93 is now available; this is the fourth pretest for
what will be the Emacs 23.1 release.  You can download it via FTP, at
the following location:

  http://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.93.tar.gz

The xdelta against the previous pretest, 23.0.92, is here:

  http://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.92-23.0.93.xdelta

Pretesters: please send an email to me reporting success or failure on
your build platform.  In addition, please report bugs via M-x
report-emacs-bugs, or send an email to emacs-pretest-bug <at> gnu.org.  For
other questions, please email emacs-devel <at> gnu.org.

Emacs developers: as mentioned earlier on emacs-devel, from this point
on, commits to CVS should consist of only fixes to regressions---i.e.,
bugs that exist in Emacs 23 but not in Emacs 22---with the exception of
documentation changes.  If you want an exception to this rule, please
discuss it on emacs-devel first.

Thank you.

Re: `font-lock-extend-region-functions' vs. `font-lock-extend-after-change-region-function'

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> The way I imagine fixing it is by changing jit-lock-functions such that
> the functions on that hook (e.g. font-lock-fontify-region) would return
> the new boundaries they used (or nil if they kept the boundaries passed
> by jit-lock).

I'd also like if the font-lock-extend-region-functions were called with
an argument counter representing the number of extend region passes so
far.

Of course that would be a backwards-incompatible API change but you
could bind a special variable representing the count.

Purpose is to guard against infinite loops.

Alternatively `font-lock-default-fontify-region' could be made smarter
in so far as it could check whether a pass actually changed
font-lock-beg and font-lock-end, and if not, would not try another pass.

(Strictly speaking the latter would also mean a slight API change, but
anyone who were bitten by this should be slapped three times by some
appropriately thick book anyway. )

  -T.