> You should follow the last link:
>
> http://cran.r-project.org/contrib/extra/winedt/
>
> There's a ReadMe.txt file with instructions.
>

Yes.
The first item on this page reads:

   R-WinEdt: WinEdt as an editor for R.

   Download, ReadMe, and Screenshots are available from
   CRAN/contrib/extra/winedt/

which links you to:

   http://cran.r-project.org/contrib/extra/winedt/

Here check ReadMe.txt and proceed according to the instructions....

Most of the instructions deal with installing and configuring R.
WinEdt part will be done automatically if you follow the
instructions... This kind of answers your question: you need
properly installed and configured R.

alex

> Could someone please help me with installing foreign language
> dictionaries?  I'm using the dictionary manager.  It correctly
> displays the number of words in my Spanish dictionary, but will not
> allow me to use it for proofreading.

Make sure that the dictionary is enabled and if you are not familiar
with modes and submodes just leave the filter (edit control next to
the Enabled Check Box) empty: this way the dictionary is always
enabled...

The only other reason would be if you are not using a word list
formatted and sorted as WinEdt Dictionary (eg. if you get it from
somewhere else). In Dictionary Manager you can explicitly select
this dictionary and execute the Sort Command but this will not help
if the dictionary uses a different code page or format...

Most WinEdt's word lists are designed for ANSI Western Code page
(unless stated otherwise).

I am not aware of any problems with this functionality (and I don't
think there are any).

Properly formatted dictionaries for WinEdt are available form links
on www.winedt.org

Best regards,

alex

Is there any status you can share about the 5.4
release?

Thanks,
Alan


__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html

If I open LaTeX 2e Help 1.6 from the WinEdt help menu, then minimize the
help window, it is not possible to make changes to documents that are open
in WinEdt.

Is this really the intended windowing behavior?

When I look something up in a help window it would be nice not to have to
close the help window before resuming editing just in case I want to refer
back to the help.

[I'm using WinEdt Build: 20030429  (v. 5.4) on Window XP.]

OK, I see what to do with this: literally assign a SHORTCUT to the macro
by going to the Shortcuts choice on Menu Setup's Main Menu tab.

What confused me was the link "read this first" on the page
http://www.winedt.org/Macros/text/.  The target of that link focuses
upon actual menu items, whether main menu or popup menus.  There is no
explicit mention there of using the Shortcut choice on the Main Menu tab.

Murray Eisenberg wrote:

> I'm trying to get abbrv to install and work correctly.  Here's what I
> did and where I'm confused:
>
> 1. Unzipped downloaded abbrv.zip to %B\Macros\text which actually unzips
> to a subdirectory abbrv of text.
>
> 2. Now here's where things get hazy!  The Installation Instructions at
> http://www.winedt.org/Macros/text/abbrv.php say merely "To use abbrv
> efficiently, you should assign a shortcut to it (I use CTRL - . )."
>
> So the question is what that actually means.
>
> I look at the page http://www.winedt.org/Macros/install.php and see the
> section "Popup Menus".  I try to follow that:
>
> a) I open Options|Menu Setup and go to tab Popup Menus.
>
> Next I'm supposed to "double-click on the menu in which you want to have
> the new menu item for the macro [or]...create a new one, and define a
> shortcut to it."
>
> There seems to be no relevant item, so:
>
> b) I add a new item, Abbreviations, and per the instructions for abbrv,
> assign shortcut key Ctrl+. to it; and of course I check the Enabled
> attribute and (since I'm not sure about this) check the Visible attribute.
>
> c) I double-click that new item to open the dialog to configure
> Abbreviations.
>
> Now do I add, say, an item here, say &Abbrev?
>
> d) I do that.
>
> I know I need to assign the macro, which I do:
>
> e) I enter in the Macro field:
>
>   [Exe("%b\Macros\text\abbrv\abbrv.edt");]
>
> Now I work my way back out with two OK's.
>
> But now what?
>
> If I type the shortcut Ctrl+. I see a dimmed little pop-up saying Abbrev
> with the A underscored.  That's all.
>
> Did I do something wrong in installing?  How do I add abbreviations and
> replacements to the database?  How do I invoke such replacements by
> using the macro (via shortcut key, I presume) now?
>
>

--
Murray Eisenberg                     murray@...
Mathematics & Statistics Dept.
Lederle Graduate Research Tower      phone 413 549-1020 (H)
University of Massachusetts                413 545-2859 (W)
710 North Pleasant Street            fax   413 545-1801
Amherst, MA 01003-9305

> If I open LaTeX 2e Help 1.6 from the WinEdt help menu, then minimize
> the help window, it is not possible to make changes to documents
> that are open in WinEdt.
>
> Is this really the intended windowing behavior?

No and I cannot confirm it on my WinXP or Win2000 with MiKTeX 2.3
(WinEdt 5.4)...

In WinEdt 5.4 the command is defined as:

IfFileExists("%$('TeX-Root');\doc\latex\help\latex2e.chm",
   `HTMLHelp("%$('TeX-Root');\doc\latex\help\latex2e.chm",1,4,"",1);`,
   `HelpKeyword("%$('TeX-Root');\doc\latex\help\latex2e.hlp","",1);`);

and with recent version of MiKTeX or TeX-Live it gives HTMLHelp. I
can see no problem with this (Help Window can be minimized and
WinEdt works normally - it is not like a modal dialog).

