BBC BASIC for Windows
IDE and Compiler >> Program Editor >> Wishlist of minor editor suggestions
http://bb4w.conforums.com/index.cgi?board=editor&action=display&num=1243343095
Wishlist of minor editor suggestions
Post by donquibeats on May 26th, 2009, 1:04pm

Hello

I can think of about half a dozen "it would be nice if..." suggestions that I could make about the BB4W Program Editor. It's a great editor and it does a brilliant job, so these aren't criticisms, just suggestions for extra non-essential functionality.

As Richard has said in the past that BB4W is pretty much completed, would there be any value in it if I posted a short wishlist here, or would I just come across as ungrateful?

Stuart
Re: Wishlist of minor editor suggestions
Post by admin on May 26th, 2009, 4:50pm

Quote:
would there be any value in it if I posted a short wishlist here, or would I just come across as ungrateful?

I wouldn't consider it "ungrateful" but the likelihood of any suggestions being incorporated is small, especially as the editor is exceptionally vulnerable to nasty bugs being introduced if 'fiddled with'.

Richard.
Re: Wishlist of minor editor suggestions
Post by donquibeats on May 26th, 2009, 5:40pm

on May 26th, 2009, 4:50pm, Richard Russell wrote:
the likelihood of any suggestions being incorporated is small


I appreciate that. Just for your interest, then, rather than any real intention that these should be added features, here are a few:

- Find only works 'down' the document (searching from your current position to the end). It would be helpful if it could also work 'up' the document. Maybe there could be checkboxes for 'up' and 'down' in the Find dialogue box (a bit like Textpad www.textpad.com)

- Right-clicking lists all the procedures in program order. Maybe it's just a sign of my disorganisation but it would be useful for larger programs if there were the option to list the procedures in alphabetical name order instead.

