Fix: Show send(cmd, true) on screen despite profile setting #7881

mpconley · 2025-05-31T22:19:40Z

Brief overview of PR changes/additions

This PR updates the behavior of the send() function so that its showOnScreen argument consistently overrides the global "Show the text you sent" setting in both directions. Previously, send(cmd, false) would suppress echo regardless of the global setting, but send(cmd, true) would not show the text if the global setting was disabled. Now, explicitly passing true or false to showOnScreen will always control whether the sent text is echoed, making the behavior more predictable and script-friendly.

Motivation for adding to Mudlet:

Resolves inconsistent behavior reported in #6919, improving script compatibility and user control over input echoing.

Other info (issues closed, discussion etc):

Closes #6919. No changes to default behavior unless showOnScreen is explicitly set in scripts.

Left is before the PR, right is after the PR:

"Show the text you sent" ✅ + send(cmd, true)
"Show the text you sent" ✅ + send(cmd, false)
"Show the text you sent" ❌ + send(cmd, true) ◀️ The change == smile prints!
"Show the text you sent" ❌ + send(cmd, false)

This is a video of the above in action, before the PR, after the PR:

Screen.Recording.2025-05-31.at.6.15.06.PM.mov

add-deployment-links · 2025-05-31T22:20:09Z

Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

linux: https://make.mudlet.org/snapshots/21ae8d/Mudlet-4.19.1-testing-pr7881-a030964b-linux-x64.AppImage.tar (commit a030964)
osx intel: https://make.mudlet.org/snapshots/54a77e/Mudlet-4.19.1-testing-pr7881-a030964b-x86_64.dmg (commit a030964)
osx arm: https://make.mudlet.org/snapshots/d8955d/Mudlet-4.19.1-testing-pr7881-a030964b-arm64.dmg (commit a030964)
windows 64 bit: https://make.mudlet.org/snapshots/0c1fd7/Mudlet-4.19.1-testing-pr7881-35f51f54-windows-64.zip (commit 35f51f5)
No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

vadi2

There isn't a right and a wrong way here, as it all depends upon the perspective - do you give the control to the player (option overrides scripts), or do you give control to the scripts here (scripts can override the option)?

Moving control from the players to the script like this might backfire with some players who'd prefer not to see the commands on the screen, despite what the script wants. Some scripts could have also been written with this option in mind working the way it is now.

So this isn't necessarily fixing an issue per se, but changing how the option works from one way to the other. I'm on the fence about this for this reason, esp. since we've just had just one feedback of this, not dozens.

Thoughts from others?

mpconley · 2025-06-01T21:36:03Z

Currently, the impact of "Show the text you sent" is quite broad. As a user, I would expect this setting to filter out only what I type directly, but it actually affects much more.

As demonstrated in the current state (see left image), unchecking "Show the text you sent" suppresses the echo of the lua command. This suppression applies not only to manually typed commands, but also to commands sent from actions, aliases, keys, timers, and triggers—even though the default for send is true for showOnScreen in these contexts.

Would it make sense to reconsider this setting? For example, we could change it to "Text from commands sent:" and offer three scopes:

Show all commands (showOnScreen not set as false)
Show only commands with showOnScreen set as true
Never show command text (ignore showOnScreen)

More detail:

Show all commands sent from actions, aliases, manually typed commands, keys, timers, and triggers
Show only commands explicitly set to display
Do not show text from any of these sources

Would this be more intuitive for users? Open to thoughts from others!

SlySven · 2025-06-13T08:49:34Z

src/Host.cpp

