23 minor issues

[David Morris]

I really like the Zeus IDE, and have decided to begin using it in my
production environment (well once I pay for it of course!). This is a
pretty strong endorsement. I want to make it clear that the following are
all tings I can live with, so really fall under the category of minor
annoyance or even wish list items. I would expect that Jussi does not run
a giant usability lab with hundreds of staff, so I imagine he welcomes
user feedback as I do for my projects (http://www.netwiz.com.au).

So the following is a list issues, that I have either worked around or
ignored, and so are not in any way deal breakers since I can use Zeus
effectivly as is, but it would be still useful if these issues were
addressed or fixed. The more obvious ones I have put at the top of the
list.

1) "File->Edit-Find in files", does not start if a document is not open.
It just might be the first thing I do, or I want to see only files that
meet some criteria.

2) "Close all files" Option for the right click on "tab/open file area":
This should be just under close document. The reason. I am too lazy
to close them through the Window menu.

3) "Add file to project" Option for the right click on "tab/open file
area": Again pure laziness, I would like not to have to move the mouse
far to find the Workspace area.

4) Find '\\' will find '\'' but not '\\' regardless of the 'Use regular
expression' check box. (And I can guess why - but is there a switch for
this feature). By contrast "Find in files" will find '\\'.

5) A find in open files would be useful. I guess I could use the replace
dialogue, but that makes me nervous.

6) A 'Replace in Files' would be useful as well. (Though I note the work
around in http://www.zeusedit.com/forum/viewtopic.php?t=17)

7) Line wrapping in a text file, does not 'keep' a blank line following
the paragraph.

Line wrapping does not 're-format' if text is inserted into an extant
paragraph.

9) Pressing Backspace does not take the cursor to the line above when
word wrapping is enabled even if that line is part of the current 'hard
line'.

10) Syntax highlighting in preprocesser defines is a tad inconsistent in
'c'. While I can see what is going on (it is highlighting strings an so
on), basically I think <stdlib.h> should be highlighted in the same way as
"mystdlib.h". In other words there should be at least an option to
highlight the whole line for a preprocessor statement.

11) When adding to the workspace, it automatically alphabetically sorts
all the projects. Since these might have been manually edited in the 'zwi'
file and placed in a specific order this is be a pain (cf:
http://www.zeusedit.com/forum/viewtopic.php?t=39). Of course some might
want it that way, so perhaps this should be configurable. Of course drop
and drag would be even better, but this is as previously discussed, hard
to implement.

12) Problem/Bug/Environment: Insert, that is pasting in a new line or part
of a line of text. Sometimes when inserting a new line the cursor seems
to move back one character, so that if I press enter the last character
ends up on a new line. This seems only seems to happen when I am doing
a lot of things and I am too busy to note how it happened, and later I
don't seem to be able to replicate it. It has happened enough times
though for me to be convinced that it is not my keystrokes.

13) Problem/Bug/Environment: Occasional screen painting glitch: Very
rarely, parts of the screen would turn black, and scroll bar would be have
erratically. Again I cannot reproduce this. It might have been a memory
or resource problem on my computer (Windows 2000, P4 512Mb).

14) Spell check: Importing a word list (list of words as a text file)
seems to work for DOS format (CR/LF) but not Unix format (LF). (I took a
while to work this out!)

15) Workspace: I would like nested projects. For example I have suite of
applications, with one program dynamically loading one of many DLLs. I
would like to have these DLLs at a lower level, but still as complete
projects.

16) Workspace: I would like to be able to place files in the work space
(as opposed to project space). These might be master bat files for a master
make, or notes, or configuration files.

17) Workspace: Classes: This is quite a useful feature, I think.
However, I think that for 'c' it should process the header files as well as
just the 'c' file. Of course I can see the limitations here; as well as
speed and memory do we really want to have all of the Windows API
included. So, perhaps this could be an option to parse on quoted
headers, not angle bracket headers. Of course while I am focusesing on
'c' I imagine that this issue would be also true in other languages, for
example ASM 'inc' files.

