Alan Mackenzie <acm@muc.de> writes:

> Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>
>> On 2022-04-13, Alan Mackenzie <acm@muc.de> wrote:

[...]

>>> Too many parentheses can make C code difficult to read. Difficult
>>> to read translates to "more bugs". A knowledge of C's precedence
>>> levels, at least to a moderate degree, can help avoid such bugs.

I definitely agree with this.

>> Too much complexity in one expression makes it hard to read.

I also agree with this.

>> Other
>> than breaking it up into smaller expression, what can help is to
>> split it into multiple lines and use indentation.

Sometimes, but rarely. In most cases another choice is better.

> This is a common attitude, and I'm sure it is wrong a lot of the time.
> Breaking up a complicated expression _fragments_ it - it spreads it over
> a greater number of source code lines, some of which may not be visible
> on the screen. While each fragment may in itself be easier to read, the
> entire expression has become more difficult.
>
>> Parenthesized expressions are much more amenable for splitting across
>> lines and indenting than pure infix operator expressions.

Yuck. Any expression complicated enough to need parentheses
_and_ multiple lines _and_ some indication of nesting merits
rewriting into simpler components.

> I'm not sure I agree with this, my background being the maintainer of
> Emacs's CC Mode.
>
> How about a real world example? In the following (from Emacs's
> syntax.c):
>
> if (code == Sendcomment
> && SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
> && (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
> (nesting > 0 && --nesting == 0) : nesting < 0)
> && !comment_ender_quoted (from, from_byte, syntax))
>
> , which is a moderately complicated example, extra parentheses around
> the operands of the &&s would clutter up the code rather than clarifying
> it. Yet the whole expression being on just five lines makes it
> relatively easy to understand.

I'm a longtime emacs user, and definitely a fan, but this code
is horrible, on several different levels. I agree that adding
extra parentheses around the &&s operands would make things
worse, but it's already way below threshold for any reasonable
standard of code review.

Just my unabashed impressions.. :)

On Monday, 25 April 2022 at 16:43:25 UTC+1, Vir Campestris wrote:
> On 25/04/2022 11:21, Alan Mackenzie wrote:
> > I think that is the best of all! Inserting brief, meaningful comments,
> > as above, makes the thing easy to understand without bloating the code.
> > I wish more people would code like this.
> Absolutely.
>
> It has the great advantage that the comments say what the code is
> _supposed_ to do. If they disagree that's a great big alarm bell to
> anyone looking for bugs.
>
> "self documenting code" doesn't do that.
>
However code tends to change over time. Since the compiler has no way
of understanding the comments, it can't warn when a comment is not
updated to reflect a change in the code.
If you have a "self-documenting" language or system, like Doxygen, which
ties comments to code features, then you can issue such warnings.

Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Alan Mackenzie <acm@muc.de> writes:

>> Kaz Kylheku <480-992-1380@kylheku.com> wrote:

>>> On 2022-04-13, Alan Mackenzie <acm@muc.de> wrote:

> [...]

>>>> Too many parentheses can make C code difficult to read. Difficult
>>>> to read translates to "more bugs". A knowledge of C's precedence
>>>> levels, at least to a moderate degree, can help avoid such bugs.

> I definitely agree with this.

>>> Too much complexity in one expression makes it hard to read.

> I also agree with this.

>>> Other
>>> than breaking it up into smaller expression, what can help is to
>>> split it into multiple lines and use indentation.

> Sometimes, but rarely. In most cases another choice is better.

>> This is a common attitude, and I'm sure it is wrong a lot of the time.
>> Breaking up a complicated expression _fragments_ it - it spreads it over
>> a greater number of source code lines, some of which may not be visible
>> on the screen. While each fragment may in itself be easier to read, the
>> entire expression has become more difficult.

>>> Parenthesized expressions are much more amenable for splitting across
>>> lines and indenting than pure infix operator expressions.

> Yuck. Any expression complicated enough to need parentheses
> _and_ multiple lines _and_ some indication of nesting merits
> rewriting into simpler components.

