From Newsgroup: comp.lang.c

On 3/26/2026 10:59 PM, Tim Rentsch wrote:

Personally, I think the proposed challenge has some interesting
parts. Unfortunately, other parts are dumb or pointless or
needlessly tedious, which is disappointing.

Give us a small Rentsch challenge that won't explode our brains.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 25/03/2026 12:32, Richard Harnden wrote:

On 22/03/2026 14:38, DFS wrote:

---------------------
Objective
---------------------
deliver a C (and optional 2nd language) program that - from a large
list of unsorted words possibly containing duplicates - extracts 26
sets of 100 random and unique words that each begin with a letter of
the English alphabet.

Here's my C attempt.

146 lines, but I like my vertical whitespace.

-----
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

#define COLS 3
#define MAX 32

static int qsort_strcmp(const void *p1, const void *p2)
{
return strcmp(*(const char **) p1, *(const char **) p2);
}

int main(void)
{
FILE *in = fopen("./words_unsorted.txt", "r");
char s[MAX];
int n;
int l = 0;
int total = 0;
int count[26] = {0};
int pos[26] = {0};
char **words[26] = {0};
char *out[2600] = {0};
int d = 0;
int o = 1 + 2600 / COLS;

while ( fgets(s, 32, in) != NULL )
{
if ( (n = strlen(s)) > l ) l = n;

total++;
count[s[0]-'a']++;
};

rewind(in);

printf("Total words: %d\n\n", total);

for (int i=0; i<26; i++)
words[i] = malloc(sizeof *words * count[i]);

while ( fgets(s, 32, in) != NULL )
{
int a;

n = strlen(s) - 1;
s[n] = '\0';

s[0] &= 0xdf;

a = s[0] - 'A';

words[a][pos[a]] = malloc(n+1);;

strcpy(words[a][pos[a]], s);

pos[a]++;
}

fclose(in);

for (int i=0; i<26; i++)
qsort(words[i], count[i], sizeof *words, qsort_strcmp);

for (int i=0; i<26; i++)
{
char *prior = NULL;

for (int j=0; j<count[i]; j++)
{
if ( prior == NULL ){
prior = words[i][j];
continue;
}

if ( strcmp(prior, words[i][j]) == 0 )
{
free(words[i][j]);
words[i][j] = NULL;

out[d] = prior;
d++;
}

prior = words[i][j];
}
}

printf("There are %d duplicates:", d);
for (int i=0; i<d; i++)
printf(" %s", out[i]);
printf("\n\n");

srand(time(NULL));

for (int i=0; i<26; i++)
{
printf("Selecting 100 words out of %d from set '%c'\n",
count[i], i+'A');

int j = 0;

while ( j < 100 )
{
int r = (rand() / (double) RAND_MAX) * count[i];

if ( words[i][r] == NULL ) continue;

out[i*100 + j] = words[i][r];
words[i][r] = NULL;

j++;
}
}

printf("\n");

qsort(out, 2600, sizeof *out, qsort_strcmp);

for (int i=0; i<o ; i++)
{
printf("%4d: ", i + 1);

for (int j=0; j<COLS; j++)
{
if ( i +j*o < 2600)
printf("%-*s", l, out[i + j*o]);
}

printf("\n");
}

for (int i=0; i<26; i++)
{
for (int j=0; j<count[i]; j++)
free(words[i][j]);

free(words[i]);
}

for (int i=0; i<2600; i++)
free(out[i]);

return 0;
}
-----

Total words: 300398

There are 5 duplicates: Congratulations On The Wherewithal Youngun

Selecting 100 words out of 20485 from set 'A'
Selecting 100 words out of 13991 from set 'B'
[...]
Selecting 100 words out of 919 from set 'Y'
Selecting 100 words out of 1148 from set 'Z'

1: Abastardize Intercurrence
Reinstitution
2: Abetter Interepidemic
Reiterating
[...]
866: Intentiveness Rehonour Zythum