18) Project compiler settings. Zeus has a hierarchy of compiler
settings, with the settings provided by the Document Type, at the default
or lowestest level, followed by those in the project which will overwrite
those in the document type. (There is implicitly another level in
between these two in the Workspace, based on the work space dialogue
settings, but either this does not work, or I have misunderstood the
dialogue.) This hierarchy is a useful and powerful feature, as you can
have a different defines or settings for different projects in the same
workspace, for example DLL, EXE, or Console application. The problem is
that once you have specified the compiler in the project space, it
supersedes ALL document types, so that you might generally compile in 'c'
correctly, but you can not longer compile an 'rc' file, as Zeus will now
use the project compiler settings.
Basically, I would like to see the project settings specify which
compiler type (or types) it applies to, and then use the default document
types for all the others.

19) Specifying a UserDirectory in the Zeus.ini file seems to supersede
the Script setting even if the script setting is "C:\Program
Files\zfw\zScript".
TIP: Useful tip, specify the CONFIG folder, and creating a
short cut to use a different INI file for each work space, you can
effectivly have per workspace document types, and settings. This can be
especially useful for setting include paths, and default compiler
settings.)

20) Window opening. I ma not even sure I am justified in reporting this.
Basically when opening the Navigator window (as a separate window rather
than docked), and this may apply to to other windows as well, it will not
remember its start position if it was negative. If you happen to have
two monitors, and the left one has windows co-ordinates that are
negative, the windows will re-appear in the right screen at the 0,0
position. Now, I can see why this is here. If the co-ordinates become
corrupted (in the INI file?) then they are likely to be either greater
than the screen resolution of less than 0. And the best correction,
would be to set them to 0. Perhaps this is a Windows API 'thing' (but I
don't think so). A suggested work around, might be to have an option
for maximum and minimum co-ordinates in the INI file, or better would be
a more complete test of the dimensions of the screen. This raises all
sorts of issues, and reminds me that I have not tested for this in my own
programs. hmmm....

21) Mouse marking mode, is really an option for column editing (Since it
seems that cut and paste follow or remember the columns). This is a
useful feature that ought to have its own button on the toolbar.

22) Excepting the above, there should be an option to have the cursor
automatically find the end of a line when moving the cursor down, if the
cursor started at the end of the line. Quite often I find myself
pasting the same thing at the end of a set of ragged lines, and this
would save much time and frustration. Crimson Editor
(http://www.crimsoneditor.com/) which I use (but lacks the IDE
features), does this very well.

23) As I write this I am on day 48 of 60 days. When I re-installed, from
version 3.93 to 3.94 the count reset to 0 (from about 30 days. I am not
complaining I think I have needed every bit of the evaluation period, but
given a post elsewhere, I thought it was worth reporting. I un-installed,
as instructed, before installing the newer version.

regards DM

[Guest]

Hi David,

I really like the Zeus IDE, and have decided to begin using it in my production environment (well once I pay for it of course!). This is a pretty strong endorsement.

I am glad the evaluation is going well

I want to make it clear that the following are all things I can live with

All comments and suggestions are more than welcome.

I would expect that Jussi does not run a giant usability lab with hundreds of staff, so I imagine he welcomes user feedback

You read my mind

1) "File->Edit-Find in files", does not start if a document is not open.

This is definitely a bug and will be fixed ASAP.

2) "Close all files" Option for the right click on "tab/open file area": This should be just under close document.

This is easy enough to add. My only concern is the popup menu is getting quite long, but I guess one more item is not going do to much harm.

In an ideal world Zeus would allow the user to configure the menus, and while configurable menus are on the todo list, this not going to happen any time soon.

3) "Add file to project" Option for the right click on "tab/open file area":

I am not sure about this one. While adding the new menu item is quite easy todo, the current project/workspace file management is usable, but far from ideal. At some stage this feature will need to be re-visited, so I am reluctant to make changes in this area until that re-work is done.

4) Find '\\' will find '\'' but not '\\'

This is a matter of documentation. The '\' is a literal marker for example '\t' will find the tab character.

As such this means that to search for '\\' you need to in fact enter '\\\\'

By contrast "Find in files" will find '\\'.

This is an unfortunate inconsistency

5) A find in open files would be useful. I guess I could use the replace dialogue, but that makes me nervous.

This has been added to the todo list.

6) A 'Replace in Files' would be useful as well.

This has been added to the todo list.

7) Line wrapping in a text file, does not 'keep' a blank line following the paragraph.
8 ) Line wrapping does not 're-format' if text is inserted into an extant paragraph.

Line wrapping is not one of Zeus best features

9) Pressing Backspace does not take the cursor to the line above

