Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Lars Ingebrigtsen]

Po Lu via Mailing list for Emacs changes <emacs-diffs@gnu.org> writes:

> -#     !BEWARE! "git clean -fdx" deletes all files that are not under
> -#     !BEWARE! version control, which means that all changes to such
> -#     !BEWARE! files will be lost and cannot be restored later

I don't think we should remove the BEWAREs -- it's a destructive
operation that we shouldn't recommend to people without these caveats.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]


>> -#     !BEWARE! "git clean -fdx" deletes all files that are not under
>> -#     !BEWARE! version control, which means that all changes to such
>> -#     !BEWARE! files will be lost and cannot be restored later
>
> I don't think we should remove the BEWAREs -- it's a destructive 
> operation that we shouldn't recommend to people without these caveats.
>

Indeed, now done.

Another "rewording":

If "make bootstrap" failed, try running "make extraclean" and then "make 
bootstrap" again.

is just wrong, "make extraclean" is already what "make bootstrap" does.

The other changes in that file were gratuitous, too.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> If "make bootstrap" failed, try running "make extraclean" and then
> "make bootstrap" again.
>
> is just wrong, "make extraclean" is already what "make bootstrap" does.

Is it?  Our naming here is pretty odd, but I think "extraclean" removes
more stuff than "bootstrap-clean" does (which is what "make bootstrap"
does).

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Another "rewording":
>
> If "make bootstrap" failed, try running "make extraclean" and then
> "make bootstrap" again.
>
> is just wrong, "make extraclean" is already what "make bootstrap" does.

That's wrong, make extraclean does much more than make bootstrap (did
you actually read the Makefile?)

The beware was ommitted by accident - I have now readded it.

> The other changes in that file were gratuitous, too.

No.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

Po Lu, it is unacceptable to "reword" a patch that has been discussed 
publicly over a week.  You had plenty of time to comment on it if you 
wanted.  The fact that the advice message is indented for example is 
intentional, it stands out better.

I now reverted you commits again, and added a mention about make 
extraclean (which is what "make bootstrap configure=default" does).

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Po Lu, it is unacceptable to "reword" a patch that has been discussed
> publicly over a week.  You had plenty of time to comment on it if you
> wanted.  The fact that the advice message is indented for example is
> intentional, it stands out better.

Sorry, but I cannot possibly follow every single discussion on this
list.  What happened was essentially this:

 - I made some changes to xfns.c.

 - They caused a build failure.

 - Leading to what seemed like a badly worded and presented message,
   which interfered with fontification in compilation-mode, being
   displayed.

Therefore, I fixed it.  Instead of complaining about the message being
previously discussed, please tell me what the problem is with my
version, and what justifies interfering with compilation-mode
fontification with multiple leading dashes and underscores.

> I now reverted you commits again, and added a mention about make
> extraclean (which is what "make bootstrap configure=default" does).

make bootstrap configure=extraclean cleans autosave and lock files?

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>
> what justifies interfering with compilation-mode fontification with 
> multiple leading dashes and underscores
>

Nobody mentioned that problem yet, I'll fix it.

>> I now reverted you commits again, and added a mention about make 
>> extraclean (which is what "make bootstrap configure=default" does).
>
> make bootstrap configure=default cleans autosave and lock files?
>

Yes, "make bootstrap configure=default" first does "make extraclean".

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Nobody mentioned that problem yet, I'll fix it.

So what exactly is the problem with my text, which you keep reverting?

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>> what justifies interfering with compilation-mode fontification with 
>> multiple leading dashes and underscores
>
> Nobody mentioned that problem yet, I'll fix it.
>

What's the problem exactly?  I don't see any interferences with 
fontification, at least not with emacs -Q.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Yes, "make bootstrap configure=default" first does "make extraclean".

Then it isn't obvious enough.  Please write "make extraclean" instead.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> What's the problem exactly?  I don't see any interferences with
> fontification, at least not with emacs -Q.

The link to the failing line of the Makefile is fontified incorrectly,
and the Makefile name is also parsed incorrectly, leading to a prompt
for the directory under which "-
Makefile" is located.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>> What's the problem exactly?  I don't see any interferences with 
>> fontification, at least not with emacs -Q.
>
> The link to the failing line of the Makefile is fontified incorrectly, 
> and the Makefile name is also parsed incorrectly, leading to a prompt 
> for the directory under which "- Makefile" is located.
>

Can you share a screenshot perhaps, with some comments?  I don't see any 
of the problems you mention here.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Can you share a screenshot perhaps, with some comments?  I don't see
> any of the problems you mention here.

This imap server will not let me send attachments for some reason, but
upon an error happening, the following is displayed:

