1. Edita help window
I just looked at the "nw" local options/definitions in Edita, and I'm quite
puzzled.
First of all, when the file being viewed is not an Eu file (welcome.txt), it
spits out the unformatted contents of the file. This displayshoumd be
suppressed I think, and F1 should go straight to the keyboard shortcut window.
It would be even better if the behaviour of F1 was predictable, using Ctrl-F1
to access the options/definition window when these words make sense for the
current file. By the way, I didn't even try if I'd get a meaningful output
using say a C++ file. Since there is syntax coloring for other languages,
I'd expect pragmas/#ifdefs and such to be displayed there.
Then I opened a standard Eu file and tried selecting different lines there,
and see what F1 does.
1/ If the line is a comment or blank, the result is a set of commented lines
in file, not always the same. I don't really get it. Shouldn't all
commented lines outside of routines be displayed? Just try the first few
lines of misc.e.
1'/ Then how could comments obviously related to routines/constants be
displayed? They are the most important thing to read, very often.
2/ So you can't display constants, procedures etc at the same time, since
the current line must be a constant declaration, procedure declaration etc.
This is hardly useful. Don't rely on the current line contents and supply
a set of checkboxes instead (plus a select all button).
3/ Staggered constant declarations don't display, namely the platform()
return values in misc.e.
A gallant try, but... imho the design has some serious flaws. And I stopped
the tests fast, because I'd consider the above as blocking.
I'm using what I think is the latest release - it has refolding and IDs as
23/12/05. The About box should really display the version number somewhere.
CChris
2. Re: Edita help window
CChris wrote:
<snip>
>I'm quite puzzled.
<snip>
>A gallant try, but... imho the design has some serious flaws.
The help system in Edita has several detractors...
Perhaps if I outline the so-called design it currently has:
1) Requirements/examples [existing functionality]
1.a Pressing F1 while on "repeat" gives the builtin definition.
Pressing Reference Manual opens lib_X_X.htm#<builtin> (if found)
accordingly.
1.b Pressing F1 while on "getFileExtension" in edita.exw shows the definition of
that function in eamisc.ew. Pressing Examine Code opens eamisc.ew at that
routine. This uses information previously stored (automagically) in edita.edb and
sets the window title to eg "C:\Program Files\Edita\eamisc.ew" and correctly
identifies say the 0.2.7 version actually being called even when edita.edb
"knows" about a same-name function elsewhere, eg in a copy of 0.2.6 still lying
around.
1.c Pressing F1 while on a call to the non-global "cut_line()" in misc.e shows a
window similar to that in 1.b entitled "Locally defined in this source". Note
that this parses the file for local routine definitions not in edita.edb
1.d Pressing F1 while on "all_ascii" in misc.e shows 8 lines it found that in.
Note that this searches the file for instances (of local variables and constants)
in a naieve fashion, .txt files as well and within comments and strings, and sets
the result window title to "Local definition/uses of all_ascii in this source".
1.e A Keyboard Help button is given on all the above, which is shown immediately
if it cannot find any other help about the word under the cursor. If you were
looking for keyboard help, but something else shows, you can just press Alt K
[see 2.d].
2) Bugs and Wishes
2.a In 1.d cursoring to the 6th instance and pressing return should jump to the
line.
2.b Pressing F1 on "it", "the", "at", etc can produce strange/silly results.
(shrug)
2.c When displaying say the getFileExtension example above, it should display
the code up to end procedure/function/type as well. I think it used to do that
once.
2.d A separate key (Ctrl F1) for Keyboard Help is a good idea, will do that.
2.e Incorporating other help systems, eg Juergen's command_line html searcher,
or F1 jockey. However this does *NOT* mean that all of 1 can be thrown in the
bin. In the past I have had trouble passing eg "open" or "repeat" to these
things, and to cut a very long story short have pretty much given up trying, and
developed a bit of a sensitive "why did I bother making it open source?" attitude
along with a not insignificant despair at any readiness to ditch 1, and 1.b in
particular. Perhaps these things could be added in the form of user defined
tools.
2.f CChris wants a filter for C++ ifdefs and pragmas. If you let/wait for me to
do it, I will probably just get it all wrong anyway 
)
2.g Pressing F1 on a routine definition somewhat pointlessly shows the routine
as per 1.c, though I generally consider this as only the most minor of
annoyances.
2.h After "Examine Code", I would like to "Go Back" to the previous source/line.
(This may not technically be Help per se, but that button furthers need.)
2.i Global variables and constants are not currently stored in edita.edb and
hence are not found when F1 is pressed in a different source. However in order to
correctly handle say global user defined types, the background processing would
have to be completely rewritten and about ten times bigger than it is now,
basically a full-blown compiler front end, no less. At the moment, globalCache is
a plain table which it uses find() on - it will most certainly need to become a
hash table if loaded with global constants and variables as well as routines.
Any others?
Testing note: when inserting/deleting/renaming globals, you should perhaps wait
for the red triangle on the toolbar to return to grey, indicating that the
"automagic" update of edita.edb has completed after a file save, before testing
F1. In some cases a restart of Edita may be needed (let me know), particularly
when cutting and pasting global routine definitions and include statements
between files, in order to flush some global items cached in memory. In extreme
cases, you may even need to run Tools/Verify edita.edb, again let me know if you
can reproduce. Actually, I know one easy way to cause this last point: physically
deleting or renaming a file.
Your "nw" example should be reviewed in light of 1.d and 2.b
>3/ Staggered constant declarations don't display, namely the platform()
> return values in misc.e.
Not really sure what you mean or expect there. Perhaps you want to edit the
lang/ealng_en.exh file and send me some updates. Generalising this is another
matter, for example pressing F1 on some call to db_select(), without modifying
database.e, I cannot imagine how it might list DB_OK etc, which is how I am
hopefully wrongly interpreting the statement/suggestion just made. Or, (not sure
I would agree with this as "Examine Code" should be used when this much detail is
needed), are you saying that F1 on DB_OK should also show DB_OPEN_FAIL etc [2.i
notwithstanding] as well?
>I'm using what I think is the latest release - it has refolding and IDs as
> 23/12/05. The About box should really display the version number somewhere.
The version number should be just left of the 23/12/05, in the window title.
I am still slowly making progress on a new release, but don't hold your breath.
Regards,
Pete
3. Re: Edita help window
Pete Lomax wrote:
>
> CChris wrote:
> <snip>
> >I'm quite puzzled.
> <snip>
> >A gallant try, but... imho the design has some serious flaws.
>
> The help system in Edita has several detractors...
> Perhaps if I outline the so-called design it currently has:
>
> 1) Requirements/examples [existing functionality]
> 1.a Pressing F1 while on "repeat" gives the builtin definition.
> Pressing Reference Manual opens lib_X_X.htm#<builtin> (if found) accordingly.
> 1.b Pressing F1 while on "getFileExtension" in edita.exw shows the definition
> of that function in eamisc.ew. Pressing Examine Code opens eamisc.ew at that
> routine. This uses information previously stored (automagically) in edita.edb
> and sets the window title to eg "C:\Program Files\Edita\eamisc.ew" and
> correctly
> identifies say the 0.2.7 version actually being called even when edita.edb
> "knows"
> about a same-name function elsewhere, eg in a copy of 0.2.6 still lying
> around.
> 1.c Pressing F1 while on a call to the non-global "cut_line()" in misc.e shows
> a window similar to that in 1.b entitled "Locally defined in this source".
> Note
> that this parses the file for local routine definitions not in edita.edb
> 1.d Pressing F1 while on "all_ascii" in misc.e shows 8 lines it found that in.
> Note that this searches the file for instances (of local variables and
> constants)
> in a naieve fashion, .txt files as well and within comments and strings, and
> sets the result window title to "Local definition/uses of all_ascii in this
> source".
> 1.e A Keyboard Help button is given on all the above, which is shown
> immediately
> if it cannot find any other help about the word under the cursor. If you were
> looking for keyboard help, but something else shows, you can just press Alt
> K [see 2.d].
>
All this sounds nice, but:
1.1/ The above makes sense only when a _word_ is selected. It would probably
be less confusing if the context help was bypassed when something else than
a word is selected. My mistake (was it?) was to expect something meaningful
when nothing is selected. Using the first word on the current line is
certainly unexpected and confusing.
1.2/ Checking for the help on "repeat" makes sense in several languages, but
you don't expect the same output according to the language used. Guessing
which language is being used is done reliably through inspection of the file
type and syntax highlighting currently in use. For now, just disable the
feature on non Eu files.
1.3/ 1.e is certainly a design flaw, because the needs for help on a word or
on akeyboard shrtcut are quite independent. This is why I strongly suggest
2 different windows and 2 different help menu entries.
> 2) Bugs and Wishes
I just opened misc.e in Edita 0.2.7, double clicked on "machine_func"
(highlighting it) at line 24, row 17. F1 then gives me the keyboard help.
This is not consistent with above description.
> 2.a In 1.d cursoring to the 6th instance and pressing return should jump to
> the line.
> 2.b Pressing F1 on "it", "the", "at", etc can produce strange/silly results.
> (shrug)
> 2.c When displaying say the getFileExtension example above, it should display
> the code up to end procedure/function/type as well. I think it used to do that
> once.
> 2.d A separate key (Ctrl F1) for Keyboard Help is a good idea, will do that.
> 2.e Incorporating other help systems, eg Juergen's command_line html searcher,
> or F1 jockey. However this does *NOT* mean that all of 1 can be thrown in the
> bin. In the past I have had trouble passing eg "open" or "repeat" to these
> things,
> and to cut a very long story short have pretty much given up trying, and
> developed
> a bit of a sensitive "why did I bother making it open source?" attitude along
> with a not insignificant despair at any readiness to ditch 1, and 1.b in
> particular.
> Perhaps these things could be added in the form of user defined tools.
> 2.f CChris wants a filter for C++ ifdefs and pragmas. If you let/wait for me
> to do it, I will probably just get it all wrong anyway )
Got the message. I may find it interesting to set that up. But I have too
many projects in mind and not enough time.
> 2.g Pressing F1 on a routine definition somewhat pointlessly shows the routine
> as per 1.c, though I generally consider this as only the most minor of
> annoyances.
> 2.h After "Examine Code", I would like to "Go Back" to the previous
> source/line.
> (This may not technically be Help per se, but that button furthers need.)
> 2.i Global variables and constants are not currently stored in edita.edb and
> hence are not found when F1 is pressed in a different source. However in order
> to correctly handle say global user defined types, the background processing
> would have to be completely rewritten and about ten times bigger than it is
> now, basically a full-blown compiler front end, no less. At the moment,
> globalCache
> is a plain table which it uses find() on - it will most certainly need to
> become
> a hash table if loaded with global constants and variables as well as
> routines.
First off, there is already such a front end, freely available in the Eu
source directory; it is made of scanner.e and parser.e. Not having to
report compile errors and not having to figure out opcodes can make them
quite lighter.
Second, I didn't expect "Help" to do that, but "Xref" rather. Such a tool
would be a tremendous boost to the usefulness of Edita. I have this sort
of thing almost working in my enhanced Visual Euphoria. I'd have to figure
the right include files to get it working again and making the tool reliable.
>
> Any others?
>
> Testing note: when inserting/deleting/renaming globals, you should perhaps
> wait
> for the red triangle on the toolbar to return to grey, indicating that the
> "automagic"
> update of edita.edb has completed after a file save, before testing F1. In
> some
> cases a restart of Edita may be needed (let me know), particularly when
> cutting
> and pasting global routine definitions and include statements between files,
> in order to flush some global items cached in memory. In extreme cases, you
> may even need to run Tools/Verify edita.edb, again let me know if you can
> reproduce.
> Actually, I know one easy way to cause this last point: physically deleting
> or renaming a file.
>
>
> Your "nw" example should be reviewed in light of 1.d and 2.b
>
>
> >3/ Staggered constant declarations don't display, namely the platform()
> > return values in misc.e.
> Not really sure what you mean or expect there. Perhaps you want to edit the
> lang/ealng_en.exh file and send me some updates. Generalising this is another
> matter, for example pressing F1 on some call to db_select(), without modifying
> database.e, I cannot imagine how it might list DB_OK etc, which is how I am
> hopefully wrongly interpreting the statement/suggestion just made.
That was a wrong interpretation (even though it could be an interesting
addition).
See my comments below.
> Or, (not
> sure I would agree with this as "Examine Code" should be used when this much
> detail is needed), are you saying that F1 on DB_OK should also show
> DB_OPEN_FAIL
> etc [2.i notwithstanding] as well?
>
Much more simply, I happened to highlight line 12 in misc.e and pressed F1.
Lune 12 starts with the word "constant", and I got a list of lines containing
the word "constant".
Since "constant" is a reserved word introducing a declaration, I'd have
expected a list of all constant declarations. I don't think the current
scheme is of much help in that case. And LINUX, FREEEBSD etc are missing
in the displayed list.
Similarly, it could be helpful to have a list of all integer variables in
current file when F1 is pressed and current line starts with "integer" or
"global{ }+integer". And displaying any comment surrounding the declaration
would certainly be helpful. Extension to user defined types would be welcome
of course.
> >I'm using what I think is the latest release - it has refolding and IDs as
> > 23/12/05. The About box should really display the version number somewhere.
> The version number should be just left of the 23/12/05, in the window title.
> I am still slowly making progress on a new release, but don't hold your
> breath.
>
> Regards,
> Pete
My best regards to Pro Krastinashun.
CChris
4. Re: Edita help window
CChris wrote:
> All this sounds nice, but:
> 1.1/ The above makes sense only when a _word_ is selected. It would probably
> be less confusing if the context help was bypassed when something else than
> a word is selected. My mistake (was it?) was to expect something meaningful
> when nothing is selected. Using the first word on the current line is
> certainly unexpected and confusing.
Oops, missed out a feature there. If, using _ to indicate cursor, you type:
Main = create(Window,"Edita",_
pressing F1 will show the help for create. So it would break stuff to require
"create" to be block selected in order to show help for it.
>
> 1.2/ Checking for the help on "repeat" makes sense in several languages, but
> you don't expect the same output according to the language used. Guessing
> which language is being used is done reliably through inspection of the file
> type and syntax highlighting currently in use. For now, just disable the
> feature on non Eu files.
Fair point, will do that.
>
> 1.3/ 1.e is certainly a design flaw, because the needs for help on a word or
> on akeyboard shrtcut are quite independent. This is why I strongly suggest
> 2 different windows and 2 different help menu entries.
As per 2.d I plan to allow Ctrl F1 for keyboard help, but I don't like the idea
of F1 on a blank line just remaining mute. Or maybe a messagebox:
<pre>
[Context Help _X]
No suitable help for "".
[Keyboard Help] [Cancel]
</pre>
>
> > 2) Bugs and Wishes
>
> I just opened misc.e in Edita 0.2.7, double clicked on "machine_func"
> (highlighting it) at line 24, row 17. F1 then gives me the keyboard help.
> This is not consistent with above description.
Odd. It works as expected here.
> First off, there is already such a front end, freely available in the Eu
> source directory; it is made of scanner.e and parser.e. Not having to
> report compile errors and not having to figure out opcodes can make them
> quite lighter.
Hmmm.
>
> Second, I didn't expect "Help" to do that, but "Xref" rather. Such a tool
> would be a tremendous boost to the usefulness of Edita. I have this sort
> of thing almost working in my enhanced Visual Euphoria. I'd have to figure
> the right include files to get it working again and making the tool reliable.
Well, there is already a useful front end in the form of scanner.e and parser.e,
which you could trivially make into Xref utility. )
Seriously though, I personally just use find in files for that soft of thing.
> Much more simply, I happened to highlight "constant" and pressed F1.
I got you now. Added to my suggestion list, thanks.
Regards,
Pete
