A true challenge for Emac and Elisp hackers - at Least I think so

A true challenge for Emac and Elisp hackers - at Least I think so

[Sune]

Hi all!

After having had dozens of null pointer exceptions thrown at me, I
decided to give up on the much hyped Eclipse CDT 3.0 and switch to
Emacs. Emacs seems to be configurable down to its atoms and I don't
have to wait for the screen to update while I type (which is eh...
nice). Basically, Emacs makes me more productive.

After starting to write some C-programs I quickly realized what I
wanted Emacs to do for me and added Elisp code into .emacs until I was
closed to being satisfied.

This is how far I've come:

Editor
- GNU coding guidelines enforced
- keyboard shortcuts to almost anything including features listed below
- nice functions like untabify-and-reindent, kill buffer of choice,
keyboard macros
etc etc

CVS
- Integrated in menu system to a satisfactory level + keyboard
shortcuts

Make
- Completely intergrated in menu system + keyboard shortcuts +
integrated with error look up in files
etc etc

But now the shit hits the fan! I want the following, but I have no clue
as to how I should even start:

The whole idea is this: I want to add debug trace with as little effort
as possible into my source.

1)
What is listed below is valid for all .c files. Not .h files!
2)
I want RET, the enter key, to trig the following behaviour:

   * If I hit RET with any shift-key being pressed
     simultaneously, RET must behave as any
     normal RET would (basically a normal
     linefeed with possible auto-indentation).
     This may seem backward but I want almost
     every line in my sorce to be traceable.

   * If I hit RET only, and the following applies:

       - It is preceeded by a ';' (semicolon) AND the
         word 'return' is not part of the current
         line or:

       - It is preceeded by a '{' (curly bracket)

     RET adds DBG after the ';' or the '{' with a
     space in between like so:

     ; DBG
     { DBG

     respectively. After that (the same key stroke)
     , RET behaves like a normal RET would (basically
     a normal linefeed with possible auto-indentation).

I have to admit that this is so far out there (at least for me) that I
would need more or less a ready-to-go implementation just to paste into
.emacs.

Do you know a place where something similar has been done which I can
steal and adapt, or are you interested in implementing it? (A place on
my tomb stone is reserved for anyone that succeeds in doing this)

Otherwise I will go back to crap Eclipse, wait for it to stabilize and
implement a plugin - that stuff I know. I just don't want to give up on
Emacs!!

Truckloads of thanks
/Sune

A true challenge for Emac and Elisp hackers - at Least I think so

[Gian Uberto Lauri]

>>>>> "S" == Sune  <sune_ahlgren@hotmail.com> writes:

S>    * If I hit RET with any shift-key being pressed simultaneously,
S> RET must behave as any normal RET would (basically a normal
S> linefeed with possible auto-indentation).  This may seem backward
S> but I want almost every line in my sorce to be traceable.

S>    * If I hit RET only, and the following applies:

S>        - It is preceeded by a ';' (semicolon) AND the word 'return'
S> is not part of the current line or:

S>        - It is preceeded by a '{' (curly bracket)

S>      RET adds DBG after the ';' or the '{' with a space in between
S> like so:

S>      ; DBG { DBG


S>      respectively. After that (the same key stroke) , RET behaves
S> like a normal RET would (basically a normal linefeed with possible
S> auto-indentation).

S> I have to admit that this is so far out there (at least for me)
S> that I would need more or less a ready-to-go implementation just to
S> paste into .emacs.

Does this help ?

(defun unusual-return ()
  (interactive)
  (save-excursion)
  (let ((here (point))
	(previous-char (char-before)))
    (beginning-of-line)
    (cond ((string-match "DGB[ \\t]*$"
			 (buffer-substring (point) here))
	   (goto-char here)
	   (newline-and-indent))
	  ((or (char-equal previous-char ?{)
	       (char-equal previous-char ?\;))
	   (goto-char here)
	   (insert " DBG"))
	  (t
	   (goto-char here)
	   (newline-and-indent)))))

You  then add  an  hook to  c-mode  a little  function  that does  the
following:

    tests that the buffer name does  end by .c 

    locally sets RET to the function above (or a better one, this is a
    5 minutes game result)

    locally sets S-RET, C-RET and M-RET to newline-and-indent

-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Slawomir Nowaczyk]

On Wed, 12 Oct 2005 04:48:25 -0700
Sune <sune_ahlgren@hotmail.com> wrote:

#> I have to admit that this is so far out there (at least for me) that I
#> would need more or less a ready-to-go implementation just to paste into
#> .emacs.

I don't think this is too far away for you :) Anyway, I somehow expect
somebody on this list to provide a more-or-less complete solution, but
the thing you should ultimately do is:

1) Learn basics of Lisp (and really, all you need here is the basics)

2) Write a function which does what you want and bind it to RET key
      *) the function should check if buffer name ends with *.c
      *) the function should get current line contents (think of
         functions buffer-substring, point, beginning-of-line, etc.)
      *) compare it with what do you want (string-match maybe?)
      *) either insert "\n" or "; DBG\n"

   And also, try "C-h i C-s elisp RET" :)