That was my point. Such rewriting bloats code, making it more difficult,
as a whole, to understand.

>> I'm not sure I agree with this, my background being the maintainer of
>> Emacs's CC Mode.

>> How about a real world example? In the following (from Emacs's
>> syntax.c):

>> if (code == Sendcomment
>> && SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
>> && (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
>> (nesting > 0 && --nesting == 0) : nesting < 0)
>> && !comment_ender_quoted (from, from_byte, syntax))

>> , which is a moderately complicated example, extra parentheses around
>> the operands of the &&s would clutter up the code rather than
>> clarifying it. Yet the whole expression being on just five lines
>> makes it relatively easy to understand.

> I'm a longtime emacs user, and definitely a fan, but this code
> is horrible, on several different levels.

I disagree. The condition being coded is "horrible", so the code cannot
be "nice". That condition is testing whether an ostensible comment ender
actually ends a comment. There are several things to test, namely,
that we're not trying to end a // comment with */, that the comment, if
nested (this can happen, for example, in Lisp or Pascal), reaches the
outer level of nesting, and that the comment ender isn't quoted.

> I agree that adding extra parentheses around the &&s operands would
> make things worse, ....

Agreed.

> .... but it's already way below threshold for any reasonable standard
> of code review.

This is simply untrue. That piece of code has been reviewed many times,
including by me, and presents no particular difficulties in
understanding.

I don't think it could be written better.

> Just my unabashed impressions.. :)

--
Alan Mackenzie (Nuremberg, Germany).

Alan Mackenzie <acm@muc.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Alan Mackenzie <acm@muc.de> writes:

>>> How about a real world example? In the following (from Emacs's
>>> syntax.c):
>
>>> if (code == Sendcomment
>>> && SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
>>> && (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
>>> (nesting > 0 && --nesting == 0) : nesting < 0)
>>> && !comment_ender_quoted (from, from_byte, syntax))
>
>>> , which is a moderately complicated example, extra parentheses around
>>> the operands of the &&s would clutter up the code rather than
>>> clarifying it. Yet the whole expression being on just five lines
>>> makes it relatively easy to understand.
>
>> I'm a longtime emacs user, and definitely a fan, but this code
>> is horrible, on several different levels.
>
> I disagree. The condition being coded is "horrible", so the code cannot
> be "nice". That condition is testing whether an ostensible comment ender
> actually ends a comment. There are several things to test, namely,
> that we're not trying to end a // comment with */, that the comment, if
> nested (this can happen, for example, in Lisp or Pascal), reaches the
> outer level of nesting, and that the comment ender isn't quoted.
>
>> I agree that adding extra parentheses around the &&s operands would
>> make things worse, ....
>
> Agreed.
>
>> .... but it's already way below threshold for any reasonable standard
>> of code review.
>
> This is simply untrue. That piece of code has been reviewed many times,
> including by me, and presents no particular difficulties in
> understanding.
>
> I don't think it could be written better.

One concern is that this is not a plain condition since it sometimes has
side effects. I'm comfortable with trivial cases of that (while (*cp++)
.... for example) but there is more to check here. For example, it's not
obvious that the conditional decrement must not happen when the rather
opaque condition

SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style

is false.

And I also find myself wondering why the value of nesting is significant
when SYNTAX_FLAGS_COMMENT_NESTED (syntax) is false. Is it playing some
dual role?

--
Ben.