I suggest writing a simple macro script to make the backspace work just the way you want it to work.

10) Syntax highlighting in preprocessor defines is a tad inconsistency in 'c'.

This will not be changing any time soon. The syntax highlighting is a dangerous section of the Zeus code that can easily create major problems (ie it involves lots of playing with pointers to strings). I agree the current highlighter does have several limitations but it is also nice and stable

11) When adding to the workspace, it automatically alphabetically sorts all the projects.

From memory it will also sort the files in the project

Adding some options to the workspace might be the way to go.

12) Problem/Bug/Environment: Insert, that is pasting in a new line or part of a line of text. .... This seems only seems to happen when I am doing a lot of things and I am too busy to note how it happened

More than likely it will be a bug triggered by some sort of unusally make copy paste combination. Other the years there a have been a few such bugs, but as you have found they can be hard to replicate.

13) Problem/Bug/Environment: Occasional screen painting glitch: Very rarely, parts of the screen would turn black, and scroll bar would be have erratically. Again I cannot reproduce this. It might have been a memory or resource problem on my computer (Windows 2000, P4 512Mb).

This does sound like a memory problem and I suspect one of the programs you are running is leaking memory. I just hope Zeus is not the one that is doing the leaking

14) Spell check: Importing a word list (list of words as a text file) seems to work for DOS format (CR/LF) but not Unix format (LF). (I took a while to work this out!)

This should be easy enough to fix.

15) Workspace: I would like nested projects.

This would be a little difficult to implement since there would be lots of places in Zeus where the two level workspace/project structure is assumed (ie hard coded). Maybe in the future

16) Workspace: I would like to be able to place files in the work space

As per 15.

17) Workspace: Classes: This is quite a useful feature, I think.
However, I think that for 'c' it should process the header files as well as just the 'c' file.

I am not sure what you mean by this

The classes tab is nothing more than a visual representation of the ctags information. The actual files that are used to create the tags information come straight out of the project (ie they are listed in the Project Files folder of the Classes panel). So if the header files are in the project they will be sent to ctags for processing.

The information that gets displayed is entirely controlled by how little or much information ctags.exe decided to put in the tags file.

18 ) Project compiler settings. Zeus has a hierarchy of compiler settings

That is correct. From memory this is the basic search logic used:

1. Get currently active file name
2. Search current workspace for the project that owns the file
3. If project was not found use the default project (ie the default workspace)
4. Get the command line details from the project (ie real or default).
5. If no command line is defined then as a last resort use the document type command line

But also remember that the project have two sets of details, one for debug and one for release.

or I have misunderstood the dialogue

The compiler output should have a line of text that indicates where Zeus thinks it got the command line from. This line of text is specifically there to help debug the configuration.

So that you might generally compile in 'c' correctly, but you can not longer compile an 'rc' file, as Zeus will now use the project compiler settings.

In this case Zeus is using the active project to compile the file. In the case of the rc file it obviously fails, but consider the case of a new 'c' file that has not yet been added to the workspace. The new 'c' file would compile just fine

As you can see trying to pick the right compiler string is quite a complex task

Basically, I would like to see the project settings specify which compiler type (or types) it applies to, and then use the default document types for all the others.

I am reluctant to add any more complexity to the current compiler model. I think there are users that already struggle with the current model.

But having said that, I think if Zeus was changed to only use the active project settings if the current file is part of the current workspace, otherwise fall back to the default workspace and failing that fallback to the document type, then this should fix the rc compile error you describe.

19) Specifying a UserDirectory in the Zeus.ini file seems to supersede the Script setting even if the script setting is "C:\Program Files\zfw\zScript".

This looks like a bug

20) Window opening. Basically when opening the Navigator window (as a separate window rather than docked).. If you happen to have two monitors

This looks like a bug

A suggested work around, might be to have an option for maximum and minimum co-ordinates in the INI file

Zeus has been specifically designed to work well on multi-monitors. For example I would assume the Find and Replace dialogs (or any of the other modeless dialogs) do not have the same problem. My guess is the navigator dialog was never tested for multi-monitors

This should be easy enough to fix.

21) Mouse marking mode, is really an option for column editing (Since it seems that cut and paste follow or remember the columns). This is a useful feature that ought to have its own button on the toolbar.

This is not quite that simple. The Zeus marking is another one of those features that is not all that you might think it is.

