headers
Frank Küster | 1 Mar 09:08
Picon

Re: Bug#297181: auctex dont't install

Bonjour Jean-Jacques,

please keep the bugnumber address in the Cc line. I'm also adding the
AUC-TeX mailing list to it, because it seems I need some help in
debugging. Davide, are you around currently?

Jean-Jacques Rétorré <jean-jacqu.retorre <at> ac-nantes.fr> schrieb:

> Frank Küster a écrit :
>> Jean-Jacques Rétorré <jean-jacqu.retorre <at> ac-nantes.fr> schrieb:
>>
>>>Package: auctex
>>>Version: 11.55-1
>>>Severity: grave
>>>Justification: renders package unusable
>>>
>>> `aptitude install auctex` report: Unpacking auctex (from
>>> .../auctex_11.55-1_all.deb) ...
>>>Setting up auctex (11.55-1) ...
>>>install/auctex: Setting up for emacs21... emacs-package-install:
>>>/usr/lib/emacsen-common/packages/install/auctex emacs21 emacs21 failed
>>>at /usr/lib/emacsen-common/emacs-package-install line 30, <TSORT> line
>>>1.
>>>dpkg: error processing auctex (--configure):
>>> subprocess post-installation script returned error exit status 2
[...]
>>  is there a file
>> CompilationLog.gz somewhere in a directory with auctex in its name,
>> probably in /usr/share/emacs21/site-lisp/auctex/CompilationLog.gz?
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ralf Angeli | 1 Mar 09:15
Picon

Re: Bug#297181: auctex dont't install

* Frank Küster (2005-03-01) writes:

> Jean-Jacques Rétorré <jean-jacqu.retorre <at> ac-nantes.fr> schrieb:
>
>> Type "make" at the prompt to build AUCTeX
>> /usr/bin/emacs21 -batch -q -no-site-file -l lpath.el -f batch-byte-compile context-en.el
>> While compiling toplevel forms in file /usr/share/emacs/site-lisp/auctex/context-en.el:
>>   !! Symbol's function definition is void ((TeX-mode-specific-command-menu))
>> Done
>> make: *** [context-en.elc] Error 1
>
> This is strange to me

This is the same symptom as described in
<URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285860&archive=yes>.
The problem there was the presence of an old AUCTeX installation.

--

-- 
Ralf
Permalink | Reply | 0 comments |
headers
Ralf Angeli | 1 Mar 10:49
Picon

Re: context coloring leaks out of verbatim environment

[Redirecting to the mailing list.]

* Ulrich Scholz (2005-03-01) writes:

>> If you want to test with `-no-site-file' you have to start Emacs with
>> `emacs -q -no-site-file' and without providing a file name at the
>> command line.  When Emacs is running you do `M-: (require 'tex-site)
>> RET' and `M-x global-font-lock-mode RET'.  _After_ that you can load a
>> LaTeX file.
>
> I did as you told.
>
> `emacs -q -no-site-file' without providing a file name
> `M-: (require 'tex-site) RET'
> `M-x global-font-lock-mode RET'
>
> Then I loaded the file given below.
>
> And the coloring leaks if I press <space> in the line of \end{verbatim}
> (before the losing '}').  Lines further down are affected if either they are
> in the same paragraph as \end{verbatim} (without empty line inbetween) or they
> are edited.

Why would you want to add a space there?

> The coloring becomes correct again if I 
> - press return at the beginning of \end{verbatim}.  I can safely remove that  
>   extra line without messing up the coloring 

It will not stay like this very long because the fontification code
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johan Glimming | 1 Mar 11:43
Picon
Picon
Favicon

M-tab and Carbon Emacs on Mac OS X

Hi

I would like to complete my macros with pressing M-tab, but in Mac OS X 
M-tab means switch window whenever M is Apple/Command (I like to have 
Meta Apple/Command since otherwise Alt-7 does not give me backslash on 
swedish keyboards etc). I don't mind not being able to switch 
applications in Carbon Emacs, but the best solution would probably be 
to change M-tab to e.g. Alt-tab or some other safe key. How can I do 
this?

Johan Glimming.
Permalink | Reply | 1 comment |
headers
David Kastrup | 1 Mar 12:18
Picon
Picon

Re: M-tab and Carbon Emacs on Mac OS X

Johan Glimming <glimming <at> kth.se> writes:

> I would like to complete my macros with pressing M-tab, but in Mac OS
> X M-tab means switch window whenever M is Apple/Command (I like to
> have Meta Apple/Command since otherwise Alt-7 does not give me
> backslash on swedish keyboards etc). I don't mind not being able to
> switch applications in Carbon Emacs, but the best solution would
> probably be to change M-tab to e.g. Alt-tab or some other safe
> key. How can I do this?

You can type either Esc Tab or M-C-i on the current binding.  Other
than that, probably something like

(add-hook 'LaTeX-mode-hook '(define-key LaTeX-mode-map (kbd "A-TAB")
'TeX-complete-symbol))

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Permalink | Reply | 0 comments |
headers
Masayuki Ataka | 1 Mar 12:22
Picon

Re: CJK in (auctex)I18n

From: Werner LEMBERG <wl <at> gnu.org>
Subject: Re: CJK in (auctex)I18n
Date: Mon, 28 Feb 2005 01:06:14 +0100 (CET)

> > > > Basically, I guess the manual entry should be revised.
> > >
> > > Yes.  Emacs > 21.3 works just fine for CJK languages.
> >
> > You mean Emacs < 22.1 does not support UNICODE CJK chars?  If
> > so, I agree with you.  UNICODE support of Emacs < 22.1 is
> > limited.  Maybe we should put some words for unicode.
> 
> Regarding my cjk-enc.el mode I need the many different mule encodings
> instead of Unicode.
> 
I didn't catch your aim of `JUST' in:
  Emacs > 21.3 works just fine for CJK languages.
# I'm poor at English.

You wanted to say that `(Emacs > 21.3) is needed for CJK languages'?
Or you wanted to just say that `Emacs 21.3 works fine for CJK languages'?

I think (Emacs > 20) works fine for CJK languages 
if UNICODE with CJK are not required.

> > [...] J <at> TeX{} for Japanese; H <at> LaTeX{} and k <at> TeX{} for Korean; and
> > @acronym{CJK}- <at> LaTeX{} package for @acronym{CJK}.
> 
> I would rather say `and CJK-LaTeX for supporting multiple CJK scripts
> within a single document'.
(Continue reading)

Permalink | Reply | 13 comments |
headers
David Kastrup | 1 Mar 14:54
Picon
Picon

Sorry for the preview-latex delays...


I have heard no vocal protests about the latest error icons (and one
does not see them too often anyway).  They only have a restricted set
of sizes and in particular are missing some smaller sizes.  Also the
default sizes picked are larger compared to the surroundings.  I think
this is appropriate since the men-at-work signs are business-as-usual,
whereas the error signs are more dire.

I have been distracted for several days hunting down a crash in
Emacs and was completely on the false track since I was suckered into
believing the debugger in optimized code.  So two warnings:

a) if you are debugging a crash due to a failed assertion, at the very
least use the -fno-crossjumps option of GCC, or compile without
optimization altogether.  If you don't, GCC will just use the same
abort() call for all failed assertions in the same function; and when
you walk the stack frame, it will be random (though every time the
same) which assertion will be flagged as being wrong.

Expensive lesson that.

b) if you are going for production use instead of debugging of CVS
Emacs (and that would apply to all packagers, too), please set
#define xassert(X)
instead of the xassert definition line in src/dispextern.h since there
are far too many bogus assertions right now.

I don't know whether I'll get the next release out before the next
batch of conferences (Chemnitzer Linuxtage Sat/Sun, where I'll be
holding the key note address as well as an "Emacs for desktop" kind of
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ralf Angeli | 1 Mar 15:25
Picon

Re: Sorry for the preview-latex delays...

* David Kastrup (2005-03-01) writes:

> b) if you are going for production use instead of debugging of CVS
> Emacs (and that would apply to all packagers, too), please set
> #define xassert(X)
> instead of the xassert definition line in src/dispextern.h since there
> are far too many bogus assertions right now.

I use

#define xassert(X)	(void) 0

anyway, as with the "default" Emacs is unbearably slow.

> I don't know whether I'll get the next release out before the next
> batch of conferences (Chemnitzer Linuxtage Sat/Sun, where I'll be
> holding the key note address as well as an "Emacs for desktop" kind of
> talk, and EuroTeX2005 with two talks and an AUCTeX/preview-latex/Emacs
> workshop).

Good luck.

--

-- 
Ralf
Permalink | Reply | 1 comment |
headers
David Kastrup | 1 Mar 15:40
Picon
Picon

Re: Sorry for the preview-latex delays...

Ralf Angeli <angeli <at> iwi.uni-sb.de> writes:

> * David Kastrup (2005-03-01) writes:
>
>> b) if you are going for production use instead of debugging of CVS
>> Emacs (and that would apply to all packagers, too), please set
>> #define xassert(X)
>> instead of the xassert definition line in src/dispextern.h since there
>> are far too many bogus assertions right now.
>
> I use
>
> #define xassert(X)	(void) 0
>
> anyway, as with the "default" Emacs is unbearably slow.

Problem is that xassert quality is rather different: most are basic
structural safety checks which would seem to exchange difficult to
find crashes and inconsistencies for easier debuggable ones.  Then
there are quite a few that try checking for visual consistency (like
cursor movements making forward progress).  They exchange a possible
nuisance for a catastrophe for the average user.  And they don't help
in debugging actually since you don't get to see the problem on the
screen...

The visual asserts are probably also mostly the expensive ones since
they sometimes have to walk through data structures to get their
condition.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Masayuki Ataka | 1 Mar 16:25
Picon

Re: CJK in (auctex)I18n

I checked in auctex.texi, including revised section `I18n'.

thanks,
---
Masayuki Ataka (japan)
Permalink | Reply | 10 comments |

Gmane