headers
Georgi Boshnakov | 6 Jul 2008 00:26
Picon
Favicon

Bulgarian and math mode

HI,

Looking at the AucTeX sources I notice that

        TeX-toggle-off-input-method

switches off the input method but only for CJK methods (hard coded in  
that function).

I suggest that this be extended to Bulgarian and Russian. This is
certainly the right thing to do for Bulgarian and I am almost sure  
about Russian.

Thanks,
Georgi
Permalink | Reply | 3 comments |
headers
Ralf Angeli | 6 Jul 2008 11:34

Re: Bulgarian and math mode

* Georgi Boshnakov (2008-07-06) writes:

> Looking at the AucTeX sources I notice that
>
>         TeX-toggle-off-input-method
>
> switches off the input method but only for CJK methods (hard coded in  
> that function).
>
> I suggest that this be extended to Bulgarian and Russian. This is
> certainly the right thing to do for Bulgarian and I am almost sure  
> about Russian.

Wouldn't you nowadays want to use Cyrillic characters in your LaTeX
source rather than the respective LaTeX commands?

--

-- 
Ralf
Permalink | Reply | 2 comments |
headers
Ralf Angeli | 6 Jul 2008 19:17

Support for SyncTeX

Hi,

there is now some support for SyncTeX in AUCTeX.  You can enable the
respective minor mode with `C-c C-t C-y' or the respective TeXing option
in the Command menu.  You will need to have a recent TeX engine with
SyncTeX support and the synctex executable in path.  (Perhaps we should
check for that when the user tries to enable the mode.)

There is currently only support for forward search because I am not
aware of a viewer for X11 which supports SyncTeX.  (And I will not boot
into Windows to test with Sumatra PDF.)

I expect the new code to have some rough edges which need to be smoothed
out, so please test it and let me know if you find a bug.  (I expect
problems when one tries to mix Source Specials mode, SyncTeX mode and
synchronization with pdfsync.  There is no logic yet to prevent this.)

--

-- 
Ralf
Permalink | Reply | 14 comments |
headers
Georgi Boshnakov | 6 Jul 2008 19:18
Picon
Favicon

Re: Bulgarian and math mode


Quoting Ralf Angeli <angeli <at> caeruleus.net>:

>> I suggest that this be extended to Bulgarian and Russian. This is
>> certainly the right thing to do for Bulgarian and I am almost sure
>> about Russian.
>
> Wouldn't you nowadays want to use Cyrillic characters in your LaTeX
> source rather than the respective LaTeX commands?
>

This has always been the case.

In maths mode however cyrillic letters are not used. Therefore it is  
natural that switching to maths mode should also switch off  the  
cyrillic alphabet. This is exactly what happens when  one starts maths  
mode with (an ellectric) `$' but only for CJK languages.   Here is the  
place in tex.el I was referring to in my previous email.