On Tuesday, 26 April 2022 at 11:34:55 UTC+1, Alan Mackenzie wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> > Alan Mackenzie <a...@muc.de> writes:
>
> >> Kaz Kylheku <480-99...@kylheku.com> wrote:
>
> >>> On 2022-04-13, Alan Mackenzie <a...@muc.de> wrote:
>
> > [...]
>
> >>>> Too many parentheses can make C code difficult to read. Difficult
> >>>> to read translates to "more bugs". A knowledge of C's precedence
> >>>> levels, at least to a moderate degree, can help avoid such bugs.
>
> > I definitely agree with this.
>
> >>> Too much complexity in one expression makes it hard to read.
>
> > I also agree with this.
>
> >>> Other
> >>> than breaking it up into smaller expression, what can help is to
> >>> split it into multiple lines and use indentation.
>
> > Sometimes, but rarely. In most cases another choice is better.
>
> >> This is a common attitude, and I'm sure it is wrong a lot of the time.
> >> Breaking up a complicated expression _fragments_ it - it spreads it over
> >> a greater number of source code lines, some of which may not be visible
> >> on the screen. While each fragment may in itself be easier to read, the
> >> entire expression has become more difficult.
>
> >>> Parenthesized expressions are much more amenable for splitting across
> >>> lines and indenting than pure infix operator expressions.
>
> > Yuck. Any expression complicated enough to need parentheses
> > _and_ multiple lines _and_ some indication of nesting merits
> > rewriting into simpler components.
> That was my point. Such rewriting bloats code, making it more difficult,
> as a whole, to understand.
> >> I'm not sure I agree with this, my background being the maintainer of
> >> Emacs's CC Mode.
>
> >> How about a real world example? In the following (from Emacs's
> >> syntax.c):
>
> >> if (code == Sendcomment
> >> && SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
> >> && (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
> >> (nesting > 0 && --nesting == 0) : nesting < 0)
> >> && !comment_ender_quoted (from, from_byte, syntax))
>
> >> , which is a moderately complicated example, extra parentheses around
> >> the operands of the &&s would clutter up the code rather than
> >> clarifying it. Yet the whole expression being on just five lines
> >> makes it relatively easy to understand.
>
> > I'm a longtime emacs user, and definitely a fan, but this code
> > is horrible, on several different levels.
> I disagree. The condition being coded is "horrible", so the code cannot
> be "nice". That condition is testing whether an ostensible comment ender
> actually ends a comment. There are several things to test, namely,
> that we're not trying to end a // comment with */, that the comment, if
> nested (this can happen, for example, in Lisp or Pascal), reaches the
> outer level of nesting, and that the comment ender isn't quoted.
> > I agree that adding extra parentheses around the &&s operands would
> > make things worse, ....
>
> Agreed.
>
> > .... but it's already way below threshold for any reasonable standard
> > of code review.
>
> This is simply untrue. That piece of code has been reviewed many times,
> including by me, and presents no particular difficulties in
> understanding.
>
> I don't think it could be written better.
>
/*
Does a comment ender token actually end a comment?
Params: code - the token (e.g. Sendcomment, Receivecomment [Malcolm ??])
syntax - syntax flags for current comment style (see SYNTAX_FLAGS)
style - current comment style [Malcolm, how does this differ from syntax?]
nesting - nesting level (note can be negative [Malcolm, explain how])
from - start of comment
from_byte - [Malcolm ???]
Returns: true if the comment ends, else false.
*/
bool is_comment_ended(int code, unsigned int syntax, unsigned int style, int nesting, char *from, char from_byte)
{ if (code != Sendcomment)
return false; // Not an end comment token
if (SYNTAX_FLAGS_COMMENT_STYLE(syntax, 0) != style)
return false; // Wrong comment style
if (SYNTAX_FLAGS_COMMENT_NESTED(syntax))
{
if (nesting != 1)
return false; // in a nested comment
}
else
{
if (nesting < 0)
return false; // [Malcolm - suspect nasty hack here, why can nesting go negative?]
}
if (comment_ender_quoted(from, from_byte, syntax))
return false; // Comment ender token is in quotes, not a comment ender

// All tests passed, must be valid comment ender.
return true;
}

Now you need to fix up the decrement on the nesting flag. That should be done outside
of the test, as it is logically separate from it.
The Malcolm comments are because Malcolm, who is totally unfamilar with the code, has
dived in and tried to fix it.Naturally they should be replaced.