867: Interassociation Reinforcing


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 3/27/2026 1:24 PM, Richard Harnden wrote:

On 25/03/2026 12:32, Richard Harnden wrote:

On 22/03/2026 14:38, DFS wrote:

---------------------
Objective
---------------------
deliver a C (and optional 2nd language) program that - from a large
list of unsorted words possibly containing duplicates - extracts 26
sets of 100 random and unique words that each begin with a letter of
the English alphabet.

Here's my C attempt.

146 lines, but I like my vertical whitespace.

Thanks for the submission.

It's 106 lines of code, so it's the shortest yet.

The only part you didn't get quite right was:

"print the 2600 words you identify in column x row order in a grid of
size (200rows x 13cols or 300x9 or 400x7 or 500x6 or 600x4 etc) "

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-03-28 05:52, DFS wrote:

On 3/27/2026 1:24 PM, Richard Harnden wrote:

On 25/03/2026 12:32, Richard Harnden wrote:

On 22/03/2026 14:38, DFS wrote:

---------------------
Objective
---------------------
deliver a C (and optional 2nd language) program that - from a large
list of unsorted words possibly containing duplicates - extracts 26
sets of 100 random and unique words that each begin with a letter of
the English alphabet.

Here's my C attempt.

146 lines, but I like my vertical whitespace.

Thanks for the submission.

It's 106 lines of code, so it's the shortest yet.

The only part you didn't get quite right was:

"print the 2600 words you identify in column x row order in a grid of
 size (200rows x 13cols or 300x9 or 400x7 or 500x6 or 600x4 etc) "

Ruminations on the recent "C" challenges...

Some requirements appear to be quite arbitrary. But okay. When
I read about the tasks to implement the first thought that came
up was to use an appropriate language or tool-set, one that fits
better for the task, tasks that at least I consider annoying to
implement them in "C" because that language doesn't support it
well, because of C's primitivity (its low-level'ness). But okay;
we're in a C-group and the residents need feeding. - Why is it
that I consider it annoying in "C"? - Because I'd have liked to
implement such tasks based on existing _building blocks_; like
associative arrays, sensible array data types, and what not.
Instead of constructing and building a car with tools like an
axe and a stone, wouldn't it be a more sensible to create useful
tools in "C" to make such challenges concentrate more on the
actual problem than on how to reinvent the simplest tasks again
and again? - I'd certainly consider it worthwhile to challenge
implementations of building blocks that alleviate C-programmers
from all the boring error-prone and low-level tasks that are
celebrated ad nauseam. - The question I'd ask myself if faced
with (arbitrary or useful) requirements would be what elementary
functions I'd need to construct the solution. Such identified
and isolated features, i.e. their implementation, would have a
persistent value for more than a single arbitrary "C" challenge.

As said; just my upcoming ruminations about that. So, YMMV.
(Disclaimer: angering folks with other mindsets not intended,
but I'd also not be surprised if it's considered offensive.)

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 3/28/2026 1:59 AM, Janis Papanagnou wrote:

On 2026-03-28 05:52, DFS wrote:

On 3/27/2026 1:24 PM, Richard Harnden wrote:

On 25/03/2026 12:32, Richard Harnden wrote:

On 22/03/2026 14:38, DFS wrote:

---------------------
Objective
---------------------
deliver a C (and optional 2nd language) program that - from a large >>>>> list of unsorted words possibly containing duplicates - extracts 26 >>>>> sets of 100 random and unique words that each begin with a letter
of the English alphabet.

Here's my C attempt.

146 lines, but I like my vertical whitespace.

Thanks for the submission.

It's 106 lines of code, so it's the shortest yet.

The only part you didn't get quite right was:

"print the 2600 words you identify in column x row order in a grid of
  size (200rows x 13cols or 300x9 or 400x7 or 500x6 or 600x4 etc) "

Ruminations on the recent "C" challenges...

Some requirements appear to be quite arbitrary.

Every challenge/competition/sport is arbitrary: the rules, the
constraints, the scoring, the technology allowed, the type of ball used,
the size of the field of play, the surface, the measures of performance,
the judging, the number of participants, etc.

