[PATCH, RFA] Fix formatting for event-top.h

[PATCH, RFA] Fix formatting for event-top.h

[Mark Kettenis]

While lacking some inspiration while writing about free electrons in a
magnetic field (the subject of my thesis) I fixed some formatting
mistakes in event-top.h.  OK to check the attached patch in?

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* event-top.h: Fix formatting.

Index: event-top.h
===================================================================
RCS file: /cvs/src/src/gdb/event-top.h,v
retrieving revision 1.2
diff -u -r1.2 event-top.h
--- event-top.h 2001/02/08 05:06:13 1.2
+++ event-top.h 2001/04/20 10:27:56
@@ -19,36 +19,36 @@
    Foundation, Inc., 59 Temple Place - Suite 330,
    Boston, MA 02111-1307, USA.  */
 
-/* Stack for prompts. Each prompt is composed as a prefix, a prompt
-   and a suffix. The prompt to be displayed at any given time is the
+/* Stack for prompts.  Each prompt is composed as a prefix, a prompt
+   and a suffix.  The prompt to be displayed at any given time is the
    one on top of the stack.  A stack is necessary because of cases in
    which the execution of a gdb command requires further input from
    the user, like for instance 'commands' for breakpoints and
-   'actions' for tracepoints. In these cases, the prompt is '>' and
+   'actions' for tracepoints.  In these cases, the prompt is '>' and
    gdb should process input using the asynchronous readline interface
    and the event loop.  In order to achieve this, we need to save
    somewhere the state of GDB, i.e. that it is processing user input
    as part of a command and not as part of the top level command loop.
-   The prompt stack represents part of the saved state. Another part
+   The prompt stack represents part of the saved state.  Another part
    would be the function that readline would invoke after a whole line
-   of input has ben entered. This second piece would be something
+   of input has ben entered.  This second piece would be something
    like, for instance, where to return within the code for the actions
    commands after a line has been read.  This latter portion has not
    beeen implemented yet.  The need for a 3-part prompt arises from
-   the annotation level. When this is set to 2, the prompt is actually
-   composed of a prefix, the prompt itself and a suffix. */
+   the annotation level.  When this is set to 2, the prompt is
+   actually composed of a prefix, the prompt itself and a suffix.  */
 
 /* At any particular time there will be always at least one prompt on
-   the stack, the one being currently displayed by gdb. If gdb is
+   the stack, the one being currently displayed by gdb.  If gdb is
    using annotation level equal 2, there will be 2 prompts on the
    stack: the usual one, w/o prefix and suffix (at top - 1), and the
-   'composite' one with prefix and suffix added (at top). At this
-   time, this is the only use of the prompt stack. Resetting annotate
+   'composite' one with prefix and suffix added (at top).  At this
+   time, this is the only use of the prompt stack.  Resetting annotate
    to 0 or 1, pops the top of the stack, resetting its size to one
-   element. The MAXPROMPTS limit is safe, for now. Once other cases
+   element.  The MAXPROMPTS limit is safe, for now.  Once other cases
    are dealt with (like the different prompts used for 'commands' or
    'actions') this array implementation of the prompt stack may have
-   to change. */
+   to change.  */
 
 #define MAXPROMPTS 10
 struct prompts
@@ -68,13 +68,16 @@
 #define SUFFIX(X) the_prompts.prompt_stack[the_prompts.top + X].suffix
 
 /* Exported functions from event-top.c. 
-   FIXME: these should really go into top.h. */
+   FIXME: these should really go into top.h.  */
 
 extern void display_gdb_prompt (char *new_prompt);
 extern void async_init_signals (void);
-extern void set_async_editing_command (char *args, int from_tty, struct cmd_list_element *c);
-extern void set_async_annotation_level (char *args, int from_tty, struct cmd_list_element *c);
-extern void set_async_prompt (char *args, int from_tty, struct cmd_list_element *c);
+extern void set_async_editing_command (char *args, int from_tty,
+				       struct cmd_list_element *c);
+extern void set_async_annotation_level (char *args, int from_tty,
+					struct cmd_list_element *c);
+extern void set_async_prompt (char *args, int from_tty,
+			      struct cmd_list_element *c);
 
 /* Signal to catch ^Z typed while reading a command: SIGTSTP or SIGCONT.  */
 #ifndef STOP_SIGNAL
