Author |
Topic: Wishlist of minor editor suggestions (Read 6795 times) |
|
knudvaneeden
Developer
member is offline
 
Posts: 32
|
 |
Re: Wishlist of minor editor suggestions
« Reply #19 on: Oct 6th, 2010, 3:02pm » |
|
As a sidestep, I have good usage for knowing where exactly the DEF PROCs and DEF FNs begin and end,
as I plan to create automatically 'dependency graphs' of BBCBASIC for Windows programs.
You basically search for the DEF PROC / DEF FN in which a given procedure or function is located. Then you search for all DEF PROC / DEF FN in which that def procedure or def fn is located and so on.
So knowledge of begin and end is also of use there.
Further the algorithm should be the same only difference is different regular expressions to find the DEF PROCs and DEF FNs in that computer language.
I might so use the heuristic approach of that it sometimes works but not always.
See e.g. for some preliminary research regarding dependency graphs
http://goo.gl/4DIZ
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Wishlist of minor editor suggestions
« Reply #20 on: Oct 6th, 2010, 4:07pm » |
|
on Oct 6th, 2010, 3:02pm, knudvaneeden wrote:| As a sidestep, I have good usage for knowing where exactly the DEF PROCs and DEF FNs begin and end, as I plan to create automatically 'dependency graphs' of BBCBASIC for Windows programs. |
|
A discussion of this whole area took place a long time ago in connection with cross-reference utilities, such as VarList207. Ideally a cross-reference utility should be able to report which variables are LOCAL and PRIVATE to each procedure/function, and obviously that means knowing where it ends. In fact it gets very complicated, since in BBC BASIC there's no requirement that the LOCAL/PRIVATE should appear at the beginning of a PROC/FN, and you can even declare the same variable LOCAL twice within the same procedure!
As with other aspects of BBC BASIC, the flexibility (or lack of discipline, if you prefer) of an interpreter makes it much harder to do a static program analysis than it is for a compiled language.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender: 
Posts: 210
|
|
Re: Wishlist of minor editor suggestions
« Reply #21 on: Nov 1st, 2010, 2:53pm » |
|
Thought of something else that might be nice, just as an add-in. I think it would be useful to be able to somehow 'highlight' a line, i.e. somehow mark the entire line with, say, a yellow or red background highlight colour. This would make it stand out easier than the REM statements that, even in good practice, can eventually seem overwhelming. As I have no idea how to begin to create an add-in, I would not suggest I try.
Matt
|
|
Logged
|
|
|
|
JGHarston
Junior Member
member is offline
Gender:
Posts: 52
|
|
Re: Wishlist of minor editor suggestions
« Reply #22 on: Nov 1st, 2010, 5:23pm » |
|
on Oct 6th, 2010, 1:23pm, Richard Russell wrote:| Usually, maybe, but frequently this is not the case. Specifically, it is not the case when a procedure (or function) has multiple entry points. |
|
A similar problem occurs with a utility I have to remove unused DEFPROCs and DEFFNs that I call a linker, from the phase in a traditional compiler (see Wikipedia: "Linkers take objects from a library ... only including symbols that are referenced from other object files or libraries.")
It scans through the program, and whenever it encounters a DEF scans the program again to see if it is called. If it is, then it continues scanning for DEFs.
If it finds that the DEF is never called, it removes the subroutine. And here is where the similar problem occurs, how to decide where the end of the code is to remove. I pragmatically decided to determine the end of the code to remove is just before the next DEF (or end of program). Note that this is slightly and subtly different to deciding where the end of the entire subroutine ends.
Take the following example:
Code:name$=FNPath_Full
END
DEFFNPath_Name:A%=6
DEFFNPath_Full:A%=&106
blah...
IFA%>255:="fred"
="jim"
DEFFNh0(A%,N%)=""
DEFFNd0(A%,N%)=""
Linking this code will find:
* DEFFNPath_Name is never called. The linker will decide to remove everything from the DEFFNPath_Name line to just before the next DEF.
* DEFFNPath_Full is called, so carries on.
* DEFFNh0 is not called, so removes it up to just before the next DEF.
* DEFFNd0 is not called, so removes it up to the end of the program.
This results in the following code:
Code:name$=FNPath_Full
END
DEFFNPath_Full:A%=&106
blah...
IFA%>255:="fred"
="jim"
All well and good. However, what if FNPath_Full is the one not called, as in the following example?
Code:name$=FNPath_Name
END
DEFFNPath_Name:A%=6
DEFFNPath_Full:A%=&106
blah...
IFA%>255:="fred"
="jim"
DEFFNh0(A%,N%)=""
DEFFNd0(A%,N%)=""
The linker then does the following:
* DEFFNPath_Name is called, so carries in.
* DEFFNPath_Full is not called, so the linker removes everything from this line to just before the next DEF.
* DEFFNh0 is not called, so removes it up to just before the next DEF.
* DEFFNd0 is not called, so removes it up to the end of the program.
This gives the following code:
Code:name$=FNPath_Name
END
DEFFNPath_Name:A%=6
Obviously not right!
I, the programmer, know what code should have been removed, but that's because I'm a human being looking at it from the outside. It's difficult to build that sort of knowledge into a deterministic program. The only way out is to adopt a certain program writing style that embeds certain hints into the code that the linker can use.
I've been planning for ages to convert the linker into BASIC to use with BB4W. The source is here. Anybody's welcome to play with it and get ideas.
|
| « Last Edit: Nov 1st, 2010, 5:28pm by JGHarston » |
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Wishlist of minor editor suggestions
« Reply #23 on: Nov 1st, 2010, 6:25pm » |
|
on Nov 1st, 2010, 2:53pm, Matt wrote:| As I have no idea how to begin to create an add-in, I would not suggest I try. |
|
It's not something that could be done that way anyway. The BB4W editor simply doesn't have the capability.
Personally I can't see any reason why you shouldn't use the 'traditional' ways of highlighting comments, for example by surrounding them with a box made up of stars or Xs. People have been wanting to emphasise comments since the days of punched tape and teletypes; they've managed perfectly well without having background colours available!
You can also make use of the alternative comment styles to help draw attention:
http://bb4w.wikispaces.com/Alternative+comment+styles
Richard.
|
|
Logged
|
|
|
|
JGHarston
Junior Member
member is offline
Gender:
Posts: 52
|
|
Re: Wishlist of minor editor suggestions
« Reply #24 on: Nov 1st, 2010, 11:56pm » |
|
To add another alternative style, I used this style earlier today.
At the risk of tempting hubris, I put this page of examples together some time ago.
Edit: I've just noticed that there's no actual BASIC programs as such on that page, I'll have to get around to putting some there. As an alternative, look at the commenting style in these BASIC libraries.
|
| « Last Edit: Nov 2nd, 2010, 12:04am by JGHarston » |
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: Wishlist of minor editor suggestions
« Reply #25 on: Nov 2nd, 2010, 06:18am » |
|
The idea of highlighting the line(s) wasn't as one would note a routine with a REM or a subsection with a band of boardered marks, but just as a temporary mark to 'highlight' a place for easy note, as one might mark a place in a rough document to be delt with later or to allow you to quickly recognise the line you're dealing with at a later stage. I often wizz around the coding trying to find the exact lines that I was dealing with.
Which brings me to another suggestion: Would there be a way of being able to flick backwards and forwards between two places. There is the 'Go back' item in the context menu, which is very useful, but the ability to alternate between the two previous points with the click of a key-combination seems to me to be a very useful thing to do.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Wishlist of minor editor suggestions
« Reply #26 on: Nov 2nd, 2010, 09:23am » |
|
on Nov 2nd, 2010, 06:18am, Matt wrote:| There is the 'Go back' item in the context menu, which is very useful, but the ability to alternate between the two previous points with the click of a key-combination seems to me to be a very useful thing to do. |
|
You could put a 'bookmark' at one of the points that you want to flip between. A bookmark is a DEF not followed by PROC or FN. For example:
Code:
Bookmarks appear in the right-click context menu, along with the PROCs and FNs, so you can jump straight there by clicking on the bookmark in that menu. You could flip between two points by alternating Go back and jumping to the bookmark.
Richard.
|
|
Logged
|
|
|
|
softweir
New Member
member is offline
Posts: 12
|
|
Re: Wishlist of minor editor suggestions
« Reply #27 on: Nov 10th, 2010, 12:02am » |
|
on Oct 6th, 2010, 08:38am, knudvaneeden wrote:| But inversely, it is probably much easier to find out where a (new) function, procedure or methods *begins*. |
|
I haven't tried this, but I seem to remember that it is possible for a BB4W program to have multiple entry points to a procedure or function. So for example:
Code:PROCprocedure1a()
PROCprocedure1b(7)
PROCprocedure1c("numero",7)
END
DEF PROCprocedure1a()
LOCAL numeral%=0
DEF PROCprocedure1b(numeral%)
LOCAL text$="Number"
DEF PROCprocedure1v(text$,numeral%)
PRINT text$;" ";numeral%
ENDPROC
(This is, of course, hideously bad programming practice!)
While PROCprocedure1a is being interpreted, the lines starting DEF PROCprocedure1b and DEF PROCprocedure1c are ignored, and it is interpreted as:
Code:DEF PROCprocedure1a()
LOCAL numeral%=0
LOCAL text$="Number"
PRINT text$;" ";numeral%
ENDPROC
Similarly, PROCprocedure1b is interpreted as:
Code:DEF PROCprocedure1b(numeral%)
LOCAL text$="Number"
PRINT text$;" ";numeral%
ENDPROC
I don't know if there are any real-world examples of code such as this (and I hope there aren't!) but any such code would seriously confuse a folding editor.
Hum. Perhaps that would be a good argument FOR a hypothetical folding editor?
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: Wishlist of minor editor suggestions
« Reply #28 on: Nov 10th, 2010, 05:17am » |
|
I notice Richard has used this practice in various places in the LIBs. One obvious case is in WINLIB5 where there are 6 DEFs together. However, the difference is that the LOCALs are on the same line as the DEF, therefore eliminating unnecessary multiple/overlapping LOCALs. I wouldn't know if this was good or bad practice, but it obviously works, and works well.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Wishlist of minor editor suggestions
« Reply #29 on: Nov 10th, 2010, 08:40am » |
|
on Nov 10th, 2010, 12:02am, softweir wrote:| I don't know if there are any real-world examples of code such as this (and I hope there aren't!) |
|
I use that technique regularly. I don't consider it particularly bad practice. Any BBC BASIC editor would have to cope with it.
Richard.
|
| « Last Edit: Nov 10th, 2010, 08:41am by admin » |
Logged
|
|
|
|
softweir
New Member
member is offline
Posts: 12
|
|
Re: Wishlist of minor editor suggestions
« Reply #30 on: Nov 11th, 2010, 5:32pm » |
|
Oh dear. I have managed to be unintentionally offensive (for which I apologise) and made myself look foolish.
Still, all this does strongly enforce the point that a BASIC IDE needs to be very flexible regarding the beginnings and ends of code structures, so much so that a hypothetical folding editor seems totally impracticable.
|
|
Logged
|
|
|
|
|