make[1]: *** [Makefile:409: advice-on-failure] Error 2

Clicking on the link to the Makefile insists on taking me to

~/path-to-emacs-src/make[1]: *** [Makefile

instead of the actual Makefile, which is what used to happen, and what
happens with my version of the message.

The link is also fontified incorrectly, with too much underlined above.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>> Can you share a screenshot perhaps, with some comments?  I don't see 
>> any of the problems you mention here.
>
> This imap server will not let me send attachments for some reason, but 
> upon an error happening, the following is displayed:
>
> make[1]: *** [Makefile:409: advice-on-failure] Error 2
>
> Clicking on the link to the Makefile insists on taking me to
>
> ~/path-to-emacs-src/make[1]: *** [Makefile
>
> instead of the actual Makefile, which is what used to happen, and what 
> happens with my version of the message.
>
> The link is also fontified incorrectly, with too much underlined above.
>

I'm puzzled.  Is that with emacs -Q?  I'm at 9035c20888, and all links 
seem to be fontified and to work correctly, each one takes me to the right 
place in the Makefile.  Do you have a recipe, perhaps?

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> I'm puzzled.  Is that with emacs -Q?

No.  I don't develop software in "emacs -Q".

> I'm at 9035c20888, and all links seem to be fontified and to work
> correctly, each one takes me to the right place in the Makefile.  Do
> you have a recipe, perhaps?

The recipe is not very relevant, since we already know the fix.  Which
is to remove indentation and leading dashes from the message.

At the same time, it would be good to remove bullet lists from the
message, and reword it in plain English.  Why?  Because it is easier for
people who, presumably unlike you, are not native English speakers, to
follow instructions laid out in the verbal format they learned at
school, instead of lists of individual, heavily context-dependent
sentences.

Emphasis is better conveyed verbally, rather than with exclamation marks
and capitals.

I think it is also good to remove all uses of the first-person pronoun,
like so:

# ADVICE-ON-FAILURE-BEGIN:all
# Running "make bootstrap" to re-build Emacs without compiled Lisp code
# commonly resolves the problem, while running "make V=1" will cause
# Make to display the commands it invokes to build Emacs, which can help
# investigate the problem.
# ADVICE-ON-FAILURE-END:all

# ADVICE-ON-FAILURE-BEGIN:bootstrap
# Try running "make extraclean" followed by "make", which will rebuild
# Emacs with the default configuration options.  Failing that, run "git
# clean -fdx" and "make bootstrap"; keep in mind that will irretrievably
# delete all files not under version control.  If Emacs still fails to
# build, please report the failure to bug-gnu-emacs@gnu.org, following
# the instructions in the 'Reporting Bugs' node of the Emacs manual.
# ADVICE-ON-FAILURE-END:bootstrap

And this type of build failure should never happen from a tarball, so
the message for both targets should be changed to:

# Please report the build failure to bug-gnu-emacs@gnu.org, following
# the instructions in the 'Reporting Bugs' node of the Emacs manual.

For both targets.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>> I'm puzzled.  Is that with emacs -Q?
>
> No.  I don't develop software in "emacs -Q".
>

That question means "Can you please try to reproduce the issue with emacs 
-Q?".  If not, it's probably something that is specific to your 
configuration.

>> I'm at 9035c20888, and all links seem to be fontified and to work 
>> correctly, each one takes me to the right place in the Makefile.  Do 
>> you have a recipe, perhaps?
>
> The recipe is not very relevant, since we already know the fix.  Which 
> is to remove indentation and leading dashes from the message.
>

There is nothing much different in that message from any other "echo" in 
other Makefiles, and I don't see why a leading indentation could change 
the way a pattern such as "[Makefile:412: advice-on-failure]" is detected 
and fontified.  It seems like a bug somewhere.  If you replace dashes 
with, say, '*', or '.', or numbers like "1." and "2.", is your problem 
solved?

>
> At the same time, it would be good to remove bullet lists from the 
> message, and reword it in plain English.
>

That's your opinion.  Nobody else said something similar, and I disagree. 
What such an advice should display is a bullet list of possible actions, 
that the use can copy-paste and immediately try.

>
> Emphasis is better conveyed verbally, rather than with exclamation marks 
> and capitals.
>

That's perhaps correct in a docstring or a manual, but not in a terminal, 
in which capitals and e.g. or colors are commonly used to put emphasis on 
something.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> That question means "Can you please try to reproduce the issue with
> emacs -Q?".  If not, it's probably something that is specific to your
> configuration.

But it used to work.  So this has broken how I work with Emacs, and I
want it changed.

And no, it doesn't happen in emacs -Q.

> There is nothing much different in that message from any other "echo"
> in other Makefiles, and I don't see why a leading indentation could
> change the way a pattern such as "[Makefile:412: advice-on-failure]"
> is detected and fontified.  It seems like a bug somewhere.  If you
> replace dashes with, say, '*', or '.', or numbers like "1." and "2.",
> is your problem solved?

The problem seems to be indentation in the Makefile.

> That's your opinion.  Nobody else said something similar, and I
> disagree. What such an advice should display is a bullet list of
> possible actions, that the use can copy-paste and immediately try.

Nobody else having commented simply means most other people do not think
much about this problem.  I do, and for the simple reason that I could
not easily understand the message printed.

What exactly is the problem with making the message easier to understand
for others, even though you yourself think it is fine?

> That's perhaps correct in a docstring or a manual, but not in a
> terminal, in which capitals and e.g. or colors are commonly used to
> put emphasis on something.

But since no colors are used here, that is besides the point.  Printing
a message like this upon something as simple as a Makefile failing:

  !BEWARE! ...mundane advice..
  !BEWARE! ...mundane advice..
  !BEWARE! ...mundane advice..

amounts to what is considered by normal people as yelling in their
faces, which is not welcome in software, or in real life.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>> That question means "Can you please try to reproduce the issue with 
>> emacs -Q?".  If not, it's probably something that is specific to your 
>> configuration.
>
> But it used to work.  So this has broken how I work with Emacs, and I 
> want it changed.
>
> And no, it doesn't happen in emacs -Q.
>

Apparently you have a bug in your configuration, why should Emacs be 
adapted to circumvent the bug in your configuration?

>> There is nothing much different in that message from any other "echo" 
>> in other Makefiles, and I don't see why a leading indentation could 
>> change the way a pattern such as "[Makefile:412: advice-on-failure]" is 
>> detected and fontified.  It seems like a bug somewhere.  If you replace 
>> dashes with, say, '*', or '.', or numbers like "1." and "2.", is your 
>> problem solved?
>
> The problem seems to be indentation in the Makefile.
>

That can't be the cause of the problem you see.  The message is indented 
with exactly two spaces, like all other "CC", "ELC", "GEN", "INFO"... 
messages.

>
> What exactly is the problem with making the message easier to understand 
> for others, even though you yourself think it is fine?
>

Because I do not think your message is easier to understand, I find it 
more difficult to understand.  When say git prints an error message, it's 
not a paragraph in prose.  Do you know other program that prints a 
paragraph in prose when a failure occurs?

>
> But since no colors are used here, that is besides the point.  Printing 
> a message like this upon something as simple as a Makefile failing:
>
> !BEWARE! ...mundane advice..
> !BEWARE! ...mundane advice..
> !BEWARE! ...mundane advice..
>
> amounts to what is considered by normal people as yelling in their 
> faces, which is not welcome in software, or in real life.
>

No, these !BEWARE! are like a traffic warning script.  If the warning text 
itself had been written in capitals, that could have been considered as 
"yelling".

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Apparently you have a bug in your configuration, why should Emacs be
> adapted to circumvent the bug in your configuration?

Why do you jump to the conclusion that it is a bug?  What other program
prints bulleted lists from its Makefile?

> That can't be the cause of the problem you see.  The message is
> indented with exactly two spaces, like all other "CC", "ELC", "GEN",
> "INFO"... messages.

Then perhaps it is the dashes? Or maybe any non-alphanumeric character
at the beginning?

> Because I do not think your message is easier to understand, I find it
> more difficult to understand.

And why is that?

> When say git prints an error message, it's not a paragraph in prose.

The message printed upon compilation failing is not simply an error
message, it is detailed advice for the user.  Such advice should
definitely not be a terse (meaning difficult to understand) bullet list,
littered with uses of the second person pronoun.

> Do you know other program that prints a paragraph in prose when a
> failure occurs?

When git or any other program prints an error message, it generally does
not try to tell the user about an elaborate series of steps that could
solve the problem.

> No, these !BEWARE! are like a traffic warning script.  If the warning
> text itself had been written in capitals, that could have been
> considered as "yelling".

A speed limit/camera warning is supposed to yell at you, and it doing so
is justified.  "!BEWARE!" followed by a mundane warning about git is
not.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>> Apparently you have a bug in your configuration, why should Emacs be 
>> adapted to circumvent the bug in your configuration?
>
> Why do you jump to the conclusion that it is a bug?
>

I do not jump to a conclusion, I said "apparently".  But you cannot share 
a screenshot, you do not want to share a recipe, it doesn't happen with 
emacs -Q nor with my configuration.  All that is not conclusive, but it 
points to a bug.

>> When say git prints an error message, it's not a paragraph in prose.
>
> The message printed upon compilation failing is not simply an error 
> message, it is detailed advice for the user. Such advice should 
> definitely not be a terse (meaning difficult to understand) bullet list, 
> littered with uses of the second person pronoun.
>

It's a detailed advice, and it's not difficult to understand, it lists a 
few commands that the user might try to use to fix the problem.  It is not 
"littered with uses of the second person pronoun" either, there's a single 
"You" at the beginning (and I don't see what's wrong with that).

>> Do you know other program that prints a paragraph in prose when a 
>> failure occurs?
>
> When git or any other program prints an error message, it generally does 
> not try to tell the user about an elaborate series of steps that could 
> solve the problem.
>

Let's see...

$ git push
fatal: The current branch my-new-branch has no upstream branch.
To push the current branch and set the remote as upstream, use

     git push --set-upstream origin my-new-branch

>> No, these !BEWARE! are like a traffic warning sign.  If the warning 
>> text itself had been written in capitals, that could have been 
>> considered as "yelling".
>
> A speed limit/camera warning is supposed to yell at you, and it doing so 
> is justified.  "!BEWARE!" followed by a mundane warning about git is 
> not.
>

It's not a "mundane" warning, "git clean -fdx" deletes files and they 
cannot be recovered, which is something a non-expert git user might not be 
aware of, so I don't see what's wrong with that warning.

But this isn't leading anywhere, let's agree to disagree.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> I do not jump to a conclusion, I said "apparently".  But you cannot
> share a screenshot, you do not want to share a recipe, it doesn't
> happen with emacs -Q nor with my configuration.  All that is not
> conclusive, but it points to a bug.

What "emacs -Q" does is not the only correct behavior out there, is it?

> It's a detailed advice, and it's not difficult to understand, it lists
> a few commands that the user might try to use to fix the problem.  It
> is not "littered with uses of the second person pronoun" either,
> there's a single "You" at the beginning (and I don't see what's wrong
> with that).

Once again, you (being a native English speaker) may not find it
difficult to understand, but I do, and probably many other people who
grew up where I did.

In the meantime, anyone who can read the Emacs tutorial or INSTALL can
read my version(s) of the message at least equally as well as he can
read yours.

> Let's see...
>
> $ git push
> fatal: The current branch my-new-branch has no upstream branch.
> To push the current branch and set the remote as upstream, use
>
>     git push --set-upstream origin my-new-branch

Where is the elaborate series of steps here? I see only one.

> It's not a "mundane" warning, "git clean -fdx" deletes files and they
> cannot be recovered, which is something a non-expert git user might
> not be aware of, so I don't see what's wrong with that warning.
>
> But this isn't leading anywhere, let's agree to disagree.

I still want the message changed, because so far it has totally broken
the "compilation failed; C-x `" muscle memory for me.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Tue, 20 Sep 2022 19:05:35 +0800
> 
> Gregory Heytings <gregory@heytings.org> writes:
> 
> > That question means "Can you please try to reproduce the issue with
> > emacs -Q?".  If not, it's probably something that is specific to your
> > configuration.
> 
> But it used to work.  So this has broken how I work with Emacs, and I
> want it changed.
> 
> And no, it doesn't happen in emacs -Q.
> 
> > There is nothing much different in that message from any other "echo"
> > in other Makefiles, and I don't see why a leading indentation could
> > change the way a pattern such as "[Makefile:412: advice-on-failure]"
> > is detected and fontified.  It seems like a bug somewhere.  If you
> > replace dashes with, say, '*', or '.', or numbers like "1." and "2.",
> > is your problem solved?
> 
> The problem seems to be indentation in the Makefile.

This is a huge thread, with many messages unrelated to the problem you
mention.  I, for one, have no idea what problem happened to you and
how it could be related to a bunch of comments.

To make discussion of that problem more efficient, please submit a bug
report with the details, and let's discuss this there.

Thanks.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>
> What "emacs -Q" does is not the only correct behavior out there, is it?
>

It isn't, but what we ask to anyone who reports a bug is to provide a 
minimal recipe starting with emacs -Q.  I don't see why the problem you 
see would be different.

Anyway, I've now changed the way the message is displayed, it now uses 
three leading stars and is redirected to stderr, which is e.g. what the 
Linux kernel uses.  Does that fix your problem?

>
> Once again, you (being a native English speaker) may not find it 
> difficult to understand, but I do, and probably many other people who 
> grew up where I did.
>

I guess it's a matter of taste.  To me this (which is the only message 
that most people will ever see):

