Salvatore Vassallo ha scritto in data 06/06/2008 16.22:
>
> There is a little Winedt macro on
> http://william.famille-blum.org/blog/index.php?entry=entry080515-065447
>
>

Questa č la macro di cui parlavi? Ho visto solo ora la risposta alla
mailing list di winedt perché sono molto indietro con la lettura.

Non ho ancora installato sumatra, possiamo farlo domani?

Ciao
G

I am very sorry: I answered to the list instead of answering to my
colleague.

I apologize

Grazia

Hi Robert,

On 2008-06-07 RS wrote:
> On 07.06.2008 16:59, Ulrich Dirr wrote:
> > both forward and inverse searches are working. That's fine. But
> > strangely when using the pdfsync package (the only thing I changed
> > in my source while testing with a recently typeset book) my
> > resulting pdf file had been changed (I got some new bad page breaks)
> > which is of course extremely bad. But maybe it's because I've also
> > got an error message near the end:
>
> Yes, pdfsync is known to be a bit flimsy. This is from pdfsync.sty:
>
> % In case of sever conflicts with another package, try
> % \usepackage[novbox]{pdfsync} instead.
> %
> % If pdfsync only breaks some part of your LaTeX code, you can try to
> % enclose it in a \pdfsyncstop \pdfsyncstart pair.
> % If you want to add more control point add \pdfsync at sensible
> % locations in your code.
> % In that case, \usepackage[off]{pdfsync} will disable pdf
> % synchronization and \relax the above commands.
> %
> % Use option nohbox (resp nocr, nopar, nomath, nodisplay) in order not
> % to add control points every hbox (resp cr, par, math,display)
> %
> % Bugs
> % ----
> % pdfsync uses extremely severe code. You should not use pdfsync on
> % final documents because it can change the layout rather significantly
> % (different page/line breaks are the most obvious changes), despite
> % this is rather rare, 17.8th Murphy's law states that it will happen to
> % you when it absolutely must not...
> %
> % You should report bugs and package conflicts to jlaurens AT users DOT
> % sourceforge DOT net.

Thank you for pointing me to the documentation ;-) Indeed putting in a
\pdfsyncstop/\pdfsynstart pair solves the problem. But the numerous changes
in page breaking aren't very smart. You mentioned that pdftex has pdfsync
incorporated into the program (>= v1.40.8, already in miktex's
1.40.8-alpha-20080323?). Will pdftex with this "native" support change the
page breaking too? If not we should ask Krzysztof Kowalczyk (SumatraPDF) to
support it!

Best regards,
Ulrich

Hello,