> When I look something up in a help window it would be nice not to
> have to close the help window before resuming editing just in case I
> want to refer back to the help.
>
> [I'm using WinEdt Build: 20030429  (v. 5.4) on Window XP.]

You probably inherited some older WinEdt settings that do not call
HTMLHelp as described above. In particular the second parameter
should be set to 1 to make HTMLHelp run as an independent
application.

OK:

   HTMLHelp("%$('TeX-Root');\doc\latex\help\latex2e.chm",1,1);

not OK:

   HTMLHelp("%$('TeX-Root');\doc\latex\help\latex2e.chm",0,1);

You can change this in Menu Setup if required for your
configuration. This is from Macros Manual (it appears that the
second parameter used to be set to 0 in the default settings of
older versions - there might have been good reasons for this on
Win9x):

HTML and Windows Help Macros
============================

  HTMLHelp("Help File.chm", No_Owner: 0..1,
            Mode: 0..5, "Keyword or Link", Get_Keyword: 0..1);

     If Main Window is the Owner WinEdt cannot be used until the
     Help Window is closed. Otherwise you can minimize the Help
     Window and continue to use WinEdt (the HTML Help Window is in
     Windows Task bar).

     Mode determines how is the HTML Help called:

       0: HH_DISPLAY_TOPIC
       1: HH_DISPLAY_TOC
       2: HH_DISPLAY_INDEX
       3: HH_DISPLAY_SEARCH
       4: HH_KEYWORD_LOOKUP
       5: HH_ALINK_LOOKUP

     Keyword or Link can be passed in Modes 4 and 5, respectively.

     Get_Keyword parameter instructs WinEdt to pass the currently
     selected string as a keyword. It can come handy if you are
     using MiKTeX's Help for LaTeX which is defined in WinEdt's
     Menu as the following macro:

       HTMLHelp("%$('TeX-Root');\doc\latex\help\latex2e.chm",0,4,"",1);

     It is enabled only if the .chm file exists (should be the case
     in MiKTeX 2.1). If no word is selected WinEdt passes the
     current word or TeX command...

   If you need more information read MS documentation for HTML Help
   systems (the above macro is an interface to Windows API)...

etc...

Best regards,

alex

> since Alex has a very good reason for everything he programs, I am
> wondering why the Insert/Date command does not delete the text if it
> is selected (WE 5.4). Quite often I am inserting a date stamp in the
> file. When updating the stamp, I select the old one and use the
> Insert/Date. This simply adds a new date, what would be more
> logically in my case is replace the selected text with the new date.
> The command is defined as:
> [SetSel(0);GetDate(7, 'yyyy-mm-dd');InsText("%!7");LetReg(7,"")]
> Has SetSel something to do with this?

I cannot recall why SetSel(0); has been put there. I have now
changed the default settings (by deleting this call) and the new
text will by default replace any selection as one might expect.

This was probably copied from some other macro (that's why %!7 is used -
I could not possibly have a good reason for this one unless the
macro was copied from some other context and the rule "if it ain't
broke don't fix it" was applied)....

I don't think the above date format is quite a default so you must
have changed it at some point. Similarly, you can also remove
SetSel(0); from your version (at it has been removed from the future
default settings)...

> The other unwanted feature is related to the taskbar (XP Pro). When
> a document is opened in WE, the taskbar displays WinEdt -
> [filename]. After the document is closed, the filename stays
> displayed in the taskbar (but not in the title bar). A fresh
> instance of WE lists only WinEdt. Is this a XP or WE "feature"?

This, too, has now been fixed. It has to do with Delphi creating a
different Windows for Application and Main MDI Form. Application's
Title has to be maintained manually with custom event handlers and I
did not take a possibility of NO MDI Child (Document) Window being
active to reset the title (it was a minor bug and it is now
fixed)...

Best regards,

alex

> Is there any status you can share about the 5.4 release?

I am doing the last testing on a stable beta version that will be
uploaded within a week. The reason for quite a delay is that in the
meantime I decided to compile this version with Delhi 7 (rather than
older Delphi 5 which does not support XP themes). While this
eliminates some known problems with the old compiler it also
introduces a slew of new oddities that have to be detected and
fixed...

I am also preparing a new build with new freeware installer (INNO)
which seems to provide more flexibility than the current Web
Packager from InstallShiled. But this, too, has to be carefully
tested under different circumstances...

Best regards,

alex

I'm impressed. Good luck with the project.

You do a great and meticulous job!

Regards,

Frans

----- Original Message -----
From: "WinEdt Team" <support@...>
To: <winedt+list@...>
Sent: Monday, April 12, 2004 11:40 PM
Subject: Re: [WinEdt] 5.4 status


> > Is there any status you can share about the 5.4 release?
>
> I am doing the last testing on a stable beta version that will be
> uploaded within a week. The reason for quite a delay is that in the
> meantime I decided to compile this version with Delhi 7 (rather than
> older Delphi 5 which does not support XP themes). While this
> eliminates some known problems with the old compiler it also
> introduces a slew of new oddities that have to be detected and
> fixed...
>
> I am also preparing a new build with new freeware installer (INNO)
> which seems to provide more flexibility than the current Web
> Packager from InstallShiled. But this, too, has to be carefully
> tested under different circumstances...
>
> Best regards,
>
> alex

unsubscribe



______________________________________________________________________
Correo Yahoo! - 6MB, más protección contra el spam ¡Gratis!
http://correo.yahoo.es

Saludos
DPP

-----Mensaje original-----
De: Abel Posso [mailto:abelgato@...]
Enviado el: Martes, 13 de Abril de 2004 06:02 PM
Para: winedt+list@...
Asunto: Re: [WinEdt] 5.4 status

unsubscribe



______________________________________________________________________
Correo Yahoo! - 6MB, más protección contra el spam ¡Gratis!
http://correo.yahoo.es

how-to-unsubscribe...
is explained e.g. in the monthly mailing list guidelines (see
excerpt below) and also in the FAQ (which should be first
place to go to anyhow, e.g. when wondering on how to
include a figure "in Winedt"...)
Cheers, Thomas

>   A lot of questions are being asked over and over  again.  Check
>   that your question isn't already answered in the WinEdt FAQ at
>      <http://www.winedt.org/Doc/FAQ>
>   or in the mailing list archives at
>      <http://groups.yahoo.com/group/WinEdt>.
>

> * Unsubscribing + More
>
>   To unsubscribe from the WinEdt Mailing List, send an empty  mail
>   to: <winedt+list-unsubscribe@...>  from  the  account  that
>   you  are subscribed with.
>
>   DO NOT send a mail to the list! This will have no effect  apart
>   from annoying the subscribers.
>
>   The complete list of administrative commands for the  WinEdt
>   Mailing List can be found here:
>   <http://www.winedt.org/Doc/listinstr.php>


Plascencia Perdomo David schrieb am 13 Apr 2004 um 18:40:

>
>
> Saludos
> DPP
>
> -----Mensaje original-----
> De: Abel Posso [mailto:abelgato@...]
> Enviado el: Martes, 13 de Abril de 2004 06:02 PM
> Para: winedt+list@...
> Asunto: Re: [WinEdt] 5.4 status
>
> unsubscribe
>
>
>
> ________________________________________________________________
> ______ Correo Yahoo! - 6MB, más protección contra el spam
> ¡Gratis! http://correo.yahoo.es
>
>

Hi,
I was wondering about a couple of things concerning the tree-
window (using WinEdt 5.4 20031209 with a clean installation
on a new Windows XP Pro).
Most of the following ideas are either suggestions for
changing the default setup of Winedt or feature requests.
Some of the latter would probably take some time to be
implemented, but maybe some or all of the setup-suggestions
could be included in the next build of Winedt?

1) The "options"-button in the tree-window does not do
anything, only the little black triangle to the right of it opens
the options.

2) The WinEdt Help file states: "The Tree control works pretty
much in the same manner as Windows Explorer: you can
double-click on any project file in order to open it." This is not
true for the default setup, so please change the default out-
of-the-box setup such that double-clicking in the tree will
open a file.

