[Cocci] Unwanted space added at end of line

[Cocci] Unwanted space added at end of line

[Eric Leblond]

Hello,

I've just wrote a really simple SMPL (attached to the mail). It makes a
modification on the code which is the following:

- if (x == NULL) S1
+ if (unlikely(x == NULL)) S1

The result is semantically correct but there is spaces at end of line as
shown in the example below:

@@ -173,8 +173,8 @@ DefragContextNew(void)
     DefragContext *dc;
 
     dc = SCCalloc(1, sizeof(*dc));
-    if (dc == NULL)
-        return NULL;<- no space
+    if (unlikely(dc == NULL))
+        return NULL;   <- 4 space here 

I've tried to look@coccinelle code but I'm unable to find a way to a
solution.

Am I missing an option ?

BR,
--
Eric Leblond

-------------- next part --------------
@istested@
identifier x;
statement S1;
identifier func =~ "(SCMalloc|SCStrdup|SCCalloc)";
@@

x = func(...)
... when != x
- if (x == NULL) S1
+ if (unlikely(x == NULL)) S1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20120922/52ec3cfa/attachment.asc>

[Cocci] Unwanted space added at end of line

[Lars-Peter Clausen]

On 09/22/2012 10:29 AM, Eric Leblond wrote:
> Hello,
> 
> I've just wrote a really simple SMPL (attached to the mail). It makes a
> modification on the code which is the following:
> 
> - if (x == NULL) S1
> + if (unlikely(x == NULL)) S1
> 
> The result is semantically correct but there is spaces at end of line as
> shown in the example below:
> 
> @@ -173,8 +173,8 @@ DefragContextNew(void)
>      DefragContext *dc;
>  
>      dc = SCCalloc(1, sizeof(*dc));
> -    if (dc == NULL)
> -        return NULL;<- no space
> +    if (unlikely(dc == NULL))
> +        return NULL;   <- 4 space here 
> 
> I've tried to look at coccinelle code but I'm unable to find a way to a
> solution.

A simple solution is to take the statment out of the diff. It is generally a
good idea to try to minimize the parts which are removed in one line but added
back in the next line since everything in the plus part of the diff will be
send through the pretty printer which may cause the code to be re-formatted

E.g. in your case a minimized cocci patch could look like this:

if (
+unlikely(
 x == NULL
+)
 ) S1

- Lars

[Cocci] Unwanted space added at end of line

[Julia Lawall]

A proposed patch that fixes this and some other trailing whitespace 
problems is attached.  I still need to check that it does not break 
anything, so let me know if there are any new problems.

julia

On Sat, 22 Sep 2012, Eric Leblond wrote:

> Hello,
>
> I've just wrote a really simple SMPL (attached to the mail). It makes a
> modification on the code which is the following:
>
> - if (x == NULL) S1
> + if (unlikely(x == NULL)) S1
>
> The result is semantically correct but there is spaces at end of line as
> shown in the example below:
>
> @@ -173,8 +173,8 @@ DefragContextNew(void)
>     DefragContext *dc;
>
>     dc = SCCalloc(1, sizeof(*dc));
> -    if (dc == NULL)
> -        return NULL;<- no space
> +    if (unlikely(dc == NULL))
> +        return NULL;   <- 4 space here
>
> I've tried to look at coccinelle code but I'm unable to find a way to a
> solution.
>
> Am I missing an option ?
>
> BR,
> --
> Eric Leblond
>
>
-------------- next part --------------
diff --git a/coccinelle/unparse_c.ml b/coccinelle/unparse_c.ml
index e0938e4..1d8f0b7 100644
--- a/coccinelle/unparse_c.ml
+++ b/coccinelle/unparse_c.ml
@@ -333,7 +333,7 @@ let comment2t2 = function
       C2(info.Common.str)
   | (Token_c.TCommentCpp x,(info : Token_c.info)) ->
       C2("\n"^info.Common.str^"\n")
-  | x -> failwith (Printf.sprintf "unexpected comment %s" (Common.dump x))
+  | x -> failwith (Printf.sprintf "unexpected comment %s" (Dumper.dump x))
 
 let expand_mcode toks =
   let toks_out = ref [] in
