Stefan Monnier | 1 May 04:58 2009
Picon

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

Tassilo Horn | 1 May 11:36 2009
Picon

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.
(Continue reading)

Emanuele Giaquinta | 1 May 12:40 2009
Picon

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
Attachment (load_charset.diff): text/x-diff, 480 bytes
Kenichi Handa | 1 May 12:56 2009

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)
(Continue reading)

Emanuele Giaquinta | 1 May 13:06 2009
Picon

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
Attachment (load_charset_map.diff): text/x-diff, 359 bytes
Kenichi Handa | 1 May 14:15 2009

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

(Continue reading)

Kenichi Handa | 1 May 14:17 2009

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

(Continue reading)

Borja Tarraso Hueso | 1 May 13:13 2009

Possible emacs bug when type password fields

Hi,

I was wondering if this is a known issue or not, but it seems some emacs bug, when I tried M-x gnus or M-x erc or any other feature in emacs (it means that is not emacs specific feature bug) I cannot use num keypad to type the password field. I tried in two different computers, with two different emacs versions, and different features, with same results.

Emacs version affected:

GNU Emacs 23.0.90.2 (i686-pc-linux-gnu) of 2009-04-21 on blackhole

Steps to reproduce the issue:

Way 1:
1) M-x gnus
2) when password prompt appears, try to use numkey pad.
3) see that dots do not appears for any key pressed.

Way 2:
1) M-x erc
2) ask several cuestions about irc server, port, nickname.
3) when password prompt appears, try to use numkey pad.
4) see that dots do not appears for any key pressed.

I did not test any other emacs feature that shows a prompt password.

Thanks!

Borja Tarraso

Chong Yidong | 1 May 18:24 2009

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.

Tobias C. Rittweiler | 1 May 18:37 2009
Picon

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.


Gmane