Hi,
I was a little (perhaps not...) surprised to see that asm is the least supported language in plugins for vim or other "already there" editors. I found the SASM proposal quite good, as it removes the need to buy the elephant to use a plugin just for asm (talking in general), where existing.
I wrote this directly to Dman95, but I think could be interesting to expand here to share ideas an opinions. In assembler IDEs are not so used, but what is really missing is some clever clever editor to support the write to build part of the flow.
This is the simple toolkit I use for daily C++
vi + .vim_runtime
https://github.com/amix/vimrcastyle
It is not that much and simply supports some operations that make the daily life (before neatbeans or others) quite better.
--- write the code, with on inline formatting, as moving back and forth } as you pair something under indented statements or exit a block
--- snippets with snipmate, mainly, if not only, to add predefined types of formatted block of comments to give another better look to the whole stuff
--- make a consistent formatting up to the space with astyle to get a precise code style after a set and forget policies in a config.
In asm, while insight/gdb is there , there is no (or probably is some elephant) focused ide or let's say editor++(+) to cover at the best the write to build (included) gdb as part of the flow.
SASM could be a quite good candidate to cover this, as it is light, is focused on NASM, already has code highlighting, supports the build phase, gives access to gdb, that is full at power to direct use for direct queries.
Suppose to have an astyle similar button to format, an inline formatting of text, more than indentation, a multiple set of quick build commands (one for inserting -g -F and one for normal build, or make debug and simply make) as it is already, but with only one, and we could begin to have some quite quick predebug support get organized.
In summary, I would leave the gdb at the bottom, improving as much as one would, but in a "light operational" debug perspective (having all at finger does not necessarily increase the operational quality, that is why insight exists on top of the engine) , while would make what comes before the better possible experience, where there is lack in the field.
The basic layout of SASM is quite comfortable and if it offers agile support to this part of the job and links to the rest, there is no religious need to go on with gedit...
Thanks
Fabio D'Alfonso