- Automatic line renumbering (this one's probably a bit frivolous)

Stuart.
Re: Wishlist of minor editor suggestions
Post by admin on May 26th, 2009, 9:38pm

Quote:
Find only works 'down' the document (searching from your current position to the end). It would be helpful if it could also work 'up' the document.

Personally I can't say I've ever felt the need for this. In those editors I use which have that capability, I never utilise it myself.

Quote:
Right-clicking lists all the procedures in program order.

Yes, partly because of the way the menu is created and partly because the idea is that you can see things like ON SYS lines in the context of their position in the program. You can even add your own 'separator' lines to the menu, which wouldn't make sense if alphabetically sorted.

Crucially, both the above features could be implemented as Add-in Utilities. I don't have to modify BB4W to provide them, you just have to persuade somebody skilled in the art of writing such utilities to create them for you (or you can learn how to do it yourself)!

Quote:
Automatic line renumbering (this one's probably a bit frivolous)

How would this differ from the Renumber facility already provided?

Richard.
Re: Wishlist of minor editor suggestions
Post by Stuart on May 27th, 2009, 1:07pm

on May 26th, 2009, 9:38pm, Richard Russell wrote:
Crucially, both the above features could be implemented as Add-in Utilities. I don't have to modify BB4W to provide them, you just have to persuade somebody skilled in the art of writing such utilities to create them for you (or you can learn how to do it yourself)![/qupte]

To be honest, this is the first I've heard about add-in utilities. Is there any documentation about how to create them?

[quote]How would this differ from the Renumber facility already provided?


It would renumber lines instantly whenever code was typed or cut or pasted. At the moment if you cut or copy and paste code with line numbers to a different part of the code, the line numbers remain attached, which arguably serves no purpose.

As I said to begin with, they are frivolous little remarks and I wouldn't stand by them in any sort of proper argument.
Re: Wishlist of minor editor suggestions
Post by admin on May 27th, 2009, 2:08pm

Quote:
To be honest, this is the first I've heard about add-in utilities. Is there any documentation about how to create them?

There's not very much documentation, as such, but they have been widely discussed recently both here and on the Yahoo group. Check out these threads:

http://bb4w.conforums.com/index.cgi?board=ide&action=display&num=1236183192
http://bb4w.conforums.com/index.cgi?board=ide&action=display&num=1241010025
http://bb4w.conforums.com/index.cgi?board=ide&action=display&num=1241940860
http://bb4w.conforums.com/index.cgi?board=ide&action=display&num=1236220487

Also see this Wiki article:

http://bb4w.wikispaces.com/Tools+and+Utilities

Quote:
At the moment if you cut or copy and paste code with line numbers to a different part of the code, the line numbers remain attached, which arguably serves no purpose.

Simple solution - don't use line numbers. Line numbers are provided for legacy reasons, so that ancient BBC Micro programs can be run. You should never use line numbers in programs these days, and I certainly won't be adding any functionality which makes their use more convenient!

On the other hand, a modification to BB4W which automatically gave a mild electric shock to anybody using line numbers in their programs would be very worthwhile wink

Richard.
Re: Wishlist of minor editor suggestions
Post by donquibeats on Jun 1st, 2009, 3:28pm

Thanks for the links. A couple of them went quite far over my head, but the idea of doing an add-in utility will be another thing on my "to do" list.

I use line numbers. I'm not ashamed.

The largest two pieces of software I've written are used on each of 20 computers on our Intranet. If the software crashes on any machine, it creates a little log file of the crash into a shared folder, and the error line ERL is a very helpful number to have. I don't know what the line-number-free alternative to ERL would be?

I don't use GOTO or RESTORE 1000 or anything like that, I promise. Just ERL.
Re: Wishlist of minor editor suggestions
Post by admin on Jun 1st, 2009, 4:42pm

Quote:
If the software crashes on any machine, it creates a little log file of the crash into a shared folder, and the error line ERL is a very helpful number to have.

Except that the compiler (assuming you've not disabled the 'concatenate lines' option) will have deleted many of those line numbers anyway! So in fact your log file probably isn't giving you the detailed information you thought it was.

Quote:
I don't know what the line-number-free alternative to ERL would be?

The line-number-free alternative to ERL is !408, which is the actual memory address of the statement (or part of a statement) in which the error was detected. The function ERL simply scans the program to find which line contains that address. You could log that value (in fact the value !408-PAGE might be better) and write a little utility that takes the log file and locates where the error occurred within the program.

Richard.
Re: Wishlist of minor editor suggestions
Post by Matt on Oct 3rd, 2010, 07:12am

Hi,

Thought of a couple of suggestions for the Program Editor (wish list only - don't take seriously, but I would like oppinions for them).

1. As well as/instead of the context menu with link references to procs and fns, there might be tabs for these (top or bottom) (possibly with a complete listing on one of the tabs). This might alow quick clicking from one section to another. Don't get me wrong, I think the context menu is far, far better than the good old fashioned scrolling through thousands of lines. Just a thought.

2. Option to have loop completion, e.g. when you enter a FOR I=1 TO 10, and press return, it automatically puts in a blank line and a NEXT and returns the curser to the blank line. The only loop that might complicate this (that I can think of) is the REPEAT UNTIL..., but this could end with either a blank or a default setting - say FALSE.

Both of these are Lazyitus setting in, but I thought I might just suggest them.

As I said - not serious. What do you think?

Matt
Re: Wishlist of minor editor suggestions
Post by admin on Oct 3rd, 2010, 09:00am

on Oct 3rd, 2010, 07:12am, Matt wrote:
As well as/instead of the context menu with link references to procs and fns, there might be tabs for these

I think the (potential) problem with this is scaling. I quite often have well over a hundred PROCs/FNs in one program, and that number of tabs would be unmanageable. I suspect it's something that looks like a good idea with relatively small programs, but not large ones.

Quote:
Option to have loop completion, e.g. when you enter a FOR I=1 TO 10, and press return, it automatically puts in a blank line and a NEXT

I have no fundamental objection, but it's one of those 'where do you stop' issues. Once you've set a precedent for automating the NEXT statement, there are probably many other similar situations that you could argue deserve the same treatment (DEF PROC producing an ENDPROC etc.).

Are you aware of the macro facility in BB4W? You could easily program one of the function keys to generate the 'newline NEXT' sequence, then you'd only have to press one key for it. Check out the Macro Recorder add-in utility.

Richard.
Re: Wishlist of minor editor suggestions
Post by donquibeats on Oct 5th, 2010, 6:18pm

As this topic seems to have sprung back to life, I will mention another entirely unessential "wouldn't it be nice if..." idea.

In Notepad++ when I'm working with XML or PHP, on the left hand side there are + and - symbols which allow you to 'hide' certain functions or sections by shrinking them down to one line.

If BB4W had this whenever there's a DEFPROC or DEFFN or FOR or REPEAT or WHILE, you could make PROCedures or sections of code you know are finished only show up as a single line, thus reducing scrolling.

Once again it really is only a thought.
Re: Wishlist of minor editor suggestions
Post by Matt on Oct 5th, 2010, 7:35pm

I like this idea, although, as it is, you could always 'hide' them by putting them in a library file.
Re: Wishlist of minor editor suggestions
Post by admin on Oct 5th, 2010, 9:02pm

on Oct 5th, 2010, 6:18pm, donquibeats wrote:
If BB4W had this whenever there's a DEFPROC or DEFFN or FOR or REPEAT or WHILE, you could make PROCedures or sections of code you know are finished only show up as a single line

I'm pretty sure this has come up before. It's similar in principle to requests to indent or otherwise highlight the 'body' of a PROC/FN. The problem with all such ideas is that, in BBC BASIC, there's no reliable way to detect where a PROC/FN ends. A PROC can contain multiple ENDPROCs and an FN can contain multiple =s. Also, there's no reason in principle why a PROC or FN shouldn't itself contain one or more single-line PROCs or FNs within its 'body' (although it's a rather perverse thing to do).

So any attempt to implement such a feature would involve some 'guesswork' as to where the PROC/FN actually ends, which wouldn't always be right.

Anyway, such a feature would require the BB4W editor to be completely restructured, because it relies on the position of a line in the editing window corresponding exactly to its position in the program (which is why line 'wrapping' is not supported).

Richard.
Re: Wishlist of minor editor suggestions
Post by knudvaneeden on Oct 6th, 2010, 08:33am

FYI That is called 'folding'
Re: Wishlist of minor editor suggestions
Post by knudvaneeden on Oct 6th, 2010, 08:38am

It might be that it is difficult to find out where a function, procedure or method *ends*.

But inversely, it is probably much easier to find out where a (new) function, procedure or methods *begins*.

The idea is that the *end* of a previous function, procedure or method is usually just before the *begin* of a new one.

So if you know where the new one begins, then you are set.

And this begin of a new function, procedure or method one usually finds by parsing (e.g. using regular expressions).

That is the way I do it to create e.g. dependency graphs for programs, beautifiers, .... And could in principle very probably also be used for folding.

Re: Wishlist of minor editor suggestions
Post by knudvaneeden on Oct 6th, 2010, 08:59am

For example this is the regular expression I use to find (the begin of, and thus then I know also the end of the previous function or procedure):

DEF PROCs and DEF FNs in BBCBASIC for Windows.

"{{^ @}|{ }}{{PROC}|{FN}}[A-Za-z_][A-Za-z_0-9]@\c(@"

It says look for the begin of the line followed by spaces, then followed by the word 'PROC' or 'FN' then followed by the character A to Z or a to z or underscore, then followed by zero or more characters A to Z or a to z or underscore or 0 to 9.

My text editor is Semware TSE professional, where I use this regular expressions to parse and automate all kind of computer language related functionality (e.g. automatic collection of BBCBASIC libraries, so facilitating with the automatic compiling of that programs, ...).
It does not do folding though (still a feature request). But I can program almost any functionality I want into it (but have never seen folding as a real bonus. For example in IBM Lotus Notes it was used a lot, you could also program the folding if you wanted, but I personally did not use it that much. You almost always had to click open or close that folded parts, especially when you did not wanted it). Further Notepad++, e-text editor, Visual Studio, E-macs, Vim, Netbeans, Eclipse, ... have implemented folding for some computer languages.
Re: Wishlist of minor editor suggestions
Post by knudvaneeden on Oct 6th, 2010, 09:23am

In case of *nested* DEF PROCs and DEF FNs you could e.g. use a stack.

The algorithm used could be similar to the 'match' algorithm you can use to check correct amount of nested (), {}, [], <>, REPEAT UNTIL, WHILE ENDWHILE, CASE ENDCASE, ...

That is you increase a counter (which is basically a simplest stack, you push or pop a '1' on that stack) if you encounter a begin symbol (e.g. DEF...) and decrease it when you encounter it again.

You could then e.g. parse the whole BBCBASIC program, and at the end you might have enough information about the whereabouts of the begins and ends of the procedures and functions.

But thinking further about it, it might thus be that in case of nested functions, as Richard said, you must also know where the function ends (e.g. by checking for 'ENDPROC', or '='. Because *only* knowing where the function or procedure begins will not be enough information.

Re: Wishlist of minor editor suggestions
Post by admin on Oct 6th, 2010, 1:23pm

on Oct 6th, 2010, 08:38am, knudvaneeden wrote:
The idea is that the *end* of a previous function, procedure or method is usually just before the *begin* of a new one.

Usually, maybe, but frequently this is not the case. Specifically, it is not the case when a procedure (or function) has multiple entry points. Take, for example, this code from WINLIB2:

Code:
      DEF PROC_pushbutton(dlg%,text$,id%,x%,y%,cx%,cy%,style%): style%+=&50010000:LOCAL class%:class%=&80
      DEF PROC_checkbox(dlg%,text$,id%,x%,y%,cx%,cy%,style%):   style%+=&50010003:LOCAL class%:class%=&80
      DEF PROC_radiobutton(dlg%,text$,id%,x%,y%,cx%,cy%,style%):style%+=&50010009:LOCAL class%:class%=&80
      DEF PROC_groupbox(dlg%,text$,id%,x%,y%,cx%,cy%,style%):   style%+=&50000007:LOCAL class%:class%=&80
      DEF PROC_editbox(dlg%,text$,id%,x%,y%,cx%,cy%,style%):    style%+=&50810000:LOCAL class%:class%=&81
      DEF PROC_static(dlg%,text$,id%,x%,y%,cx%,cy%,style%):     style%+=&50000000:LOCAL class%:class%=&82
      DEF PROC_listbox(dlg%,text$,id%,x%,y%,cx%,cy%,style%):    style%+=&50A10003:LOCAL class%:class%=&83
      DEF PROC_combobox(dlg%,text$,id%,x%,y%,cx%,cy%,style%):   style%+=&50210000:LOCAL class%:class%=&85
      DEF PROC_dlgitem(dlg%,text$,id%,x%,y%,cx%,cy%,style%,class%)
      LOCAL P%, L%
      P% = dlg%!12
      WHILE (P% AND 3) P% += 1 : ENDWHILE
      IF (P%+2*LENtext$+26) > dlg%!8 ERROR 0, "No room for dialogue template"
      :
      P%!0 = style%
      P%!4 = 0
      P%!8 = (y% << 16) OR x%
      P%!12 = (cy% << 16) OR cx%
      P%!16 = &FFFF0000 OR id%
      P%!20 = class%
      :
      SYS "MultiByteToWideChar", 0, 0, text$, -1, P%+22, 65536 TO L%
      P%!(2*L%+20) = 0
      :
      dlg%!12 = P%+2*L%+24
      dlg%!24 += 1
      ENDPROC

Here, the procedure has nine different entry points and only one ENDPROC. So assuming that DEF PROC signifies the end of a previous procedure will completely fail in this case.

Richard.
Re: Wishlist of minor editor suggestions
Post by knudvaneeden on Oct 6th, 2010, 2:39pm

Yes, it does not look like there is enough information present in the source code to automatically and unambiguously determine the begin and end of a function, procedure.

As a workaround one could maybe e.g. introduce the heuristic rule that "if no clear end (like ENDPROC or =)" has been found, then it must be a nested DEF PROC or nested FN.

One could in general still go for the "well maybe not always correct, but at least most of the time" approach.

Nested procedures and functions are not that common, as far as my experience goes. I have actually only seen it used once in my life before
(in 'the article about the program 'Basic Analyser', author = Mike Stallybrass, in which he describes an interpreter for BBCBASIC).
But maybe it is used (much) more in BBCBASIC for Windows.

It is further so that in that text editors the user can manually decide where and when to fold. E.g. by clicking on the side bar and create or remove such a '+' or '-' entry. So maybe not automatically, but at least possible.

Anyhow ideas are cheap, implementation probably not feasable or desirable.
Re: Wishlist of minor editor suggestions
Post by knudvaneeden 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
Re: Wishlist of minor editor suggestions
Post by admin 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.
Re: Wishlist of minor editor suggestions
Post by Matt 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
Re: Wishlist of minor editor suggestions
Post by JGHarston 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.
Re: Wishlist of minor editor suggestions
Post by admin 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.
Re: Wishlist of minor editor suggestions
Post by JGHarston 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.
Re: Wishlist of minor editor suggestions
Post by Matt 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
Re: Wishlist of minor editor suggestions
Post by admin 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:
      DEF _bookmark1_

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.
Re: Wishlist of minor editor suggestions
Post by softweir 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?
Re: Wishlist of minor editor suggestions
Post by Matt 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
Re: Wishlist of minor editor suggestions
Post by admin 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.
Re: Wishlist of minor editor suggestions
Post by softweir 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.