On 2022-04-25, Vir Campestris <vir.campestris@invalid.invalid> wrote:
> On 25/04/2022 11:21, Alan Mackenzie wrote:
>> I think that is the best of all! Inserting brief, meaningful comments,
>> as above, makes the thing easy to understand without bloating the code.
>> I wish more people would code like this.
>
> Absolutely.
>
> It has the great advantage that the comments say what the code is
> _supposed_ to do. If they disagree that's a great big alarm bell to
> anyone looking for bugs.
>
> "self documenting code" doesn't do that.

I will take a set of test cases that break right away, over some comment
that started lying 13 years ago, but nobody noticed untl now.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Tuesday, 26 April 2022 at 11:34:55 UTC+1, Alan Mackenzie wrote:
>> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
>> > Alan Mackenzie <a...@muc.de> writes:

>> >> Kaz Kylheku <480-99...@kylheku.com> wrote:

>> >>> On 2022-04-13, Alan Mackenzie <a...@muc.de> wrote:

>> > [...]

>> >>>> Too many parentheses can make C code difficult to read. Difficult
>> >>>> to read translates to "more bugs". A knowledge of C's precedence
>> >>>> levels, at least to a moderate degree, can help avoid such bugs.

>> > I definitely agree with this.

>> >>> Too much complexity in one expression makes it hard to read.

>> > I also agree with this.

>> >>> Other than breaking it up into smaller expression, what can help
>> >>> is to split it into multiple lines and use indentation.

>> > Sometimes, but rarely. In most cases another choice is better.

>> >> This is a common attitude, and I'm sure it is wrong a lot of the
>> >> time. Breaking up a complicated expression _fragments_ it - it
>> >> spreads it over a greater number of source code lines, some of
>> >> which may not be visible on the screen. While each fragment may in
>> >> itself be easier to read, the entire expression has become more
>> >> difficult.

>> >>> Parenthesized expressions are much more amenable for splitting
>> >>> across lines and indenting than pure infix operator expressions.

>> > Yuck. Any expression complicated enough to need parentheses _and_
>> > multiple lines _and_ some indication of nesting merits rewriting
>> > into simpler components.

>> That was my point. Such rewriting bloats code, making it more
>> difficult, as a whole, to understand.

>> >> I'm not sure I agree with this, my background being the maintainer
>> >> of Emacs's CC Mode.

>> >> How about a real world example? In the following (from Emacs's
>> >> syntax.c):

>> >> if (code == Sendcomment
>> >> && SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
>> >> && (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
>> >> (nesting > 0 && --nesting == 0) : nesting < 0)
>> >> && !comment_ender_quoted (from, from_byte, syntax))

>> >> , which is a moderately complicated example, extra parentheses
>> >> around the operands of the &&s would clutter up the code rather
>> >> than clarifying it. Yet the whole expression being on just five
>> >> lines makes it relatively easy to understand.

>> > I'm a longtime emacs user, and definitely a fan, but this code
>> > is horrible, on several different levels.

>> I disagree. The condition being coded is "horrible", so the code
>> cannot be "nice". That condition is testing whether an ostensible
>> comment ender actually ends a comment. There are several things to
>> test, namely, that we're not trying to end a // comment with */, that
>> the comment, if nested (this can happen, for example, in Lisp or
>> Pascal), reaches the outer level of nesting, and that the comment
>> ender isn't quoted.

>> > I agree that adding extra parentheses around the &&s operands would
>> > make things worse, ....

>> Agreed.

>> > .... but it's already way below threshold for any reasonable
>> > standard of code review.

>> This is simply untrue. That piece of code has been reviewed many
>> times, including by me, and presents no particular difficulties in
>> understanding.

>> I don't think it could be written better.