22) Excepting the above, there should be an option to have the cursor automatically find the end of a line when moving the cursor down

A linedown.lua macro script something like this will do the trick:

Code: Select all

function key_macro()
  -- macro only works for documents
  local document = is_document()

  -- macro only works for read/write documents.
  local locked = is_read_only()

  if (locked == 1) or (document == 0) then
    -- let the default processing handle the unexpected case
    MoveLineDown()
  else
    -- if within line do nothing

--  this code may/may not be needed
--  if (is_cursor_online() == 1) then
--    MoveLineDown()
--  else
      MoveLineDown()
      MoveLineEnd()
--  end
  end
end

key_macro() -- run the macro

You can bind the macro to the down key and obviously there is a similar macro needed for line up.

Code: Select all

23) As I write this I am on day 48 of 60 days. When I re-installed, from version 3.93 to 3.94 the count reset to 0 (from about 30 days.

The trial period is reset on each new version as this allows users of an older version of the shareware to also evaluate the latest shareware version. But as a new Zeus releases usually come out every 6 to 9 months, eventually the trial period will run out.

Cheers Jussi

[jussij]

Hi David,

19) Specifying a UserDirectory in the Zeus.ini file seems to supersede the Script setting even if the script setting is "C:\Program Files\zfw\zScript".

For me the INI file settings are working fine. What I did was shut down Zeus, then I edited the Zeus INI file using Notepad to add these entries:

Code: Select all

[Network]
UserDirectory="D:\TEMP\"
Script="C:\TEMP\ZEUS_TEST\SCRIPT\"

Now when I start Zeus and use the Tools, DOS Command Line menu to run dir $zd I get the correct Zeus directory:

Code: Select all

Volume in drive D is Development
 Volume Serial Number is B418-8817

 Directory of D:\TEMP
 .....

Finally if I then use the Macros, Load menu the file open dialog opens in the correct C:\TEMP\ZEUS_TEST\SCRIPT\ directory.

Jussi

[Guest]

Hi Jussi.

Thanks for the quick response. Rather than extensivly quote and unqote, I'll just use number here to respond to the points above. For 3), this does not mean a change to the workspace menu, rather the open file menu. It means that you won't have to move off the open file to add it to the project, there by reducing the risk of errors while saving mouse movement and clicks.

In a couple of places you have suggested Macros, which is great (as I can use these), however, ideally in thing these features should be hard coded, for both consistency and speed. This of course presupposed that my view are shared by the majority of users, which of course may not be
the case.

For 10), I understand your view, and reliability is more important to me than any of these 23 points.

To clear up what I meant in 17). The Unix tool makedepend (which I have modified to use in Windows) can parse a 'c' file to modify a mak file so that all the header files can be included as dependencies. In the same way, when you have 'c' file in the project, rather than having to add all the 'h' files (which you might otherwise open as 'include files' from the context menu), the 'tags' part could/should parse these from 'c' file to get all the structures et al that are used in the 'c' file. Having said all of that, I found that as I added another 15 or so projects yesterday, the tags feature was slowing things down too much every time I saved a file that I have now disabled that feature.

Perhaps, an option to manual parse all the files in the project, with another option to walk down the tree into include or dependant files? (So I can eave the automatic updates turned off).

For 18)

But having said that, I think if Zeus was hanged to only use the active project settings if the current file is part of the current workspace, otherwise fall back to the default workspace and failing that fall-back to the document type, then this should fix the rc compile error you describe.

Rather than making "the active project settings if the current file is part of the current workspace", which as far as I can tell would be all files since you can only have one workspace loaded at a time(?), I think it would be better to make it use the active project settings for a specified type of file (or files), and default to the document type for all the others. Ideally I would like to be able to have several compiler options for each project (perhaps a maximum of 5). These could be INI file settings, with a numeral added to the key, and another setting for the doc type. e.g. something like:

Code: Select all

<DebugCompile>C:\LANG\MSVC6\BIN\cl.exe @c:\Work\montel\src\config\wincfvmt.rsp -Foc:\temp\$FB.obj -Tc$FN</DebugCompile>
  <DebugCompileDocType1>.rc</DebugCompileDocType1>
  <DebugCompile1>C:\LANG\MSVC6\BIN\rc.exe @c:\Work\montel\src\config\rcflags.rsp -Foc:\temp\$FB.res $FN</DebugCompile1>