2a) The current behavior for (Double-)clicking on an entry in
the TOC of the tree is the following:
Clicking on a graphics-file will move the cursor to the place
where the graphic-file is called. Double-clicking on an entry
with subentries will expand the branch. Right-clicking on an
entry gives a "find"-command to move the cursor.
This complete (default) behavior is not very consistent (also
compared the behavior in the files-section of the tree, see my
point 2) above).
I propose the following behavior, which seems to be natural
(to me at least...) (to be set up as default settings, for some of
these there is probably a need for some configuration options
so that other users can set it up the way they prefer):
- clicking on the "plus" or "minus"-sign in front of the branch
will expand / collapse the branch (as it does right now)
- clicking on the text of a branch will expand / collapse the
branch
- double-clicking on the text of a branch will jump the cursor
to that (sub-)section / graphics-inclusion / etc...
- right-clicking will give all appropriate options always
(Comments welcome for changes to this default-setup-idea!)

2b) The help file on "tree" is quite incomplete. Also "Tree" is
not listed on the starting page of the help file. On the "tree"-
page (as found via the index) the options are not explained at
all (and I could not find explanations for them anywhere else
in the text-files. At this point I can repeat my usual call for a
**unified** and somewhat complete help ressource...)
Most options I could somehow figure out, but:
  - what does "expand tree" do?
  - most options seem to influence the "file"-part of the tree
only, not the TOC-part (see also previous points)
(- why can I select "open on click" and "open on double-click"
at the same time?)

3) The tree-window does not remember its appearance (after
restarting WinEdt). It would be nice if it would remember it.
Or, alternatively / additionally: Is it possible to configure
WinEdt such that the tree-branches (e.g. within the TOC) are
automatically expanded (ideally only the top "n" levels are
expanded...)?

4) Feature request: Is it possible that in the TOC the section
the cursor is currently in is highlighted in the tree-window? (or
its superior level, if the (sub)section is not currently expanded
/ displayed) I took the idea from the blueish icon-highlighting
in the bookmark-window in Adobe / Acrobat Reader. It would
be similar to the "track files"-options.
(BTW: I do not quite understand why "track-files" is very
useful, as I can see the file name in the tabs anyhow?)