> /*
> Does a comment ender token actually end a comment?
> Params: code - the token (e.g. Sendcomment, Receivecomment [Malcolm ??])
> syntax - syntax flags for current comment style (see SYNTAX_FLAGS)
> style - current comment style [Malcolm, how does this differ from syntax?]
> nesting - nesting level (note can be negative [Malcolm, explain how])
> from - start of comment
> from_byte - [Malcolm ???]
> Returns: true if the comment ends, else false.
> */
> bool is_comment_ended(int code, unsigned int syntax, unsigned int style, int nesting, char *from, char from_byte)
> {
> if (code != Sendcomment)
> return false; // Not an end comment token
> if (SYNTAX_FLAGS_COMMENT_STYLE(syntax, 0) != style)
> return false; // Wrong comment style
> if (SYNTAX_FLAGS_COMMENT_NESTED(syntax))
> {
> if (nesting != 1)
> return false; // in a nested comment
> }
> else
> {
> if (nesting < 0)
> return false; // [Malcolm - suspect nasty hack here, why can nesting go negative?]
> }
> if (comment_ender_quoted(from, from_byte, syntax))
> return false; // Comment ender token is in quotes, not a comment ender

> // All tests passed, must be valid comment ender.
> return true;
> }

You make my point more eloquently than I could. ;-) 5 lines have become
20 non-comment lines plus comments, and several more lines will be needed
to handle the decrementation of the variable `nesting'. These 20 lines
have been fragmented from the context where they formally belonged. Or,
in plain English, you've got to keep moving backwards and forwards
between this new functiom and the calling point to understand things.

This new function is a bit like the long gentle ramp often seen at the
entrance to public buildings for the benefit of wheelchair users. It is
less effort to walk up than climbing the stairs, since each step is
gentler, but the total time and energy expended is much more. Otherwise,
able bodied people would walk up the ramp rather than climbing the
stairs. In this analogy, the stairs correspond with the five line
original piece of code.

> Now you need to fix up the decrement on the nesting flag. That should
> be done outside of the test, as it is logically separate from it.

Perhaps, perhaps not. If one construes the 5-line original as "handle a
comment closer", then decrementing the nesting level is an integral part
of it.

> The Malcolm comments are because Malcolm, who is totally unfamilar with
> the code, has dived in and tried to fix it.Naturally they should be
> replaced.

:-)

There're quite a lot of pieces of code like my original citation in the
Emacs C code. I can't remember there ever being a call to make it less
compact.

--
Alan Mackenzie (Nuremberg, Germany).

Ben <ben.usenet@bsb.me.uk> wrote:
> Alan Mackenzie <acm@muc.de> writes:

>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> Alan Mackenzie <acm@muc.de> writes:

>>>> How about a real world example? In the following (from Emacs's
>>>> syntax.c):

>>>> if (code == Sendcomment
>>>> && SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
>>>> && (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
>>>> (nesting > 0 && --nesting == 0) : nesting < 0)
>>>> && !comment_ender_quoted (from, from_byte, syntax))

>>>> , which is a moderately complicated example, extra parentheses around
>>>> the operands of the &&s would clutter up the code rather than
>>>> clarifying it. Yet the whole expression being on just five lines
>>>> makes it relatively easy to understand.

>>> I'm a longtime emacs user, and definitely a fan, but this code
>>> is horrible, on several different levels.

>> I disagree. The condition being coded is "horrible", so the code cannot
>> be "nice". That condition is testing whether an ostensible comment ender
>> actually ends a comment. There are several things to test, namely,
>> that we're not trying to end a // comment with */, that the comment, if
>> nested (this can happen, for example, in Lisp or Pascal), reaches the
>> outer level of nesting, and that the comment ender isn't quoted.

>>> I agree that adding extra parentheses around the &&s operands would
>>> make things worse, ....

>> Agreed.

>>> .... but it's already way below threshold for any reasonable standard
>>> of code review.

>> This is simply untrue. That piece of code has been reviewed many times,
>> including by me, and presents no particular difficulties in
>> understanding.

>> I don't think it could be written better.

> One concern is that this is not a plain condition since it sometimes
> has side effects. I'm comfortable with trivial cases of that (while
> (*cp++) ... for example) but there is more to check here. For example,
> it's not obvious that the conditional decrement must not happen when
> the rather opaque condition

> SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style

> is false.

That condition just checks that we're not trying to close a C line
comment with a */, for example.

> And I also find myself wondering why the value of nesting is significant
> when SYNTAX_FLAGS_COMMENT_NESTED (syntax) is false. Is it playing some
> dual role?

Yes, unfortunately so. There's an ad-hoc convention where this variable
is -1 in non-nested comments. It plays a role where there are both
nested and non-nested comments in a language (such as Common Lisp).

> --
> Ben.

--
Alan Mackenzie (Nuremberg, Germany).

Alan Mackenzie <acm@muc.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

[...]

I should note here that I have read through your previous
comments but don't have any response to them at this time.

>> .... but it's already way below threshold for any reasonable
>> standard of code review.
>
> This is simply untrue.

My statement is a statement of opinion, not a statement of fact,
and so it is neither true nor false -- it is just my opinion.

> That piece of code has been reviewed many times, including by
> me, and presents no particular difficulties in understanding.
>
> I don't think it could be written better.

Different people have different metrics for "better". I'm
interested to hear reactions from other people on this question.

To give some additional context, below is the function forw_comment,
taken from syntax.c in emacs 28.1, and which containts the if()
expression (or something very much like it) under discussion.

What do other comp.lang.c folks think of the code below? Does it
present any difficulties in understanding it? Can or should it
be revised to make it "better"? If yes, what kinds of changes
would make it better? Any other comments are also welcome.

(The excerpt below starts with a function-level comment, and after
that has one C function definition. There is no indentation except
what was present in the original code, and there is nothing more in
the posting after the excerpt.)

/* Jump over a comment, assuming we are at the beginning of one.
FROM is the current position.
FROM_BYTE is the bytepos corresponding to FROM.
Do not move past STOP (a charpos).
The comment over which we have to jump is of style STYLE
(either SYNTAX_FLAGS_COMMENT_STYLE (foo) or ST_COMMENT_STYLE).
NESTING should be positive to indicate the nesting at the beginning
for nested comments and should be zero or negative else.
ST_COMMENT_STYLE cannot be nested.
PREV_SYNTAX is the SYNTAX_WITH_FLAGS of the previous character
(or 0 if the search cannot start in the middle of a two-character).

If successful, return true and store the charpos of the comment's
end into *CHARPOS_PTR and the corresponding bytepos into
*BYTEPOS_PTR. Else, return false and store the charpos STOP into
*CHARPOS_PTR, the corresponding bytepos into *BYTEPOS_PTR and the
current nesting (as defined for state->incomment) in
*INCOMMENT_PTR. Should the last character scanned in an incomplete
comment be a possible first character of a two character construct,
we store its SYNTAX_WITH_FLAGS into *last_syntax_ptr. Otherwise,
we store Smax into *last_syntax_ptr.

The comment end is the last character of the comment rather than the
character just after the comment.

Global syntax data is assumed to initially be valid for FROM and
remains valid for forward search starting at the returned position. */

static bool
forw_comment (ptrdiff_t from, ptrdiff_t from_byte, ptrdiff_t stop,
EMACS_INT nesting, int style, int prev_syntax,
ptrdiff_t *charpos_ptr, ptrdiff_t *bytepos_ptr,
EMACS_INT *incomment_ptr, int *last_syntax_ptr)
{ unsigned short int quit_count = 0;
int c, c1;
enum syntaxcode code;
int syntax, other_syntax;

if (nesting <= 0) nesting = -1;

/* Enter the loop in the middle so that we find
a 2-char comment ender if we start in the middle of it. */
syntax = prev_syntax;
code = syntax & 0xff;
if (syntax != 0 && from < stop) goto forw_incomment;

while (1)
{
if (from == stop)
{
*incomment_ptr = nesting;
*charpos_ptr = from;
*bytepos_ptr = from_byte;
*last_syntax_ptr =
(code == Sescape || code == Scharquote
|| SYNTAX_FLAGS_COMEND_FIRST (syntax)
|| (nesting > 0
&& SYNTAX_FLAGS_COMSTART_FIRST (syntax)))
? syntax : Smax ;
return 0;
}
c = FETCH_CHAR_AS_MULTIBYTE (from_byte);
syntax = SYNTAX_WITH_FLAGS (c);
code = syntax & 0xff;
if (code == Sendcomment
&& SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
&& (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
(nesting > 0 && --nesting == 0) : nesting < 0)
&& !(comment_end_can_be_escaped && char_quoted (from, from_byte)))
/* We have encountered a comment end of the same style
as the comment sequence which began this comment
section. */
break;
if (code == Scomment_fence
&& style == ST_COMMENT_STYLE)
/* We have encountered a comment end of the same style
as the comment sequence which began this comment
section. */
break;
if (nesting > 0
&& code == Scomment
&& SYNTAX_FLAGS_COMMENT_NESTED (syntax)
&& SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style)
/* We have encountered a nested comment of the same style
as the comment sequence which began this comment section. */
nesting++;
if (comment_end_can_be_escaped
&& (code == Sescape || code == Scharquote))
{
inc_both (&from, &from_byte);
UPDATE_SYNTAX_TABLE_FORWARD (from);
if (from == stop) continue; /* Failure */
}
inc_both (&from, &from_byte);
UPDATE_SYNTAX_TABLE_FORWARD (from);

forw_incomment:
if (from < stop && SYNTAX_FLAGS_COMEND_FIRST (syntax)
&& (c1 = FETCH_CHAR_AS_MULTIBYTE (from_byte),
other_syntax = SYNTAX_WITH_FLAGS (c1),
SYNTAX_FLAGS_COMEND_SECOND (other_syntax))
&& SYNTAX_FLAGS_COMMENT_STYLE (syntax, other_syntax) == style
&& ((SYNTAX_FLAGS_COMMENT_NESTED (syntax) ||
SYNTAX_FLAGS_COMMENT_NESTED (other_syntax))
? nesting > 0 : nesting < 0))
{
syntax = Smax; /* So that "|#" (lisp) can not return
the syntax of "#" in *last_syntax_ptr. */
if (--nesting <= 0)
/* We have encountered a comment end of the same style
as the comment sequence which began this comment section. */
break;
else
{
inc_both (&from, &from_byte);
UPDATE_SYNTAX_TABLE_FORWARD (from);
}
}
if (nesting > 0
&& from < stop
&& SYNTAX_FLAGS_COMSTART_FIRST (syntax)
&& (c1 = FETCH_CHAR_AS_MULTIBYTE (from_byte),
other_syntax = SYNTAX_WITH_FLAGS (c1),
SYNTAX_FLAGS_COMMENT_STYLE (other_syntax, syntax) == style
&& SYNTAX_FLAGS_COMSTART_SECOND (other_syntax))
&& (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ||
SYNTAX_FLAGS_COMMENT_NESTED (other_syntax)))
/* We have encountered a nested comment of the same style
as the comment sequence which began this comment section. */
{
syntax = Smax; /* So that "#|#" isn't also a comment ender. */
inc_both (&from, &from_byte);
UPDATE_SYNTAX_TABLE_FORWARD (from);
nesting++;
}

rarely_quit (++quit_count);
}
*charpos_ptr = from;
*bytepos_ptr = from_byte;
*last_syntax_ptr = Smax; /* Any syntactic power the last byte had is
used up. */
return 1;
}

i dont remember them still.. thought probabbly it would be really nice
to learn them

for example i was surprised recently by bug in my code i wrote

if(!atoms.first[right_bracket ].beg[0]==']')

i thought ! negates this == , it showed i need to add

if(!(atoms.first[right_bracket ].beg[0]==']'))

which is unfortunate, fortunatelly at least some may write
if(atoms.first[right_bracket ].beg[0]!=']')

overally what is worse i got no or for for ifs i mean i much prefer like writing

if(a) if(b) if(c) than if(a && b && c)
and it is cool i can but i need or
if(a) if(b) if(c) or if(d) if(e) { }
and this dont work