Emacs pretest 23.0.96 is available
Eli Zaretskii
alpha.gnu.org:
http://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.96.tar.gz
ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.96.tar.gz
It builds okay with DJGPP v2.03 on my XP SP2 machine.
Barring catastrophic bugs, this is the last pretest before Emacs 23.1
is released. So please try it if you can, and report any findings.
TIA
Rugxulo
On Jul 12, 12:48 pm, Eli Zaretskii <e...@gnu.org> wrote:
>
> Another pretest of Emacs 23.1, v23.0.96 is available from
> alpha.gnu.org:
>
> It builds okay with DJGPP v2.03 on my XP SP2 machine.
>
> Barring catastrophic bugs, this is the last pretest before Emacs 23.1
> is released. So please try it if you can, and report any findings.
Sorry for the minor delay in responding.
I built it with GCC 4.4.0 and DJGPP 2.04 on my XP machine again. Seems
to work okay (although I could *swear* hide-ifdef-mode works
differently on Vista but can't confirm just yet ...). Tetris ('p' for
pause, nice ...), gomoku (man I suck ...), Info reader, frames (C-x 5
2), vertical windows (C-x 3), menus via mouse, dired, Leim (esperanto-
postfix), random other stuff. Loading the 100 MB "enwik8" still works
(although wastes RAM vs. rel_alloc of course).
I used "config.bat --with-system-malloc msdos", sed -i "s/-O2/-Os -
mtune=i686/" .../make*, and manually did a dir /s/a-d/b | file -f - |
grep -i "exe\|COFF" | grep -v "POSIX" so as to delete the dumb
extensionless .EXE file duplicates (e.g. ebrowse and ebrowse.exe both
exist). I also deleted all *.o files but kept everything else (against
my better judgment, heh).
"Your file has been saved and can now be downloaded 10 times. It will
be deleted after 90 days without download."
http://rapidshare.com/files/256087289/emacs-djgpp-23096.7z.html
(35 MB)
MD5: 6A0A8D3654ECEB9396A52263ECAAB67E
Thanks for your efforts on this. Definitely worth preserving this gem
of a program, a big selling / bragging point for DOS: "Hey, we've got
modern Emacs too!" ;-)
Rugxulo
On Jul 12, 12:48 pm, Eli Zaretskii <e...@gnu.org> wrote:
>
> Another pretest of Emacs 23.1, v23.0.96 is available from
> alpha.gnu.org:
>
> Barring catastrophic bugs, this is the last pretest before Emacs 23.1
> is released. So please try it if you can, and report any findings.
I don't know what you call it (tooltips?), but when you hover the
mouse over certain items in the menu, the status line displays a
description of the choice. However, this isn't being displayed
correctly. I've actually mentioned this before, so you probably know
what I mean (though I admit it's low priority, just mentioning it just
for completeness ...).
Eli Zaretskii
> Date: Wed, 15 Jul 2009 07:21:16 -0700 (PDT)
>
> I don't know what you call it (tooltips?), but when you hover the
> mouse over certain items in the menu, the status line displays a
> description of the choice.
Yes, that's the replacement for tooltips for non-GUI builds of Emacs
(which is what DJGPP builds) that have the mouse.
> However, this isn't being displayed correctly. I've actually
> mentioned this before, so you probably know what I mean (though I
> admit it's low priority, just mentioning it just for completeness
Well, I seem to have forgot; can you describe what's incorrect?
Thanks for testing the pretest versions.
Rugxulo
On Jul 15, 12:51 pm, Eli Zaretskii <e...@gnu.org> wrote:
> > From: Rugxulo <rugx...@gmail.com>
Basically that some of the longer menus aren't showing the full
tooltip (some minor corruption). Here's a screencap, a lot easier to
show than describe:
Eli Zaretskii
> Date: Wed, 15 Jul 2009 12:23:38 -0700 (PDT)
>
> http://rugxulo.googlepages.com/emacs23096.png
Ah, that one... Yes, I remember now. It's somewhere on my todo.
Tomasz Zbro�ek
> Another pretest of Emacs 23.1, v23.0.96 is available from
> alpha.gnu.org:
I compiled it on XP SP3, DJGPP 2.04, gcc 4.3.2.
Looks good :D
Tomasz Zbro�ek
Client, DJGPP 2.04, GCC 4.2.3, I had a little problem while depacking with
djtar (-x) :
unable to create directory: emacs-23.0.96\nextstep\Cocoa\Emacs.base
\Contents\Resources\English.lproj
I pressed enter key on this event.
Then, during compilation info files were not compiled, anyway Emacs was
created and works ok! (but a little bit slowly loads files but maybe it's
slow machine ?:).
Eli Zaretskii
> Date: Tue, 21 Jul 2009 07:06:45 +0000 (UTC)
Thanks for testing.
Eli Zaretskii
> version=3.1.0
> From: "Tomasz Zbrożek" <t.zb...@upos.com.pl>
> Date: Tue, 21 Jul 2009 13:36:41 +0000 (UTC)
>
> I compiled it also on Wincorf Nixdorf Beetle/M, MS DOS 6.22 + MS Network
> Client, DJGPP 2.04, GCC 4.2.3, I had a little problem while depacking with
> djtar (-x) :
> unable to create directory: emacs-23.0.96\nextstep\Cocoa\Emacs.base
> \Contents\Resources\English.lproj
What was the full path of that directory, starting with the root of
the drive? If it was more than 8 levels deep, then this is expected
on plain DOS: it's a limitation of DOS filesystems.
> I pressed enter key on this event.
That's the right way of dealing with the problem: this directory is
not needed for the DJGPP port
> Then, during compilation info files were not compiled
This is normal: the Info files are supplied as part of the tarball.
> anyway Emacs was created and works ok! (but a little bit slowly
> loads files but maybe it's slow machine ?:).
What is the CPU speed?
Anyway, thanks again for testing. A successful build on plain DOS is
an important evidence.
Tomasz Zbro�ek
> What was the full path of that directory, starting with the root of
> the drive?
Even in main C:/ problem still exist.
> What is the CPU speed?
566 MHz, 128 MB RAM
Eli Zaretskii
> Date: Wed, 22 Jul 2009 07:03:45 +0000 (UTC)
>
> Eli Zaretskii <el...@gnu.org> wrote in news:83bpnd6...@gnu.org:
>
> > What was the full path of that directory, starting with the root of
> > the drive?
>
> Even in main C:/ problem still exist.
Does it work to say
mkdir emacs-23.0.96\nextstep\Cocoa\Emacs.base\Contents\Resources\English.lproj
from the DOS prompt? (You may need to tweak the "emacs-23.0.96" part
in the same way djtar did when it unpacked the distribution.)
> > What is the CPU speed?
>
> 566 MHz, 128 MB RAM
At such a speed, I'm not surprised it's a bit slow. If it's not
too much trouble, could you please tell how much time it takes for
"emacs -Q" to start up on this system?
Tomasz Zbro�ek
> mkdir
> emacs-23.0.96\nextstep\Cocoa\Emacs.base\Contents\Resources\English.lp
> roj
it's a bit strange, following command does not work :
mkdir c:\emacs-23.0-9\nextstep\Cocoa\Emacs.bas\Contents\Resource
\English.lpr
but for example :
mkdir c:\emacs-23.0-9\nextstep\Cocoa\Emacs.bas\Contents\Resource\Eng.a
and
mkdir c:\emacs-23.0-9\nextstep\Cocoa\Emacs.bas\Contents\Resource\English
works OK.
Sven Joachim
> Eli Zaretskii <el...@gnu.org> wrote in news:831vo86...@gnu.org:
>
>> mkdir
>> emacs-23.0.96\nextstep\Cocoa\Emacs.base\Contents\Resources\English.lp
>> roj
>
> it's a bit strange, following command does not work :
>
> mkdir c:\emacs-23.0-9\nextstep\Cocoa\Emacs.bas\Contents\Resource
> \English.lpr
The path name is too long, it exceeds the DOS limit of 64 bytes (sans
leading c:\ ).
> but for example :
>
> mkdir c:\emacs-23.0-9\nextstep\Cocoa\Emacs.bas\Contents\Resource\Eng.a
>
> and
>
> mkdir c:\emacs-23.0-9\nextstep\Cocoa\Emacs.bas\Contents\Resource\English
>
> works OK.
These are short enough that DOS can cope with them.
Sven
Rugxulo
On Jul 22, 12:50 pm, Eli Zaretskii <e...@gnu.org> wrote:
> > From: "Tomasz Zbro¿ek" <t.zbro...@upos.com.pl>
> > Date: Wed, 22 Jul 2009 07:03:45 +0000 (UTC)
>
> > Eli Zaretskii <e...@gnu.org> wrote innews:83bpnd6...@gnu.org:
>
> > > What is the CPU speed?
>
> > 566 MHz, 128 MB RAM
>
> At such a speed, I'm not surprised it's a bit slow. If it's not
> too much trouble, could you please tell how much time it takes for
> "emacs -Q" to start up on this system?
Um, I would hope that 566 Mhz should be fast enough!!!
I actually stripped and ran upx --best on my own GCC 4.4.0 / DJGPP
2.04 --with-system-malloc -Os -mtune=i686 build, and I ran that 2
MB .EXE on my Pentium 166 no MMX (32 MB RAM total, minus 5 MB for UIDE
cache and 5 MB for RAM disk) without any .el files or anything else.
It started up almost immediately, and this was under either DR-DOS
7.03 or FreeDOS 1.0++. So I don't know what Tomasz is experiencing
(although I didn't try loading anything > 500k, the ASCII .txt from
NASM 0.98.39 was the biggest I could think of offhand). I assume he
compiled it correctly since -O2 is default.
Tomasz, what size files are you trying to load? What text encoding? I
highly doubt it's a MS-DOS 6.22-specific slowdown although I guess
it's possible. Maybe your network redirector is slowing down all files
accesses. Are you using a decent cache? Even with all the billions
of .el files auto-loading, I find it hard to believe that normal-sized
files take long to load. (Sure, 100 MB might take a while, but by
"normal" I mean several MB at most.) Font-lock is on by default now,
so maybe he should turn that off.
Eli Zaretskii
> Date: Thu, 23 Jul 2009 06:48:51 -0700 (PDT)
>
> > > > What is the CPU speed?
> >
> > > 566 MHz, 128 MB RAM
> >
> > At such a speed, I'm not surprised it's a bit slow. If it's not
> > too much trouble, could you please tell how much time it takes for
> > "emacs -Q" to start up on this system?
>
> Um, I would hope that 566 Mhz should be fast enough!!!
It _is_ fast, but Emacs 23 is a large executable (9MB stripped vs 6MB
for Emacs 22.3 and 5MB for Emacs 21.4), so just loading it could take
some time, at least with a cold cache.
> Font-lock is on by default now, so maybe he should turn that off.
If the machine is too slow for that, yes.
Rugxulo
On Jul 23, 6:19 am, Sven Joachim <svenj...@gmx.de> wrote:
> On 2009-07-23 12:38 +0200, Tomasz Zbro¿ek wrote:
>
>
> > it's a bit strange, following command does not work :
>
> > mkdir c:\emacs-23.0-9\nextstep\Cocoa\Emacs.bas\Contents\Resource
> > \English.lpr
>
> The path name is too long, it exceeds the DOS limit of 64 bytes (sans
> leading c:\ ).
For reference, here's what mkdir.c from libc says:
----------------------------------------------------
#if 0
/* It seems that no version of DOS, including DOS 8, which is part
of Windows/ME, implements this function. Without LFN, this fails
mkdir on Windows/ME. Disabled. */
else if ((_osmajor > 7 && _osmajor < 10) /* OS/2 returns v10 and
above */
|| (_osmajor == 7 && _osminor >= 20))
{
/* DOS 7.20 (Windows 98) and later supports a new function with
a maximum path length of 128 characters instead of 67. This
is important for deeply-nested directories. */
r.x.ax = 0x43ff;
r.x.bp = 0x5053;
r.h.cl = 0x39;
}
#endif
----------------------------------------------------
http://www.delorie.com/djgpp/doc/rbinter/id/30/28.html (mkdir,
rename)
"Note: these functions are equivalent to INT 21/AH=39h and INT 21/
AH=56h,
but with a maximum path length of 128 characters instead of 67;
unlike INT 21/AX=71xxh, these functions are available under bare
DOS and not just in a Windows DOS box"
However, I guess it didn't work in all cases since it's disabled. I
don't know the details, but I do wonder why.
Rugxulo
On Jul 23, 2:08 pm, Eli Zaretskii <e...@gnu.org> wrote:
> > From: Rugxulo <rugx...@gmail.com>
> > Date: Thu, 23 Jul 2009 06:48:51 -0700 (PDT)
>
> > > > > What is the CPU speed?
>
> > > > 566 MHz, 128 MB RAM
>
> > > At such a speed, I'm not surprised it's a bit slow. If it's not
> > > too much trouble, could you please tell how much time it takes for
> > > "emacs -Q" to start up on this system?
>
> > Um, I would hope that 566 Mhz should be fast enough!!!
>
> It _is_ fast, but Emacs 23 is a large executable (9MB stripped vs 6MB
> for Emacs 22.3 and 5MB for Emacs 21.4), so just loading it could take
> some time, at least with a cold cache.
I don't think it would be any slower on his machine than mine.
Granted, I didn't have every (or any) .el loading up, but it seemed
plenty fast enough for me. Heck, Emacs has always had the rep of being
slow to start, hence emacsclient and the "keep it always open and do
everything within it" suggestions.
But anyways, he actually said "but a little bit slowly loads files but
maybe it's slow machine ?" So he's talking about loading files. I
didn't see any slowdown at all loading files, but like I said, I
didn't try anything too big. (I'll admit that loading a 100 MB file on
Vista with Emacs 23 is slower than other editors, e.g. TDE, but that's
not really a typical file size.) So it could be his hard drive is
slow. Or anything else, I dunno. We'd need more information from him
to know exactly.
Tomasz Zbro�ek
When I start emacs and load first file (e.g malloc.c) it takes 2-3 seconds
to be loaded with font-lock-mode enabled. But when I load second file
(buffer.c which is even bigger) it takes only about 1 second. I noticed
that only loading first file takes more time, next files load much faster.
My smartdrv params are: /n /f 8192
I made a test without smartdrv at all, it was much slower to run emacs and
to load files of course :)
Eli Zaretskii
> Date: Fri, 24 Jul 2009 11:21:15 +0000 (UTC)
>
> I talk about emacs *.c files like malloc.c or buffer.c.
> When I start emacs and load first file (e.g malloc.c) it takes 2-3 seconds
> to be loaded with font-lock-mode enabled. But when I load second file
> (buffer.c which is even bigger) it takes only about 1 second. I noticed
> that only loading first file takes more time, next files load much faster.
This is normal: the first time you visit a .c file, Emacs loads the
CC-Mode package that supports editing C and C++ source files. CC-Mode
is quite large, so it takes some time to load. You can see that by
evaluating "(featurep 'cc-mode)" before and after you visit the first
.c file.
In previous versions of Emacs, loading Lisp libraries was always
announced in the echo area, so you'd see that and understand the
delay. But in Emacs 23, it was decided (against my objections, FWIW)
to suppress these messages, so now the user has no clue.
Laurynas Biveinis
> In previous versions of Emacs, loading Lisp libraries was always
> announced in the echo area, so you'd see that and understand the
> delay. But in Emacs 23, it was decided (against my objections, FWIW)
> to suppress these messages, so now the user has no clue.
Is this customizable--is there any way to get those messages back?
--
Laurynas
Eli Zaretskii
> Date: Sat, 25 Jul 2009 08:18:21 +0200
Funny you should ask, because I just added a variable to do that.
It's called `force-load-messages'.
It's too late to get this into Emacs 23.1, whose release is expected
next week. But you can apply the patch below when you build it, and
then you have the feature.
2009-07-25 Eli Zaretskii <el...@gnu.org>
* lread.c (syms_of_lread) <force_load_messages>: New variable.
(Fload): Use it to force load messages, even if NOMESSAGES is
non-nil.
Index: src/lread.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/lread.c,v
retrieving revision 1.408
retrieving revision 1.409
diff -u -r1.408 -r1.409
--- src/lread.c 25 Jul 2009 07:36:19 -0000 1.408
+++ src/lread.c 25 Jul 2009 08:50:17 -0000 1.409
@@ -214,6 +214,10 @@
int load_dangerous_libraries;
+/* Non-zero means force printing messages when loading Lisp files. */
+
+int force_load_messages;
+
/* A regular expression used to detect files compiled with Emacs. */
static Lisp_Object Vbytecomp_version_regexp;
@@ -970,7 +974,8 @@
If optional second arg NOERROR is non-nil,
report no error if FILE doesn't exist.
Print messages at start and end of loading unless
-optional third arg NOMESSAGE is non-nil.
+optional third arg NOMESSAGE is non-nil (but `force-load-messages'
+overrides that).
If optional fourth arg NOSUFFIX is non-nil, don't try adding
suffixes `.elc' or `.el' to the specified name FILE.
If optional fifth arg MUST-SUFFIX is non-nil, insist on
@@ -1164,7 +1169,7 @@
error ("File `%s' was not compiled in Emacs",
SDATA (found));
}
- else if (!NILP (nomessage))
+ else if (!NILP (nomessage) && !force_load_messages)
message_with_string ("File `%s' not compiled in Emacs", found, 1);
}
@@ -1186,7 +1191,7 @@
newer = 1;
/* If we won't print another message, mention this anyway. */
- if (!NILP (nomessage))
+ if (!NILP (nomessage) && !force_load_messages)
{
Lisp_Object msg_file;
msg_file = Fsubstring (found, make_number (0), make_number (-1));
@@ -1208,7 +1213,7 @@
emacs_close (fd);
val = call4 (Vload_source_file_function, found, hist_file_name,
NILP (noerror) ? Qnil : Qt,
- NILP (nomessage) ? Qnil : Qt);
+ (NILP (nomessage) || force_load_messages) ? Qnil : Qt);
return unbind_to (count, val);
}
}
@@ -1231,7 +1236,7 @@
if (! NILP (Vpurify_flag))
Vpreloaded_file_list = Fcons (file, Vpreloaded_file_list);
- if (NILP (nomessage))
+ if (NILP (nomessage) || force_load_messages)
{
if (!safe_p)
message_with_string ("Loading %s (compiled; note unsafe, not compiled in Emacs)...",
@@ -1280,7 +1285,7 @@
prev_saved_doc_string = 0;
prev_saved_doc_string_size = 0;
- if (!noninteractive && NILP (nomessage))
+ if (!noninteractive && (NILP (nomessage) || force_load_messages))
{
if (!safe_p)
message_with_string ("Loading %s (compiled; note unsafe, not compiled in Emacs)...done",
@@ -4354,6 +4359,11 @@
them. */);
load_dangerous_libraries = 0;
+ DEFVAR_BOOL ("force-load-messages", &force_load_messages,
+ doc: /* Non-nil means force printing messages when loading Lisp files.
+This overrides the value of the NOMESSAGE argument to `load'. */);
+ force_load_messages = 0;
+
DEFVAR_LISP ("bytecomp-version-regexp", &Vbytecomp_version_regexp,
doc: /* Regular expression matching safe to load compiled Lisp files.
When Emacs loads a compiled Lisp file, it reads the first 512 bytes