Hicks: It shouldn't be.
This buffer is only cleared with CTRL-N.
Can you reproduce the problem?
I will try.
Another strange thing:
8 ** [
2 ** BYTE #
2 ** BYTE #+64
Generate #00,#01,#40,#41,... instead of #00,#00,#40,#40,...
Maybe confusing, not strange at all! The `#` is the innermost counter (associated with 2 **).
8 ** [
2 ** BYTE ##
2 ** BYTE ##+64
About the "CTRL-DEL / CTRL+P problem", I tried again and the buffer is still here... So I guess I pressed CTRL+N by reflex last time.
Ok for the "repeted byte problem", it's a little bit confusing but we just have to know how to avoid the issue.
Sorry for those two fake bug report news!
It's not that
3 ** BYTE # ; Gives 1, 2, 3
1 ** [
3 ** BYTE # ; Also gives 1, 2, 3
The assembler cannot read your mind and associate # with the counter you are thinking of.
So it's best:
* To be consistent (# is always the innermost counter)
* Make sure 1 ** [ CODE ] is equivalent to CODE.
Considering using CONTROL-f1 to CONTROL-f9 to switch between opened files.
* Pro: More handy than cycling through files. You quickly memorize which number is which file (also it will be
* Con: Limited to 9 files.
What do you think?
A tip from Orgams' coder himself.
Since CTRL-ENTER now works in comments, you can put a table of content as the top or bottom of your source:
; - params
; - start
; - gen_texture
; - frame1
; - frame2
; - variables
What about unrolling the macro's content under its name inside the source when pressing a special key with the cursor pointing on it?
That would be very useful to see on the same screen the macro's content with what's happening before and after, for optimization sessions (jumping from the macro's usage to its definition many times is quite distracting).
I don't know if this feature is already planned?
I add: auto-completion would really be very useful to be able to use longer (and therefore more explicit) names more easily.