It's all made up on a whim.

But okay. When
I read about the tasks to implement the first thought that came
up was to use an appropriate language or tool-set, one that fits
better for the task, tasks that at least I consider annoying to
implement them in "C" because that language doesn't support it
well, because of C's primitivity (its low-level'ness). But okay;
we're in a C-group and the residents need feeding. - Why is it
that I consider it annoying in "C"? - Because I'd have liked to
implement such tasks based on existing _building blocks_; like
associative arrays, sensible array data types, and what not.
Instead of constructing and building a car with tools like an
axe and a stone, wouldn't it be a more sensible to create useful
tools in "C" to make such challenges concentrate more on the
actual problem than on how to reinvent the simplest tasks again
and again? - I'd certainly consider it worthwhile to challenge implementations of building blocks that alleviate C-programmers
from all the boring error-prone and low-level tasks that are
celebrated ad nauseam. - The question I'd ask myself if faced
with (arbitrary or useful) requirements would be what elementary
functions I'd need to construct the solution. Such identified
and isolated features, i.e. their implementation, would have a
persistent value for more than a single arbitrary "C" challenge.

I think one word would've sufficed where you used 235: python

I just like to see how the good programmers of clc use C to approach
different tasks. It's always educational to read clc.

One "implementation of persistent value" you might've enjoyed if you participated is how to print data by column then row (it was in both of
my recent challenges). There's a powerful Linux command (column) that
does it, but it gives you no control over the number of rows, and no
line numbering option.

Combine the amt of data you have to print, the rows x columns you want
to use, and a simple function to know how wide your terminal window is,
and you have a lot of control over the presentation of data.

int gettermcols() {
struct winsize w = {0};
ioctl(STDOUT_FILENO, TIOCGWINSZ, &w);
return w.ws_col;
}


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 3/26/2026 10:59 PM, Tim Rentsch wrote:

Personally, I think the proposed challenge has some interesting
parts. Unfortunately, other parts are dumb or pointless or
needlessly tedious, which is disappointing.

Sounds like human life.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-03-28 14:05, DFS wrote:

On 3/28/2026 1:59 AM, Janis Papanagnou wrote:
[...]

But okay. When
I read about the tasks to implement the first thought that came
up was to use an appropriate language or tool-set, one that fits
better for the task, tasks that at least I consider annoying to
implement them in "C" because that language doesn't support it
well, because of C's primitivity (its low-level'ness). But okay;
we're in a C-group and the residents need feeding. - Why is it
that I consider it annoying in "C"? - Because I'd have liked to
implement such tasks based on existing _building blocks_; like
associative arrays, sensible array data types, and what not.
Instead of constructing and building a car with tools like an
axe and a stone, wouldn't it be a more sensible to create useful
tools in "C" to make such challenges concentrate more on the
actual problem than on how to reinvent the simplest tasks again
and again? - I'd certainly consider it worthwhile to challenge
implementations of building blocks that alleviate C-programmers
from all the boring error-prone and low-level tasks that are
celebrated ad nauseam. - The question I'd ask myself if faced
with (arbitrary or useful) requirements would be what elementary
functions I'd need to construct the solution. Such identified
and isolated features, i.e. their implementation, would have a
persistent value for more than a single arbitrary "C" challenge.

I think one word would've sufficed where you used 235: python

Sorry, I cannot associate that statement with anything I said. -
What is that "235: python" referring to? - Mind to elaborate?

Janis

[...]

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 30/03/2026 10:26, Janis Papanagnou wrote:

On 2026-03-28 14:05, DFS wrote:

On 3/28/2026 1:59 AM, Janis Papanagnou wrote:
[...]