Item 22) marking seems to act like column mode on some other editors, though I have not explored this in detail. I don't normally use it, however I can see some situations where a button to quickly change could be very useful.

And for 19) in your follow up post. I re did what I did to produced the error, and it ran the line-wrap macro file as a test. The first time I ran the macro it worked, and I wondered how I saw the problem. The I typed some more text, perhaps did something else, and ran the macro again (this time for real), and then:- there was no 'debug' tab, just and error on the statuts line at the bottom "Error loading the C:\work\Montel\ZeuszScript\linewrap.lua' macro file".

And the command line used to load Zeus is:

Code: Select all

"C:\Program Files\zfw\zeus.exe" -s  -uC:\Work\Montel\Zeus  
-iC:\Work\Montel\Zeus\zeus32.ini -wC:\Work\Montel\MonTel32.zwi

The network section of the zues32.ini file is:

Code: Select all

[Network] 
UserDirectory="C:\Work\Montel\Zeus" 
Backup="C:\Work\Montel\Zeus\zBackup" 
Config="C:\Work\Montel\Zeus\config32" 
Example="C:\Program Files\zfw\zExample" 
Help="C:\Program Files\zfw\zHelp" 
Script="C:\Program Files\zfw\zScript" 
Spell="C:\Work\Montel\Zeus\zSpell"

My work around was comment out UserDirectory thus:

Code: Select all

;UserDirectory="C:\Work\Montel\Zeus"

And then everything worked as expected. (Zeus version is 3.94a).

regards DM

[Guest]

Hi David,

however, ideally in thing these features should be hard coded

I am not so sure about this. For example consider your case of a new line down functionality. Just off the top of my head there are at least three ways to code this function:

The first one would look like this:

Code: Select all

Move down one line (as it currently stands)

this is the second:

Code: Select all

Move down one line
if (past end of line) Move to end of line

and finally this one:

Code: Select all

Move down one line
Move to end of line

Lets assume these three (and their corresponding line up) functions get added to Zeus:

Code: Select all

MoveLineDown
MoveLineDownEx
MoveLineDownExEx
MoveLineUp
MoveLineUpEx
MoveLineUpExEx

So now there are six new line down/up functions. Ignoring the fact that these new functions need to be documented and tested, the hardest part is deciding which line down/up function should be used in the current set of keyboard mappings. If MoveLineDown is chosen how is the user meant to know they could rebind the keymap to use the other two functions MoveLineDownEx or MoveLineDownEx. The functions would get written but never used.

And the problem does not end there We have only considered the Up and Down arrow keys. The same argument applies just as well for the Backspace, Tab, Shift Tab, Enter, Left Arrow, Right Arrow keys. If every possibale variation of these keys is added to Zeus this would add several dozen new keyboard functions, most of which would never get used.

I feel the scripting option is perfect for this as it allows the user to re-configure each and every key making them work any way they like.

for both consistency, and speed

The problem is there is no consistency. All editors try to do something extra special with these keys. As for speed, I am sure you would not even notice the difference

I added another 15 or so projects yesterday, the tags feature was slowing things down too much every time I saved a file that I have now disabled that feature.

This is rather odd

Speed is a very subjective thing but just now I have the Zeus Workspace open and it contains some 500+ files split over 6 projects and for me the save is less than a second. The Zeus tagging engine uses the file timestamp to see if a re-build is needed so in theory only the files that have changed need to be re-tagged.

In any case you can also turn off the tag on save option (see the tags section of the workspace). You can then use the Tags, Update menu to force a tag build.

Ideally I would like to be able to have several compiler options for each project (perhaps a maximum of 5).

The Zeus hierarchical compiler setting was specifically design to make the configration more flexible, while still attempting to keep the configuration as simple as possible. But more and more users seem to find the task of configuring a compiler in Zeus quite a difficult task I think many have something todo with the fact that a lot of modern day developers are brought up using nothing but IDE's that hide the compiler configuration entirely. So they when the are forced to deal with command lines, batch files and make files it can get a little difficult

For this reason I very reluctant to add yet another layer of complexity to a compiler configuration model, given that it could be argued that it is already far too complex for the average user.

"Error loading the C:\work\Montel\ZeuszScript\linewrap.lua' macro file".

