gas-mode.el - Comments welcome

gas-mode.el - Comments welcome

[Heike C. Zimmerer]

A few days ago, I have posted gas-mode.el, a mode to edit assembly
language files, to gnu.emacs.sources.  I once started out to write
this code since I was not satisfied with the current asm-mode.  At
some later point I decided it could be of general interest and made it
ready for a first release.

Richard then contacted me, asking about the whys and hows, and a few
e-mails later we agreed to make it a replacement for the current
asm-mode.el.

It is now time time to check it out in order to make it ready for
inclusion with GNU Emacs.  So I'm asking you for comments.  If you do
assembly language programming, you could try it out.  If you know
someone who might be interested, you could make him aware of it.
Also, since Lisp is not the language I usually do much programming in,
tips, hints and comments on coding style and conformance to coding
conventions are welcome.

The name `gas-mode' is somewhat misleading; it is no more specific to
the GNU gas assembler as the current asm-mode is (we'll change the
name to `asm-mode' later).  For users of asm-mode, a switch to
gas-mode should go rather smoothly (and you get extra features like
code beautifying, paragraph-filling which is sensitive to the kind of
comment you're in, limited support for embedded C-declarations meant
for automatic export into .h files, symbol highlighting and jumping
between matching definitions and references - all that at no extra
cost ...).  There might be one exception however: cases where the
comment character differs from the standard value (?\;) are not yet
tested; here I could use some helping hands and some real world
examples which work or don't work yet.

The documentation: Until now, there's only the existing doc written
for asm-mode, the mode-specific help (C-h m) of gas-mode, and the
Commentary: part at the beginning of gas-mode.el.  Some help from
proofreaders will be required when more doc evolves since English is
not my native language.

I've put up a web page for the distribution of updated versions.
You'll always find the most recent version at

   http.//www.hczim.de/software/gas-mode.html