But okay. When
I read about the tasks to implement the first thought that came
up was to use an appropriate language or tool-set, one that fits
better for the task, tasks that at least I consider annoying to
implement them in "C" because that language doesn't support it
well, because of C's primitivity (its low-level'ness). But okay;
we're in a C-group and the residents need feeding. - Why is it
that I consider it annoying in "C"? - Because I'd have liked to
implement such tasks based on existing _building blocks_; like
associative arrays, sensible array data types, and what not.
Instead of constructing and building a car with tools like an
axe and a stone, wouldn't it be a more sensible to create useful
tools in "C" to make such challenges concentrate more on the
actual problem than on how to reinvent the simplest tasks again
and again? - I'd certainly consider it worthwhile to challenge
implementations of building blocks that alleviate C-programmers
from all the boring error-prone and low-level tasks that are
celebrated ad nauseam. - The question I'd ask myself if faced
with (arbitrary or useful) requirements would be what elementary
functions I'd need to construct the solution. Such identified
and isolated features, i.e. their implementation, would have a
persistent value for more than a single arbitrary "C" challenge.

I think one word would've sufficed where you used 235: python

Sorry, I cannot associate that statement with anything I said. -
What is that "235: python" referring to? - Mind to elaborate?

The 235 refers to the number of words in your paragraph (I haven't checked).

And 'python' is a summary of what they think you're trying to say. That language already has those ready-made building blocks.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-03-30 05:26, Janis Papanagnou wrote:

On 2026-03-28 14:05, DFS wrote:

...

I think one word would've sufficed where you used 235: python

Sorry, I cannot associate that statement with anything I said. -
What is that "235: python" referring to? - Mind to elaborate?

I cannot answer your question, but the way you worded it suggests to me
that you may have parsed his comment incorrectly. It should be parsed as

"I think one word would've sufficed where you used 235. That word is
python."
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-03-31 02:33, James Kuyper wrote:

On 2026-03-30 05:26, Janis Papanagnou wrote:

On 2026-03-28 14:05, DFS wrote:

...

I think one word would've sufficed where you used 235: python

Sorry, I cannot associate that statement with anything I said. -
What is that "235: python" referring to? - Mind to elaborate?

I cannot answer your question, but the way you worded it suggests to me
that you may have parsed his comment incorrectly.

Indeed. - Thanks.

It should be parsed as

"I think one word would've sufficed where you used 235. That word is
python."

I see.

Obviously any language with decent building blocks would qualify.
It wouldn't have come to my mind that Python is the (only) answer
to explain the characteristics in a generic way. It may serve as
an example, but I cannot expect everyone knowing that language.

But the the post was about this and other useful contests in "C".
(Certainly not about "<language> is better than C".)

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Mon, 30 Mar 2026 12:10:46 +0100
Bart <bc@freeuk.com> wrote:

On 30/03/2026 10:26, Janis Papanagnou wrote:

On 2026-03-28 14:05, DFS wrote:

On 3/28/2026 1:59 AM, Janis Papanagnou wrote:
[...]

But okay. When
I read about the tasks to implement the first thought that came
up was to use an appropriate language or tool-set, one that fits
better for the task, tasks that at least I consider annoying to
implement them in "C" because that language doesn't support it
well, because of C's primitivity (its low-level'ness). But okay;
we're in a C-group and the residents need feeding. - Why is it
that I consider it annoying in "C"? - Because I'd have liked to
implement such tasks based on existing _building blocks_; like
associative arrays, sensible array data types, and what not.
Instead of constructing and building a car with tools like an
axe and a stone, wouldn't it be a more sensible to create useful
tools in "C" to make such challenges concentrate more on the
actual problem than on how to reinvent the simplest tasks again
and again? - I'd certainly consider it worthwhile to challenge
implementations of building blocks that alleviate C-programmers
from all the boring error-prone and low-level tasks that are
celebrated ad nauseam. - The question I'd ask myself if faced
with (arbitrary or useful) requirements would be what elementary
functions I'd need to construct the solution. Such identified
and isolated features, i.e. their implementation, would have a
persistent value for more than a single arbitrary "C" challenge.

I think one word would've sufficed where you used 235: python