There was a small bug with this code in the sense it did not check for correctly formated directory names. If you look at the line above you will notice the ZeuszScript should have read Zeus/zScript. I think if you change the your INI file to read:

Code: Select all

[Network]
UserDirectory="C:\Work\Montel\Zeus\"
Backup="C:\Work\Montel\Zeus\zBackup\"
Config="C:\Work\Montel\Zeus\config32\"
Example="C:\Program Files\zfw\zExample\"
Help="C:\Program Files\zfw\zHelp\"
Script="C:\Program Files\zfw\zScript\"
Spell="C:\Work\Montel\Zeus\zSpell\"

then I think it should work just fine.

Cheers Jussi

[David Morris]

Hi Jussi

Hi David,
I am not so sure about this. For example consider your case of a new line down functionality. Just off the top of my head there are at least three ways to code this function

I don't think you would ever need the third option.

However, I can understand your concern when you factor in all the other keystrokes. I would suggest though that this might be a special case where the default might be worth changing for moving up and down. I would add that I think the backspace should be able to move up to the previous line as well.

>I added another 15 or so projects yesterday, the tags feature was slowing things down too much every time I saved a file that I have now disabled that feature.

This is rather odd

I assume you meant my comment about speed rather than adding 15 or so projects to the workspace Actually, I think I understated it. There are now 54 projects (including a config project for common make files et al), and while most projects have about 7 or 8 files, there are some that have 40 or 50. So it is getting quiet busy (and I have't quite finished yet!).

I don't know how to easily count the files (yet another feature = YAF).

Speed is a very subjective thing ...

Agreed. Usability studies say 5 seconds is the limit. But if you are
rapidly cycling through an edit and compile session, even a second can be too long (for me).
I'll try the option you suggested. I must say though the speed I have now is ideal!

>Ideally I would like to be able to have several compiler options for each project (perhaps a maximum of 5).

The Zeus hierarchical compiler setting was specifically design to make the configration more flexible, while to do attempting to keep the configuration as simple as possible. But more and more users seem to find the task of configuring a compiler in Zeus quite a difficult task I think many have something todo with the fact that a lot of modern day developers are brought up using nothing but IDE's that hide the compiler configuration entirely. So they when the are forced to deal with command lines, batch files and make files it can get a little difficult

Indeed. Though I find it strange that people can do really complex things in C++, but can't program a DOS bat file.

In fairness to them, I don't think the documentation makes this structure very clear. It took me a while work through it, but some simple diagrams I think would make this pretty easy.

I understand you are concerned about complexity, but part of the problem is that I think you need to have a dialog item to specify the document type to which the compiler settings apply. By calling the prompt something like: "Override doc compiler for:"

• , it then becomes clear which compiler settings will apply, and you still have the fall back into the doc types.
  

  "Error loading the C:\work\Montel\ZeuszScript\linewrap.lua' macro file".

  There was a small bug with this code in the sense it did not check for correctly formated directory names.

  I was too busy to notice the obvious here!
  
  regards DM

[David Morris]

Hi, one more for the list.

24) Spell checker does not remeber the capital letter at the beginning of a sentence.

regards DM

[David Morris]

Hi, another one for the list.

25) Context highlighting does not have a string continuation character option. For example in a STRINGTABLE in RC files you might have a string that looks like:

Code: Select all