@@ -1240,12 +1240,13 @@ QPair<QString, QString> Host::getSearchEngine()
 // cTelnet::sendData(...) call:
 void Host::send(QString cmd, bool wantPrint, bool dontExpandAliases)
 {
-    if (wantPrint && (!mIsRemoteEchoingActive) && mPrintCommand) {


👎 The "profile" setting is entirely contained within this use of mPrintCommand - so removing it here renders everything else about the setting as dead cruft in several files.

Perhaps, the default setting of mPrintCommand to true - currently in the Host constructor initialisation list but really should be moved to the header file - should be amended to false instead - would this address the discomfort you have with this setting @mpconley?

The other place this is used is TCommandLine::enterCommand(QKeyEvent* event) for MiniConsole.

Showing what text is sent is my preferred default option for a profile, as-is. This is a nuance for sure.

Sorry, you are right, my searching was flawed and didn't give me that second usage. I suppose there is an option to turn the control in the preferences into a tri-state - with the default being partially checked meaning - "go with the Lua arguments" and the other two being always/never show the send command.

🤷

vadi2 · 2025-06-13T10:40:45Z

I'm wary of adding more detail to the option - and thus making it harder to use - without a good amount of impetus behind this from the playerbase. I'll ask around to see if there is a need for it! Should there be large demand, we should go with it. Otherwise, better to keep things simpler.

mpconley · 2025-06-13T11:13:52Z

I don't have an emotional tie to this PR, but I want to give the issue requester a chance, so I will present a case. A bit dramatic perhaps, but a scenario:

We have a package repo now for a world of authors. A package may have something critical to tell a user from its functionality. A core dev may have reviewed that package and gave it a 👍 because it informed the user of something. The package gets deployed, used for months, and then it is found that something unwanted is occuring consistently to multiple users and no one knows why. The package author did their diligence - they sent output. The core dev did not consider this "feature" of Mudlet. The end-user did not think that would have been an effect of checking a box to not "Show the text you sent". But Mudlet scoped out the critical script output with that checkbox, and now people are scared to use packages from others anymore, the package repo dies, and people start looking for their ZMud license codes.

Let's enable presenting information to people wherever we can, unless the opt-out is very clear.

ZookaOnGit · 2025-06-13T12:37:05Z

I agree with the intent of the PR here.

As a user, I would expect this setting to filter out only what I type directly, but it actually affects much more.

This was what I originally thought the preference was for as well. I would also think that any 'send command directly to the game' options would follow this setting ie., Command boxes in aliases and keybindings. I would assume that send() would be toggleable as per the API.

Showing what text is sent is my preferred default option for a profile, as-is.

Agreed: I manually sent a command, I need feedback that this command has been sent, otherwise lag (whether network or game imposed) may see me sending it again with disastrous consequences.

I'm wary of adding more detail to the option

Agreed: we are trying to simplify preferences.

I note in the tooltip that the server can turn this option off. How does this affect scripts with/without the patch? Is the result expected?

Lastly, perhaps scripts should be using a 'best practice' with getConfig("showTextSent") if certain things should be displayed or not? e.g., always show for ultra laggy multi-command functions, or not for one-liner quick return functions. This patch at least gives that option now.

e.g.,

function autoEat()
   local echoCmd = getConfig("showTextSent")
   send("eat apple", echoCmd)
end

mpconley · 2025-06-17T01:21:32Z

I note in the tooltip that the server can turn this option off. How does this affect scripts with/without the patch? Is the result expected?

The note in the tooltip is geared toward the ECHO handling with the server, however it is possible for a script to toggle showTextSent. While setConfig("showTextSent") is a helpful function (perhaps used for a11y), it could be used with unwanted intent by a script, too.

Should certain settings come with a prompt to ensure the user is OK with changing the setting?

mpconley · 2025-06-17T01:22:32Z

Lastly, perhaps scripts should be using a 'best practice' with getConfig("showTextSent") if certain things should be displayed or not?

Great idea

Fix: Show send('text', true) on screen despite profile setting

8230017

mpconley requested a review from a team as a code owner May 31, 2025 22:19

mpconley self-assigned this May 31, 2025

vadi2 reviewed Jun 1, 2025

View reviewed changes

Merge branch 'development' into want_print_vs_print_command

874c93a

mpconley added 5 commits June 2, 2025 07:21

Merge branch 'development' into want_print_vs_print_command

8000

79f52fe

formatting

1be5e2d

Merge branch 'development' into want_print_vs_print_command

9123a30

Merge branch 'development' into want_print_vs_print_command

35f51f5

Merge branch 'development' into want_print_vs_print_command

a030964

SlySven reviewed Jun 13, 2025

View reviewed changes

Merge branch 'development' into want_print_vs_print_command

3e1a713

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Fix: Show send(cmd, true) on screen despite profile setting #7881

Fix: Show send(cmd, true) on screen despite profile setting #7881

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Fix: Show send(cmd, true) on screen despite profile setting #7881

Are you sure you want to change the base?

Fix: Show send(cmd, true) on screen despite profile setting #7881

Conversation

Uh oh!

Brief overview of PR changes/additions

Motivation for adding to Mudlet:

Other info (issues closed, discussion etc):

Uh oh!

Uh oh!

Test versions

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!