headers
Richard Stallman | 1 Aug 2006 01:59
Picon
Picon

Re: [simon.marshall <at> misys.com: Font Lock on-the-fly misfontification in C++]

To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs
has nothing to do with GNU.  Since XEmacs is a forked version of Emacs,
that is a misleading impression.  Please write "Emacs" and "XEmacs",
or else "GNU Emacs" and "GNU XEmacs".

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Nick Roberts | 1 Aug 2006 03:16
Picon

Re: crash when function-key-map is nil

 >  >   keytran.start = keytran.end = KEYMAPP (keytran.map) ? 0 : bufsize + 1;
 > 
 > 
 > Please try this replacement line:
 > 
 >  >     keytran.start = keytran.end = 0;
 > 
 > I think that will make things cleaner.

Looks good.  How about the lines (9495-7):

   mock_input = max (t, mock_input);
   fkey.start = fkey.end = KEYMAPP (fkey.map) ? 0 : bufsize + 1;
   keytran.start = keytran.end = KEYMAPP (keytran.map) ? 0 : bufsize + 1;

should they also read?:

   mock_input = max (t, mock_input);
   fkey.start = fkey.end = 0;
   keytran.start = keytran.end = 0;

--

-- 
Nick                                           http://www.inet.net.nz/~nickrob
Permalink | Reply | 1 comment |
headers
emacs user | 1 Aug 2006 07:14
Picon
Favicon

reproducible cygwin memory problems


A brief problem description:

memory usage of emacs does not decrease after killing buffers with images.

details:

I start emacs with

emacs.exe -q --no-site-file&

the memory usage right after startup is 14912;

after editing a small image: 16452;

after killing the buffer with the image and using M-:(clear-image-cache 
t)RET: 16476;

after editing a large image: 39164;

again quit+clear cache: 34484;

edit small+medium+large images: 58936;

quit+clear: 87636...  (increased!)

I hope someone can look into this, and I am happy to provide information 
given specific instructions.

thanks...  EU
(Continue reading)

Permalink | Reply | 1 comment |
headers
Romain Francoise | 1 Aug 2006 10:06
X-Face
Favicon
Gravatar

Re: [simon.marshall <at> misys.com: Font Lock on-the-fly misfontification in C++]

Richard Stallman <rms <at> gnu.org> writes:

> To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs
> has nothing to do with GNU.  Since XEmacs is a forked version of Emacs,
> that is a misleading impression.  Please write "Emacs" and "XEmacs",
> or else "GNU Emacs" and "GNU XEmacs".

But XEmacs is not a GNU package.

Maybe we should call it "non-GNU XEmacs" instead... ;-)

--

-- 
Romain Francoise <romain <at> orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Alan Mackenzie | 1 Aug 2006 11:21
Picon
Favicon

Re: [simon.marshall <at> misys.com: Font Lock on-the-fly misfontification in C++]

Morning, Stefan!

On Mon, Jul 31, 2006 at 06:03:41PM -0400, Stefan Monnier wrote:
> >> The patch below seems to fix number 2 and 3 for me.  Someone who
> >> understands cc-fonts.el better than me and thus knows where the two
> >> "public XXX" lines are handled could probably do a similar
> >> adjustment for them.

> > At the very least, this isn't suitable for the CC Mode repository,
> > since font-lock-multiline hasn't (yet?) been implemented in XEmacs
> > or older GNU Emacsen.

> I find it quite suitable, personally, since although it indeed only
> fixes the OP's problem under Emacs-22 (and Emacs-21 if you're willing
> to set the font-lock-multiline variable to t), it won't hurt in
> Emacs-20 or XEmacs.

> Better yet: you can make it work under any old font-lock
> implementation (Emacs-19/20/21, XEmacs-??) by using
> font-lock-fontify-region-function to obey the font-lock-multiline
> property.

And yes, f-l-fontify-region-function does exist in XEmacs.  :-)