"make all" failed with exit status 2.
You might try to:
- run "make bootstrap", which might fix the problem
- run "make V=1", which displays the full commands invoked by make,
   to further investigate the problem

immediately tells me that there is a build failure, and that I have two 
options: "make bootstrap" to try to fix the problem, and "make V=1" to 
investigate the problem.  What is unclear to you in that message?

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> It isn't, but what we ask to anyone who reports a bug is to provide a
> minimal recipe starting with emacs -Q.  I don't see why the problem
> you see would be different.

Because this is a bug that occurs before Emacs has been built, so the
buggy Emacs cannot be started with "emacs -Q".

> Anyway, I've now changed the way the message is displayed, it now uses
> three leading stars and is redirected to stderr, which is e.g. what
> the Linux kernel uses.  Does that fix your problem?

That does, yes.

> I guess it's a matter of taste.  To me this (which is the only message
> that most people will ever see):
>
> "make all" failed with exit status 2.
> You might try to:
> - run "make bootstrap", which might fix the problem
> - run "make V=1", which displays the full commands invoked by make,
>   to further investigate the problem
>
> immediately tells me that there is a build failure, and that I have
> two options: "make bootstrap" to try to fix the problem, and "make
> V=1" to investigate the problem.  What is unclear to you in that
> message?