Sorry, I cannot associate that statement with anything I said. -
What is that "235: python" referring to? - Mind to elaborate?

The 235 refers to the number of words in your paragraph (I haven't
checked).

I did. There are 223 words.
So, now I have more interesting question - how did DFS come to number
235? If by eye sight - it's impressively precise. If by use of word
count utility - it's too imprecise.


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 31/03/2026 10:11, Michael S wrote:

On Mon, 30 Mar 2026 12:10:46 +0100
Bart <bc@freeuk.com> wrote:

On 30/03/2026 10:26, Janis Papanagnou wrote:

On 2026-03-28 14:05, DFS wrote:

On 3/28/2026 1:59 AM, Janis Papanagnou wrote:
[...]

But okay. When
I read about the tasks to implement the first thought that came
up was to use an appropriate language or tool-set, one that fits
better for the task, tasks that at least I consider annoying to
implement them in "C" because that language doesn't support it
well, because of C's primitivity (its low-level'ness). But okay;
we're in a C-group and the residents need feeding. - Why is it
that I consider it annoying in "C"? - Because I'd have liked to
implement such tasks based on existing _building blocks_; like
associative arrays, sensible array data types, and what not.
Instead of constructing and building a car with tools like an
axe and a stone, wouldn't it be a more sensible to create useful
tools in "C" to make such challenges concentrate more on the
actual problem than on how to reinvent the simplest tasks again
and again? - I'd certainly consider it worthwhile to challenge
implementations of building blocks that alleviate C-programmers
from all the boring error-prone and low-level tasks that are
celebrated ad nauseam. - The question I'd ask myself if faced
with (arbitrary or useful) requirements would be what elementary
functions I'd need to construct the solution. Such identified
and isolated features, i.e. their implementation, would have a
persistent value for more than a single arbitrary "C" challenge.

I think one word would've sufficed where you used 235: python

Sorry, I cannot associate that statement with anything I said. -
What is that "235: python" referring to? - Mind to elaborate?

The 235 refers to the number of words in your paragraph (I haven't
checked).

I did. There are 223 words.
So, now I have more interesting question - how did DFS come to number
235? If by eye sight - it's impressively precise. If by use of word
count utility - it's too imprecise.

OK, now I have to count them! If I use 'wc' on the original paragraph
that JP wrote, which starts like this:

Some requirements appear to be quite arbitrary. But okay. ...

Then it says 230 words. But there was also another line before that
paragraph which was this:

Ruminations on the recent "C" challenges...

If that is included, then 'wc' reports 236 words. (It's also possible
that DFS mistyped the value.)

Presumably your count starts from 'But okay;'; then I get 223 words too.


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 31 Mar 2026 11:53:29 +0100
Bart <bc@freeuk.com> wrote:

On 31/03/2026 10:11, Michael S wrote:

On Mon, 30 Mar 2026 12:10:46 +0100
Bart <bc@freeuk.com> wrote:

On 30/03/2026 10:26, Janis Papanagnou wrote:

On 2026-03-28 14:05, DFS wrote:

On 3/28/2026 1:59 AM, Janis Papanagnou wrote:
[...]

But okay. When
I read about the tasks to implement the first thought that came
up was to use an appropriate language or tool-set, one that fits
better for the task, tasks that at least I consider annoying to
implement them in "C" because that language doesn't support it
well, because of C's primitivity (its low-level'ness). But okay;
we're in a C-group and the residents need feeding. - Why is it
that I consider it annoying in "C"? - Because I'd have liked to
implement such tasks based on existing _building blocks_; like
associative arrays, sensible array data types, and what not.
Instead of constructing and building a car with tools like an
axe and a stone, wouldn't it be a more sensible to create useful
tools in "C" to make such challenges concentrate more on the
actual problem than on how to reinvent the simplest tasks again
and again? - I'd certainly consider it worthwhile to challenge
implementations of building blocks that alleviate C-programmers
from all the boring error-prone and low-level tasks that are
celebrated ad nauseam. - The question I'd ask myself if faced
with (arbitrary or useful) requirements would be what elementary
functions I'd need to construct the solution. Such identified
and isolated features, i.e. their implementation, would have a
persistent value for more than a single arbitrary "C"
challenge.