@@ -396,7 +396,7 @@ let expand_mcode toks =
       |	Ast_c.FakeTok (s,_) ->
 	  push2 (C2 s) toks_out
       |	_ ->
-	  Printf.fprintf stderr "line: %s\n" (Common.dump info);
+	  Printf.fprintf stderr "line: %s\n" (Dumper.dump info);
 	  failwith "not an abstract line");
       (!(info.Ast_c.comments_tag)).Ast_c.mafter +>
       List.iter (fun x -> Common.push2 (comment2t2 x) toks_out) in
@@ -872,11 +872,12 @@ let paren_then_brace toks =
 	else x :: search_paren xs
     | x::xs -> x :: search_paren xs
   and search_plus xs =
-    let (spaces, rest) = Common.span is_whitespace xs in
+    let (spaces, rest) = Common.span is_space xs in
+    let (nls, rest) = Common.span is_newline rest in
     match rest with
       (* move the brace up to the previous line *)
       ((Cocci2("{",_,_,_,_)) as x) :: (((Cocci2 _) :: _) as rest) ->
-	(C2 " ") :: x :: spaces @ rest
+	spaces @ x :: nls @ rest
     | _ -> xs in
   search_paren toks
 
@@ -1163,13 +1164,15 @@ let rec adjust_indentation xs =
 	    _current_tabbing := tu::(!_current_tabbing);
 	     (* can't be C2, for later phases *)
 	     Cocci2 (tu,-1,-1,-1,None)::aux started xs)
-    | Unindent_cocci2(permanent)::xs ->
+    | Unindent_cocci2(permanent)::((Cocci2("\n",_,_,_,_)) as x)::xs ->
+	(* seems only relevant if there is a following cocci newline *)
 	(match !_current_tabbing with
 	  [] -> aux started xs
 	| _::new_tabbing ->
             let s = String.concat "" new_tabbing in
 	    _current_tabbing := new_tabbing;
-	    Cocci2 (s,-1,-1,-1,None)::aux started xs)
+	    x::Cocci2 (s,-1,-1,-1,None)::aux started xs)
+    | Unindent_cocci2(permanent)::xs -> aux started xs
     (* border between existing code and cocci code *)
     | ((T2 (tok,_,_)) as x)::((Cocci2("\n",_,_,_,_)) as y)::xs
       when str_of_token2 x =$= "{" ->

[Cocci] Unwanted space added at end of line

[Eric Leblond]

Hello,

Thanks a lot Julia for your fast and efficient answer !

Le samedi 22 septembre 2012 ? 19:08 +0200, Julia Lawall a ?crit :
> A proposed patch that fixes this and some other trailing whitespace 
> problems is attached.  I still need to check that it does not break 
> anything, so let me know if there are any new problems.

First of all, it fixes the whitespace issue described in my previous
mail.

I've runned all my cocci test with this patch applied and no problem
appears.

I've only one issue left regarding formatting but this is dependant of
my indentation style and can not be considered as a real problem. The
issue is that the transformation modifies my indentation like shows in
the following example:

-    if (new_pe == NULL) {
-        return NULL;
-    }
+    if (unlikely(new_pe == NULL))
+        {
+            return NULL;
+        }

I obtain a code which is not with the good coding style and need to be
reindented. Is there a way to specify to coccinelle we want to use a
specific model of indentation ?

BR,
> 
> julia
> 
> On Sat, 22 Sep 2012, Eric Leblond wrote:
> 
> > Hello,
> >
> > I've just wrote a really simple SMPL (attached to the mail). It makes a
> > modification on the code which is the following:
> >
> > - if (x == NULL) S1
> > + if (unlikely(x == NULL)) S1
> >
> > The result is semantically correct but there is spaces at end of line as
> > shown in the example below:
> >
> > @@ -173,8 +173,8 @@ DefragContextNew(void)
> >     DefragContext *dc;
> >
> >     dc = SCCalloc(1, sizeof(*dc));
> > -    if (dc == NULL)
> > -        return NULL;<- no space
> > +    if (unlikely(dc == NULL))
> > +        return NULL;   <- 4 space here
> >
> > I've tried to look at coccinelle code but I'm unable to find a way to a
> > solution.
> >
> > Am I missing an option ?
> >
> > BR,
> > --
> > Eric Leblond
> >
> >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20120923/84b5f167/attachment.asc>