As a matter of interest, does the f-l-multiline mechanism somehow work
with a _first_ fontification?  Assume CC Mode has been enhanced to use
f-l-multiline.  Say we have a buffer of C source in fundamental mode (so
there're no f-l-m properties on the buffer), and the top of the screen
is in the middle of a C construct.  If we do M-x c-mode, will the top
line get correctly fontified?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Mackenzie | 1 Aug 2006 09:59
Picon
Favicon

Re: [simon.marshall <at> misys.com: Font Lock on-the-fly misfontification in C++]

Good morning, Richard!

On Mon, Jul 31, 2006 at 07:59:55PM -0400, Richard Stallman wrote:

> To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs
> has nothing to do with GNU.

XEmacs isn't maintained by the GNU project.

> Since XEmacs is a forked version of Emacs, that is a misleading
> impression.  Please write "Emacs" and "XEmacs", or else "GNU Emacs"
> and "GNU XEmacs".

"Emacs", unqualified, can be ambiguous.  It can mean either (i) "an
editor of the Emacs persuasion"; or (ii) "the best editor in the world,
maintained by the GNU project".  In contexts where it is important to
emphasise that (ii) is meant, surely "GNU Emacs" is what to write.  

"XEmacs", by contrast, means what it means.  It's what its maintainers
call it, and I think they would be irritated a fair bit by "GNU XEmacs".
Also, "GNU XEmacs" is so unusual, that to write it would distract
attention from one's intented message.

--

-- 
Alan.
Permalink | Reply | 0 comments |
headers
David Kastrup | 1 Aug 2006 10:32
Picon
Picon

Re: [simon.marshall <at> misys.com: Font Lock on-the-fly misfontification in C++]

Alan Mackenzie <acm <at> muc.de> writes:

> Good morning, Richard!
>
> On Mon, Jul 31, 2006 at 07:59:55PM -0400, Richard Stallman wrote:
>
>> To speak of "GNU Emacs" and "XEmacs" gives the impression that
>> XEmacs has nothing to do with GNU.
>
> XEmacs isn't maintained by the GNU project.

Correct.

>> Since XEmacs is a forked version of Emacs, that is a misleading
>> impression.  Please write "Emacs" and "XEmacs", or else "GNU Emacs"
>> and "GNU XEmacs".
>
> "Emacs", unqualified, can be ambiguous.

No.

> It can mean either (i) "an editor of the Emacs persuasion";

In which case you can write "Emacsen".  Anyway, there are quite more
"editors of the Emacs persuasion", such as MicroEmacs and jed, and we
don't mean them when writing "Emacs", either.

If you mean "Emacs or XEmacs", write "Emacs or XEmacs".

> or (ii) "the best editor in the world, maintained by the GNU
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Kastrup | 1 Aug 2006 11:06
Picon
Picon

Lockup


Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

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

Hi, I just had a lockup occuring.  Here is a backtrace:

If emacs crashed, and you have the emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/local/emacs-21/share/emacs/22.0.50/etc/DEBUG for instructions.

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb79602ae in __lll_mutex_lock_wait ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb795cfc7 in _L_mutex_lock_159 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0x00000063 in ?? ()
#4  0xbfabe690 in ?? ()
#5  0x086a6d48 in ?? ()
#6  0xbfabe6d8 in ?? ()
#7  0x080c78f0 in handle_one_xevent (dpyinfo=0x82f375c, eventp=0xbfabdbec,
    finish=0xb79602ae, hold_quit=0x82f375c) at /home/tmp/emacs/src/xterm.c:6916
#8  0x0813b963 in emacs_blocked_malloc (size=4294967292, ptr=0xb7993042)
    at /home/tmp/emacs/src/alloc.c:1231
(Continue reading)

Permalink | Reply | 13 comments |
headers
Jan Djärv | 1 Aug 2006 15:35
Picon

Re: Lockup


David Kastrup skrev:
> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.
> 
> Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.
> 
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
> 
> Hi, I just had a lockup occuring.  Here is a backtrace:

Ouch, this is serious.  I currently have no idea how to solve this, except 
change Emacs to use SYNC_INPUT.  I'll have to think about this.

	Jan D.

> 
> If emacs crashed, and you have the emacs process in the gdb debugger,
> please include the output from the following gdb commands:
>     `bt full' and `xbacktrace'.
> If you would like to further debug the crash, please read the file
> /usr/local/emacs-21/share/emacs/22.0.50/etc/DEBUG for instructions.
> 
> (gdb) bt
> #0  0xffffe410 in __kernel_vsyscall ()
> #1  0xb79602ae in __lll_mutex_lock_wait ()
>    from /lib/tls/i686/cmov/libpthread.so.0
> #2  0xb795cfc7 in _L_mutex_lock_159 () from /lib/tls/i686/cmov/libpthread.so.0
> #3  0x00000063 in ?? ()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Van Holder | 1 Aug 2006 15:36
Picon

Directory name completion blocks with single alternative

[GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.18) of 2006-08-01 on leeloo]

Given a directory structure of the form:

/top-dir/sub-dir/a-file
/top-dir/some-file

With M-x cd, entering "/t" TAB completes to "/top-dir/" like it should,
but "/top-dir/s" TAB does NOT complete to "/top-dir/sub-dir/" even though
there is only 1 matching directory (TAB TAB shows only "sub-dir" as only
alternative); it's necessary to disambiguate the directory name from the
names of any and all files in the same location for tab completion to
proceed.  This seems like a bug.
Permalink | Reply | 0 comments |

Gmane