5) In general: tree / gather relationship? E.g. "toc"-window in
gather compared to tree? Same thing? What about including
e.g. tables in the tree? Graphics are already in there.
Or the other way round: Do we need a "TOC" in the tree (and
all the stuff suggested above) as everything (?) is already in
the "Gather"-window???
I personally prefer to work with the tree-window. One reason
for this is that the tree-window uses useful icons in the TOC,
whereas the gather-TOC-window is way too big to be used as
"right" or "left"-docked window. Another reason is that images
are already included in the TOC (but not tables :-(
Maybe many of my comments in this email also apply to the
gather-window?
While I am at it: Another suggestions for changing the default
setup-up of Winedt: In the Gather-window "Ref" the collection
of "refs" should also collect "\autoref"-commands (from
hyperref-package).

Thanks for listening,
Thomas

Hi, Alex,
  While working with Popup Menus, I have discovered some
  inconveniences.
  (1) If Acute popup menu page is evoked with the macro function
  Popup("Acute"); (so not by its shortcut), it works, but its
  title does not appear on the status line. If it is set visible,
  its dialog is visible but the title is not.
  (2) I have created an additional macro in Acute page
  Popup("Umlaut");Prompt("Umlaut"); named &' with shortcut '.
  After evoking Acute (even by its shortcut) and pressing ' , the
  macro function Popup("Umlaut") does not work although the
  Umlaut information appears.
  (3) If the macro is changed to be Prompt("Umlaut");Popup("Umlaut");
  it works after the same manipulation (without Umlaut title) only if
  Acute is invisible.
      I need a similar functionality for my national keyboard, so
  I would appreciate if it worked.
      Thank you very much.           Jiri

-------- Original Message --------
Subject: [WinEdt] Problemes with Popup
Date: Thu, 15 Apr 2004 15:57:39 +0200
From: Jiri Jelinek <jelinek@...>
Reply-To: <winedt+list@...>
Organization: Dept Math Analysis, Fac Math&Physics, Charles Uni Prague
To: winedt+list@...

  Sorry, Alex, I have forgotten to say that I use the last
  version 20031209

  Hi, Alex,
  While working with Popup Menus, I have discovered some
  inconveniences.
  (1) If Acute popup menu page is evoked with the macro function
  Popup("Acute"); (so not by its shortcut), it works, but its
  title does not appear on the status line. If it is set visible,
  its dialog is visible but the title is not.
  (2) I have created an additional macro in Acute page
  Popup("Umlaut");Prompt("Umlaut"); named &' with shortcut '.
  After evoking Acute (even by its shortcut) and pressing ' , the
  macro function Popup("Umlaut") does not work although the
  Umlaut information appears.
  (3) If the macro is changed to be Prompt("Umlaut");Popup("Umlaut");
  it works after the same manipulation (without Umlaut title) only if
  Acute is invisible.
      I need a similar functionality for my national keyboard, so
  I would appreciate if it worked.
      Thank you very much.           Jiri

On 14.04.2004 16:47, Thomas Dudey wrote:
> I propose the following behavior, which seems to be natural
> (to me at least...) (to be set up as default settings, for some of
> these there is probably a need for some configuration options
> so that other users can set it up the way they prefer):

Some of it can be configured in %b\Local\WinEdtEx.ini: You can set
ON_CLICK, ON_DOUBLE_CLICK, ON_CTRL_CLICK, etc. The response to clicking
on a branch head is not configurable, though.

> - clicking on the "plus" or "minus"-sign in front of the branch
> will expand / collapse the branch (as it does right now)

Sure. Like in Explorer.

> - clicking on the text of a branch will expand / collapse the
> branch

But this would not conform to your quote from (2): In Windows Explorer,
you have to double-click on a folder to expand it.

> - double-clicking on the text of a branch will jump the cursor
> to that (sub-)section / graphics-inclusion / etc...

Here, I would say it should be a single click. Again, one could take the
Explorer as the UI model: There, if you click on a directory *once* in
the tree panel, this will show the folder. You don't click have to click
twice.

> - right-clicking will give all appropriate options always
> (Comments welcome for changes to this default-setup-idea!)

I would suggest to have it the other way round.

One problem is that double-clicking implies clicking. That means that if
you double-click on a section with subentries in order to expand it,
you'ld also move the caret to the corresponding point in the file -- or,
if things were the other way round, if you double-click on an entry in
order to get there, you'ld also expand it.

> 2b) The help file on "tree" is quite incomplete. Also "Tree" is
> not listed on the starting page of the help file. On the "tree"-
> page (as found via the index) the options are not explained at
> all (and I could not find explanations for them anywhere else
> in the text-files.

I think the help still entirely refers to the old (5.3) tree. The new
tree is only documented in News.txt. WinEdt's online help doesn't catch
up with its development...

> At this point I can repeat my usual call for a **unified** and
> somewhat complete help ressource...)

Wasn't that a FAQ ;-)

> Most options I could somehow figure out, but:
>  - what does "expand tree" do?

It determines whether the file tree should be expanded.

>  - most options seem to influence the "file"-part of the tree
> only, not the TOC-part (see also previous points)

That is correct. The TOC-(and whatever-)part can be configured in
WinEdtEx.ini.

> (- why can I select "open on click" and "open on double-click"
> at the same time?)

Why not? ;-)

> 3) The tree-window does not remember its appearance (after
> restarting WinEdt). It would be nice if it would remember it.
> Or, alternatively / additionally: Is it possible to configure
> WinEdt such that the tree-branches (e.g. within the TOC) are
> automatically expanded (ideally only the top "n" levels are
> expanded...)?

You can set this in WinEdtEx.ini, too:

    BRANCH_EXPANDED=1

with values between 0 and 2 (2 means fully expanded).

> 4) Feature request: Is it possible that in the TOC the section
> the cursor is currently in is highlighted in the tree-window? (or
> its superior level, if the (sub)section is not currently expanded
> / displayed) I took the idea from the blueish icon-highlighting
> in the bookmark-window in Adobe / Acrobat Reader. It would
> be similar to the "track files"-options.

That would be nice, indeed.

> (BTW: I do not quite understand why "track-files" is very
> useful, as I can see the file name in the tabs anyhow?)

Why not? Saves you from shifting your focus.

