Custom Search
|
Date: July 29, 2003
From: Toby Speight <streapadair@xxxxxxx>
In-reply-to:
<1059463788.3f26226cd0693@xxxxxxxxxxxxxx> (Gian Uberto Lauri's message of "Tue, 29 Jul 2003 09:29:48 +0200")
References:
<877k62fkcf.fsf@xxxxxxxxxxx> <1059463788.3f26226cd0693@xxxxxxxxxxxxxx>
0> In article <1059463788.3f26226cd0693@xxxxxxxxxxxxxx>, 0> Gian Uberto Lauri <URL:mailto:GianUberto.Lauri@xxxxxx> ("Gian") wrote: Gian> Quoting Dan Jacobson <jidanni@xxxxxxxxxxx>: >> Would byte-compiling these speed things up? >> Loading 50gnuserv (source)...done >> Loading 50html-helper-mode (source)...done >> Loading 50mmm-mode (source)...done Gian> Does not slow down for sure. html-helper-mode has some loops inside Gian> that could benefit from byte compiling. Really? /etc/emacs/site-start.d/50html-helper-mode.el has (my counting): 5 setq 5 cons 4 quote 2 concat 1 symbol-name 1 autoload Perhaps you're confusing the site-start file with the html-helper-mode implementation (which *is* byte-compiled)?
Date: July 29, 2003
From: Gian Uberto Lauri <GianUberto.Lauri@xxxxxx>
In-reply-to:
<877k62fkcf.fsf@xxxxxxxxxxx>
References:
<877k62fkcf.fsf@xxxxxxxxxxx>
Quoting Dan Jacobson <jidanni@xxxxxxxxxxx>:
> Would byte-compiling these speed things up?
> Loading 50gnuserv (source)...done
> Loading 50html-helper-mode (source)...done
> Loading 50mmm-mode (source)...done
Does not slow down for sure. html-helper-mode has some loops inside that could
benefit from byte compiling.
I usually do it.
--
ing. Gian Uberto Lauri
Consulente main(){printf(&unix["\021%six\012\0"],
Gruppo Competenza (unix)["have"]+"fun"-0x60);}
Ambienti di Sviluppo David Korn, AT&T Bell Labs
C.so Stati Uniti 23/I ioccc best One Liner, 1987
35100 Padova (Italia)
+39 049 828 3556
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
Date: July 29, 2003
From: James LewisMoss <dres@xxxxxxxxxx>
In-reply-to:
<877k62fkcf.fsf@xxxxxxxxxxx> (Dan Jacobson's message of "Tue, 29 Jul 2003 04:49:04 +0800")
References:
<877k62fkcf.fsf@xxxxxxxxxxx>
>>>>> On Tue, 29 Jul 2003 04:49:04 +0800, Dan Jacobson <jidanni@xxxxxxxxxxx> >>>>> said: Dan> Would byte-compiling these speed things up? Loading 50gnuserv Dan> (source)...done Loading 50html-helper-mode (source)...done Dan> Loading 50mmm-mode (source)...done etc. They are so small that I can't imagine it making much of a difference and the complications of byte compiling them for everything would be a pain. (Not to mention making sure they are re compiled when changed (they being config files and all that).) Jim -- @James LewisMoss <dres@xxxxxxxxxx> | Blessed Be! @ http://people.debian.org/~dres | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach
Date: July 28, 2003
From: Dan Jacobson <jidanni@xxxxxxxxxxx>
Would byte-compiling these speed things up? Loading 50gnuserv (source)...done Loading 50html-helper-mode (source)...done Loading 50mmm-mode (source)...done etc.
Date: July 28, 2003
From: James LewisMoss <dres@xxxxxxxxxx>
In-reply-to:
<1059405762.10349.35.camel@zi1-placenta
> (Bernhard Kleine's message of "28 Jul 2003 17:22:41 +0200")
References:
<1059405762.10349.35.camel@zi1-placenta
>
>>>>> On 28 Jul 2003 17:22:41 +0200, Bernhard Kleine >>>>> <bernhard.kleine@xxxxxxxxxx> said: Bernhard> Hallo, I use xemacs21.4-6 on two different debian woody Bernhard> machines. Both have been installed from the same debian Bernhard> mirror. the apt/sources.list files are equally identical Bernhard> since the second one is a copy of the first one. Updates Bernhard> are also the same. Bernhard> I have now noticed some strange behaviour: While I can use Bernhard> the alt-key to access the menu items like File Edit View Bernhard> Cmds etc ( the F of file, the E of edit, the V of View Bernhard> etc. are underlined), I fail to use this shortcuts on the Bernhard> second machine. Since I have copied the init.el and the Bernhard> custom.el files from one machine to the .xemacs directory Bernhard> in my home directory, I cannot understand, why the same Bernhard> program runs differently on two machines. Bernhard> I have also checked the /usr/bin/xemacs /usr/bin/xemacs21 Bernhard> links and it happened that one machine runs xemacs21-mule Bernhard> while the other one runs xemacs21-mule-canna-wnn. Starting Bernhard> the program without the links by typing the long file names Bernhard> did not change the access to the menu items. Bernhard> When I changed options->menubars-"alt/meta selects menu Bernhard> items" and saved the changed options to custom.el, nothing Bernhard> changed. Bernhard> Any help appreciated since I would be glad to avoid the Bernhard> mouse as much as possible My best bet is that the key you are using on the two machines is sending different key codes. On each machine run "xev" (from an xterm so you can see its output). Put your mouse pointer in the little white box that pops up and press the alt/meta key you are expecting to be the same. Look at the xterm for the output from xev. Compare and contrast. Jim -- @James LewisMoss <dres@xxxxxxxxxx> | Blessed Be! @ http://people.debian.org/~dres | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach
Date: July 28, 2003
From: Bernhard Kleine <bernhard.kleine@xxxxxxxxxx>
Hallo, I use xemacs21.4-6 on two different debian woody machines. Both have been installed from the same debian mirror. the apt/sources.list files are equally identical since the second one is a copy of the first one. Updates are also the same. I have now noticed some strange behaviour: While I can use the alt-key to access the menu items like File Edit View Cmds etc ( the F of file, the E of edit, the V of View etc. are underlined), I fail to use this shortcuts on the second machine. Since I have copied the init.el and the custom.el files from one machine to the .xemacs directory in my home directory, I cannot understand, why the same program runs differently on two machines. I have also checked the /usr/bin/xemacs /usr/bin/xemacs21 links and it happened that one machine runs xemacs21-mule while the other one runs xemacs21-mule-canna-wnn. Starting the program without the links by typing the long file names did not change the access to the menu items. When I changed options->menubars-"alt/meta selects menu items" and saved the changed options to custom.el, nothing changed. Any help appreciated since I would be glad to avoid the mouse as much as possible Merci vielmals Bernhard
signature.asc
Description: This is a digitally signed message part
Date: July 22, 2003
From: Arnaud Vandyck <arnaud-guest@xxxxxxxxxxxxxxxxxxxxxxx>
In-reply-to:
<kooezoask1.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<kooezoask1.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Does anyone heard of it? Shouldn't it be interresting for Debian? Eric Ludlam <eludlam@xxxxxxxxxxxxx> wrote: > You could try cogre (connected graph editor), but you will need to > hack some lisp code to support flow chart blocks. It is currently > moving toward uml class hierarchy diagrams. > > http://cedet.sourceforge.net/cogre.shtml > > Eric > -- > Eric Ludlam "Photonic Doodler" The MathWorks x 7556 > eludlam@xxxxxxxxxxxxx (work) http://www.mathworks.com > eric@xxxxxxxxxxxxxxxx (home) http://www.siege-engine.com -- Arnaud Vandyck http://alioth.debian.org/users/arnaud-guest/
Date: July 20, 2003
From: Leandro Guimarães Faria Corsetti Dutra <lgcdutra@xxxxxxxxxxxx>
References:
<pan.2003.07.20.01.03.20.688658@xxxxxxxxxxxx>
On Sun, 20 Jul 2003 03:03:21 +0200, Leandro Guimarães Faria Corsetti
Dutra wrote:
> I use LANG=pt_BR.UTF-8. Everytime I try to input accented
> characters to GNU Emacs 21 (unstable cum testing) I get garbage.
Forget about it, the unstable GNU Emacs 21.3.2 gets it right.
--
_ Leandro Guimarães Faria Corsetti Dutra +41 (21) 648 11 34
/ \ http://br.geocities.com./lgcdutra/ +41 (78) 778 11 34
\ / Answer to the list, not to me directly! +55 (11) 5686 2219
/ \ Rate this if helpful: http://svcs.affero.net/rm.php?r=leandro
Date: July 20, 2003
From: Leandro Guimarães Faria Corsetti Dutra <lgcdutra@xxxxxxxxxxxx>
I use LANG=pt_BR.UTF-8. Everytime I try to input accented
characters to GNU Emacs 21 (unstable cum testing) I get garbage.
I had to revert to LC_CTYPE=pt_BR due to a Gtk+ 2 input bug.
Suddenly, GNU Emacs get all my accented characters.
Is this a missing feature, a bug, a configuration error,
something else?...
Thanks in advance!
--
_ Leandro Guimarães Faria Corsetti Dutra +41 (21) 648 11 34
/ \ http://br.geocities.com./lgcdutra/ +41 (78) 778 11 34
\ / Answer to the list, not to me directly! +55 (11) 5686 2219
/ \ Rate this if helpful: http://svcs.affero.net/rm.php?r=leandro
Date: July 11, 2003
From: John Paul Wallington <jpw@xxxxxxx>
In-reply-to:
<1057939456.30036.25.camel@columbia
> (message from Colin Walters on 11 Jul 2003 12:04:21 -0400)
References:
<E19apb0-00008s-00@xxxxxxxxxxxxxxxx> <20030711064946.GA7868@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <87brw1fsdj.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <1057939456.30036.25.camel@columbia
>
> But apparently I was under the wrong impression about which branch of > Emacs development was going to be released. I committed calc to what > was HEAD at the time, and I thought that was going to become 21.3, but > there was a different branch slated for release. Anyways, calc will be > in 21.4. Just check out Emacs from CVS and peruse "NEWS". > > The next obvious question is when 21.4 is going to be released, and I > can't answer that... The vibes I have gotten from following the emacs-devel list is that 21.4 may come from the RC branch (looks like there are enough commits post 21.3 to warrant it), in which case HEAD will be 21.5.
Date: July 11, 2003
From: Colin Walters <walters@xxxxxxxxxx>
In-reply-to:
<87brw1fsdj.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<E19apb0-00008s-00@xxxxxxxxxxxxxxxx> <20030711064946.GA7868@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <87brw1fsdj.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx>
On Fri, 2003-07-11 at 03:13, Manoj Srivastava wrote: > I use this package, and am interested in adopting it, except > that I note that Colin Walters states that: > > > I am orphaning the calc package; it is now included in the GNU Emacs > > > > CVS, and will be in the coming 20.3 release. Since I think XEmacs has > > > > their own version of calc, this package will soon have little purpose in > > > > life except to provide calc for Emacs 20 users, who should be switching > > > > to Emacs 21 anyways. > > > > [I think he meant 21.3, not 20.3] I did... > I note, however, that we have 21.3 in unstable, and we still > do not seem to have calc in emacs21. Does anyone know what happened? > I note that ftp://ftp.gnu.org/poub/gnu/calc/ still contains calc > 2.02f.tar.gz from 1997. But apparently I was under the wrong impression about which branch of Emacs development was going to be released. I committed calc to what was HEAD at the time, and I thought that was going to become 21.3, but there was a different branch slated for release. Anyways, calc will be in 21.4. Just check out Emacs from CVS and peruse "NEWS". The next obvious question is when 21.4 is going to be released, and I can't answer that...
Date: July 11, 2003
From: Manoj Srivastava <srivasta@xxxxxxxxxx>
In-reply-to:
<20030711064946.GA7868@xxxxxxxxxxxxxxxxxxxxxxxxxxx> (Marcelo E. Magallon's message of "Fri, 11 Jul 2003 08:49:46 +0200")
References:
<E19apb0-00008s-00@xxxxxxxxxxxxxxxx> <20030711064946.GA7868@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Fri, 11 Jul 2003 08:49:46 +0200, Marcelo E Magallon <mmagallo@xxxxxxxxxx>
said:
>> calc (#175399), orphaned 186 days ago Description: An advanced
>> calculator and mathematical tool for Emacs Reverse Depends:
>> riece-ndcc
> Maybe the maintainer of riece-ndcc cares about this?
I use this package, and am interested in adopting it, except
that I note that Colin Walters states that:
> I am orphaning the calc package; it is now included in the GNU Emacs
>
> CVS, and will be in the coming 20.3 release. Since I think XEmacs has
>
> their own version of calc, this package will soon have little purpose in
>
> life except to provide calc for Emacs 20 users, who should be switching
>
> to Emacs 21 anyways.
>
[I think he meant 21.3, not 20.3]
I note, however, that we have 21.3 in unstable, and we still
do not seem to have calc in emacs21. Does anyone know what happened?
I note that ftp://ftp.gnu.org/poub/gnu/calc/ still contains calc
2.02f.tar.gz from 1997.
> I've CC'd this to the debian-emacsen list in case any Debian Emacs
>
> hacker wants to adopt it.
>
And I am CC'ing that list to see if anyone can shed any light
on this issue.
manoj
--
Term, holidays, term, holidays, till we leave school, and then work,
work, work till we die. C.S. Lewis
Manoj Srivastava <srivasta@xxxxxxxxxx> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Date: July 08, 2003
From: Dan Sheridan <dan.sheridan@xxxxxxxxxxxxxx>
In-reply-to:
<867k6sgb8z.fsf@xxxxxxxxxxxxxxxxx> (Dan Sheridan's message of "Tue, 08 Jul 2003 18:49:00 +0100")
References:
<867k6sgb8z.fsf@xxxxxxxxxxxxxxxxx>
Dan Sheridan <dan.sheridan@xxxxxxxxxxxxxx> writes:
> I am using the latest XEmacs from sid, and I have the above message in
> my minibuffer whenever I try to use the minibuffer -- that is, any
> keypress in the minibuffer, such as when entering a filename, brings
> up the message, which obscures the display for a couple of
> seconds.
Ah, a little more fiddling revealed it to be something in my .xemacs
files. And a lot of binary searching revealed that removing from
custom.el the line:
'(lazy-lock-mode t nil (lazy-lock))
fixes the problem. Switching Lazy-lock back on from within customize
brings the problem back.
Who should I submit a bug report to?
Dan.
--
Dan Sheridan -- Research Student -- LFCS, Division of Informatics
University of Edinburgh, King's Buildings, Mayfield Road EH9 3JZ
Date: July 08, 2003
From: Dan Sheridan <dan.sheridan@xxxxxxxxxxxxxx>
Dear all,
I am using the latest XEmacs from sid, and I have the above message in
my minibuffer whenever I try to use the minibuffer -- that is, any
keypress in the minibuffer, such as when entering a filename, brings
up the message, which obscures the display for a couple of
seconds. This makes emacs rather unusable.
I've tried both mule and nomule variants with the same results. I am
also seeing a different set of font colours in LaTeX mode than I am
used to, though this is probably unrelated.
The current package version is 21.4.13-1; last time I saw it working I
was running 21.4.12-1.
Any suggestions?
Dan.
--
Dan Sheridan -- Research Student -- LFCS, Division of Informatics
University of Edinburgh, King's Buildings, Mayfield Road EH9 3JZ
Date: July 06, 2003
From: Dan Jacobson <jidanni@xxxxxxxxxxx>
While the gnus maintainer is now hopefully making the gnus package installable even on my system, I would recommend that if installation fails, there be a messages emitted to see http://groups.google.com/groups?selm=u1y713qu2.fsf%40sdm.de wherein we are told to manually delete the line "(setq gnus-format-specs '(..." from .newsrc.eld as the key to life with a removed gnus package, just using the previous emacs underlying version. Odd how the previous gnus package I had installed is gone too. Fortunate that there is a gnus inside emacs to fall back on. Unfortunate that I must brace for more mailbox corruption as I scrape back and forth oort/non-oort.
Date: July 06, 2003
From: Dan Jacobson <jidanni@xxxxxxxxxxx>
One even gets http://debian.linux.org.tw/debian/pool/main/g/gnus/gnus_5.10.2.orig.tar.gz and follows the instructions $ make cd lisp && make EMACS="emacs" lispdir="/usr/share/emacs/site-lisp" all make[1]: Entering directory `/home/jidanni/tmp/gnus-5.10.2/lisp' rm -f *.elc gnus-load.el URLDIR=/usr/share/emacs/21.2/site-lisp/url/ W3DIR=/usr/share/emacs21/site-lisp/w3-el/ lispdir=/usr/share/emacs/site-lisp srcdir=. emacs -batch -q -no-site-file -l ./dgnushack.el -f dgnushack-make-cus-load . Loading cus-dep... Directory . Generating cus-load.el... Wrong type argument: stringp, (mm-inline-text-html-with-images custom-variable) make[1]: *** [gnus-load.el] Error 255 make[1]: Leaving directory `/home/jidanni/tmp/gnus-5.10.2/lisp' make: *** [lick] Error 2