[Cocci] Unwanted space added at end of line

[Julia Lawall]

On Sun, 23 Sep 2012, Eric Leblond wrote:

> Hello,
>
> Thanks a lot Julia for your fast and efficient answer !
>
> Le samedi 22 septembre 2012 ? 19:08 +0200, Julia Lawall a ?crit :
>> A proposed patch that fixes this and some other trailing whitespace
>> problems is attached.  I still need to check that it does not break
>> anything, so let me know if there are any new problems.
>
> First of all, it fixes the whitespace issue described in my previous
> mail.
>
> I've runned all my cocci test with this patch applied and no problem
> appears.
>
> I've only one issue left regarding formatting but this is dependant of
> my indentation style and can not be considered as a real problem. The
> issue is that the transformation modifies my indentation like shows in
> the following example:
>
> -    if (new_pe == NULL) {
> -        return NULL;
> -    }
> +    if (unlikely(new_pe == NULL))
> +        {
> +            return NULL;
> +        }
>
> I obtain a code which is not with the good coding style and need to be
> reindented. Is there a way to specify to coccinelle we want to use a
> specific model of indentation ?

To me, it looks like a bug, not a model of indentation.  It should have 
put the first { where it was before, and then everything would have been 
OK.  I'll take a look.

julia

[Cocci] Unwanted space added at end of line

[Julia Lawall]

A patch against rc15 is attached.

julia

On Sun, 23 Sep 2012, Eric Leblond wrote:

> Hello,
>
> Thanks a lot Julia for your fast and efficient answer !
>
> Le samedi 22 septembre 2012 ? 19:08 +0200, Julia Lawall a ?crit :
>> A proposed patch that fixes this and some other trailing whitespace
>> problems is attached.  I still need to check that it does not break
>> anything, so let me know if there are any new problems.
>
> First of all, it fixes the whitespace issue described in my previous
> mail.
>
> I've runned all my cocci test with this patch applied and no problem
> appears.
>
> I've only one issue left regarding formatting but this is dependant of
> my indentation style and can not be considered as a real problem. The
> issue is that the transformation modifies my indentation like shows in
> the following example:
>
> -    if (new_pe == NULL) {
> -        return NULL;
> -    }
> +    if (unlikely(new_pe == NULL))
> +        {
> +            return NULL;
> +        }
>
> I obtain a code which is not with the good coding style and need to be
> reindented. Is there a way to specify to coccinelle we want to use a
> specific model of indentation ?
>
> BR,
>>
>> julia
>>
>> On Sat, 22 Sep 2012, Eric Leblond wrote:
>>
>>> Hello,
>>>
>>> I've just wrote a really simple SMPL (attached to the mail). It makes a
>>> modification on the code which is the following:
>>>
>>> - if (x == NULL) S1
>>> + if (unlikely(x == NULL)) S1
>>>
>>> The result is semantically correct but there is spaces at end of line as
>>> shown in the example below:
>>>
>>> @@ -173,8 +173,8 @@ DefragContextNew(void)
>>>     DefragContext *dc;
>>>
>>>     dc = SCCalloc(1, sizeof(*dc));
>>> -    if (dc == NULL)
>>> -        return NULL;<- no space
>>> +    if (unlikely(dc == NULL))
>>> +        return NULL;   <- 4 space here
>>>
>>> I've tried to look at coccinelle code but I'm unable to find a way to a
>>> solution.
>>>
>>> Am I missing an option ?
>>>
>>> BR,
>>> --
>>> Eric Leblond
>>>
>>>
>
>
-------------- next part --------------
diff --git a/parsing_c/unparse_cocci.ml b/parsing_c/unparse_cocci.ml
index a3f9730..3ed2b0b 100644
--- a/parsing_c/unparse_cocci.ml
+++ b/parsing_c/unparse_cocci.ml
@@ -69,6 +69,12 @@ let print_option_prespace fn = function
   | Some x -> pr_space(); fn x in
 let print_between = Common.print_between in
 
+let rec param_print_between between fn = function
+  | [] -> ()
+  | [x] -> fn x
+  | x::xs -> fn x; between x; param_print_between between fn xs in
+
+
 let outdent _ = () (* should go to leftmost col, does nothing now *) in
 
 let pretty_print_c =
@@ -201,20 +207,24 @@ in
 
 (* --------------------------------------------------------------------- *)
 
-let handle_metavar name fn =
+let lookup_metavar name =
   let ((_,b) as s,info,mc,pos) = name in
   let line = info.Ast.line in
   let lcol = info.Ast.column in
-  match Common.optionise (fun () -> List.assoc s env) with
+  let rcol = if lcol = unknown then unknown else lcol + (String.length b) in
+  let res = Common.optionise (fun () -> List.assoc s env) in
+  (res,b,line,lcol,rcol) in
+
+let handle_metavar name fn =
+  let (res,name_string,line,lcol,rcol) = lookup_metavar name in
+  match res with
     None ->
-      let name_string (_,s) = s in
       if generating
-      then
-	mcode (function _ -> print_string (name_string s)) name
+      then mcode (function _ -> print_string name_string) name
       else
 	failwith
 	  (Printf.sprintf "SP line %d: Not found a value in env for: %s"
-	     line (name_string s))
+	     line name_string)
   | Some e  ->
       pr_barrier line lcol;
       (if generating
@@ -222,16 +232,14 @@ let handle_metavar name fn =
 	(* call mcode to preserve the -+ annotation *)
 	mcode (fun _ _ _ -> fn e) name
       else fn e);