@@ -95,7 +98,7 @@
 extern void async_enable_stdin (void *dummy);
 
 /* Exported variables from event-top.c.
-   FIXME: these should really go into top.h. */
+   FIXME: these should really go into top.h.  */
 
 extern int async_command_editing_p;
 extern int exec_done_display_p;

Re: [PATCH, RFA] Fix formatting for event-top.h

[Elena Zannoni]

Mark Kettenis writes:
 > While lacking some inspiration while writing about free electrons in a
 > magnetic field (the subject of my thesis) I fixed some formatting
 > mistakes in event-top.h.  OK to check the attached patch in?
 > 
 > Mark
 > 

Sure, thanks. Except I like better functions declarations on just one
line, so I can see all the parameters when I do a grep, but maybe this
is not compliant with the general rule? A quick look shows that I am
probably wrong. 
So I think it's ok to check this in.

Elena


 > 
 > Index: ChangeLog
 > from  Mark Kettenis  <kettenis@gnu.org>
 > 
 > 	* event-top.h: Fix formatting.
 > 
 > Index: event-top.h
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/event-top.h,v
 > retrieving revision 1.2
 > diff -u -r1.2 event-top.h
 > --- event-top.h 2001/02/08 05:06:13 1.2
 > +++ event-top.h 2001/04/20 10:27:56
 > @@ -19,36 +19,36 @@
 >     Foundation, Inc., 59 Temple Place - Suite 330,
 >     Boston, MA 02111-1307, USA.  */
 >  
 > -/* Stack for prompts. Each prompt is composed as a prefix, a prompt
 > -   and a suffix. The prompt to be displayed at any given time is the
 > +/* Stack for prompts.  Each prompt is composed as a prefix, a prompt
 > +   and a suffix.  The prompt to be displayed at any given time is the
 >     one on top of the stack.  A stack is necessary because of cases in
 >     which the execution of a gdb command requires further input from
 >     the user, like for instance 'commands' for breakpoints and
 > -   'actions' for tracepoints. In these cases, the prompt is '>' and
 > +   'actions' for tracepoints.  In these cases, the prompt is '>' and
 >     gdb should process input using the asynchronous readline interface
 >     and the event loop.  In order to achieve this, we need to save
 >     somewhere the state of GDB, i.e. that it is processing user input
 >     as part of a command and not as part of the top level command loop.
 > -   The prompt stack represents part of the saved state. Another part
 > +   The prompt stack represents part of the saved state.  Another part
 >     would be the function that readline would invoke after a whole line
 > -   of input has ben entered. This second piece would be something
 > +   of input has ben entered.  This second piece would be something
 >     like, for instance, where to return within the code for the actions
 >     commands after a line has been read.  This latter portion has not
 >     beeen implemented yet.  The need for a 3-part prompt arises from
 > -   the annotation level. When this is set to 2, the prompt is actually
 > -   composed of a prefix, the prompt itself and a suffix. */
 > +   the annotation level.  When this is set to 2, the prompt is
 > +   actually composed of a prefix, the prompt itself and a suffix.  */
 >  
 >  /* At any particular time there will be always at least one prompt on
 > -   the stack, the one being currently displayed by gdb. If gdb is
 > +   the stack, the one being currently displayed by gdb.  If gdb is
 >     using annotation level equal 2, there will be 2 prompts on the
 >     stack: the usual one, w/o prefix and suffix (at top - 1), and the
 > -   'composite' one with prefix and suffix added (at top). At this
 > -   time, this is the only use of the prompt stack. Resetting annotate
 > +   'composite' one with prefix and suffix added (at top).  At this
 > +   time, this is the only use of the prompt stack.  Resetting annotate
 >     to 0 or 1, pops the top of the stack, resetting its size to one
 > -   element. The MAXPROMPTS limit is safe, for now. Once other cases
 > +   element.  The MAXPROMPTS limit is safe, for now.  Once other cases
 >     are dealt with (like the different prompts used for 'commands' or
 >     'actions') this array implementation of the prompt stack may have
 > -   to change. */
 > +   to change.  */
 >  
 >  #define MAXPROMPTS 10
 >  struct prompts
 > @@ -68,13 +68,16 @@
 >  #define SUFFIX(X) the_prompts.prompt_stack[the_prompts.top + X].suffix
 >  
 >  /* Exported functions from event-top.c. 
 > -   FIXME: these should really go into top.h. */
 > +   FIXME: these should really go into top.h.  */
 >  
 >  extern void display_gdb_prompt (char *new_prompt);
 >  extern void async_init_signals (void);
 > -extern void set_async_editing_command (char *args, int from_tty, struct cmd_list_element *c);
 > -extern void set_async_annotation_level (char *args, int from_tty, struct cmd_list_element *c);
 > -extern void set_async_prompt (char *args, int from_tty, struct cmd_list_element *c);
 > +extern void set_async_editing_command (char *args, int from_tty,
 > +				       struct cmd_list_element *c);
 > +extern void set_async_annotation_level (char *args, int from_tty,
 > +					struct cmd_list_element *c);
 > +extern void set_async_prompt (char *args, int from_tty,
 > +			      struct cmd_list_element *c);
 >  
 >  /* Signal to catch ^Z typed while reading a command: SIGTSTP or SIGCONT.  */
 >  #ifndef STOP_SIGNAL
 > @@ -95,7 +98,7 @@
 >  extern void async_enable_stdin (void *dummy);
 >  
 >  /* Exported variables from event-top.c.
 > -   FIXME: these should really go into top.h. */
 > +   FIXME: these should really go into top.h.  */
 >  
 >  extern int async_command_editing_p;
 >  extern int exec_done_display_p;
 > 