I was wondering whether anyone knows of a mode for running SML
(functional programming language: see http://www.smlnj.org) under WinEdt?

The basic functionality I would be after is an easy way of compiling and
running the ML program in the current WinEdt window.

Thanks very much,

James

Hello,
I am trying to produce an a4 landscape pdf file by the pdfTeXify option, but
I get a document which is 11 x 9 in (27,937 x 21,587 cm) instead of 29, 7 x
21 cm.
Any help to solve this problem would be appreciated.
Sincerely,
José A. Facenda Aguirre

Am Donnerstag, 12. Juni 2008 schrieb José A. Facenda Aguirre:

> Hello,
> I am trying to produce an a4 landscape pdf file by the pdfTeXify option, but
> I get a document which is 11 x 9 in (27,937 x 21,587 cm) instead of 29, 7 x
> 21 cm.
> Any help to solve this problem would be appreciated.
> Sincerely,
> José A. Facenda Aguirre


Depends a bit on the class used.

\usepackage[dvips]{geometry} %yes dvips is okay even with pdflatex!

or option pagesize if you are using on of the koma-classes or typearea.

memoir has it own method.

http://www.tex.ac.uk/cgi-bin/texfaq2html?label=papersize

--
Mit freundlichen Grüßen
Ulrike Fischer
mailto:list@...

Hello,
this is my preamble:

\documentclass[10pt]{article}
\usepackage{amsmath,amssymb,enumerate}
\usepackage[ansinew]{inputenc}
\usepackage[spanish]{babel}

By the way latex->dvips-ps2pdf,  (using the command line switches), I get a
correct landscape a4.
I  wonder if it possible to obtain the a4 pdf file directly by pdfTeXify
rute. The default paper size is not set to a4. How can I fix that?
Thanks,
José A. Facenda Aguirre

\usepackage[dvips]{graphicx,color,colortbl}\usepackage[body={27cm,17cm},landscap\
e]{geometry}
----- Original Message -----
From: "Ulrike Fischer" <list@...>
To: <winedt+list@...>
Sent: Thursday, June 12, 2008 10:30 AM
Subject: Re: [WinEdt] pdf in A4 paper


Am Donnerstag, 12. Juni 2008 schrieb José A. Facenda Aguirre:

> Hello,
> I am trying to produce an a4 landscape pdf file by the pdfTeXify option,
> but
> I get a document which is 11 x 9 in (27,937 x 21,587 cm) instead of 29, 7
> x
> 21 cm.
> Any help to solve this problem would be appreciated.
> Sincerely,
> José A. Facenda Aguirre


Depends a bit on the class used.

\usepackage[dvips]{geometry} %yes dvips is okay even with pdflatex!

or option pagesize if you are using on of the koma-classes or typearea.

memoir has it own method.

http://www.tex.ac.uk/cgi-bin/texfaq2html?label=papersize

--
Mit freundlichen Grüßen
Ulrike Fischer
mailto:list@...

Am Donnerstag, 12. Juni 2008 schrieb José A. Facenda Aguirre:

> Hello,
> this is my preamble:

> \documentclass[10pt]{article}
> \usepackage{amsmath,amssymb,enumerate}
> \usepackage[ansinew]{inputenc}
> \usepackage[spanish]{babel}
> \usepackage[dvips]{graphicx,color,colortbl}
                 ^^^
Don't use the option dvips here. It is unnecessary and will only give
trouble if you run pdflatex.

> \usepackage[body={27cm,17cm},landscape]{geometry}

> I  wonder if it possible to obtain the a4 pdf file directly by pdfTeXify
> rute.

Did you try the geometry option I suggested and read the FAQ-link I sent you?:

>> \usepackage[dvips]{geometry} %yes dvips is okay even with pdflatex!
>> http://www.tex.ac.uk/cgi-bin/texfaq2html?label=papersize

> The default paper size is not set to a4. How can I fix that?

Read the documentation of geometry. It tells you how to set the paper
size.


--
Mit freundlichen Grüßen
Ulrike Fischer
mailto:list@...

José A. Facenda Aguirre wrote:
> By the way latex->dvips-ps2pdf,  (using the command line switches), I
> get a correct landscape a4.
> I  wonder if it possible to obtain the a4 pdf file directly by
> pdfTeXify rute. The default paper size is not set to a4. How can I fix
> that?

I had the same problem and here is the solution I found:

Option -> Execution Modes

Choose dvi2pdf under Accessories (or whatever else you use)

Choose A4 (instead of default) under Paper Size

Hope that helps!

Michail

dear alex,

i have just encountered two problems with
               WinEdt 5.6: [Build: 20080429] beta
1. if one performs a diagnosis he/she gets
     the error message

TeX-Help: (latex2e.chm) not found
    C:\Program Files\MiKTeX 2.7\doc\latex2e.chm
****************************************************
WinEdt did not find the expected documentation in TeX's Help folder. To
correct the problem install extra TeX Documentation (eg. with MiKTeX's
Package Manager or TeX Live Manager) or reinstall a complete (reasonably
up-to-date) TeX System. Otherwise you will not be able to use
TeX-Related Help Items in WinEdt's Help Menu.
****************************************************

     however, winedt 5.6 looks for latex2e.chm at a wrong place since
     the file is put into the subdirectory
     C:\Program Files\MiKTeX 2.7\doc\latex\help\latex2e.chm

     by miktex. in other words some settings are incorrect.
     if i copy latex2e.chm into the directory
          C:\Program Files\MiKTeX 2.7\doc\
     the error message disappears.

2. i have been typesetting a book using the amsbook documentclass.
     the book consists of 218 pages. when texifying the manuscript
     (there is a project containing the various chapters in separate
     files) i am getting funny error messages in the window that opens
     at the bottom of the winedt screen:

Package hyperref Warning: Token not allowed in a PDF string (Unicode),
(hyperref)                removing `math shift' on input line 389.

[66] <3-3abra.eps> <3-4abra.eps> <3-5abra.eps> <3-6abra.eps>
Underfull \hbox (badness 1527) in paragraph at lines 516--518
[][]| \T1/cmr/m/n/10.95 A [][][][]. áb-rán fel-tün-te-tett
$\OML/cmm/m/it/10.95
   O \OMS/cmsy/m/n/10.95

the last five lines is being repeated a number of times (till texify
runs). this phenomenon has nothing to do with miktex. why? after i had
reloaded winedt 5.5 i did not got any error message when i was texifying
the same project.

if the files i am texifying are shorter the phenomenon described above
does not occur.

otherwise the dvi file resulted seems to be correct.

best regards
gyorgy

> i have just encountered two problems with
>               WinEdt 5.6: [Build: 20080429] beta
> 1. if one performs a diagnosis he/she gets
>     the error message
>
> TeX-Help: (latex2e.chm) not found
>    C:\Program Files\MiKTeX 2.7\doc\latex2e.chm
> ****************************************************
> WinEdt did not find the expected documentation in TeX's Help folder. To
> correct the problem install extra TeX Documentation (eg. with MiKTeX's
> Package Manager or TeX Live Manager) or reinstall a complete (reasonably
> up-to-date) TeX System. Otherwise you will not be able to use
> TeX-Related Help Items in WinEdt's Help Menu.
> ****************************************************
>
>     however, winedt 5.6 looks for latex2e.chm at a wrong place since
>     the file is put into the subdirectory
>     C:\Program Files\MiKTeX 2.7\doc\latex\help\latex2e.chm
>
>     by miktex. in other words some settings are incorrect.
>     if i copy latex2e.chm into the directory
>          C:\Program Files\MiKTeX 2.7\doc\
>     the error message disappears.

WinEdt no longer uses this file and the diagnosis in the Wizard
is wrong and has to be removed. This does not affect any
functionality since WinEdt 5.6 now comes with its own LaTeX
Help...

This has already been fixed in my working version (WinEdt no
longer searches for MiKTeX's .chm files). For now, just ignore
this message.

> 2. i have been typesetting a book using the amsbook
> documentclass.
>     the book consists of 218 pages. when texifying the manuscript
>     (there is a project containing the various chapters in separate
>     files) i am getting funny error messages in the window that opens
>     at the bottom of the winedt screen:
>
> Package hyperref Warning: Token not allowed in a PDF string (Unicode),
> (hyperref)                removing `math shift' on input line 389.
>
> [66] <3-3abra.eps> <3-4abra.eps> <3-5abra.eps> <3-6abra.eps>
> Underfull \hbox (badness 1527) in paragraph at lines 516--518
> [][]| \T1/cmr/m/n/10.95 A [][][][]. áb-rán fel-tün-te-tett
> $\OML/cmm/m/it/10.95
>   O \OMS/cmsy/m/n/10.95
>
> the last five lines is being repeated a number of times (till texify
> runs). this phenomenon has nothing to do with miktex. why? after i had
> reloaded winedt 5.5 i did not got any error message when i was texifying
> the same project.

The above message has nothing to do WinEdt and unless you have
changed something in WinEdt Execution Modes your observation
about the message not being present in 5.5 is likely wrong. You
may not see it on the screen if you have WinEdt 5.5 configured
so as to run texify in the background (you can do the same in
5.6 through the Execution Modes). Of course, I can only assume
that your 5.5 is configured to run the same version of MiKTeX
as 5.6 which may not be the case if you have more than one
version of MiKTeX installed (check the execution modes to be
sure!!!).

> if the files i am texifying are shorter the phenomenon described above
> does not occur.
>
> otherwise the dvi file resulted seems to be correct.

Start the Command prompt and type:

texify.exe --src yourmainfile.tex

watch the messages / warnings in Windows Console. This command
gets executed both in 5.5 and 5.6 when you texify a document.

What happens if you disable the option WinEdt Console in 5.6
Execution Modes for texify?

If the message disappears in this case (TeXify is now running
in the black box just like before) then the problem could be in
the way TeXify spawns processes and passes STD Output and Error
Handles. WinEdt's Console displays both (as it should!) but it
is possible that STD Error is ignored or redirected when texify
runs in its own console... That does not mean that the messages
have not been issued -- they are just not displayed on the
screen (although they should be). Try to execute latex.exe (as
well as texify.exe) from the command prompt and see if there is
any difference. Also check the log file and see if the messages
are there (texify might redirect STD Error directly to the log
file)...

You should compare the log file generated when you compile with
WinEdt 5.5 or 5.6. Anyway, I see no way of WinEdt making up the
above message. If its there it was reported by TeX (either to
STD Output or STD Error pipe) and WinEdt will almost certainly
turn out to be irrelevant to all of this... I am really curious
about this one as there should be no difference whether you
launch texify from 5.5 or 5.6 (except for the explanation above
about how texify manages its output and error handles when
using its own console in which case the problem is there and
not in the new WinEdt Console)...

Let me know when you perform the above tests and see what is in
the log file.

Best regards,

alex

Le 14/06/2008 17:18, Gyorgy SZEIDL a écrit :
> dear alex,
>
> 2. i have been typesetting a book using the amsbook documentclass.
>    the book consists of 218 pages. when texifying the manuscript
>    (there is a project containing the various chapters in separate
>    files) i am getting funny error messages in the window that opens
>    at the bottom of the winedt screen:
>
> Package hyperref Warning: Token not allowed in a PDF string (Unicode),
> (hyperref)                removing `math shift' on input line 389.
>
> [66] <3-3abra.eps> <3-4abra.eps> <3-5abra.eps> <3-6abra.eps>
> Underfull \hbox (badness 1527) in paragraph at lines 516--518
> [][]| \T1/cmr/m/n/10.95 A [][][][]. áb-rán fel-tün-te-tett
> $\OML/cmm/m/it/10.95
>  O \OMS/cmsy/m/n/10.95
>
> the last five lines is being repeated a number of times (till texify
> runs). this phenomenon has nothing to do with miktex. why? after i had
> reloaded winedt 5.5 i did not got any error message when i was texifying
> the same project.
>
> if the files i am texifying are shorter the phenomenon described above
> does not occur.
>
> otherwise the dvi file resulted seems to be correct.
>
> best regards
> gyorgy
>

Sorry but it is typically hyperref+latex problems

The hyperref warning : you must have some math ($ $) in a \chapter or a
\section or a \subsection...

Underfull \hbox : classical latex warning which occurs when latex can't
cut well a line.


François Pétiard

Hello,
thanks, this works fine
Jose A. Facenda Aguirre


----- Original Message -----
From: "Michail G. Lagoudakis" <lagoudakis@...>
To: <winedt+list@...>
Sent: Thursday, June 12, 2008 11:38 PM
Subject: Re: [WinEdt] pdf in A4 paper


> José A. Facenda Aguirre wrote:
>> By the way latex->dvips-ps2pdf,  (using the command line switches), I get
>> a correct landscape a4.
>> I  wonder if it possible to obtain the a4 pdf file directly by pdfTeXify
>> rute. The default paper size is not set to a4. How can I fix that?
>
> I had the same problem and here is the solution I found:
>
> Option -> Execution Modes
>
> Choose dvi2pdf under Accessories (or whatever else you use)
>
> Choose A4 (instead of default) under Paper Size
>
> Hope that helps!
>
> Michail
>
>
>

> remark 2. if i chose windows console for texify in the
> execution modes window winedt 56 works in the same way as
> winedt 55 (no console, everything is ok and i can see the lines
> of the log file running down in the cmd window.)
>
> this setting is what i am going to prefer for the time being.

I know that texify does not handle Input/ Output Handles
properly because it creates empty console when executed in
detached mode (instead of passing redirected input/ output
handles to precesses it launches during the compilation). They
tested in in Windows Console where the problem may not appear
but when using pipes any such problem can become visible.

It would be best if you can do the following: ZIP your complete
problematic project (eps and bib and sty files) and send it to
me (privately). I will perform more tests (since I could not
detect any such behavior with my samples) and I should be able
to see exactly what is going on, in which pipe is the unwanted
output placed and why it persists there... Then I can do
something about it and in the process make WinEdt console more
robust. I will, of course, delete your files as soon as I am
done with testing. It is essential that I can reproduce the
situation first as it is unlikely that guess-work will provide
a solution... This business with re-directed I/O can be quite
tricky as every console application tends to handle its I/O
uniquely:-) OK?

Best regards,

alex

ps. This has nothing to do with your compiled document. The
issue is only what is displayed in the console. There are no
errors but the warnings are there no matter how you execute
texify. Again, the question is only what you see on the screen
during the compilation and I would like to see it myself and
then I can do something about it...

> I run into a weird problem with a WinEdt macro. When you run the macro
> below, the first prompt shows what I expect but the second prompt
> doesn't. The only difference is the order of the parameters of \#~{}.
> Can anyone explain to me why the difference?
>
> ////////////////////////////////////////////
> // underscore before < but not in between <<,
> // nor if preceded by beginning of line, tab or space
> LetReg( 7, "Line 1<%\<Line 2 (The good one)%\Line 3 <%\Line 4<<" );
> SubstituteInString('%!7', '\#~{<|{[ \&9;]|\<}}\<', '_\<', 1, 8);
> Prompt( "%!8" );
> LetReg( 7, "Line 1<%\<Line 2 (The problem one)%\Line 3 <%\Line 4<<" );
> SubstituteInString('%!7', '\#~{{[ \&9;]|\<}|<}\<', '_\<', 1, 8);
> Prompt( "%!8" );
> Exit;
> ////////////////////////////////////////////

I finally got around to investigate what appears a RegEx
oddity...

However, there is an explanation for this behavior. When BOLN
is a part of a filter like this it should be specified first
because this match has zero length and the actual match string
is also a part of a filter.

You don't need additional grouping but < must be before \< in
or expression or else a strange thing happen when evaluating a
filter expressions: WinEdt matches the very same < character
but since it extends past the beginning of the expression
without a filter it considers it a non-match. Double negation
thus gives you an unwanted match. It is best to leave it like
this as changes to \# filter can introduce incompatibilities.

   \#~{<|[ \&9;]|\<}\<
   \#~{[ \&9;]|<|\<}\<

etc... are OK. But \< before < in this case will cause a
problem because "<" character is also the matching string.

Best regards,

alex

dear alex,

my e-mail address is
    gyorgy.szeidl@...
would you be so kind as to send me
your personal address so that i can
send you my project?

thank you in advance.
best regards
gyorgy
>> remark 2. if i chose windows console for texify in the
>> execution modes window winedt 56 works in the same way as
>> winedt 55 (no console, everything is ok and i can see the lines
>> of the log file running down in the cmd window.)
>>
>> this setting is what i am going to prefer for the time being.
>
> I know that texify does not handle Input/ Output Handles
> properly because it creates empty console when executed in
> detached mode (instead of passing redirected input/ output
> handles to precesses it launches during the compilation). They
> tested in in Windows Console where the problem may not appear
> but when using pipes any such problem can become visible.
>
> It would be best if you can do the following: ZIP your complete
> problematic project (eps and bib and sty files) and send it to
> me (privately). I will perform more tests (since I could not
> detect any such behavior with my samples) and I should be able
> to see exactly what is going on, in which pipe is the unwanted
> output placed and why it persists there... Then I can do
> something about it and in the process make WinEdt console more
> robust. I will, of course, delete your files as soon as I am
> done with testing. It is essential that I can reproduce the
> situation first as it is unlikely that guess-work will provide
> a solution... This business with re-directed I/O can be quite
> tricky as every console application tends to handle its I/O
> uniquely:-) OK?
>
> Best regards,
>
> alex
>
> ps. This has nothing to do with your compiled document. The
> issue is only what is displayed in the console. There are no
> errors but the warnings are there no matter how you execute
> texify. Again, the question is only what you see on the screen
> during the compilation and I would like to see it myself and
> then I can do something about it...
>

dear alex,

i sent my project zipped into a single file
to the address

support@...

best regards
gyorgy

Hello,
I am a long time registered user. May I use my code to install WinEdt on a
second computer in my home network? It is a notebook, as would like to be able
to work on LaTeX documents when traveling.
Thank you,
Paolo Cavallo

Hello,
I am a long time registered user. May I use my code to install WinEdt on a second computer in my home network? It is a notebook, as would like to be able to work on LaTeX documents when traveling.
Thank you,
Paolo Cavallo

Hi Jim,

Sorry for the delay. I've been working around the clock and I
just can't keep up...

> (The following bug can be reproduced using the psnup mui that
> Alex wrote.)
>
> Bug: Value of a TComboBox (style=1, save mode='3') cannot be set
> with MUISet, if the previous action was to select the "blank"
> value of the combo box from the drop down list.
>
> How to reproduce using Accessories|MUI|psnup...:
> 1. If you have never used psnup mui, execute the psnup mui once,
> so that it stores at least one filename (.ps) in the Input File
> dropdown box.
> 2. Once again, open psnup mui.
> 3. Select the Input File dropdown menu, and select the blank
> value at the bottom of the list.
> 4. Select the Browse button, and attempt to select a new .ps
> file.
> 5. The Input File combo box will not get updated.
> 6. (Optional) Click the dropdown arrow once to drop the list
> down, and once again to roll the list back up.  Now, the Browse
> feature _will_ work, oddly.

It turns out that the text in the combo box cannot be reset
under the circumstances unless the selected item index is first
set to -1. It took a while but it is now fixed... Well
spotted:-)

Best regards,

alex

Hi Gyorgy,

Thanks for the zipped project. This saved us a lot of time.

I first tested with my working version of WinEdt only to obtain
exactly the same output in WinEdt's Console as in Windows
Console. I even executed the command from the Windows Command
Prompt (using "...>x.log" to capture the exact console output)
only to conclude after comparing the two files that WinEdt
displays EXACTLY the same text as the console. However, this is
now and then was then. Your version uses RTF control in
WinEdt's Console and this control chokes after it receives a
null character. Thus after line 328 (where this actually
happens) nothing else can be appended to the console text. And,
yes, it flickers quite a bit rewriting the same text over and
over again.

This has already been addressed since WinEdt now uses its own
code to display and interpret console messages (flickering and
non-efficiency of the old control becomes obvious with large
output). As for null characters: Windows Console displays them
as spaces and I will do the same. I don't know why TeX sends
null characters to the console (probably some UNICODE thing
with your Hungarian document and babel and hyperref package).
But this is not a WinEdt-related issue (TeX and its verbose log
files and output is not the most human friendly in warning(s)-
reporting department)...

Anyway the mystery has been solved: RTF kept refreshing the
same text over and over again because the text following the
first null character has been discarded (by RTF control)...

Case closed.

Best regards,

alex

hi alex,

thank you both for your message and for the time you have devoted
to the solution of my problem. i am pleased to learn that everything
is clear and winedt 56 seems to be ok.

i am waiting for the next beta release.

thank you once again
best regards
gyorgy
> Hi Gyorgy,
>
> Thanks for the zipped project. This saved us a lot of time.
>
> I first tested with my working version of WinEdt only to obtain
> exactly the same output in WinEdt's Console as in Windows
> Console. I even executed the command from the Windows Command
> Prompt (using "...>x.log" to capture the exact console output)
> only to conclude after comparing the two files that WinEdt
> displays EXACTLY the same text as the console. However, this is
> now and then was then. Your version uses RTF control in
> WinEdt's Console and this control chokes after it receives a
> null character. Thus after line 328 (where this actually
> happens) nothing else can be appended to the console text. And,
> yes, it flickers quite a bit rewriting the same text over and
> over again.
>
> This has already been addressed since WinEdt now uses its own
> code to display and interpret console messages (flickering and
> non-efficiency of the old control becomes obvious with large
> output). As for null characters: Windows Console displays them
> as spaces and I will do the same. I don't know why TeX sends
> null characters to the console (probably some UNICODE thing
> with your Hungarian document and babel and hyperref package).
> But this is not a WinEdt-related issue (TeX and its verbose log
> files and output is not the most human friendly in warning(s)-
> reporting department)...
>
> Anyway the mystery has been solved: RTF kept refreshing the
> same text over and over again because the text following the
> first null character has been discarded (by RTF control)...
>
> Case closed.
>
> Best regards,
>
> alex
>

Dear WinEdters,

is there a macro similar to latex.edt for launching xelatex (as included in
MiKTeX 2.7) in WinEdt?

Thanks in advance for any advice.

Rudi

Dear WinEdters,

at my office we have recently upgraded to WinEdt 5.5. Since then, if I open a
tex-file from the explorer, another WinEdt window opens even if one instance of
WinEdt is already running. Same happens if I use the Send to... shortcut. I'd
prefer to have the files opended in the same WinEdt window that is already open.
Which settings do I have to adjust?

As always: thaks for any replies.

Rudi

> at my office we have recently upgraded to WinEdt 5.5. Since
> then, if I open a tex-file from the explorer, another WinEdt
> window opens even if one instance of WinEdt is already
> running. Same happens if I use the Send to... shortcut. I'd
> prefer to have the files opended in the same WinEdt window
> that is already open. Which settings do I have to adjust?

| Options | Preferences | Shell | check "Run Once Instance Only"

Cheers,  Phil
  --
  Email.it, the professional e-mail, gratis per te: http://www.email.it/f

  Sponsor:
  Cerchi un hotel per visitare i parchi della Romagna ? Oltremare, Aquafan,
Mirabilandia e Fiabilandia ti aspettano. Scegli un RivieraParkHotels  per la
tua vacanza a Riccione
  Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8012&d=20080618

Am Mittwoch, 18. Juni 2008 schrieb Wapler Rüdiger:

> Dear WinEdters,

> is there a macro similar to latex.edt for launching xelatex (as
> included in MiKTeX 2.7) in WinEdt?

Not in winedt 5.5.

You will have to change a copy of \Exec\MiKTeX\ExecModes.edt (for the
execution mode, put the copy in the Application Data folder) and a
copy of pdflatex.edt and then make a menu entry.




--
Mit freundlichen Grüßen
Ulrike Fischer
mailto:list@...

-------- Original Message  --------
Subject: [WinEdt] RE : [WinEdt] Registration Code
From: Razafy Paul <paulrazafi@...>
To: winedt+list@...
Date: Tue Jun 17 2008 15:04:10 GMT+0200 (ora legale Europa occidentale)

> Hi Paolo,
>
> I think you can! the usual procedure

Thank you,
Paolo

Can winedt provide code collapse like eclipse, visual studio?