-      let rcol =
-	if lcol = unknown then unknown else lcol + (String.length b) in
       pr_barrier line rcol
 in
 (* --------------------------------------------------------------------- *)
 let dots between fn d =
   match Ast.unwrap d with
-    Ast.DOTS(l) -> print_between between fn l
-  | Ast.CIRCLES(l) -> print_between between fn l
-  | Ast.STARS(l) -> print_between between fn l
+    Ast.DOTS(l) -> param_print_between between fn l
+  | Ast.CIRCLES(l) -> param_print_between between fn l
+  | Ast.STARS(l) -> param_print_between between fn l
 in
 
 let nest_dots starter ender fn f d =
@@ -593,18 +601,25 @@ and ty_space ty =
 and ft_space ty =
   match Ast.unwrap ty with
     Ast.Type(_,cv,ty) ->
-      (match Ast.unwrap ty with
-	Ast.Pointer(_,_) -> ()
-      | Ast.MetaType(name,_,_) ->
-	  (match List.assoc (Ast.unwrap_mcode name) env with
-            Ast_c.MetaTypeVal (tq,ty) ->
-	      (match Ast_c.unwrap ty with
-		Ast_c.Pointer(_,_) -> ()
-	      |	_ -> pr_space())
-	  | _ -> pr_space())
-      | _ -> pr_space())
+      let isptr =
+	match Ast.unwrap ty with
+	  Ast.Pointer(_,_) -> true
+	| Ast.MetaType(name,_,_) ->
+	    let (res,name_string,line,lcol,rcol) = lookup_metavar name in
+	    (match res with
+	      None ->
+		failwith
+		  (Printf.sprintf "variable %s not known on SP line %d\n"
+		     name_string line)
+	    | Some (Ast_c.MetaTypeVal (tq,ty)) ->
+		(match Ast_c.unwrap ty with
+		  Ast_c.Pointer(_,_) ->  true
+		| _ -> false)
+	    | _ -> false)
+	| _ -> false in
+      if isptr then () else pr_space()
   | _ -> pr_space()
-
+	
 and declaration d =
   match Ast.unwrap d with
     Ast.MetaDecl(name,_,_) ->
@@ -642,11 +657,11 @@ and declaration d =
       mcode print_string sem
   | Ast.MacroDecl(name,lp,args,rp,sem) ->
       ident name; mcode print_string_box lp;
-      dots (function _ -> ()) expression args;
+      dots (function _ -> ()) arg_expression args;
       close_box(); mcode print_string rp; mcode print_string sem
   | Ast.MacroDeclInit(name,lp,args,rp,eq,ini,sem) ->
       ident name; mcode print_string_box lp;