> 5) In general: tree / gather relationship? E.g. "toc"-window in
> gather compared to tree? Same thing? What about including
> e.g. tables in the tree? Graphics are already in there.
> Or the other way round: Do we need a "TOC" in the tree (and
> all the stuff suggested above) as everything (?) is already in
> the "Gather"-window???
> I personally prefer to work with the tree-window. One reason
> for this is that the tree-window uses useful icons in the TOC,
> whereas the gather-TOC-window is way too big to be used as
> "right" or "left"-docked window. Another reason is that images
> are already included in the TOC (but not tables :-(

Here's what I have in my WinEdtEx.ini (beware, the CAPTION lines
are terribly long, the mailer probably breaks them):

//--------------------------------------------------------------------------
// gather captions of figure and table environments

BRANCH="Figures"
    BRANCH_MODE="TeX"
    BRANCH_ICON="Image"
    BRANCH_SORTED=0
    BRANCH_CASE_SENSITIVE=1
    BRANCH_IGNORE_COMMENTS=1
    BRANCH_EXPANDED=1

// this is supposed to find {figure} and {figure*} environments
// I hope it doesn't find too much
    ITEM="\begin{figure?}"
      MODE="TeX"
      CASE_SENSITIVE=1
      BEGINNING_OF_LINE_ONLY=0
      CURRENT_DOCUMENT_ONLY=0
      ALL_OPENED_DOCUMENTS=0
      COMPLETE_PROJECT_TREE=1
      MAX_LINE_SPAN=1
      ICON="Image"
      LEVEL=0
      CAPTION="%[!`TreeGetFileName(1); GetDocAsASCII(1,'%!1',0,0);
TreeGetLineNumber(0); CLToIndex(1,%!0,2,'%!1');
FindInString('%!1','<@^{%%|\\end\{figure}\\end\{figure@\*\}',0,3,1001,%!2);
ExtractByIndex(0,'%!1',%!2,%!0);
FindInString('%!0','\\caption{\[\(+{>|@{\[*\]}^{\]}}\)\]}|{\{\(+{>|@{\{*\}}^{\}}\
}\)\}}',0,1,1);
IfOK('GetTag(0,0);','LetReg(0,''???'');');LetReg(0,'Figure: %!0');`];%!0"
      ON_CTRL_CLICK="TreeTrack(2);"
      ON_CLICK="TreeTrack(2);"
      ACTION="Find"
        MENU_ICON="Find"
        MACRO="TreeTrack(2);"

    ITEM="\begin{table?}"
      MODE="TeX"
      CASE_SENSITIVE=1
      BEGINNING_OF_LINE_ONLY=0
      CURRENT_DOCUMENT_ONLY=0
      ALL_OPENED_DOCUMENTS=0
      COMPLETE_PROJECT_TREE=1
      MAX_LINE_SPAN=1
      ICON="Image"
      LEVEL=0
      CAPTION="%[!`TreeGetFileName(1); GetDocAsASCII(1,'%!1',0,0);
TreeGetLineNumber(0); CLToIndex(1,%!0,2,'%!1');
FindInString('%!1','<@^{%%|\\end\{table}\\end\{table@\*\}',0,3,1001,%!2);
ExtractByIndex(0,'%!1',%!2,%!0);
FindInString('%!0','\\caption{\[\(+{>|@{\[*\]}^{\]}}\)\]}|{\{\(+{>|@{\{*\}}^{\}}\
}\)\}}',0,1,1);
IfOK('GetTag(0,0);','LetReg(0,''???'');'); LetReg(0,'Table: %!0');`];%!0"
      ON_CTRL_CLICK="TreeTrack(2);"
      ON_CLICK="TreeTrack(2);"
      ACTION="Find"
        MENU_ICON="Find"
        MACRO="TreeTrack(2);"

    ITEM="\begin{SCfigure}"
      MODE="TeX"
      CASE_SENSITIVE=1
      BEGINNING_OF_LINE_ONLY=0
      CURRENT_DOCUMENT_ONLY=0
      ALL_OPENED_DOCUMENTS=0
      COMPLETE_PROJECT_TREE=1
      MAX_LINE_SPAN=1
      ICON="Image"
      LEVEL=0
      CAPTION="%[!`TreeGetFileName(1); GetDocAsASCII(1,'%!1',0,0);
TreeGetLineNumber(0); CLToIndex(1,%!0,2,'%!1');
FindInString('%!1','<@^{%%|\\end\{SCfigure}\\end\{SCfigure\}',0,3,1001,%!2);
ExtractByIndex(0,'%!1',%!2,%!0);
FindInString('%!0','\\caption{\[\(+{>|@{\[*\]}^{\]}}\)\]}|{\{\(+{>|@{\{*\}}^{\}}\
}\)\}}',0,1,1);
IfOK('GetTag(0,0);','LetReg(0,''???'');'); LetReg(0,'Figure: %!0');`];%!0"
      ON_CTRL_CLICK="TreeTrack(2);"
      ON_CLICK="TreeTrack(2);"
      ACTION="Find"
        MENU_ICON="Find"
        MACRO="TreeTrack(2);"

//--------------------------------------------------------------------------

If you don't want the figures to be gathered in a separate branch but
rather within the TOC branch (like the images), leave the first lines
starting with "BRANCH" away, and append the rest to the TOC branch.



One thing I dread is how to add configurations to WinEdtEx.ini in a
stable way. E.g., I'm currently updating my RCS configuration. It should
also come with the possibility to tag the tabs of opened files with
respect to their RCS status. That means the installation macro should
add stuff to the DOCUMENT_TABS section in WinEdtEx.ini. As order
matters, my additions must come at a certain place in the file, not too
late and not too early. But this depends on the user's configuration. I
have no idea what to do here except for explaning what the user should do.


Regards,
Robert.

>  While working with Popup Menus, I have discovered some
>  inconveniences.
>  (1) If Acute popup menu page is evoked with the macro function
>  Popup("Acute"); (so not by its shortcut), it works, but its
>  title does not appear on the status line. If it is set visible,
>  its dialog is visible but the title is not.
>  (2) I have created an additional macro in Acute page
>  Popup("Umlaut");Prompt("Umlaut"); named &' with shortcut '.
>  After evoking Acute (even by its shortcut) and pressing ' , the
>  macro function Popup("Umlaut") does not work although the
>  Umlaut information appears.
>  (3) If the macro is changed to be Prompt("Umlaut");Popup("Umlaut");
>  it works after the same manipulation (without Umlaut title) only if
>  Acute is invisible.
>      I need a similar functionality for my national keyboard, so
>  I would appreciate if it worked.

A while ago I noticed and fixed problems with popup menus in WinEdt
5.4.

I quickly tested your problem and it is not present in the latest
(upcoming) build. Of course, Popup("Umlaut");Prompt("Umlaut"); only
makes sense if Popup Menu Umlaut is visible. Otherwise, Prompt will
be executed immediately (before you have a chance to type
anything)...

Best regards,

alex

> I use WinEdt 5.3 (Build 22020323) under Windows 98.
> After an error of manipulation (I do not know which one) the MSDos
> window, when I call it,  fills the screen and I can go out of it
> only by typing Ctrl+Alt+Suppr.
>
> How (and where) can I fix the size of this window  ?

Really a Windogs question, don't you think?

Anyway, type Alt+Esc (that works for me on W2K anyway) so as not to kill the
window entirely.  Then right click on the corresponding button on the task
bar and select properties - change Full Screen to Window.  In W98 this might
be different, but something like right clicking on the button should give
access to a properties page.

Cheers,  Phil

Doesn't Alt-Enter toggle between the two ?
Philip Taylor.
--------
Philip G. Ratcliffe wrote:

>>I use WinEdt 5.3 (Build 22020323) under Windows 98.
>>After an error of manipulation (I do not know which one) the MSDos
>>window, when I call it,  fills the screen and I can go out of it
>>only by typing Ctrl+Alt+Suppr.
>>
>>How (and where) can I fix the size of this window  ?
>
>
> Really a Windogs question, don't you think?
>
> Anyway, type Alt+Esc (that works for me on W2K anyway) so as not to kill the
> window entirely.  Then right click on the corresponding button on the task
> bar and select properties - change Full Screen to Window.  In W98 this might
> be different, but something like right clicking on the button should give
> access to a properties page.
>
> Cheers,  Phil

> Doesn't Alt-Enter toggle between the two ?
> Philip Taylor.

Right you are!  Didn't know that one.

Cordialmente,  Philip G. Ratcliffe

Hi,

Is there any way to add to the list of working files to erase
some particular extension of my interest?

I tried the settings and preferences but I couldn't find any option there
I also tried to check macros, but couldn't find it either.

The standard extensions include .toc, .glo, .tmp, etc...
I would like to include something like ".thm" for the
auxiliary files generated by "ntheorem.sty".

Regards
Leo
=====================================
Leonardo Freitas
PhD Research Student - Circus Project
Formal Methods - Model Checking
Computing Laboratory
University of Kent
Canterbury
CT2 7NF, UK
=====================================

> Is there any way to add to the list of working files to erase
> some particular extension of my interest?
>
> I tried the settings and preferences but I couldn't find any option there
> I also tried to check macros, but couldn't find it either.

Because it's in Exec ... one of Alex's little quirks ...

> The standard extensions include .toc, .glo, .tmp, etc...
> I would like to include something like ".thm" for the
> auxiliary files generated by "ntheorem.sty".

Look at ...\WinEdt\Exec\Erase Working Files.edt

Cut, paste and modify to your heart's content.

Cordialmente,  Philip G. Ratcliffe

Rock On, Alex!

WinEdt Team wrote:

> > Is there any status you can share about the 5.4 release?
>
> I am doing the last testing on a stable beta version that will be
> uploaded within a week.
>

> I have found a small problem in the spell checking procedure (5.4
> build 20031209): I have the option to confirm the addition of
> capitalized words to the dictionary checked, so the corresponding
> window pops up when I elect to add a capitalized word. This happens
> quite often when I am writing German, because in that language all
> nouns are capitalized. Now the strange thing. If the word contains
> the special German letter ß (a special form of double ss), the
> window does not appear. I note that this is  also the case for words
> (like acronyms or abbrviations) with capitals within the word, so
> perhaps ß is treated like a capital? Actually ß never starts a word
> and has no capital form.

This has now been fixed. Indeed ß was treated as neither lower or
upper case and this caused WinEdt to think that the word is
irregularly capitalized anyway (like WinEdt or MiKTeX) and the
confirmation was cancelled as a result...

Best regards,

alex

> I was wondering about a couple of things concerning the tree- window
> (using WinEdt 5.4 20031209 with a clean installation on a new
> Windows XP Pro). Most of the following ideas are either suggestions
> for changing the default setup of Winedt or feature requests. Some
> of the latter would probably take some time to be implemented, but
> maybe some or all of the setup-suggestions could be included in the
> next build of Winedt?

Quite a few have already been implemented or changed in the default
settings...

Robert commented on most issues; here is more...

> 1) The "options"-button in the tree-window does not do anything,
> only the little black triangle to the right of it opens the options.

It does in the new build...

> 2) The WinEdt Help file states: "The Tree control works pretty much
> in the same manner as Windows Explorer: you can double-click on any
> project file in order to open it." This is not true for the default
> setup, so please change the default out- of-the-box setup such that
> double-clicking in the tree will open a file.

The defaults have been changed in this respect: clicking now
highlights the section (that is, on_click response is defined as
TreeTrack). Double-clicking is reserved for expanding or shrinking a
branch (this is a built-in tree control response and it is not easy to
suppress it). Double-clicking on special items (which are always
end-branches) defines extra actions such as previewing a graphics
file. Right-clicking brings a context sensitive popup with all
available actions defined for the item in question...

Any further changes would require suppressing the default
double-click response and this is anything but straightforward...

> 2a) The current behavior for (Double-)clicking on an entry in the
> TOC of the tree is the following: Clicking on a graphics-file will
> move the cursor to the place where the graphic-file is called.
> Double-clicking on an entry with subentries will expand the branch.
> Right-clicking on an entry gives a "find"-command to move the
> cursor. This complete (default) behavior is not very consistent
> (also compared the behavior in the files-section of the tree, see my
> point 2) above). I propose the following behavior, which seems to be
> natural (to me at least...) (to be set up as default settings, for
> some of these there is probably a need for some configuration
> options so that other users can set it up the way they prefer): -
> clicking on the "plus" or "minus"-sign in front of the branch will
> expand / collapse the branch (as it does right now) - clicking on
> the text of a branch will expand / collapse the branch -
> double-clicking on the text of a branch will jump the cursor to that
> (sub-)section / graphics-inclusion / etc... - right-clicking will
> give all appropriate options always (Comments welcome for changes to
> this default-setup-idea!)

I had to manually filter a few click events which could result from
shrinking a branch. This has been done for the next build and this
was the main reason why I avoided using simple click responses in
the defaults for the previous build. However, double-clicking is
reserved for expanding/ collapsing and I did not find any way to
suppress it. One can define an extra double-click handler but
unfortunately shrinking or expanding occurs regardless of custom
responses and that's why double-click is only defined for graphics
preview where one is guaranteed not to have any sub-branches...

As for options: this aspect has to customized by editing
WinExdEx.ini (there is a menu item to do this in the default Options
Menu). It is not that complicated (eg. comparable with editing Bib
item) and copy and paste can be used to define new items:

   ITEM="\includegraphics?{?}"
     MODE="TeX"
     CASE_SENSITIVE=1
     BEGINNING_OF_LINE_ONLY=0
     CURRENT_DOCUMENT_ONLY=0
     ALL_OPENED_DOCUMENTS=0
     COMPLETE_PROJECT_TREE=1
     ICON="Image"
     LEVEL=0
     CAPTION="%?"
     BALANCED="{}\"
     ON_CTRL_CLICK="GlobalMark;TreeTrack(2);"
     ON_CTRL_DBL_CLICK="Exe('%b\Macros\GraphicsPreview.edt');"
     ON_CLICK="TreeTrack(2,1);"
     ON_DBL_CLICK="Exe('%b\Macros\GraphicsPreview.edt');"
     // %? is filename possibly without extension
     ACTION="Find"
       MENU_ICON="Find"
       MACRO="TreeTrack(2);"
     ACTION="Preview"
       MENU_ICON="View"
       MACRO="Exe('%b\Macros\GraphicsPreview.edt');"

etc...

An interface like this is required to provide enough flexibility
(custom responses for different items and possibly different
behavior of branches depending on the nature of data they are
representing). A GUI to make definitions would result in a cluttered
dialog not necessarily easier to configure than editing the .ini
file (and making future additions harder)...

> 2b) The help file on "tree" is quite incomplete. Also "Tree" is not
> listed on the starting page of the help file. On the "tree"- page
> (as found via the index) the options are not explained at all (and I
> could not find explanations for them anywhere else in the
> text-files. At this point I can repeat my usual call for a
> **unified** and somewhat complete help ressource...) Most options I
> could somehow figure out, but:
>  - what does "expand tree" do?
>  - most options seem to influence the "file"-part of the tree
> only, not the TOC-part (see also previous points) (- why can I
> select "open on click" and "open on double-click" at the same time?)

Help is obsolete and it only describes the functionality that was in
5.3. Extra branches have been introduced in 5.4 and the help does
not describe how to control them. They are defined in WinEdtEx.ini
and that's where they have to be customized.

Expand tree shows the first branch (the file structure) expanded
when the tree is rebuilt. It has no effect on the new branches.

I am setting up an HTML Help project in an attempt to update and
improve the documentation. It will take some time before it is
finished through. Adriana promised to do the indexing so it should
be easier to find things.

FAQs (wiki) project on winedt.org did not get any responses and now
it is up to me to update/ rewrite the documentation for the official
release of 5.4...

> 3) The tree-window does not remember its appearance (after
> restarting WinEdt). It would be nice if it would remember it. Or,
> alternatively / additionally: Is it possible to configure WinEdt
> such that the tree-branches (e.g. within the TOC) are automatically
> expanded (ideally only the top "n" levels are expanded...)?

BRANCH="TOC"
   BRANCH_MODE="TeX"
   BRANCH_ICON="TOC"
   BRANCH_SORTED=0
   BRANCH_CASE_SENSITIVE=1
   BRANCH_IGNORE_COMMENTS=1
   BRANCH_EXPANDED=0

You can set

   BRANCH_EXPANDED=1
or
   BRANCH_EXPANDED=2

to have level 1 or full expansion of the branch.

The rest is a feature request and won't be there in this release
(either remembering a tree status or controlling the number of
expanded levels).

> 4) Feature request: Is it possible that in the TOC the section the
> cursor is currently in is highlighted in the tree-window? (or its
> superior level, if the (sub)section is not currently expanded /
> displayed) I took the idea from the blueish icon-highlighting in the
> bookmark-window in Adobe / Acrobat Reader. It would be similar to
> the "track files"-options. (BTW: I do not quite understand why
> "track-files" is very useful, as I can see the file name in the tabs
> anyhow?)

This will have to wait. Tracking files was implemented at the time
when a tree only consisted of one branch describing the file
structure. Now that TOC (and possibly more branches) are there it
would make sense to implement tracking in TOC but an efficient
implementation is tricky and may require some work and extensive
testing. Acrobat Reader has an advantage: the structure is static
while in WinEdt your can delete, move or insert blocks (whole
sections) and tracking becomes much more demanding and in the ideal
world the tree would get automatically updated to reflect changes
while you are editing.

Also (more on previewer comparison) information in a compiled pdf file
is linear while a TeX source can consist of (sub)subdocuments and
this makes tracking in TOC trickier (eg. moving over an include
directive may position you much further in the TOC)... One can also
switch to a file that is not in the project (another complication
which Reader does not have to worry about)...

Another feature: it would make sense to allow rearranging a document
by dragging TOC items around (it will eventually be there but not
just yet). This, too, can become complicated when input directives
are extensively used (especially if sections are not strictly
contained in included files)...

It can be done (and it has been considered) but it will have to wait
and the implementation should not affect the performance of editing
functions...

> 5) In general: tree / gather relationship? E.g. "toc"-window in
> gather compared to tree? Same thing? What about including e.g.
> tables in the tree? Graphics are already in there. Or the other way
> round: Do we need a "TOC" in the tree (and all the stuff suggested
> above) as everything (?) is already in the "Gather"-window??? I
> personally prefer to work with the tree-window. One reason for this
> is that the tree-window uses useful icons in the TOC, whereas the
> gather-TOC-window is way too big to be used as "right" or
> "left"-docked window. Another reason is that images are already
> included in the TOC (but not tables :-( Maybe many of my comments in
> this email also apply to the gather-window? While I am at it:
> Another suggestions for changing the default setup-up of Winedt: In
> the Gather-window "Ref" the collection of "refs" should also collect
> "\autoref"-commands (from hyperref-package).

Tree and Gather control are two different interfaces to essentially
the same functionality.

Tree is an interface to display items collected in markup language
inside the branches. Gather control is a different interface with
similar function except that collected items are presented in a
linear list and "main" branches are defined as Tabs. Tree has been
introduced later and I decided to define it in WinEdEx.ini (in a
standard editable .ini format) while Gather interface is defined in
WinEdt.gdi with a slightly more complicated syntax based on WinEdt's
Macro Language Parser... Tree is more suitable for data that is
naturally nested (such as TOC) but there is no reason for not
defining branches that correspond to Tab Pages in gather control (in
fact I am considering adding Labels and Bibliography Branch in the
defaults).

Other users will eventually contribute Extensions.ini files for
a particular purpose (Robert already has a few extensions). The new
build allows you to install such extensions (eg. extra branches)
without modifying the default WinEdtEx.ini file; that's why it makes
sense to keep defaults reasonably simple and offer extras on
WinEdt.org...

As for Gather: since it was there before Tree, changing any click or
double-click responses in the defaults is likely to provoke many
complaints from users that are upgrading. After this is officially
documented some users may just have to customize their instance
since the defaults cannot please everyone and are done with an
average user in mind.

Let me know exactly what you want added in default WinEdt.gdi to
cover \autoref(s). You can do a better job since I am not
using or familiar with the package...

Best regards,

alex

> One thing I dread is how to add configurations to WinEdtEx.ini in a
> stable way. E.g., I'm currently updating my RCS configuration. It
> should also come with the possibility to tag the tabs of opened
> files with respect to their RCS status. That means the installation
> macro should add stuff to the DOCUMENT_TABS section in WinEdtEx.ini.
> As order matters, my additions must come at a certain place in the
> file, not too late and not too early. But this depends on the user's
> configuration. I have no idea what to do here except for explaning
> what the user should do.

In the new build you can Load Extra configurations by appending them to
the default ones. In fact I have changed the default settings so
that such extras should go in %b\Local folder while the default
WinEdtEx.ini is now in %b. Also %b\Local now contains local Startup.edt
and users are no longer advised to modify the global one. Stuff in
Local folder will be preserved during upgrades...

However, this does not solve the problem with Tabs where the order
matters. One solution might be for WinEdt to optionally "sort" the
items according to the number of selectors. In most cases the items
with more selectors should be considered first. Would this solve
your problem (if you could append and sort the items in this way)?

Best regards,

alex

----

Back to the tree and WinEdEx.ini changes that have been implemented
for the next build:

- LoadConfig() macro now has an extra parameter that allows you to
append new items to the existing (default) data:

     LoadConfig("INI File Name",Append:0..1);

This makes it possible to have more than one WinEdtEx.ini file for
mode-specific tasks...

- Items in the Navigation Bar (TOC) in WinEdtEx.ini now allow and
extra option:

     BALANCED="{}\"

This option forces WinEdt to collect balanced wildcards and thus
properly display TOC in case the title contains nested braces. The
third (optional) character in the string ignores control characters
\{ and \} which do not have to balanced if control character is
specified...

This string can also be used to collect data with ANSI Strings and
strings using an ESCAPE convention by setting:

     BALANCED="""""" or BALANCED="''" (depending on ANSI Quote)
and
     BALANCED="\", (depending on the ESCAPE character)

respectively. Defaults have been fixed appropriately...

- Items in WinEdt.gdi also allow an extra Balanced parameter with
the same meaning as TOC...

- Some users also wanted TOC Items to be cleared of labels etc...
This is now possible by specifying a set of RegEx substitutions that
are performed before the item is placed in the tree. Default for TeX
do the following:

     SUBSTITUTION="\label{*}"
       SUB_FIND="\\label\{*\}"
       SUB_REPLACE=""
       SUB_REG_EX=1
       SUB_CASE_SENSITIVE=1
     SUBSTITUTION="  "
       SUB_FIND=" +{ }"
       SUB_REPLACE=" "
       SUB_REG_EX=1
       SUB_CASE_SENSITIVE=1
     SUBSTITUTION="\ldots"
       SUB_FIND="\ldots"
       SUB_REPLACE="..."
       SUB_REG_EX=0
       SUB_CASE_SENSITIVE=1

to remove labels, multiple spaces and change "\ldots" to "...".
There is no limit on the number of substitutions but some restrain
should be exercised if you don't want to affect the performance too
much...

- BuildTree macro now has a parameter TreeEx which determines if
Branches defined in WinEdtEx.ini (such as TOC) are build as well:

   BuildTree(Rebuild: -1..1);
     -1 - never
      0 - only if tree control is visible
      1 - always

- BRANCH_SORTED=1 now works as intended (before it was ignored):
     the branch items are sorted depending on preferences in the
     Sort Dialog (Table,Ascending and Case Sensitive)...

- *** IMPORTANT: The following Keywords in [DOCUMENT_TABS] are no
longer recognized in WinEdtEx.ini:

   VISIBLE
   MULTILINE
   SCROLL_OPOSITE
   DISPLAY_FILETYPES
   HOT_TRACKING
   CUSTOM_COLORS
   TEXT_COLOR

They can be set the Appearance Dialog and were ignored anyway. For
the official release it looks like a good idea to clear WinEdtEx
from ignored attributes but users that have customized this behavior
may have to manually delete a few lines from WinEdtEx.ini before it
can be successfully loaded in a new version.

New Filter for tracking:

       TreeTrack(SelMode: 0..9, filter=0..2);
          filter - 0 None
                   1 Only if Open on Click is enabled
                   2 Only if Open on Double-Click is enabled

On 17.04.2004 01:37, WinEdt Team wrote:
> In the new build you can Load Extra configurations by appending them
> to the default ones. In fact I have changed the default settings so
> that such extras should go in %b\Local folder while the default
> WinEdtEx.ini is now in %b. Also %b\Local now contains local
> Startup.edt and users are no longer advised to modify the global one.
> Stuff in Local folder will be preserved during upgrades...

Yes, that is good.

> However, this does not solve the problem with Tabs where the order
> matters. One solution might be for WinEdt to optionally "sort" the
> items according to the number of selectors. In most cases the items
> with more selectors should be considered first. Would this solve your
> problem (if you could append and sort the items in this way)?

Not really. It more depends on the meaning, and relevance of the
selectors, and on the user's preferences.

If there was a fixed set of selectors, your solution could help, but
with the possibility to define new sets (either with the TAG tag, or
using MODE), the situation gets messy. One would have to create a
complete new set of possible file states (for all MODIFIED, NEW etc.),
and even then, would still be at loss, if there is more than one set of
this kind (e.g. for TeX mode, and for RCS status).

To illustrate this: For my RCS mode, a file will be tagged as being in
the RCS repository if the corresponding repository file exists (this is
being checked when opening the file, and can also be checked by asking
RCS). If it also is modified, it will be tagged differently. In the
default WinEdtEx.ini, the additions must therefore come before the
Modified selector, and should come after Externally Modified, Error and
the like, since that seems to be more important information. So, my
installation macro would simply search for the "Modified" selector, and
insert the additions before that.

However, if a user has uncommented the TeX mode stuff in WinEdtEx.ini,
the RCS additions should probably come before that, as well. Should
there be even more customizations, the installation macro would simply
don't know, and AFAICT couldn't know, what to do.

So, to cut this short, no, I don't think sorting the items would help.


Regards,
Robert.