3) And that's it :)

No, seriously, after you are done with the above come back with your
solution and somebody will certainly provide you with a lot of
hints... but you will at least understand what is going on :)

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

I'd love to change the world, but they won't give me the source code!

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Matthieu Moy]

Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:

> 2) Write a function which does what you want and bind it to RET key
>       *) the function should check if buffer name ends with *.c

Better: bind this function only in c-mode and c++-mode. No test needed
in the command itself.

  C-h v c++-mode-map RET
  C-h v c-mode-map RET

>       *) the function should get current line contents (think of
>          functions buffer-substring, point, beginning-of-line, etc.)

and C-h f looking-at RET. You don't even need to get it in a string.

(if (save-excursion
      (beginning-of-line)
      (looking-at ".*return;")) ; adapt ...
  ...
...)

>       *) compare it with what do you want (string-match maybe?)
>       *) either insert "\n" or "; DBG\n"
>
>    And also, try "C-h i C-s elisp RET" :)

C-h i m eli TAB RET ;-).

-- 
Matthieu

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Pascal Bourguignon]

"Sune" <sune_ahlgren@hotmail.com> writes:
> 1)
> What is listed below is valid for all .c files. Not .h files!
> 2)
> I want RET, the enter key, to trig the following behaviour:
>
>    * If I hit RET with any shift-key being pressed
>      simultaneously, RET must behave as any
>      normal RET would (basically a normal
>      linefeed with possible auto-indentation).
>      This may seem backward but I want almost
>      every line in my sorce to be traceable.
>
>    * If I hit RET only, and the following applies:
>
>        - It is preceeded by a ';' (semicolon) AND the
>          word 'return' is not part of the current
>          line or:
>
>        - It is preceeded by a '{' (curly bracket)
>
>      RET adds DBG after the ';' or the '{' with a
>      space in between like so:
>
>      ; DBG
>      { DBG
>
>      respectively. After that (the same key stroke)
>      , RET behaves like a normal RET would (basically
>      a normal linefeed with possible auto-indentation).
>
> I have to admit that this is so far out there (at least for me) that I
> would need more or less a ready-to-go implementation just to paste into
> .emacs.

This is not a challenge, this is trivial.


(defvar *c-trace-code* " DBG;\n")

(defun c-after (regexp)
  (save-excursion
    (backward-char)
    (while (and (< (point-min) (point)) (looking-at "[\t\n ]"))
      (backward-char))
    (looking-at regexp)))

(defun insert-return-and-trace ()
  (interactive)
    (if (c-after "[{;]")
        (insert *c-trace-code*)
        (insert "\n"))
    (c-indent-command))

(add-hook 'c-mode-hook
          (lambda ()
            (unless (string-match "\\.h$" (buffer-name))
                (local-set-key [return]   (function insert-return-and-trace))
                (local-set-key [S-return] (function newline)))))



> Do you know a place where something similar has been done which I can
> steal and adapt, or are you interested in implementing it? (A place on
> my tomb stone is reserved for anyone that succeeds in doing this)

(info "elisp")


-- 
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Slawomir Nowaczyk]

On Wed, 12 Oct 2005 15:29:54 +0200
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote:

#> Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
#> 
#> > 2) Write a function which does what you want and bind it to RET key
#> >       *) the function should check if buffer name ends with *.c
#> 
#> Better: bind this function only in c-mode and c++-mode. No test needed
#> in the command itself.

Well, my system reports c++-mode for *.h files as well. Original
poster specifically asked the function to apply to *.c files only.

#> >       *) the function should get current line contents (think of
#> >          functions buffer-substring, point, beginning-of-line, etc.)
#> 
#> and C-h f looking-at RET. You don't even need to get it in a string.

docstring for looking-at suggests it looks at text after point, while
the needed one seems to be before the point. Sure you can move to the
beginning of line first, but then I fail to see the benefit...

#> (if (save-excursion
#>       (beginning-of-line)
#>       (looking-at ".*return;")) ; adapt ...
#>   ...
#> ...)

(if (string-match ".*return;"
        (buffer-substring (line-beginning-position) (point)))
     ...
 ...)

Well, OK, your version is shorter :)

#> >    And also, try "C-h i C-s elisp RET" :)

#> C-h i m eli TAB RET ;-).

Ah, yes, I always forget this one... Thanks :)

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