Re: [PATCH, RFA] Fix formatting for event-top.h

[Mark Kettenis]

   From: Elena Zannoni <ezannoni@cygnus.com>
   Date: Fri, 20 Apr 2001 10:13:26 -0400 (EDT)

   Mark Kettenis writes:
    > While lacking some inspiration while writing about free electrons in a
    > magnetic field (the subject of my thesis) I fixed some formatting
    > mistakes in event-top.h.  OK to check the attached patch in?
    > 
    > Mark
    > 

   Sure, thanks. Except I like better functions declarations on just one
   line, so I can see all the parameters when I do a grep, but maybe this
   is not compliant with the general rule? A quick look shows that I am
   probably wrong.

Hmm.  The GNU coding standards strongly suggest that one should break
parameter lists if they don't fit on a single line, at least for
function definitions.  Personally I find those long lines very
distracting when I'm using Emacs with 80 characters per line.  So I
checked it in :-).

Mark

Re: [PATCH, RFA] Fix formatting for event-top.h

[Michael Snyder]

Mark Kettenis wrote:
> 
>    From: Elena Zannoni <ezannoni@cygnus.com>
>    Date: Fri, 20 Apr 2001 10:13:26 -0400 (EDT)
> 
>    Mark Kettenis writes:
>     > While lacking some inspiration while writing about free electrons in a
>     > magnetic field (the subject of my thesis) I fixed some formatting
>     > mistakes in event-top.h.  OK to check the attached patch in?
>     >
>     > Mark
>     >
> 
>    Sure, thanks. Except I like better functions declarations on just one
>    line, so I can see all the parameters when I do a grep, but maybe this
>    is not compliant with the general rule? A quick look shows that I am
>    probably wrong.
> 
> Hmm.  The GNU coding standards strongly suggest that one should break
> parameter lists if they don't fit on a single line, at least for
> function definitions.  Personally I find those long lines very
> distracting when I'm using Emacs with 80 characters per line.  So I
> checked it in :-).

I agree with Mark, I like long lines to be broken at a logical point
and the sub-lines neatly indented (rather than wrapping around my 
screen at column 79 and beginning in column one).

Michael