-      dots (function _ -> ()) expression args;
+      dots (function _ -> ()) arg_expression args;
       close_box(); mcode print_string rp;
       pr_space(); mcode print_string eq;
       pr_space(); initialiser true ini; mcode print_string sem
@@ -826,7 +841,7 @@ and rule_elem arity re =
   | Ast.IteratorHeader(nm,lp,args,rp) ->
       pr_arity arity;
       ident nm; pr_space(); mcode print_string_box lp;
-      dots (function _ -> ()) expression args; close_box();
+      dots (function _ -> ()) arg_expression args; close_box();
       mcode print_string rp
 
   | Ast.SwitchHeader(switch,lp,exp,rp) ->
@@ -914,11 +929,32 @@ and print_fninfo = function
   | Ast.FAttr(attr) -> mcode print_string attr; pr_space() in
 
 let indent_if_needed s f =
-  match Ast.unwrap s with
-    Ast.Seq(lbrace,body,rbrace) -> pr_space(); f()
-  | _ ->
+  let isseq =
+    match Ast.unwrap s with
+      Ast.Seq(lbrace,body,rbrace) -> true
+    | Ast.Atomic s ->
+	(match Ast.unwrap s with
+	| Ast.MetaStmt(name,_,_,_) ->
+	    let (res,name_string,line,lcol,rcol) = lookup_metavar name in
+	    (match res with
+	      None ->
+		failwith
+		  (Printf.sprintf "variable %s not known on SP line %d\n"
+		     name_string line)
+	    | Some (Ast_c.MetaStmtVal stm) ->
+		(match Ast_c.unwrap stm with
+		  Ast_c.Compound _ -> true
+		| _ -> false)
+	    | _ -> failwith "bad metavariable value")
+	| _ -> false)
+    | _ -> false in
+  if isseq
+  then begin pr_space(); f() end
+  else
+    begin
       (*no newline at the end - someone else will do that*)
-      start_block(); f(); unindent true in
+      start_block(); f(); unindent true
+    end in
 
 let rec statement arity s =
   match Ast.unwrap s with
@@ -1107,7 +1143,12 @@ let rec pp_any = function
 
   (* this is not '...', but a list of expr/statement/params, and
      normally there should be no '...' inside them *)
-  | Ast.ExprDotsTag(x) -> dots (function _ -> ()) expression x; false
+  | Ast.ExprDotsTag(x) ->
+      let check_comma cm =
+	match Ast.unwrap cm with
+	  Ast.EComma(cm) -> pr_space()
+	| _ -> () in
+      dots check_comma expression x; false
   | Ast.ParamDotsTag(x) -> parameter_list x; false
   | Ast.StmtDotsTag(x) -> dots force_newline (statement "") x; false
   | Ast.DeclDotsTag(x) -> dots force_newline declaration x; false

[Cocci] Unwanted space added at end of line

[Eric Leblond]

Hello,

Le dimanche 23 septembre 2012 ? 11:24 +0200, Julia Lawall a ?crit :
> A patch against rc15 is attached.

It works perfectly ! Thanks a lot!

My patch is clean and my coccinelle test are still running fine.

Not related to this discussion: is there a reason why there is no small
commits on github ? It could help people like me to understand how
things are working and help them to fix potential "small" issues.

BR,