What is the point of all the "might try to".  It's not that the message
is unclear; it is hard to understand until you read it at least twice in
both directions.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>> Anyway, I've now changed the way the message is displayed, it now uses 
>> three leading stars and is redirected to stderr, which is e.g. what the 
>> Linux kernel uses.  Does that fix your problem?
>
> That does, yes.
>

Great!

>
> What is the point of all the "might try to".  It's not that the message 
> is unclear; it is hard to understand until you read it at least twice in 
> both directions.
>

I just changed that into "could try to", is it clearer now?

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Emanuel Berg]

Gregory Heytings wrote:

>> What is the point of all the "might try to". It's not that
>> the message is unclear; it is hard to understand until you
>> read it at least twice in both directions.
>
> I just changed that into "could try to", is it clearer now?

What do you mean?

-- 
underground experts united
https://dataswamp.org/~incal

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> I just changed that into "could try to", is it clearer now?

How about "Try to", dropping "you could" entirely?

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>> I just changed that into "could try to", is it clearer now?
>
> How about "Try to", dropping "you could" entirely?
>

That would sound like an injunction instead of a suggestion.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> That would sound like an injunction instead of a suggestion.

Those two are orthogonal, and the advice should be presented rather
forcefully, since it usually does work.

For people building from the repo, of course.  I think the warning
should be replaced with "see 'Reporting Bugs'" for releases.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Gregory Heytings]