(defun TeX-toggle-off-input-method ()
   "Toggle off input methods.
Currently, only support CJK input methods provided by LEIM package."
   (cond
    ;; LEIM Package
    ((and (boundp 'current-input-method) current-input-method
	 (string-match "^\\(chinese\\|japanese\\|korean\\)" current-input-method))
     (inactivate-input-method))
    (t );; do nothing
    ))
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ralf Angeli | 6 Jul 2008 19:33

Re: Bulgarian and math mode

* Georgi Boshnakov (2008-07-06) writes:

> In maths mode however cyrillic letters are not used.

Ah, in _math_ mode.  Now I got it.  I thought you were speaking of
disabling the input method unconditionally.

I implemented your suggestion.

--

-- 
Ralf
Permalink | Reply | 0 comments |
headers
David Kastrup | 6 Jul 2008 19:55
Picon
Picon

Re: Support for SyncTeX

Ralf Angeli <angeli <at> caeruleus.net> writes:

> there is now some support for SyncTeX in AUCTeX.  You can enable the
> respective minor mode with `C-c C-t C-y' or the respective TeXing
> option in the Command menu.  You will need to have a recent TeX engine
> with SyncTeX support and the synctex executable in path.  (Perhaps we
> should check for that when the user tries to enable the mode.)
>
> There is currently only support for forward search because I am not
> aware of a viewer for X11 which supports SyncTeX.  (And I will not
> boot into Windows to test with Sumatra PDF.)
>
> I expect the new code to have some rough edges which need to be
> smoothed out, so please test it and let me know if you find a bug.  (I
> expect problems when one tries to mix Source Specials mode, SyncTeX
> mode and synchronization with pdfsync.  There is no logic yet to
> prevent this.)

Personally, I would have considered it more userfriendly if SyncTeX was
basically a configuration option of Source Specials mode (call it Source
Correlation mode if you need to), and probably the default for
PDF+SourceSpecial.  I don't think that there is much sense in using both
Source Special and SyncTeX at once.  Feel free to persuade me otherwise.
I won't veto your implementation, though.  I don't use either frequently
enough nowadays to be the final judge.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Permalink | Reply | 2 comments |
headers
Ralf Angeli | 6 Jul 2008 20:21

Re: Support for SyncTeX

* David Kastrup (2008-07-06) writes:

> Personally, I would have considered it more userfriendly if SyncTeX was
> basically a configuration option of Source Specials mode (call it Source
> Correlation mode if you need to), and probably the default for
> PDF+SourceSpecial.  I don't think that there is much sense in using both
> Source Special and SyncTeX at once.

Me neither.  I think, hiding the technical details from the user as you
propose is a good idea and would be in line with how AUCTeX deals with
other features of TeX engines.  However, I'd be a bit concerned about
how the underlying options, esp. source specials vs. SyncTeX, can be
chosen and controlled if both could be used.  Especially when one wants
to do this on a per file basis, one would have to do both, activate the
Source Correlation mode and set the variable controlling the technique
to be used.  But perhaps this is a corner use case and not very
important.  I'll think about it ...

--

-- 
Ralf
Permalink | Reply | 1 comment |
headers
David Kastrup | 7 Jul 2008 12:02
Picon
Picon

Upstream support of XEmacs in AUCTeX


Directed to both XEmacs and AUCTeX developer lists.

It has become clear in the last few years that the efforts of AUCTeX
developers to support XEmacs are basically a waste of time.  According
to the XEmacs developer lists, there is no noticeable interest in an
uptodate AUCTeX distribution.

We have up to now provided an XEmacs package-like tarball (I have been
educated that calling it an XEmacs package would be wrong, since an
XEmacs package is defined by being built in the XEmacs package tree, not
by having the complete structure of an XEmacs package).

We have scripts in place for creating this tarball.  However, the
efforts of XEmacs developers that have tried to integrate AUCTeX into
XEmacs (without success so far since 11.55) don't make any use of our
work: while it would seem completely reasonable to me to start with the
XEmacs package-like tarball that our scripts create and start from this
ready-for-XEmacs configured state of the relevant startup files for
creating the CVS version of the XEmacs package, it would appear that all
approaches focus on duplicating the build procedure into XEmacs rather
than taking our work as a starting point.

In short: it appears that our own attempts at supporting the XEmacs
package system are a waste of time.  Nothing from that effort will
apparently be used or accepted in any form into downstream as long as no
AUCTeX core developer becomes a part of the XEmacs development team and
does the work himself.

I would thus suggest that we discontinue maintenance of the
(Continue reading)

Permalink | Reply | 18 comments |
headers
Uwe Brauer | 7 Jul 2008 14:53
Picon
Favicon

Re: Upstream support of XEmacs in AUCTeX


>>>>> "David" == David Kastrup <dak <at> gnu.org> writes:
Hello David,

   > Directed to both XEmacs and AUCTeX developer lists.

   > It has become clear in the last few years that the efforts of
   > AUCTeX developers to support XEmacs are basically a waste of time.
   > According to the XEmacs developer lists, there is no noticeable
   > interest in an uptodate AUCTeX distribution.

Well, first of all I have to apologize for not having been able to
submit the desired patch in due time. However thanks to Mats Lidell we
have an almost working solution (save a patch which should be applied to
XEmacs.rules). It is however not clear right now, whether this patch
will be accepted or another solution should be found. In any case I will
submit that patch tomorrow, (my workload has been high in the past
months) and hopefully within a couple of days we will have a working
solution. Once that is settled further synchronization should be easy
(given that the Installation process will not be changed again).

I all the time have benefit from your generous support of XEmacs and
appreciate that a lot. It is true there was no real Xemacs hacker (save
Nick for a time) actively contribution code to auctex. The best I could
offer myself would be testing, some contributions to style files but
unfortunately not more.

   > Am I overlooking something?

So given that we will have a working solution soon I would like to ask
(Continue reading)

Permalink | Reply | 12 comments |
headers
David Kastrup | 7 Jul 2008 15:05
Picon
Picon

Re: Re: Upstream support of XEmacs in AUCTeX

Uwe Brauer <oub <at> mat.ucm.es> writes:

>>>>>> "David" == David Kastrup <dak <at> gnu.org> writes:
> Hello David,
>
>
>    > Directed to both XEmacs and AUCTeX developer lists.
>
>    > It has become clear in the last few years that the efforts of
>    > AUCTeX developers to support XEmacs are basically a waste of time.
>
> Well, first of all I have to apologize for not having been able to
> submit the desired patch in due time. However thanks to Mats Lidell we
> have an almost working solution (save a patch which should be applied to
> XEmacs.rules). It is however not clear right now, whether this patch
> will be accepted or another solution should be found. In any case I will
> submit that patch tomorrow, (my workload has been high in the past
> months) and hopefully within a couple of days we will have a working
> solution. Once that is settled further synchronization should be easy
> (given that the Installation process will not be changed again).
>
>    > Am I overlooking something?
>
>
> So given that we will have a working solution soon I would like to ask
> you, not to stop the support you have given so far to XEmacs.

Unless I misunderstand, the patch that is going to be checked into the
XEmacs package system does not make any use of the build infrastructure
for XEmacs that the AUCTeX upstream has created, but rather tries to
(Continue reading)

Permalink | Reply | 8 comments |

Gmane