Re: please explain diff bet. K&R and Linux c-mode styles

Re: please explain diff bet. K&R and Linux c-mode styles

[Matt Armstrong]

In article <mailman.1035590178.16479.help-gnu-emacs@gnu.org>,
seberino@spawar.navy.mil wrote:
> Linux kernel docs recommend K&R c-mode style...
> 
> then what is "Linux c-mode style"?? How is it different?

C-h v c-style-alist

That'll show you all the styles in their gory detail.



-- 
matt

Re: please explain diff bet. K&R and Linux c-mode styles

[seberino]

I tried your command... there was no function or
variable called c-style-alist in Emacs. :(

CS

On Fri, Oct 25, 2002 at 09:26:16PM -0600, Matt Armstrong wrote:
> In article <mailman.1035590178.16479.help-gnu-emacs@gnu.org>,
> seberino@spawar.navy.mil wrote:
> > Linux kernel docs recommend K&R c-mode style...
> > 
> > then what is "Linux c-mode style"?? How is it different?
> 
> C-h v c-style-alist
> 
> That'll show you all the styles in their gory detail.
> 
> 
> 
> -- 
> matt
> _______________________________________________
> Help-gnu-emacs mailing list
> Help-gnu-emacs@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-gnu-emacs

-- 
_______________________________________

Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
49590 Lassing Road, Room A339
San Diego, CA 92152-6147
U.S.A.

Phone: (619) 553-7940
Fax:   (619) 553-1269
Email: seberino@spawar.navy.mil
_______________________________________

Re: please explain diff bet. K&R and Linux c-mode styles

[Edgar Antonio Luna Díaz]

seberino@spawar.navy.mil writes:

> I tried your command... there was no function or
> variable called c-style-alist in Emacs. :(
Being in a cc-mode buffer?

-- 
Edgar Antonio Luna Díaz - http://www.gnulinux.org.mx
Key Fingerprint=C008 5EAC 5272 AC8C 7589  4821 8B34 6166 8733 8310

Re: please explain diff bet. K&R and Linux c-mode styles

[Kevin Dziulko]

I don't see a c-style-alist either.  Check out
http://www.science.uva.nl/~mes/jargon/i/indentstyle.html
I think Linux style is the same as GNU style. You could
also just type in a few functions and see the fundamental
differences.


On Mon, 28 Oct 2002 seberino@spawar.navy.mil wrote:

> I tried your command... there was no function or
> variable called c-style-alist in Emacs. :(
>
> CS
>
> On Fri, Oct 25, 2002 at 09:26:16PM -0600, Matt Armstrong wrote:
> > In article <mailman.1035590178.16479.help-gnu-emacs@gnu.org>,
> > seberino@spawar.navy.mil wrote:
> > > Linux kernel docs recommend K&R c-mode style...
> > >
> > > then what is "Linux c-mode style"?? How is it different?
> >
> > C-h v c-style-alist
> >
> > That'll show you all the styles in their gory detail.
> >
> >
> >
> > --
> > matt
> > _______________________________________________
> > Help-gnu-emacs mailing list
> > Help-gnu-emacs@gnu.org
> > http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
>
>

Re: please explain diff bet. K&R and Linux c-mode styles

[Alfred M. Szmidt]

   I think Linux style is the same as GNU style. You could
   also just type in a few functions and see the fundamental
   differences.

Linux style and GNU style are completely different.  The coding style
that is used in Linux looks similar to K&R.  The main difference
between Linux and K&R style is that Linux uses TAB characters to
indent where as K&R uses four spaces.  

The GNU Coding Standard describes the GNU style
(http://www.gnu.org/pre/standards.html), and the file
Documentation/CodingStyle in the source code for Linux described the
Linux style.

if statements:
GNU style          Linux style         K&R style

if (foobar)        if (foobar) {       if (foobar) {
  {                        foo;            foo;
    foo;           }                   }
  }


functions:
GNU style         Linux style          K&R style

int
foobar (void)     int foobar (void)    int foobar (void)
{                 {                    {
  return 1;               return 1;        return 1;
}                 }                    }

Emacs Lisp: Problem with nested condition-case and catch in byte compiled code

[Greg Hill]

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

This one has me stumped.

Here is my source code:

-----------------------------------------------------------------------------
(defun cctest ()
   (interactive)
   (catch 'cctest
     (message "before condition-case in catch, (interactive-p) = %s"
	     (interactive-p))
     (condition-case nil
	(message "inside condition-case in catch, (interactive-p) = %s"
		(interactive-p))
       (error nil))
     (message "after condition-case in catch, (interactive-p) = %s"
	     (interactive-p)))

   (message "before condition-case after catch, (interactive-p) = %s"
	   (interactive-p))
   (condition-case nil
       (message "inside condition-case after catch, (interactive-p) = %s"
	       (interactive-p))
     (error nil))
   (message "after condition-case after catch, (interactive-p) = %s"
	   (interactive-p))

   (condition-case nil
       (progn
	(message "before catch in condition-case, (interactive-p) = %s"
		(interactive-p))
	(catch 'cctest
	  (message "inside catch in condition-case, (interactive-p) = %s"
		   (interactive-p)))
	(message "after catch in condition-case, (interactive-p) = %s"
		(interactive-p)))
     (error nil)))
----------------------------------------------------------------------------


If I load the .el source file and execute cctest interactively, I get:

-------------------------------------------------------
before condition-case in catch, (interactive-p) = t
inside condition-case in catch, (interactive-p) = t
after condition-case in catch, (interactive-p) = t
before condition-case after catch, (interactive-p) = t
inside condition-case after catch, (interactive-p) = t
after condition-case after catch, (interactive-p) = t
before catch in condition-case, (interactive-p) = t
inside catch in condition-case, (interactive-p) = t
after catch in condition-case, (interactive-p) = t
-------------------------------------------------------


If I byte compile, load the .elc, and execute cctest interactively, I get:

-------------------------------------------------------
before condition-case in catch, (interactive-p) = t
inside condition-case in catch, (interactive-p) = nil
after condition-case in catch, (interactive-p) = t
before condition-case after catch, (interactive-p) = t
inside condition-case after catch, (interactive-p) = t
after condition-case after catch, (interactive-p) = t
before catch in condition-case, (interactive-p) = t
inside catch in condition-case, (interactive-p) = nil
after catch in condition-case, (interactive-p) = t
-------------------------------------------------------


There seems to be something special about a call to (interactive-p) 
inside a condition-case inside a catch, or inside a catch inside a 
condition-case, in byte-compiled code.  But for the life of me I 
can't imagine what that could be.  Anybody have any ideas?

--Greg

[-- Attachment #2: Type: text/html, Size: 4947 bytes --]

Re: Emacs Lisp: Problem with nested condition-case and catch in byte compiled code

[Greg Hill]

[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]

A bit more experimentation shows that nesting a catch inside a catch 
or a condition-case inside a condition-case causes the same problem.

I'm beginning to think I must have stumbled across a bug in either 
the byte compiler or the byte-code interpreter.

--Greg

At 6:54 PM -0800 11/14/02, Greg Hill wrote:
>This one has me stumped.
>
>Here is my source code:
>
>-----------------------------------------------------------------------------
>(defun cctest ()
>   (interactive)
>   (catch 'cctest
>     (message "before condition-case in catch, (interactive-p) = %s"
>	     (interactive-p))
>     (condition-case nil
>	(message "inside condition-case in catch, (interactive-p) = %s"
>		(interactive-p))
>       (error nil))
>     (message "after condition-case in catch, (interactive-p) = %s"
>	     (interactive-p)))
>
>   (message "before condition-case after catch, (interactive-p) = %s"
>	   (interactive-p))
>   (condition-case nil
>       (message "inside condition-case after catch, (interactive-p) = %s"
>	       (interactive-p))
>     (error nil))
>   (message "after condition-case after catch, (interactive-p) = %s"
>	   (interactive-p))
>
>   (condition-case nil
>       (progn
>	(message "before catch in condition-case, (interactive-p) = %s"
>		(interactive-p))
>	(catch 'cctest
>	  (message "inside catch in condition-case, (interactive-p) = %s"
>		   (interactive-p)))
>	(message "after catch in condition-case, (interactive-p) = %s"
>		(interactive-p)))
>     (error nil)))
>----------------------------------------------------------------------------
>
>
>If I load the .el source file and execute cctest interactively, I get:
>
>-------------------------------------------------------
>before condition-case in catch, (interactive-p) = t
>inside condition-case in catch, (interactive-p) = t
>after condition-case in catch, (interactive-p) = t
>before condition-case after catch, (interactive-p) = t
>inside condition-case after catch, (interactive-p) = t
>after condition-case after catch, (interactive-p) = t
>before catch in condition-case, (interactive-p) = t
>inside catch in condition-case, (interactive-p) = t
>after catch in condition-case, (interactive-p) = t
>-------------------------------------------------------
>
>
>If I byte compile, load the .elc, and execute cctest interactively, I get:
>
>-------------------------------------------------------
>before condition-case in catch, (interactive-p) = t
>inside condition-case in catch, (interactive-p) = nil
>after condition-case in catch, (interactive-p) = t
>before condition-case after catch, (interactive-p) = t
>inside condition-case after catch, (interactive-p) = t
>after condition-case after catch, (interactive-p) = t
>before catch in condition-case, (interactive-p) = t
>inside catch in condition-case, (interactive-p) = nil
>after catch in condition-case, (interactive-p) = t
>-------------------------------------------------------
>
>
>There seems to be something special about a call to (interactive-p) 
>inside a condition-case inside a catch, or inside a catch inside a 
>condition-case, in byte-compiled code.  But for the life of me I 
>can't imagine what that could be.  Anybody have any ideas?
>
>--Greg

[-- Attachment #2: Type: text/html, Size: 6165 bytes --]

Re: Emacs Lisp: Problem with nested condition-case and catch in byte compiled code

[Stefan Monnier <foo@acm.com>]

>>>>> "Greg" == Greg Hill <ghill@synergymicro.com> writes:
> A bit more experimentation shows that nesting a catch inside a catch or
> a condition-case inside a condition-case causes the same problem.
> I'm beginning to think I must have stumbled across a bug in either the byte
> compiler or the byte-code interpreter.

Or more likely in the `interactive-p' function which does a lot of ad-hoc
parsing of the call-stack and is thus susceptible to funny things.


        Stefan

Re: Emacs Lisp: Problem with nested condition-case and catch in byte compiled code

[Greg Hill]

Stefan,

As you surmised, it turned out to be a bug in the interactive-p 
function, where it checks to see whether it is executing 
byte-compiled code.  I submitted a formal bug report, and Richard 
Stallman promptly sent me a patch that fixes the problem.  I assume 
that when he is entirely comfortable with it, he will make the patch 
generally available.

--Greg

At 7:08 PM -0500 11/18/02, Stefan Monnier <foo@acm.com wrote:
>  >>>>> "Greg" == Greg Hill <ghill@synergymicro.com> writes:
>>  A bit more experimentation shows that nesting a catch inside a catch or
>>  a condition-case inside a condition-case causes the same problem.
>>  I'm beginning to think I must have stumbled across a bug in either the byte
>>  compiler or the byte-code interpreter.
>
>Or more likely in the `interactive-p' function which does a lot of ad-hoc
>parsing of the call-stack and is thus susceptible to funny things.
>
>
>         Stefan
>
>_______________________________________________
>Help-gnu-emacs mailing list
>Help-gnu-emacs@gnu.org
>http://mail.gnu.org/mailman/listinfo/help-gnu-emacs

Lisp: Functions for multiple comparisons

[Greg Hill]

I am aware of the built-in functions memq and member.  But what I 
really want is a pair of special forms that work more like 'or and 
'and.  The first argument would be compared against all of the rest 
using either 'eq or 'equal, returning 't if any match was found.

For example, a special form using an 'eq comarison might be named 
'meq and be called like:

	(meq (char-syntax (following-char)) ?w ?_)

instead of using

	(memq (char-syntax (following-char) '(?w ?_)))
or
	(or (eq (char-syntax (following-char)) ?w) (eq (char-syntax 
(following-char)) ?_))
or
	(let ((syntax (char-syntax (following-char)))) (or (eq syntax 
?w) (eq syntax ?_)))

Is there already something like that that I simply am not yet aware 
of?  If not, am I wrong in thinking that the kind of special forms I 
am imagining would be computationally more efficient than any of the 
alternatives shown above?

--Greg

Re: Lisp: Functions for multiple comparisons

[Stefan Monnier <foo@acm.com>]

>>>>> "Greg" == Greg Hill <ghill@synergymicro.com> writes:
> 	(meq (char-syntax (following-char)) ?w ?_)
> instead of using
> 	(memq (char-syntax (following-char) '(?w ?_)))

memq is pretty fast given the general slowness of the elisp interpreter.
If you really care about the few extra chars, then you can of course do

   (defun meq (x &rest xs) (memq x xs))

although I honestly don't see the point.


        Stefan

Re: Lisp: Functions for multiple comparisons

[Pascal Bourguignon]

"Stefan Monnier <foo@acm.com>" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

> >>>>> "Greg" == Greg Hill <ghill@synergymicro.com> writes:
> > 	(meq (char-syntax (following-char)) ?w ?_)
> > instead of using
> > 	(memq (char-syntax (following-char) '(?w ?_)))
> 
> memq is pretty fast given the general slowness of the elisp interpreter.
> If you really care about the few extra chars, then you can of course do
> 
>    (defun meq (x &rest xs) (memq x xs))
> 
> although I honestly don't see the point.
> 
> 
>         Stefan

Perhaps avoiding cutting too much:

Greg Hill <ghill@synergymicro.com> writes:

> I am aware of the built-in functions memq and member.  But what I
> really want is a pair of special forms that work more like 'or and
> 'and.  The first argument would be compared against all of the rest
> using either 'eq or 'equal, returning 't if any match was found.

So, Greg  wants a special form like  'or or 'and.  That  is, with lazy
evaluation of the remaining arguments!

(defmacro meq (key &rest values)
  `(let ((meq_key    ,key)
         (meq_values ',values))
    (while (and meq_values (not (eq meq_key (eval (car meq_values)))))
      (setq meq_values (cdr meq_values)))
    meq_values))

(show (macroexpand (quote (meq 12  (+ 9 1) (+ 10 2) (length (make-vector 1e9)) 13))))

==> (let ((meq_key 12) (meq_values (quote ((+ 9 1) (+ 10 2) (length (make-vector 1000000000.0)) 13)))) (while (and meq_values (not (eq meq_key (eval (car meq_values))))) (setq meq_values (cdr meq_values))) meq_values)

(show (meq 12  (+ 9 1) (+ 10 2) (length (make-vector 1e9)) 13))

==> ((+ 10 2) (length (make-vector 1000000000.0)) 13)


But of course, it you only  use lists of constants like '(?w ?_), it's
better to use memq which is a primitive.
 
> For example, a special form using an 'eq comarison might be named 'meq
> and be called like:
> 
> 	(meq (char-syntax (following-char)) ?w ?_)
> 
> instead of using
> 
> 	(memq (char-syntax (following-char) '(?w ?_)))
> or
> 	(or (eq (char-syntax (following-char)) ?w) (eq (char-syntax
> (following-char)) ?_))
> or
> 	(let ((syntax (char-syntax (following-char)))) (or (eq syntax ?w)
> (eq syntax ?_)))
> 
> Is there already something like that that I simply am not yet aware
> of?  If not, am I wrong in thinking that the kind of special forms I
> am imagining would be computationally more efficient than any of the
> alternatives shown above?
> 
> --Greg


-- 
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him.  -- Robert Heinlein

Index of element in a sequence

[Greg Hill]

Are there any built-in functions that provide the equivalent of the 
following lisp routines?

(defun indq (value seq)
   "Return the index number of VALUE in sequence SEQ, using eq for test.
Return nil if VALUE does not exist in SEQ."
   (let ((ix 0) (len (length seq)))
     (catch 'indq
       (while (< ix len)
	(if (eq (elt seq ix) value)
	    (throw 'indq ix)
	  (setq ix (1+ ix)) ) ) ) ))


(defun index (value seq)
   "Return the index number of VALUE in sequence SEQ, using equal for test.
Return nil if VALUE does not exist in SEQ."
   (let ((ix 0) (len (length seq)))
     (catch 'index
       (while (< ix len)
	(if (equal (elt seq ix) value)
	    (throw 'index ix)
	  (setq ix (1+ ix)) ) ) ) ))

--Greg

Re: Index of element in a sequence

[Barry Margolin]

In article <mailman.1038424169.3933.help-gnu-emacs@gnu.org>,
Greg Hill  <ghill@synergymicro.com> wrote:
>Are there any built-in functions that provide the equivalent of the 
>following lisp routines?

The 'position' function can be loaded with (require 'cl).

-- 
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.