emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Booleans


From: Paul Eggert
Subject: Re: Booleans
Date: Mon, 16 Dec 2013 09:28:49 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Stefan Monnier wrote:

> it's better to do it only where you already make other changes.

Ah, I interpreted that to mean "while you're in the same file",
but I guess you meant "while you're in the same line",
or something like that.  It seemed odd to change a
declaration from 'int foo = 0;' to 'bool foo = 0;', while
leaving a later 'foo = 1' undisturbed because it's far
from the declaration, which is why I took a more expansive
interpretation.

Here's the state of the 'bool' pass so far.  *.h files now
use 'bool', 'true', and 'false' for boolean, because of the
most-recent big patch.  .c files from src/alloc.c through
src/undo.c now use 'bool' but not 'true' and 'false',
because of earlier patches.  The remaining .c files largely
have yet to be looked at systematically; I suppose I might
change them to use 'bool', and to use 'true' and 'false' if
connected to a 'bool' change, while leaving constructions
like 'while (0)' and '#if 0' alone.

Obviously none of this is urgent.

Eli Zaretskii wrote:

> you also removed several struct members in that hunk.

They were mostly unused int members that were probably
intended to be bool.  Rather than try to guess types
it was simpler to remove unused members.  This part of
Emacs is so little used that it doesn't really matter much.

> "#if false" looks very odd to me, I don't think I've ever seen that.

It won't appear in any code intended to be portable to
pre-C99 (at least, not without something like gnulib), which
is why it looks "funny" to developers whose experience is
based on such programs.  If people prefer "#if 0" that's fine.

Jarek Czekalski wrote:

> Was it a private discussion?

Yes.  In relatively-unimportant matters, communicating
privately often saves everybody time.  One can't always
judge in advance which cases these will be, alas.

> Why this single change should be a separate commit?

In the past, I've been asked to not use lots of little
commits for related changes; I've also been asked to not
have one big commit when changes can be separated out.  So I
try to use my best judgment as to which method to use, and
(as we've seen here) my judgment is fallible.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]