> 
> julia
> 
> On Sun, 23 Sep 2012, Eric Leblond wrote:
> 
> > Hello,
> >
> > Thanks a lot Julia for your fast and efficient answer !
> >
> > Le samedi 22 septembre 2012 ? 19:08 +0200, Julia Lawall a ?crit :
> >> A proposed patch that fixes this and some other trailing whitespace
> >> problems is attached.  I still need to check that it does not break
> >> anything, so let me know if there are any new problems.
> >
> > First of all, it fixes the whitespace issue described in my previous
> > mail.
> >
> > I've runned all my cocci test with this patch applied and no problem
> > appears.
> >
> > I've only one issue left regarding formatting but this is dependant of
> > my indentation style and can not be considered as a real problem. The
> > issue is that the transformation modifies my indentation like shows in
> > the following example:
> >
> > -    if (new_pe == NULL) {
> > -        return NULL;
> > -    }
> > +    if (unlikely(new_pe == NULL))
> > +        {
> > +            return NULL;
> > +        }
> >
> > I obtain a code which is not with the good coding style and need to be
> > reindented. Is there a way to specify to coccinelle we want to use a
> > specific model of indentation ?
> >
> > BR,
> >>
> >> julia
> >>
> >> On Sat, 22 Sep 2012, Eric Leblond wrote:
> >>
> >>> Hello,
> >>>
> >>> I've just wrote a really simple SMPL (attached to the mail). It makes a
> >>> modification on the code which is the following:
> >>>
> >>> - if (x == NULL) S1
> >>> + if (unlikely(x == NULL)) S1
> >>>
> >>> The result is semantically correct but there is spaces at end of line as
> >>> shown in the example below:
> >>>
> >>> @@ -173,8 +173,8 @@ DefragContextNew(void)
> >>>     DefragContext *dc;
> >>>
> >>>     dc = SCCalloc(1, sizeof(*dc));
> >>> -    if (dc == NULL)
> >>> -        return NULL;<- no space
> >>> +    if (unlikely(dc == NULL))
> >>> +        return NULL;   <- 4 space here
> >>>
> >>> I've tried to look at coccinelle code but I'm unable to find a way to a
> >>> solution.
> >>>
> >>> Am I missing an option ?
> >>>
> >>> BR,
> >>> --
> >>> Eric Leblond
> >>>
> >>>
> >
> >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20120923/8c511d9c/attachment.asc>

[Cocci] Unwanted space added at end of line

[Julia Lawall]

On Sun, 23 Sep 2012, Eric Leblond wrote:

> Hello,
>
> Le dimanche 23 septembre 2012 ? 11:24 +0200, Julia Lawall a ?crit :
>> A patch against rc15 is attached.
>
> It works perfectly ! Thanks a lot!
>
> My patch is clean and my coccinelle test are still running fine.
>
> Not related to this discussion: is there a reason why there is no small
> commits on github ? It could help people like me to understand how
> things are working and help them to fix potential "small" issues.

Too complicated for my way of working.

julia

[Cocci] Clarification of work flows with content management systems

[SF Markus Elfring]

>
>> is there a reason why there is no small commits on github ?
>> It could help people like me to understand how
>> things are working and help them to fix potential "small" issues.
>
> Too complicated for my way of working.

I am curious to know a bit more about related issues. Can any versioning 
steps be improved here?

Regards,
Markus

[Cocci] Clarification of work flows with content management systems

[Jesper Louis Andersen]

On Sun, Sep 23, 2012 at 10:55 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:

> I am curious to know a bit more about related issues. Can any versioning
> steps be improved here?

No.

Let me explain why I think no:

I know scores of competent programmers. The basic rule is that all of
those competent people work in different ways. They use different
editors, often with different tab-settings. They write their code in
different indentation styles. Some are vi users, some use emacs and
some took upon the newest kids on the block: Sublime Text, TextMate,
Eclipse. And some use old archaic editors like sam(1) still. Their
workflow differ: some write code in the morning, where I am normally
happily in bed sleeping. Some write code late in the night. Some will
appear offline for weeks on end and then suddenly have a brilliant
patch for a part of the code you are working on. Others meticulously
track their record in many small patches. They work in different
revision control systems. Some like tea while others like coffee. And
so on.

You can't enforce people to work in a specific way. And you shouldn't
- it would be outright rude to tell people that their way of working
is less efficient than some other way of working. Furthermore, you
can't in general change the way a project is maintained and steered,
unless it is your own. The power of Open Source is that you are free
to fork the project, or to maintain a branch next to it with smaller
changes. Git even makes it so easy it is ridiculous.

But I have a strong opinion that the creator and maintainer of the
project rules how contributions should happen and how the project
should be maintained. Of course, there is a responsibility to this -
if the project is poorly maintained it is harder to succeed. If the
project is too poorly maintained, it will either die or be forked,
whichever comes first. And I have a strong opinion that as long as you
follow the basic rules laid down by the maintainer, you are free to
operate as you see fit in that framing. Be it choice of editor,
workflow or espresso-addiction.

You may of course suggest, with a proper argument, why a certain way
of working in the workflow is sub-optimal. But the opinion of the
benevolent dictator is always right. Or you have not read enough
Machiavelli :)


-- 
J.