I think one word would've sufficed where you used 235: python

Sorry, I cannot associate that statement with anything I said. -
What is that "235: python" referring to? - Mind to elaborate?

The 235 refers to the number of words in your paragraph (I haven't
checked).

I did. There are 223 words.
So, now I have more interesting question - how did DFS come to
number 235? If by eye sight - it's impressively precise. If by use
of word count utility - it's too imprecise.

OK, now I have to count them! If I use 'wc' on the original paragraph
that JP wrote, which starts like this:

Some requirements appear to be quite arbitrary. But okay. ...

Then it says 230 words. But there was also another line before that paragraph which was this:

Ruminations on the recent "C" challenges...

If that is included, then 'wc' reports 236 words. (It's also possible
that DFS mistyped the value.)

Presumably your count starts from 'But okay;'; then I get 223 words
too.

Yes, I took paragraph as quoted by DFS. Now I see that in original post
the paragraph was longer.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 3/31/2026 5:11 AM, Michael S wrote:

I did. There are 223 words.
So, now I have more interesting question - how did DFS come to number
235? If by eye sight - it's impressively precise. If by use of word
count utility - it's too imprecise.

Starting with "But okay. When", I counted on my fingers while moving my
lips. Lost count several times before I dropped it into Notepad++ and
did View | Summary.




--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 31 Mar 2026 13:07:48 -0400
DFS <nospam@dfs.com> wrote:

On 3/31/2026 5:11 AM, Michael S wrote:

I did. There are 223 words.
So, now I have more interesting question - how did DFS come to
number 235? If by eye sight - it's impressively precise. If by use
of word count utility - it's too imprecise.

Starting with "But okay. When", I counted on my fingers while moving
my lips. Lost count several times before I dropped it into Notepad++
and did View | Summary.

Now I know that Notepad++ has View | Summary. Thank you.


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 3/31/2026 2:15 PM, Michael S wrote:

On Tue, 31 Mar 2026 13:07:48 -0400
DFS <nospam@dfs.com> wrote:

On 3/31/2026 5:11 AM, Michael S wrote:

I did. There are 223 words.
So, now I have more interesting question - how did DFS come to
number 235? If by eye sight - it's impressively precise. If by use
of word count utility - it's too imprecise.

Starting with "But okay. When", I counted on my fingers while moving
my lips. Lost count several times before I dropped it into Notepad++
and did View | Summary.

Now I know that Notepad++ has View | Summary. Thank you.

But if I use Notepad++ and replace every space with a \n I get 223
words. Difference of 12. Strange.

Google AI Mode says:

"Notepad++'s View | Summary (or double-clicking the status bar) is known
to produce inaccurate word counts because it uses a simplified algorithm
that often misinterprets punctuation, special characters, and encodings
as word boundaries. It is widely considered "totally wrong" for precise
work.

Recommended Workarounds
For an accurate word count, use these more reliable methods:

Regex Count (Most Accurate):
Press Ctrl + F and go to the Mark or Find tab.
In Find what, type: \w+ (this matches alphanumeric word characters).
Set the Search Mode to Regular expression.
Click Count (or Mark All). The accurate word count will appear in the
status bar of that window.

Counting Selected Text Only:
To count a specific section, highlight the text and follow the Regex
Count steps above, making sure to check the In selection box.

Plugins:
NppTextFX2: This updated plugin provides a dedicated "Word Count" tool
under TextFX > TextFX Tools.

PythonScript: Advanced users can use a script (like StatusBarWordCount)
to display a live, accurate count in the status bar.

Why "Summary" is Inaccurate
Encoding Issues: It may miscount characters in specific encodings like
UCS-2.

Word Definition: Unlike a full word processor, the Summary feature's
basic definition of a "word" often fails to handle contractions (like
"don't") or hyphenated words correctly.