I'll post a message pointing there in gnu.emacs.sources - not for each
update, but when major changes become available.  There's already a
new version there.  The main difference to the one posted in
gnu.emacs.sources is that the doc strings and some commentaries have
been polished.  Also a bug (you're not very likely to stumble upon)
has been fixed.  For testing how it works, the already posted code is
sufficient.  If you'd like to have a look at the internals, I
recommend downloading the new version.

- Heike

Re: gas-mode.el - Comments welcome

[Masatake YAMATO]

(Is it ready to discuss new future:-P)

> A few days ago, I have posted gas-mode.el, a mode to edit assembly
> language files, to gnu.emacs.sources.  I once started out to write
> this code since I was not satisfied with the current asm-mode.  

Me, too.  My interests are comment char and font-locking.

Which architecture are you targeting on? i386?
If you are interested in multiple architecture support, please look at 
my old post and rms's comment.

- http://lists.gnu.org/archive/html/emacs-devel/2006-06/msg00321.html
- http://lists.gnu.org/archive/html/emacs-devel/2006-06/msg00343.html

gdb-ui.el could show disassembled code. If gas-mode can supports
font-locking well on multiple architectures' assembly code, 
gas-mode's font-locking code can be applied to gdb-ui.el.


Masatake YAMATO

Re: gas-mode.el - Comments welcome

[Heike C. Zimmerer]

Masatake YAMATO <jet@gyve.org> writes:

> Which architecture are you targeting on? i386?

It is not bound to a specific architecture (there are just too many of
them).  Checking of opcodes or even arguments is IMHO better done by
the assembler.  However, it would be no big deal to highlight specific
opcodes (the code is already there and used to recognize asm
directives) or even to check for the correct number of arguments (the
current parser returns the number of arguments).

I've postponed this idea, since I feel it wouldn't buy much for me.
Once you're accustomed to the instruction set (and I've seen a lot of
exotic ones), getting opcode and number of arguments correct is not
something that IMHO justifies another level of highlighting (I don't
think the more's the better when it comes to it).

I see that it might, however, be a coding aid for the occasional
programmer and for beginners, so if there's enough interest in it, it
can be done, preferably by reading the instruction set from some
external configuration file.

For now, we should stick with the present features and make sure they
work rock solid.

> gdb-ui.el could show disassembled code. If gas-mode can supports
> font-locking well on multiple architectures' assembly code, 
> gas-mode's font-locking code can be applied to gdb-ui.el.

That would be no big deal.  gas-mode can parse any standard assembler
line and return its syntactic fields, including positional
information.  Let's focus on that later.

- Heike

Re: gas-mode.el - Comments welcome

[Stefan Monnier]

> It is now time time to check it out in order to make it ready for
> inclusion with GNU Emacs.  So I'm asking you for comments.  If you do
> assembly language programming, you could try it out.  If you know
> someone who might be interested, you could make him aware of it.
> Also, since Lisp is not the language I usually do much programming in,
> tips, hints and comments on coding style and conformance to coding
> conventions are welcome.

I don't do much asm programming (just enough to prompt me to slightly revise
asm-mode.el's indentation a few years while back), but here are some
comments:
- when you define faces used for font-locking, try to make them inherit from
  font-lock's default faces.  I personally hate color-based highlighting and
  use font-based highlighting instead, and every mode which redefines its
  own set of faces is just a pain in the <beep>, unless it does it by
  inheriting from the default faces.
- I'd use word and symbol syntaxes instead of `gas-re-sym' and friends.
  I.e. instead of (skip-chars-forward gas-skip-sym), I'd use
  (skip-syntax-forward "w_") and I'd use "\\_>" and "\\_<" for symbol
  boundaries instead of gas-re-nosym.
- it seems that comment-start, comment-start-skip, comment-end,
  comment-end-skip are not defined.
- try C-u M-x checkdoc-current-buffer RET
  It'll complain about things which you may rightfully decide to leave
  unchanged, but it will also complain about some cosmetic things which you
  need to fix, e.g. the first line should have 3 semi-colons rather than 2.
  It may also tell you to use names such as "*-flag" for boolean vars, with
  which I completely disagree.
- add some ;;;###autoload cookies (at least one for the major mode).
- fix naming to use the `gas-' (or `asm-') prefix for vars such as
  `line-cache'.  Provide defvars with docstring explaning what
  they contain.
- gas-change-comment-string seems not to be used.
- your syntax-table also accepts comments of the form //...\n although this
  seems to be mentioned nowhere.  Is it done on purpose or is it
  an oversight?
- not sure if I like the "use forward-sexp to jump to next occurrence of
  highlighted symbol".  In conjunction with C-M-t for example, this is odd.
  The intention of forwrd-sexp-function is to allow the use of elisp code
  when the syntax-table isn't flexible enough to describe some "sexps"
  (e.g. sexps like "begin ... end").  If you want to extend the semantics of
  C-M-f (rather than forward-sexp which may very well be called
  non-interactively by other pieces of Elisp code) then rebind this
  key sequence.
- The docstring of gas-mode says that gas-comment calls comment-dwim, but
  I don't see where that happens.  Also its description of comment-dwim
  doesn't quite match my understanding of it.  AFAIK it doesn't treat
  "comment with leading white space" specially and it doesn't remove
  comments unless provided with a C-u prefix.
- Try to present it as a patch to asm-mode.el (this one does set
  comment-start and friends, so the patch would make it trivial to see that
  this part was incorrectly removed).


        Stefan

Re: gas-mode.el - Comments welcome

[Masatake YAMATO]

Hi,

> > Which architecture are you targeting on? i386?
> 
> It is not bound to a specific architecture (there are just too many of
> them).  Checking of opcodes or even arguments is IMHO better done by
> the assembler.  However, it would be no big deal to highlight specific
> opcodes (the code is already there and used to recognize asm
> directives) or even to check for the correct number of arguments (the
> current parser returns the number of arguments).
> 
> I've postponed this idea, since I feel it wouldn't buy much for me.
> Once you're accustomed to the instruction set (and I've seen a lot of
> exotic ones), getting opcode and number of arguments correct is not
> something that IMHO justifies another level of highlighting (I don't
> think the more's the better when it comes to it).
> 
> I see that it might, however, be a coding aid for the occasional
> programmer and for beginners, so if there's enough interest in it, it
> can be done, preferably by reading the instruction set from some
> external configuration file.

Sorry. My statement in the last mail leads the discussion wrong way.
My interest is highlight register notation, literal notation and
comments. My interest is not highlight specific opcodes.
register notation, literal notation and comments are depends on 
architectures.

> For now, we should stick with the present features and make sure they
> work rock solid.

I see.

BTW, 

I've tried the latest version(1.08).
`indent-for-tab-command' reports "-: Wrong type argument: number-or-marker-p, nil"
with following line:

.type __kernel_sigreturn,@function

Re: gas-mode.el - Comments welcome

[Heike C. Zimmerer]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> - when you define faces used for font-locking, try to make them inherit from
>   font-lock's default faces.  I personally hate color-based highlighting and
>   use font-based highlighting instead, and every mode which redefines its
>   own set of faces is just a pain in the <beep>, unless it does it by
>   inheriting from the default faces.

They lack the inherit.  Will be corrected.

> - I'd use word and symbol syntaxes instead of `gas-re-sym' and friends.
>   I.e. instead of (skip-chars-forward gas-skip-sym), I'd use
>   (skip-syntax-forward "w_") and I'd use "\\_>" and "\\_<" for symbol
>   boundaries instead of gas-re-nosym.

There's a comment at the start of gas-parse-comment-really which
explains why I prefer regexp over syntax tables.

> - it seems that comment-start, comment-start-skip, comment-end,
>   comment-end-skip are not defined.

Not sure where what they would be needed for.  I'm providing my own
fill functions.  Did I overlook anything?

> - try C-u M-x checkdoc-current-buffer RET
>   It'll complain about things which you may rightfully decide to leave
>   unchanged, but it will also complain about some cosmetic things which you
>   need to fix, e.g. the first line should have 3 semi-colons rather than 2.
>   It may also tell you to use names such as "*-flag" for boolean vars, with
>   which I completely disagree.

Yes.  Didn't do that.

> - add some ;;;###autoload cookies (at least one for the major mode).

Yes.

> - fix naming to use the `gas-' (or `asm-') prefix for vars such as
>   `line-cache'.  Provide defvars with docstring explaning what
>   they contain.

The caches are always buffer-local.  According to what I learned from
the documentation, the prefix is only required for globals.  I
sometimes even deliberately removed the prefix from symbols to
emphasize on its local binding (as here).  Anything wrong with it?

> - gas-change-comment-string seems not to be used.

The ultimate word on it is not spoken yet; changing the comment
character is not yet tested.

> - your syntax-table also accepts comments of the form //...\n although this
>   seems to be mentioned nowhere.  Is it done on purpose or is it
>   an oversight?

Purpose.  asm-mode has it too, gas accepts it.

> - not sure if I like the "use forward-sexp to jump to next occurrence of
>   highlighted symbol".  In conjunction with C-M-t for example, this is odd.
>   The intention of forwrd-sexp-function is to allow the use of elisp code
>   when the syntax-table isn't flexible enough to describe some "sexps"
>   (e.g. sexps like "begin ... end").  If you want to extend the semantics of
>   C-M-f (rather than forward-sexp which may very well be called
>   non-interactively by other pieces of Elisp code) then rebind this
>   key sequence.

The idea why I didn't bind it to a key directly is that I wanted it to
show up wherever the user has bound a syntax-based jump to.
forward-sexp seemed the nearest match.  I'm not too lucky with it, but
couldn't come up with a better key used for a similar purpose in other
programming modes.  As to transpose-sexps (C-M-t), I did not check
this at all, since I didn't get the idea why anybody would try that in
an asm context.  I'll check it to make sure it at least does no harm.

> - The docstring of gas-mode says that gas-comment calls comment-dwim, but
>   I don't see where that happens.

OK.  Will be changed (either the docstring or the binding).

>   Also its description of comment-dwim doesn't quite match my
>   understanding of it.  AFAIK it doesn't treat "comment with leading
>   white space" specially and it doesn't remove comments unless
>   provided with a C-u prefix.

For the latter, it does.  That's part of the 'dwim'.  For the former,
it means that it tries to remove only the kind of comment point is on,
leaving the others untouched.  There are different kinds of comments,
starting in different columns, thus the 'leading white space'.  I
don't know of an other programming mode which has this distinction so
I cannot say how it treats it.

> - Try to present it as a patch to asm-mode.el (this one does set
>   comment-start and friends, so the patch would make it trivial to see that
>   this part was incorrectly removed).

This would remove about all and replace it by a different thing.  It's
not by accident or incorrectly that any part has been removed.  It's
not been removed, but rewritten without it.  There are left-overs from
asm-mode in it and I tried to use its terminology where appropriate,
since that was where I once started from, but I doubt there are many.

- Heike

Re: gas-mode.el - Comments welcome

[David Kastrup]

"Heike C. Zimmerer" <nospam07q1@gmx.net> writes:

>> - fix naming to use the `gas-' (or `asm-') prefix for vars such as
>>   `line-cache'.  Provide defvars with docstring explaning what
>>   they contain.
>
> The caches are always buffer-local.  According to what I learned
> from the documentation, the prefix is only required for globals.

Buffer-local variables have global bindings (they don't go away after
a function finishes).  You are confusing them with let-bound
variables.

> I sometimes even deliberately removed the prefix from symbols to
> emphasize on its local binding (as here).  Anything wrong with it?

Yes.  Conflict with similarly named variables elsewhere.

-- 
David Kastrup

Re: gas-mode.el - Comments welcome

[Heike C. Zimmerer]

David Kastrup <dak@gnu.org> writes:

> "Heike C. Zimmerer" <nospam07q1@gmx.net> writes:
>
>>> - fix naming to use the `gas-' (or `asm-') prefix for vars such as
>>>   `line-cache'.  Provide defvars with docstring explaning what
>>>   they contain.
>>
>> The caches are always buffer-local.  According to what I learned
>> from the documentation, the prefix is only required for globals.
>
> Buffer-local variables have global bindings (they don't go away after
> a function finishes).  You are confusing them with let-bound
> variables.

I see.  OK, I'll fix it.

Re: gas-mode.el - Comments welcome

[Stefan Monnier]

>> - it seems that comment-start, comment-start-skip, comment-end,
>> comment-end-skip are not defined.

> Not sure where what they would be needed for.  I'm providing my own
> fill functions.  Did I overlook anything?

It's used by all the functions in newcomment.el, including comment-dwim.
What do you gain by not defining them?

>> - not sure if I like the "use forward-sexp to jump to next occurrence of
>> highlighted symbol".  In conjunction with C-M-t for example, this is odd.
>> The intention of forwrd-sexp-function is to allow the use of elisp code
>> when the syntax-table isn't flexible enough to describe some "sexps"
>> (e.g. sexps like "begin ... end").  If you want to extend the semantics of
>> C-M-f (rather than forward-sexp which may very well be called
>> non-interactively by other pieces of Elisp code) then rebind this
>> key sequence.

> The idea why I didn't bind it to a key directly is that I wanted it to
> show up wherever the user has bound a syntax-based jump to.
> forward-sexp seemed the nearest match.

I still don't understand.  If you don't want to hard code C-M-f but just use
whichever binding the user has chosen for forward-sexp, then just use
substitute-key-definition?

>> Also its description of comment-dwim doesn't quite match my
>> understanding of it.  AFAIK it doesn't treat "comment with leading
>> white space" specially and it doesn't remove comments unless
>> provided with a C-u prefix.

> For the latter, it does.  That's part of the 'dwim'.

I wrote comment-dwim, so I'm surprised.  In which case exactly does
comment-dwim remove comments without providing it with a C-u prefix?
Unless maybe you mean "uncomment" instead of "remove comment" (but the two
are very different).

> For the former, it means that it tries to remove only the kind of comment
> point is on, leaving the others untouched.  There are different kinds of
> comments, starting in different columns, thus the 'leading white space'.
> I don't know of an other programming mode which has this distinction so
> I cannot say how it treats it.

Without even defining comment-start and other such variables, I'm really
surprised that comment-dwim would do all that.  And even if you define it,
I can't see how/where this happens, because I never thought of such
features (which doesn't mean that there might be clever ways to use the
command which I hadn't thought of).  But also as a user I don't understand
what that means.


        Stefan

Re: gas-mode.el - Comments welcome

[Johan Bockgård]

"Heike C. Zimmerer" <nospam07q1@gmx.net> writes:

> tips, hints and comments on coding style and conformance to coding
> conventions are welcome.

    [...]
    (beginning-of-buffer)      

"Don't use this command in Lisp programs!
(goto-char (point-min)) is faster and avoids clobbering the mark."

Re: gas-mode.el - Comments welcome

[Heike C. Zimmerer]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> "Heike C. Zimmerer" <nospam07q1@gmx.net> writes:
>
>> tips, hints and comments on coding style and conformance to coding
>> conventions are welcome.
>
>     [...]
>     (beginning-of-buffer)      
>
> "Don't use this command in Lisp programs!
> (goto-char (point-min)) is faster and avoids clobbering the mark."

Done.

- Heike

Re: gas-mode.el - Comments welcome

[Dan Nicolaescu]

"Heike C. Zimmerer" <nospam07q1@gmx.net> writes:

  > A few days ago, I have posted gas-mode.el, a mode to edit assembly
  > language files, to gnu.emacs.sources.  I once started out to write
  > this code since I was not satisfied with the current asm-mode.  At
  > some later point I decided it could be of general interest and made it
  > ready for a first release.
  > 
  > Richard then contacted me, asking about the whys and hows, and a few
  > e-mails later we agreed to make it a replacement for the current
  > asm-mode.el.
  > 
  > It is now time time to check it out in order to make it ready for
  > inclusion with GNU Emacs.  So I'm asking you for comments.  If you do
  > assembly language programming, you could try it out.  If you know
  > someone who might be interested, you could make him aware of it.
  > Also, since Lisp is not the language I usually do much programming in,
  > tips, hints and comments on coding style and conformance to coding
  > conventions are welcome.

Any updates on this?  It looked very promising ...