richardpawson
commented
2 weeks ago I am not keen to encourage 'commenting out' code - as this often leads to scruffy code that remains full of comment-out parts and is never cleaned up. Nonetheless, I recognise the validity of what you are wanting to do. There are several over possibilities.
For example in Stride and Strype one can 'disable' a frame. This has the effect of commenting-out (the code cannot be reached in execution) but is rendered differently - for example in Elan the disable code could be faded to 50% tint. I would prefer to go further though than Stride/Stype and say that disabled code is enforced as for temporary reference only - it is not saved with the code (unless you first re-enable it).
Another possibility is to implement a multi-part scratchpad that you can easily cut code into - and which would could be viewed alongside the main code editor.
nbrockington
I was wondering about the situation where a student might wish to comment (and uncomment) a few lines of code in the Elan IDE in order to try to achieve the same mini-task in a different way, but without losing their original code for doing so. This is so they can use the original code for visual reference or go back to it easily if their new approach doesn't work. I have found this useful for them during teaching in the past.
This issue doesn't seem to come under issue #273 of converting frames since it would involve nesting an already existent frame within a comment frame.
Indeed the point could be rendered moot when it becomes possible to cut and paste frames as per #211, but cutting and pasting to an external file is clunky.
(Similarly it would be moot if the task were in a function or procedure, but students might not have learnt these yet.)