The greatest enemy of a good plan is the dream of a perfect plan.

RE: A true challenge for Emac and Elisp hackers - at Least I think so

[Drew Adams]

    Emacs seems to be configurable down to its atoms

Down to its strings, actually.

No, way beyond that even - far on beyond zebracs, down to its very emarcs,
the fundamental building blocks of all becoming, in the wholly Narrowed
Region that quivers and spits between the transient Mark of being and the
pointless Point of nothingness.

`C-ohm-m-m-m' (an oxymoron, of course)

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Giorgos Keramidas]

Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
> On Wed, 12 Oct 2005 15:29:54 +0200
> Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote:
> #> Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
> #>
> #> > 2) Write a function which does what you want and bind it to RET key
> #> >       *) the function should check if buffer name ends with *.c
> #>
> #> Better: bind this function only in c-mode and c++-mode. No test needed
> #> in the command itself.
>
> Well, my system reports c++-mode for *.h files as well. Original
> poster specifically asked the function to apply to *.c files only.

That was probably a mis-statement of the original poster's intent,
since it's not unheard of to have macros with real C or C++ code in
header files too :)

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Chris McMahan]

Ahh functional specs... :)

- Chris

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
>> On Wed, 12 Oct 2005 15:29:54 +0200
>> Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote:
>> #> Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
>> #>
>> #> > 2) Write a function which does what you want and bind it to RET key
>> #> >       *) the function should check if buffer name ends with *.c
>> #>
>> #> Better: bind this function only in c-mode and c++-mode. No test needed
>> #> in the command itself.
>>
>> Well, my system reports c++-mode for *.h files as well. Original
>> poster specifically asked the function to apply to *.c files only.
>
> That was probably a mis-statement of the original poster's intent,
> since it's not unheard of to have macros with real C or C++ code in
> header files too :)
>

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Thien-Thi Nguyen]

"Sune" <sune_ahlgren@hotmail.com> writes:

> I just don't want to give up
> on Emacs!!

i'm sure emacs won't mind if you "implement a plugin" for it,
although you might want to phrase it a little differently...

thi

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Sune]

Thien-Thi Nguyen skrev:

> "Sune" <sune_ahlgren@hotmail.com> writes:
>
> > I just don't want to give up
> > on Emacs!!
>
> i'm sure emacs won't mind if you "implement a plugin" for it,
> although you might want to phrase it a little differently...
> 
> thi

Yeah, but I don't think a Java plugin will do...

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Joe Corneli]

   Thien-Thi Nguyen skrev:

   > "Sune" <sune_ahlgren@hotmail.com> writes:
   >
   > > I just don't want to give up
   > > on Emacs!!
   >
   > i'm sure emacs won't mind if you "implement a plugin" for it,
   > although you might want to phrase it a little differently...
   > 
   > thi

   Yeah, but I don't think a Java plugin will do...


If you feel you need java to do something this easy, maybe you've
already given up.  However, I suppose the (much more complicated)
problem of using java as an extension language for Emacs has been
considered by some people... you could, er, look into it.

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Sune]

Thien-Thi Nguyen skrev:

> "Sune" <sune_ahlgren@hotmail.com> writes:
>
> > I just don't want to give up
> > on Emacs!!
>
> i'm sure emacs won't mind if you "implement a plugin" for it,
> although you might want to phrase it a little differently...
> 
> thi

Yeah, but I think emacs would mind a Java plugin...

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Sune]

> This is not a challenge, this is trivial.

Well, for you perhaps. Nevertheless I appreciate your effort. I've
tested it and it works fine.

Thanks a lot Pascal!

> i'm sure emacs won't mind if you "implement a plugin" for it,
> although you might want to phrase it a little differently...

Thi, I do emacs would mind a Java plugin regardless of name...

/Sune

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Thien-Thi Nguyen]

"Sune" <sune_ahlgren@hotmail.com> writes:

> Thi, I do emacs would mind a Java plugin regardless of name...

the name of the thing is not the thing.

thi

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Sune]

Hi!

> This is not a challenge, this is trivial.
Well, for you perhaps  ;)  Anyway, it worked just the way I hoped for.
Thanks Pascal.

> i'm sure emacs won't mind if you "implement a plugin" for it,
> although you might want to phrase it a little differently...
Thanks for the pointless remark thi. I think Emacs would mind a plugin
written in Java...

BRs
Sune

Re: A true challenge for Emac and Elisp hackers - at Least I think so

[Thien-Thi Nguyen]

"Sune" <sune_ahlgren@hotmail.com> writes:

> Thanks for the pointless remark thi.

i'm just trying to hint to hackers looking for hacks on a possibly
enjoyable SMOP.  let's hope someone hears this and helps you and me
both, in the long run.  then, we will know the point has been made.

thi