>
> How about "Try to", dropping "you could" entirely?
>

I'm curious, you seem to dislike the word "you".  Why is that?  There are 
133 occurrences of that word in INSTALL and INSTALL.REPO (together).

>> That would sound like an injunction instead of a suggestion.
>
> Those two are orthogonal, and the advice should be presented rather 
> forcefully, since it usually does work.
>

But it's not what everyone who will see that message should do, right? 
Emacs developers for example might know why the build is broken and do 
something completely different, like fixing a syntax error in some file 
and type "make" again.  So it shouldn't be, or look like, an injunction, 
especially given that two options are presented and we're not suggesting 
to try both.

Anyway, I think we've already spent more than enough time on this little 
detail.  And these messages will possibly be simplified further in the 
near future while updating bootstrap-clean.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> I'm curious, you seem to dislike the word "you".  Why is that?  There
> are 133 occurrences of that word in INSTALL and INSTALL.REPO
> (together).

It doesn't sound right, having the Makefile address the user by pronoun
is very confusing.

> But it's not what everyone who will see that message should do, right?
> Emacs developers for example might know why the build is broken and do
> something completely different, like fixing a syntax error in some
> file and type "make" again.  So it shouldn't be, or look like, an
> injunction, especially given that two options are presented and we're
> not suggesting to try both.

Emacs developers will know enough to ignore the message anyway.

Re: master 5b3c4004a9 2/2: Remove calls to intern with a static string from code that runs on X

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Thu, 22 Sep 2022 10:47:16 +0800
> 
> Gregory Heytings <gregory@heytings.org> writes:
> 
> > I'm curious, you seem to dislike the word "you".  Why is that?  There
> > are 133 occurrences of that word in INSTALL and INSTALL.REPO
> > (together).
> 
> It doesn't sound right, having the Makefile address the user by pronoun
> is very confusing.

I don't find it confusing at all, and we do this all over the place,
including in the manuals.