After hacking away happily for a few hours with v0.18.2 all of a sudden the keys went crazy.
Up/Down arrow was jumping by a page or so and moving some blue highlighting but the cursor did not follow. Other keys non-functional, Control-S non-functional. Hit the close button, prompted for save, OK, restart, all OK. No idea how I got to this state.
Edit: Ooops, there it goes again. Seems all keys are going to the message output window, hence the blue highlighting is following the warning messages as hit I Up/Down arrow. Can't get keys back to the edit window.
Edit: On Debian lenny.
Edit: OK this does it:
1. Open BST
2. Project -> Recent Projects -> mocog_demo.sprj
Editing works fine so far.
3. ALT-TAB around to Firefox
4. Refresh the Propeller forum (of course)
5. ALT-TAB back to BST.
Now the edit window has the mouse focus but not the keyboard. Can't get out of this state.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What a pain in the bottom! I've just managed to reproduce this, so I will have a fix out tomorrow evening (if I'm lucky). Thanks for your patience in tracking this down. It's a bug in the underlying toolchain I need to chase and fix.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
noticed an odd feature (?) ... this isn't picking a nit, it's just weird to me
1. open any reasonable length file (for example \library\VGA_Demo.spin)
2. view->line #'s (on)
3. expand any/all sections
4. carefully mouse over the line showing the open sections - in the left margin, right of the line no's.
5. when mouse icon changes from text to arrow, right click - and you'll see the 'feature' ... what's·the number·indicate?
maybe a dangling menu?
thanks
- Howard
(another satisfied beta testor [noparse]:)[/noparse]
noticed an odd feature (?) ... this isn't picking a nit, it's just weird to me
1. open any reasonable length file (for example \library\VGA_Demo.spin)
2. view->line #'s (on)
3. expand any/all sections
4. carefully mouse over the line showing the open sections - in the left margin, right of the line no's.
5. when mouse icon changes from text to arrow, right click - and you'll see the 'feature' ... what's the number indicate?
maybe a dangling menu?
Indeed, it's a leftover from some debugging I was doing of the editor component I left enabled. Well spotted. It does nothing aside from appear.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
3. ALT-TAB around to Firefox
4. Refresh the Propeller forum (of course)
5. ALT-TAB back to BST.
Now the edit window has the mouse focus but not the keyboard. Can't get out of this state.
Just a follow up on this. The problem runs much deeper in the underlying tools than I'd first realised, and is going to take quite some digging to solve (It's an issue with the interaction between GTK2 and X with the Lazarus framework and will only affect the linux builds).
In the mean time, heater has kindly pointed out that if this happens to you, you can use almost any alt-key combination to get control of the program back.
The issue is bst is seeing the alt-key-press, but when you hit tab it loses focus and misses the alt-key-up event so it thinks the alt key is locked down. A simple tap of the alt key will not solve this. You need to use a key combination (I use alt-a here).
This is a very annoying bug and I'll get it fixed as soon as I can. Thanks for your patience.
I'd like to thank heater for his work in helping me reproduce and track this one down.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
As we keep saying Brad, very nice work. I got back onto this thread because I was experiencing weird keyboard issues and worked out that it was part of the alt-tab thing etc. Seeing that you are aware of it I thought I would inform you that this bug is also a feature (I think). I noticed that I could perform a "columns" select in this mode and then release the alt and presto! Can your IDE perform a column select normally? I don't recall seeing it anywhere.
I mentioned this to Brad already. No BST does not normally have column select. This is some change in the default behaviour of a new version of the GUI tool kit used for BST. Brad can explain.
Anyway that column select mode sort of works for me as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Indeed. Column select is something I've been toying with, but I've not developed it any further. Normally on linux alt-left-drag is grabbed by the window manager to drag the window around, so it's not normally accessible. It's something I've got on my todo list, but not something I've been actively working on. I'd like to get this alt-tab bug fixed first [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
Brad, what are the odds of a print routine in BST?
I whinned before about the PropTool's inability to turn off the background colors - so when you print right from the tool, it looks like toner poopy.
[noparse][[/noparse]Yes, before anyone says it --- I know I can cut-paste to other editors. But that's work the computer is supposed to do for me [noparse]:)[/noparse] ]
I ask you because you're very responsive to our suggestions and feedback (whereas the prop tool folks probably have more pressing matters).
Print stuff's pretty easy in Win, bet it's a tad messy in GTK/Lazarus.
You might be surprised at how many of us would like this feature ... because of the number of us who are both lazy and whimpy of vision [noparse];)[/noparse]
Wow, it must be about ten years since I saw anyone print out any source code. And that was probably me[noparse]:)[/noparse]
I must say, from time to time, I do miss being able to print a file onto 2 or 3 meters of that fan fold paper with green stripes and then be able to stand back and comprehend the structure of the code a a larger scale.
Often, with just seeing my programs in editor windows, I feel like I'm painting a room through the key hole.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Wow, it must be about ten years since I saw anyone print out any source code. And that was probably me[noparse]:)[/noparse]
LOL - you know it is nice to turn off the bean counter, sit in a quite corner with a cup of tea, coffee, or a good brew -·and veg out over some juicy code once in a while [noparse]:)[/noparse])
I think printouts are very much a waste of paper as anything small enough to be printed out is also simple enough not to. Sometimes it might be good to have a bloated printout as "gloatware" for the non-appreciative non-technical who can't see that most of the really smart stuff is buried in software. After all a board with a simple program or one crammed with software both look the same. Pity we couldn't have dripping Matrix pixels but maybe someone has done that already for the Prop.
But Brad I have a question regarding the documentation of BST, is there anything available? I was looking for conditional compilation and found these in the executable:
#DEFINE
#IFDEF
#IFNDEF
#ELSEIFDEF
#ELSEIFNDEF
#ELSE
#ENDIF
#UNDEF
#WARN
#INFO
#ERROR
Maybe even a summary of BST's features etc would be helpful.
But Brad I have a question regarding the documentation of BST, is there anything available? I was looking for conditional compilation and found these in the executable:
#DEFINE
#IFDEF
#IFNDEF
#ELSEIFDEF
#ELSEIFNDEF
#ELSE
#ENDIF
#UNDEF
#WARN
#INFO
#ERROR
You will find them in the changelog in the top post and in the posts back a few pages where their development was discussed.
also http://forums.parallax.com/showthread.php?p=804887 about half way down that page where they were announced.
Peter Jakacki said...
Maybe even a summary of BST's features etc would be helpful.
I've been meaning to write a brief bit on some of the extra bits and pieces, but other things keep getting in the way (like putting food on the table).
I'll have a crack at writing up some of the less obvious stuff when I get a moment.
Thanks Brad, the thread is so long that things like these need to be put somewhere, maybe even just a link on you website. Could I request just an easy little feature? Sometimes it would be nice to select line-wrap.
BTW, when I said summary of features I should have been more specific and mentioned a summary of the directives and their usage perhaps.
heater said...
Here is a copy of sdspiqasm.spin that produces the invalid input to iconv after having been saved by BST with "Save as UTF8" option checked.
Thanks heater, I appreciate that. On it [noparse]:)[/noparse]
Is there any possibility of getting an option to disable the expanding of tabs to spaces entirely?
Opening and saving a file with tabs seems to work, but they still behave as spaces when using the arrow keys, and if you accidentally type in one it seems to shunt your typed text about in interesting ways.
Aside from that, I really like bst. I use windows, and I can tell you that I much prefer your software over the propeller tool for one giant reason... Tabs! The propeller tool refuses to use them, and replaces them with spaces when you import a file with them. It's a stupid little thing, but it drove me nuts.
Aside from that, I'd be awesome if there was an option to treat newlines normally, rather the way the prop tool does.
Edit: Oh, a little Bug (well, really more of an oversight). The popoup Windows (e.g. "Detected a Propeller Version:1", "Compiler Information" etc...) are not forced on top of the main window. Therefore, you can wind up stuck if you select the main window, as it is disabled, but gets placed above the popup window anyways. The only way out is alt+tab. It should be possible to set any alert windows to be always on top (I'm only familliar with wxWindows).
Post Edited (Fake-Name) : 7/11/2009 2:24:32 PM GMT
Fake-Name said...
Is there any possibility of getting an option to disable the expanding of tabs to spaces entirely?
Opening and saving a file with tabs seems to work, but they still behave as spaces when using the arrow keys, and if you accidentally type in one it seems to shunt your typed text about in interesting ways.
Tabs are an interesting creature. Unfortunately tab expansion is a bit of an odd and inconsistent case. Look at the non-uniform tab stops for each block type. Now try and figure out how to properly tab that. Then you have the ability to define tab stops, *but* the Propeller compiler _always_ converts tabs to 8 spaces. No if's, no but's. I'm honestly not entirely sure how to create sane behaviour when the editor allows you to redefine your tab stops, but tabs must remain 8 spaces such that the compiler gets the indenting right.
The way it's done now is a bit of an inheritance of the way the ide has been developed over its 9 month life span (has it really been that long already?). I really need to sit down and define how it needs to work and properly re-build the tab code.
Fake-Name said...
Aside from that, I really like bst. I use windows, and I can tell you that I much prefer your software over the propeller tool for one giant reason... Tabs! The propeller tool refuses to use them, and replaces them with spaces when you import a file with them. It's a stupid little thing, but it drove me nuts.
Aside from that, I'd be awesome if there was an option to treat newlines normally, rather the way the prop tool does.
Edit: Oh, a little Bug (well, really more of an oversight). The popoup Windows (e.g. "Detected a Propeller Version:1", "Compiler Information" etc...) are not forced on top of the main window. Therefore, you can wind up stuck if you select the main window, as it is disabled, but gets placed above the popup window anyways. The only way out is alt+tab. It should be possible to set any alert windows to be always on top (I'm only familliar with wxWindows).
bst is *supposed* to convert tabs to spaces the same way the propeller tool does. It does it "good enough", but I guess it does not do things right. Question is, what is actually the right way to behave?
The window modality is an interesting one, and not one I've actually seen in use (probably because I don't actually use windows, I just boot a VM periodically to test basic bst functionality). I will try and get it sorted though.
Can you elaborate on the "newlines" thing? I'm not adverse to making changes, I'm just not sure what you mean here.
A thought on recurring questions about features, documentation etc.
Maybe the use of a specific and unique keyword dropped into any post that includes things the user may want to research later until and if there is anything written. Then the user can search for the unique keyword in the search tool, and not have to read through the numerous pages. An awkward solution but may help.
The thing is the forums search tool doesn't seem to work well, but the google based search tool may work after some period of time (day or two?)
The Propeller compiler _always_ converts tabs to 8 spaces.
I know, and I hate it for that. It would be awesome if there was an option to treat \t characters as \t characters, with NO conversion at all. When you hit the tab button, insert a \t character, and treat it as a single entity, rather than a composite of spaces.
BradC said...
bst is *supposed* to convert tabs to spaces the same way the propeller tool does. It does it "good enough", but I guess it does not do things right. Question is, what is actually the right way to behave?
The window modality is an interesting one, and not one I've actually seen in use (probably because I don't actually use windows, I just boot a VM periodically to test basic bst functionality). I will try and get it sorted though.
Can you elaborate on the "newlines" thing? I'm not adverse to making changes, I'm just not sure what you mean here.
Basically, in every editor I have experience with, if you scroll past the end of the line (to the right) using arrow keys, etc... the cursor wraps to the beginning of the next line. Similarly, if you click in the empty space to the right of a line, the cursor is placed at the end of that line. Currently, it's placed directly at the mouse pointer, as iff all the white space to the right of every line is full of space characters.
Basically, I'd prefer if the editor behaved like Windows Notepad/GEdit/Every other text editor.
I'm a bit mystified that the people behind the propeller tool decided to have their IDE behave differently than pretty much every other IDE/text editor on the planet.
Post Edited (Fake-Name) : 7/12/2009 8:34:04 AM GMT
I know, and I hate it for that. It would be awesome if there was an option to treat \t characters as \t characters, with NO conversion at all. When you hit the tab button, insert a \t character, and treat it as a single entity, rather than a composite of spaces.
Problem.. again, variable tab stops. How do you make it work? At the moment if the next tab stop is 3 characters away, when you hit the tab key you get three spaces. You can't have variable tab stops that match the propeller tool (which I actually quite like) and also have valid hard tab characters.
Did you know that bst has three different ways of handling tabs?
a) Smart tabs - Cute but sometimes annoying
b) Fixed tabs like every other editor (but with a configurable tab stop - this can confuse the compiler if you are not careful and its not set to 8) - This does what you are asking above
c) Parallax style variable tabs
This is configurable in the IDE options.
Fake-Name said...
Basically, in every editor I have experience with, if you scroll past the end of the line (to the right) using arrow keys, etc... the cursor wraps to the beginning of the next line. Similarly, if you click in the empty space to the right of a line, the cursor is placed at the end of that line. Currently, it's placed directly at the mouse pointer, as iff all the white space to the right of every line is full of space characters.
Basically, I'd prefer if the editor behaved like Windows Notepad/GEdit/Every other text editor.
I'm a bit mystified that the people behind the propeller tool decided to have their IDE behave differently than pretty much every other IDE/text editor on the planet.
Right. How about a compromise. I *like* the ability to be able to click out in no-mans-land and start typing without having to space/tab my way out there. What about if I were to set it up so it linewraps like other editors when using the cursor keys back and forwards. But if you want to "get out there" you can click the mouse there and just start typing?
I don't want to add yet another option, but I kinda like the functionality in the compromise. (Read that as I've just made it work that way and I don't want to go adding extra configuration options)
heater said...
Here is a copy of sdspiqasm.spin that produces the invalid input to iconv after having been saved by BST with "Save as UTF8" option checked.
$ iconv -f UTF-8 -t US-ASCII -o temp sdspiqasm.spin
iconv: illegal input sequence at position 341
Ok, this is not a bug in bst. There is nothing wrong with that UTF-8 sequence. The issue is iconv is trying to convert from UTF-8 to US-ASCII and 341 is the first character it comes across that is not translatable into the ASCII character set (Its the first line in the schematic). iconv is simply complaining that it does not know how to produce an output in US-ASCII for that particular character. (The error message could use some improvement/clarification I grant you, but as it was written by Ulrich Drepper it's hardly a surprise)
Do you have any plans on adding more pre-processor support? In particular #define macros and #include? I use both in my stuff and currently use a C++ pre-processor to pre-process the files before running propellent. It would be nice to have a better dev environment.
Also what about adding Alt-F, etc. functionality to access menu items. I miss that from bst.
Comments
After hacking away happily for a few hours with v0.18.2 all of a sudden the keys went crazy.
Up/Down arrow was jumping by a page or so and moving some blue highlighting but the cursor did not follow. Other keys non-functional, Control-S non-functional. Hit the close button, prompted for save, OK, restart, all OK. No idea how I got to this state.
Edit: Ooops, there it goes again. Seems all keys are going to the message output window, hence the blue highlighting is following the warning messages as hit I Up/Down arrow. Can't get keys back to the edit window.
Edit: On Debian lenny.
Edit: OK this does it:
1. Open BST
2. Project -> Recent Projects -> mocog_demo.sprj
Editing works fine so far.
3. ALT-TAB around to Firefox
4. Refresh the Propeller forum (of course)
5. ALT-TAB back to BST.
Now the edit window has the mouse focus but not the keyboard. Can't get out of this state.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/3/2009 7:07:16 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
just started using 0.18.2 win - nice work!
noticed an odd feature (?) ... this isn't picking a nit, it's just weird to me
1. open any reasonable length file (for example \library\VGA_Demo.spin)
2. view->line #'s (on)
3. expand any/all sections
4. carefully mouse over the line showing the open sections - in the left margin, right of the line no's.
5. when mouse icon changes from text to arrow, right click - and you'll see the 'feature' ... what's·the number·indicate?
maybe a dangling menu?
thanks
- Howard
(another satisfied beta testor [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Indeed, it's a leftover from some debugging I was doing of the editor component I left enabled. Well spotted. It does nothing aside from appear.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
Edit: THIS IS NOT A BUG, $ IS THE CURRENT COG ADDRESS
A wee bug?
I don't know what the Prop Tool does but it does not look like the following should compile without error to me:
PUB start DAT BYTE $▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/6/2009 3:15:05 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just a follow up on this. The problem runs much deeper in the underlying tools than I'd first realised, and is going to take quite some digging to solve (It's an issue with the interaction between GTK2 and X with the Lazarus framework and will only affect the linux builds).
In the mean time, heater has kindly pointed out that if this happens to you, you can use almost any alt-key combination to get control of the program back.
The issue is bst is seeing the alt-key-press, but when you hit tab it loses focus and misses the alt-key-up event so it thinks the alt key is locked down. A simple tap of the alt key will not solve this. You need to use a key combination (I use alt-a here).
This is a very annoying bug and I'll get it fixed as soon as I can. Thanks for your patience.
I'd like to thank heater for his work in helping me reproduce and track this one down.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
*Peter*
Anyway that column select mode sort of works for me as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
I whinned before about the PropTool's inability to turn off the background colors - so when you print right from the tool, it looks like toner poopy.
[noparse][[/noparse]Yes, before anyone says it --- I know I can cut-paste to other editors. But that's work the computer is supposed to do for me [noparse]:)[/noparse] ]
I ask you because you're very responsive to our suggestions and feedback (whereas the prop tool folks probably have more pressing matters).
Print stuff's pretty easy in Win, bet it's a tad messy in GTK/Lazarus.
You might be surprised at how many of us would like this feature ... because of the number of us who are both lazy and whimpy of vision [noparse];)[/noparse]
thanks much for your time!
Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I must say, from time to time, I do miss being able to print a file onto 2 or 3 meters of that fan fold paper with green stripes and then be able to stand back and comprehend the structure of the code a a larger scale.
Often, with just seeing my programs in editor windows, I feel like I'm painting a room through the key hole.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Printing is one of those painful parts of cross-platform apps. Each platform has its own printing API, and they are all completely different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
Well... if you ever get bored
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
But Brad I have a question regarding the documentation of BST, is there anything available? I was looking for conditional compilation and found these in the executable:
#DEFINE
#IFDEF
#IFNDEF
#ELSEIFDEF
#ELSEIFNDEF
#ELSE
#ENDIF
#UNDEF
#WARN
#INFO
#ERROR
Maybe even a summary of BST's features etc would be helpful.
*Peter*
You will find them in the changelog in the top post and in the posts back a few pages where their development was discussed.
also http://forums.parallax.com/showthread.php?p=804887 about half way down that page where they were announced.
www.fnarfbargle.com/features.html
Documentation is sparse to non existent at best.
I've been meaning to write a brief bit on some of the extra bits and pieces, but other things keep getting in the way (like putting food on the table).
I'll have a crack at writing up some of the less obvious stuff when I get a moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
BTW, when I said summary of features I should have been more specific and mentioned a summary of the directives and their usage perhaps.
*Peter*
$ iconv -f UTF-8 -t US-ASCII -o temp sdspiqasm.spin
iconv: illegal input sequence at position 341
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks heater, I appreciate that. On it [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Opening and saving a file with tabs seems to work, but they still behave as spaces when using the arrow keys, and if you accidentally type in one it seems to shunt your typed text about in interesting ways.
Aside from that, I really like bst. I use windows, and I can tell you that I much prefer your software over the propeller tool for one giant reason... Tabs! The propeller tool refuses to use them, and replaces them with spaces when you import a file with them. It's a stupid little thing, but it drove me nuts.
Aside from that, I'd be awesome if there was an option to treat newlines normally, rather the way the prop tool does.
Edit: Oh, a little Bug (well, really more of an oversight). The popoup Windows (e.g. "Detected a Propeller Version:1", "Compiler Information" etc...) are not forced on top of the main window. Therefore, you can wind up stuck if you select the main window, as it is disabled, but gets placed above the popup window anyways. The only way out is alt+tab. It should be possible to set any alert windows to be always on top (I'm only familliar with wxWindows).
Post Edited (Fake-Name) : 7/11/2009 2:24:32 PM GMT
The way it's done now is a bit of an inheritance of the way the ide has been developed over its 9 month life span (has it really been that long already?). I really need to sit down and define how it needs to work and properly re-build the tab code.
bst is *supposed* to convert tabs to spaces the same way the propeller tool does. It does it "good enough", but I guess it does not do things right. Question is, what is actually the right way to behave?
The window modality is an interesting one, and not one I've actually seen in use (probably because I don't actually use windows, I just boot a VM periodically to test basic bst functionality). I will try and get it sorted though.
Can you elaborate on the "newlines" thing? I'm not adverse to making changes, I'm just not sure what you mean here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
A thought on recurring questions about features, documentation etc.
Maybe the use of a specific and unique keyword dropped into any post that includes things the user may want to research later until and if there is anything written. Then the user can search for the unique keyword in the search tool, and not have to read through the numerous pages. An awkward solution but may help.
The thing is the forums search tool doesn't seem to work well, but the google based search tool may work after some period of time (day or two?)
Post Edited (TChapman) : 7/11/2009 4:16:45 PM GMT
I know, and I hate it for that. It would be awesome if there was an option to treat \t characters as \t characters, with NO conversion at all. When you hit the tab button, insert a \t character, and treat it as a single entity, rather than a composite of spaces.
Basically, in every editor I have experience with, if you scroll past the end of the line (to the right) using arrow keys, etc... the cursor wraps to the beginning of the next line. Similarly, if you click in the empty space to the right of a line, the cursor is placed at the end of that line. Currently, it's placed directly at the mouse pointer, as iff all the white space to the right of every line is full of space characters.
Basically, I'd prefer if the editor behaved like Windows Notepad/GEdit/Every other text editor.
I'm a bit mystified that the people behind the propeller tool decided to have their IDE behave differently than pretty much every other IDE/text editor on the planet.
Post Edited (Fake-Name) : 7/12/2009 8:34:04 AM GMT
Problem.. again, variable tab stops. How do you make it work? At the moment if the next tab stop is 3 characters away, when you hit the tab key you get three spaces. You can't have variable tab stops that match the propeller tool (which I actually quite like) and also have valid hard tab characters.
Did you know that bst has three different ways of handling tabs?
a) Smart tabs - Cute but sometimes annoying
b) Fixed tabs like every other editor (but with a configurable tab stop - this can confuse the compiler if you are not careful and its not set to 8) - This does what you are asking above
c) Parallax style variable tabs
This is configurable in the IDE options.
Right. How about a compromise. I *like* the ability to be able to click out in no-mans-land and start typing without having to space/tab my way out there. What about if I were to set it up so it linewraps like other editors when using the cursor keys back and forwards. But if you want to "get out there" you can click the mouse there and just start typing?
I don't want to add yet another option, but I kinda like the functionality in the compromise. (Read that as I've just made it work that way and I don't want to go adding extra configuration options)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Ok, this is not a bug in bst. There is nothing wrong with that UTF-8 sequence. The issue is iconv is trying to convert from UTF-8 to US-ASCII and 341 is the first character it comes across that is not translatable into the ASCII character set (Its the first line in the schematic). iconv is simply complaining that it does not know how to produce an output in US-ASCII for that particular character. (The error message could use some improvement/clarification I grant you, but as it was written by Ulrich Drepper it's hardly a surprise)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Looking at iconv harder I see it can be persuaded to replace the untranslatable chars with something it thinks might be similar:
iconv -f UTF-8 -t US-ASCII//TRANSLIT -o temp sdspiqasm.spin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Nah, it's all good. In the least, I learned about a tool I'd never known about before [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Also what about adding Alt-F, etc. functionality to access menu items. I miss that from bst.