STRINGTABLE
    {
    STR_SELECTDESTINATION_UNABLECREATE,  "Error %li: %s \n\n%s\
                                         was unable to create %s .\n\n\
                                         Please check that the volume or drive \
                                         exists and that you have permission to \
                                         write to that area of the server.  \
                                         Please note that you will need to map \
                                         a drive letter for this installation \
                                         to proceed."
...

where the string enclosed in quotes continues over more than one line.

regards DM

[jussij]

Hi David,

I don't think you would ever need the third option.

Yes, but you never really know, and just to prove my point , take a look at how MSVC thinks the home key should work

I would add that I think the backspace should be able to move up to the previous line as well.

Use the Zeus BackspaceEx keyboard function.

I don't know how to easily count the files (yet another feature = YAF).

Maybe

But if you are rapidly cycling through an edit and compile session, even a second can be too long (for me).

Too true. When I'm on a roll (coding wise), there is nothing more frustrating than having stop and wait for the computer

In fairness to them, I don't think the documentation makes this structure very clear. It took me a while work through it, but some simple diagrams I think would make this pretty easy.

At it simplest all Zeus really does is run a batch file or executable and capture the output produced. But Zeus is designed to be very flexible and provides the user with many ways achieve this result (ie tools, macros, document type, workspace). Trying to document all of these options is the difficult part

By calling the prompt something like: "Override doc compiler for:"

• , it then becomes clear which compiler settings will apply, and you still have the fall back into the doc types.

I am still not convinced. The original example you quoted (ie workspace open containing c/c++, and you try to compile an rc file) is definitely a problem and in fact I think it can be considered a bug. But as I said before, a simple change to the Zeus compiler search logic should fix this problem.

Here is the current Zeus search logic in more detail, with what I think is the fix to the problem:

1. Take the active file and run a search for the associated project
2. Is the file is in any of the projects of the current workspace ?
3. If yes then we have found our project
4. If no then use the active project This step is removed:
5. If no fall back to the default project
6. Get compiler details from the project found above
7. If no compiler details are defined fallback to document type
8. If no compiler details are defined fallback to default document type

So going back to your example, if the RC file is not defined in any of the workspaces and no settings are defined in the default workspace Zeus will compile the file using the RC document type.

Context highlighting does not have a string continuation character option.

This is very true. Also triple quoted strings common in languages like Python are not supported

But the work around is

Code: Select all

STRINGTABLE
    {
    STR_SELECTDESTINATION_UNABLECREATE,  "Error %li: %s \n\n%s"\
                                         "was unable to create %s .\n\n"\
                                         "Please check that the volume or drive "\
                                         "exists and that you have permission to "\
                                         "write to that area of the server.  "\
                                         "Please note that you will need to map "\
                                         "a drive letter for this installation "\
                                         "to proceed."

Cheers Jussi

[Guest]

I am still not convinced. The original example you quoted (ie workspace open containing c/c++, and you try to compile an rc file) is definitely a problem and in fact I think it can be considered a bug. But as I said before, a simple change to the Zeus compiler search logic should fix this problem.

Here is the current Zeus search logic in more detail, with what I think is the fix to the problem:

1. Take the active file and run a search for the associated project
2. Is the file is in any of the projects of the current workspace ?
3. If yes then we have found our project
4. If no then use the active project This step is removed:
5. If no fall back to the default project
6. Get compiler details from the project found above
7. If no compiler details are defined fall-back to document type
8. If no compiler details are defined fall-back to default document type

So going back to your example, if the RC file is not defined in any of the workspaces and no settings are defined in the default workspace Zeus will compile the file using the RC document type.

Ok, this is a useful description, and you should have it in your documentation, because I didn't realise "If no then use the active project" step existed.

But while I agree that step is confusing and perhaps redundant, it does not address my issue. If I have an RC file in a project, and I want to compile it (as part of that edit/compile loop I mentioned above), I can't. If we had a doc type associated with the project compile, then it could fall back to the default RC doc type (since in my case I would be using 'c' as the project compile doc type), and I could modify the settings there. Since the way I work is to have an INI file and config folder for each workspace, that effectivly gives me a set of default workspace doc types settings. Otherwise for me, (and using the set-up you describe above) I can't ever compile an RC file from within the IDE.

Having said that I can work around it, because of those bat file settings that you fixed for 3.94.

I thing my suggested extra feature is reasonably trivial, but perhaps for version 4 the whole structure of the workspace needs to be revisited. If so, I would suggest and hierecahy of doc types, so that you can modify each setting at each level - default - workspace - project (and preferably through a tree of projects). The changes to specific setings could be included in the project/workspace xml files, with any setting not specified falling back through the tree to the default. By changing the colour of the edit field, you could indicate if the setting was modified at the current level, or at a higher level.

regards DM

[jussij]

If I have an RC file in a project, and I want to compile it (as part of that edit/compile loop I mentioned above), I can't.

Yes and no. For example one option would be to write a batch file that takes the file name and the file extension. The batch file would be responsible for running the correct compile based on the file extension. Zeus would be quite happy to run the batch file passing it the $fn and $ext macro tags as parameters.

Another option is to think of the project as nothing more than a special type of document type. For example if you put your c/c++ in the Source Project and the RC files into the Resource project, you can define two sets of independent sets of compiler command lines.

If we had a doc type associated with the project compile, then it could fall back to the default RC doc type

The reason I do not like this fix is it really does not fix the problem entirely. For example consider a project containing three different file types (ie c/c++, RC and Java). Once again the compile will not work for one of the three file type.

The ideal solution is to change the project configuration entirely and maybe allow multiple command lines to be defined against multiple file extensions within the project (ie a project becomes something like a collect of mini document types) or some other similar solution. At this stage I am not sure what is the best way to fix the problem, but I do know there is no quick fix

I can't ever compile an RC file from within the IDE.

Never say can't

I thing my suggested extra feature is reasonably trivial, but perhaps for version 4 the whole structure of the workspace needs to be revisited.

You have hit the nail smack bang on the head. I don't disagree that a fix is possible, but I don't like the fix because it is really nothing more than a work around. The real problem is current configuration model simply does not support this concept and the only ideal fix is to come up with a better configuration model.

If so, I would suggest and hierecahy of doc types, so that you can modify each setting at each level - default - workspace - project (and preferably through a tree of projects).

This is definitely the sort of direction the see the Workspace taking. The current project/workspace model is not bad and is a nice first step, but as always, there are definite things that can be done better.

Cheers Jussi

[David Morris]

12) Problem/Bug/Environment: Insert, that is pasting in a new line or part of a line of text. .... This seems only seems to happen when I am doing a lot of things and I am too busy to note how it happened

More than likely it will be a bug triggered by some sort of unusally make copy paste combination. Other the years there a have been a few such bugs, but as you have found they can be hard to replicate.

I can now replicate this issue. Place the mouse cursor past the end of the line and drag it back to highlight the whole line. Now copy it, and paste it in fount of some of text at the beginning of a line.

The 'phantom' spaces at the end to the line will be pasted, but the cursor will end up, not at the end of the 'phantom' spaces, but back one place in the 'real' text that has just been pasted.

Of course, if you are on a roll like I am some times (it seems rarer as I get older!), you can cut and paste on not see why semi colons are ending up on news lines in 'c'.

regards DM

[David Morris]

Item 26)