Hidden Spaces: It sometimes overcounts by treating multiple spaces or
line returns as extra word breaks."



Overcounting by 12 from a 223-word paragraph is ridiculously wrong. I'm surprised, since Notepad++ is otherwise a great editor.

Note: if I use the AI suggestion of "Regex Count", it also says 235 words.

223 it is.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 31 Mar 2026 16:59:41 -0400
DFS <nospam@dfs.com> wrote:

On 3/31/2026 2:15 PM, Michael S wrote:

On Tue, 31 Mar 2026 13:07:48 -0400
DFS <nospam@dfs.com> wrote:

On 3/31/2026 5:11 AM, Michael S wrote:

I did. There are 223 words.
So, now I have more interesting question - how did DFS come to
number 235? If by eye sight - it's impressively precise. If by use
of word count utility - it's too imprecise.

Starting with "But okay. When", I counted on my fingers while
moving my lips. Lost count several times before I dropped it into
Notepad++ and did View | Summary.

Now I know that Notepad++ has View | Summary. Thank you.

But if I use Notepad++ and replace every space with a \n I get 223
words. Difference of 12. Strange.

Google AI Mode says:

"Notepad++'s View | Summary (or double-clicking the status bar) is
known to produce inaccurate word counts because it uses a simplified algorithm that often misinterprets punctuation, special characters,
and encodings as word boundaries. It is widely considered "totally
wrong" for precise work.

Recommended Workarounds
For an accurate word count, use these more reliable methods:

Regex Count (Most Accurate):
Press Ctrl + F and go to the Mark or Find tab.
In Find what, type: \w+ (this matches alphanumeric word characters).
Set the Search Mode to Regular expression.
Click Count (or Mark All). The accurate word count will appear in the
status bar of that window.

Counting Selected Text Only:
To count a specific section, highlight the text and follow the Regex
Count steps above, making sure to check the In selection box.

Plugins:
NppTextFX2: This updated plugin provides a dedicated "Word Count"
tool under TextFX > TextFX Tools.

PythonScript: Advanced users can use a script (like
StatusBarWordCount) to display a live, accurate count in the status
bar.

Why "Summary" is Inaccurate
Encoding Issues: It may miscount characters in specific encodings
like UCS-2.

Word Definition: Unlike a full word processor, the Summary feature's

basic definition of a "word" often fails to handle contractions (like "don't") or hyphenated words correctly.

Hidden Spaces: It sometimes overcounts by treating multiple spaces or
line returns as extra word breaks."

Overcounting by 12 from a 223-word paragraph is ridiculously wrong.
I'm surprised, since Notepad++ is otherwise a great editor.

Note: if I use the AI suggestion of "Regex Count", it also says 235
words.

223 it is.

Now I had unknown that Notepad++ has View | Summary. Thank you.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 3/31/2026 6:02 PM, Michael S wrote:

Now I had unknown that Notepad++ has View | Summary. Thank you.

You're welcome.

But it appears unreliable.




--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-03-31 22:59, DFS wrote:

[ reporting notepad++ deficiencies ]

I'm surprised, since Notepad++ is otherwise a great editor.

Depends on what you want to do, what you expect and what you
want to avoid.

(I'm sure there's at least three major camps of user types.)


Being curious I took a sentence from your post (only inserted
a hyphen for an additional case covered) to check my editor:

Word Definition: Unlike a full-word processor, the Summary
feature's basic definition of a "word" often fails to handle
contractions (like "don't") or hyphenated words correctly.

(and it reports, I'd say correctly, 25 words).

This sentence appears interesting (at first glance) since it
contains punctuation, quoted words, parenthesis, hyphenation,
and an apostrophized word. Though on a second view I've asked
myself whether a word count could simply be determined by the
white-space separators. If it's so simple I wonder what these
other editors do to show as reported such a broken behavior.

Janis

PS: Followup-to comp.editors set.

--- Synchronet 3.21f-Linux NewsLink 1.2