This is really a feature request....

....Bookmarks.

Perhaps a column to the right(?) of the line numbers to display a check mark, to turn off a highlight mark of the whole row, so that multiple rows can be marked, so you can some back quickly to that part of the file, or even better come back to that book mark after having saved and closed the file (and/or Zeus). You could even have a few different types of bookmarks that you could cycle through for different levels of emphasis.

I think a lot of IDEs have this. Borland 'C'5.02 is the one I am familiar with.

regards DM

[jussij]

Hi David,

Believe it or not the column marking was coded to work this way

Here is an example to better explain the why the feature works this way. Consider the following code where the text has been arranged into nice and neat rows and columns:

Code: Select all

1  c1  c2  c3  c4  c5
2  c1      c3
3  c1  c2      c4
4  c1      c3
5  c1  c2          c5
6  c1      c3  c4

Notice how these lines are of varying length (ie the lines end at the last non-white space character of each line).

Now use the mouse to mark a small column region starting at the c character of c3, row one and ending one character after 4 (ie the end point is past the actual end of line of row six) at c4,row six.

If this makred area is copied to clipboard, the cursor moved to before the c character of c3, row one and the text inserted you should get this result:

Code: Select all

1  c1  c2  c3  c4 c3  c4  c5
2  c1      c3     c3
3  c1  c2      c4     c4
4  c1      c3     c3
5  c1  c2                 c5
6  c1      c3  c4 c3  c4

Becuase of the behaviour of the column copy and paste the row and column arrangements have been maintained. If the paste had not added the phantom white space characters then the nice and neat arrangement of the rows and columns would have been destroyed.

To achieve this result the column mode copy actually filled the marked virtual space with white space characters.

I personally think this is the way Zeus should work in column mode copy and paste, but I also agree that for the special only a single line is marked case maybe there is no need for the virtual white space filling

Item 26) This is really a feature request.... Bookmarks.

The entire Zeus bookmarking feature needs to be re-worked to add this and many other features. This re-write is on the Zeus todo list but as yet it has not yet reached the top of the list

Cheers Jussi

[David Morris]

Hi Jussi.

It isn't the pasting of the 'phantom characters that bothers me, it is the that the cursor ends up one short of the last character of the real text (so that the last character and the phantom spaces come after it). I am not quite sure why that would help in column mode.

But as I said the phantom characters are fine.

regards DM