akinomyoga / ble.sh

Bash Line Editor―a line editor written in pure Bash with syntax highlighting, auto suggestions, vim modes, etc. for Bash interactive sessions.
BSD 3-Clause "New" or "Revised" License
2.33k stars 77 forks source link

Notify users when overwriting options? #412

Closed TheFantasticWarrior closed 1 month ago

TheFantasticWarrior commented 4 months ago

New to using linux and was taking a long time to figure out stty was reset by this script, and another long time figuring out where it is located Would be cool to either [1]notify the users what were changed that's not default settings (if possible), or [2]some customizations and document Another one small issue is when running make install after cd ble.sh it doesn't work example for [1]

no change from user -> no notify stty intr ... in .bashrc -> notify user option is overwritten

Also I hope changing that doesn't break anything in the script, still figuring things out, amazing script!

akinomyoga commented 4 months ago

[1]notify the users what were changed that's not default settings (if possible), or [2]some customizations and document

It is technically possible to implement either one literally, but I doubt if that helps. Although you haven't explained the problem (how you originally set up TTY and what you expected with that setup), I suspect you misunderstand something about ble.sh's manipulation of TTY because those requests don't seem to make sense to me.

I'd rather add an option to restore the original TTY state on the command execution. Does that work for you? If not, could you explain your setup and what you expect?

akinomyoga commented 4 months ago

Another one small issue is when running make install after cd ble.sh it doesn't work example for [1]

What does it mean? Could you explain it in more detail?

TheFantasticWarrior commented 4 months ago

Sorry, I'm very new to Linux.

Does that work for you? If not, could you explain your setup and what you expect?

I'm not entirely sure, I tried to use stty intr ^X in .bashrc because I set ^C to copy in urxvt, but stty -a restores to intr ^C right after the execution no matter where I put it in bashrc. There might be other settings that I will change, day by day, and maybe it will be conflicted with the script, so I'm asking if doing this for every setting will be possible, might be a stretch

Another one small issue is when running make install after cd ble.sh it doesn't work example for [1]

What does it mean? Could you explain it in more detail?

When I already have ble.sh directory(I think it was created when following the steps to install), and I cd into it to change the util.sh, the make fails trying to cd ble.sh again, and because I am already in the ble.sh directory and I have to cd .. then run the command again

akinomyoga commented 4 months ago

I'm not entirely sure, I tried to use stty intr ^X in .bashrc because I set ^C to copy in urxvt, but stty -a restores to intr ^C right after the execution no matter where I put it in bashrc.

What is the purpose of changing intr? If you change intr for canceling the execution of the currently running commands, I think "the option to save and restore the TTY state for the user command execution" would cleanly solve the problem. If you also intend to change the behavior of the line editor on pressing ^X by intr, you need a separate setting using ble-bind.

I'll later add the option and ask you to try it. It might take a few or several days because I'm currently testing another big change in ble.sh in a limited time.

There might be other settings that I will change, day by day, and maybe it will be conflicted with the script, so I'm asking if doing this for every setting will be possible, might be a stretch

I'd say it's not possible. I was reluctant to explain all those details, but I'll probably have to explain it after all.

First of all, ble.sh maintains two TTY states: one is for the line editor (let me call it the internal TTY state hereafter), and the other is for the command execution (let me call this the external TTY state). The internal TTY state needs to be properly configured for the line editor to work, while the external TTY state can be arbitrary in principle. I'm not sure whether you only want to change the external TTY state or both the internal and external TTY states, but let me assume you are specifically talking about the external TTY state. In principle, ble.sh might specify all the options in the internal TTY state to the proper ones. However, the problem is that the set of available options by stty and the ways to specify them depends on the system, and it is hard to perfectly specify the whole TTY state. So, ble.sh copies the external TTY state to the internal TTY state and then adjusts the known options needing modifications. If you configure the external TTY state to an unusual one, the internal TTY state is also affected, and it may break the line editor or cause some unpredictable behaviors.

When I already have ble.sh directory(I think it was created when following the steps to install), and I cd into it to change the util.sh, the make fails trying to cd ble.sh again, and because I am already in the ble.sh directory and I have to cd .. then run the command again

Thanks for the explanation. In that case, you can simply drop -C ble.sh from the arguments of the make command. make -C dir xxx is essentially the same as (cd dir && make xxx). There is technically a difference, but ble.sh's make configuration doesn't rely on the feature utilizing the difference between cd and -C.

TheFantasticWarrior commented 4 months ago

What is the purpose of changing intr? If you change intr for canceling the execution of the currently running commands, I think "the option to save and restore the TTY state for the user command execution" would cleanly solve the problem.

Yes that is probably the case, and yes I'm changing the external state to interrupt programs

There might be other settings that I will change, day by day, and maybe it will be conflicted with the script, so I'm asking if doing this for every setting will be possible, might be a stretch

I'd say it's not possible. I was reluctant to explain all those details, but I'll probably have to explain it after all.

I mean that I would change other settings and it would be nice to know what other things might conflict with the script, not just stty. I haven't read all the documentation yet, but a short list of what might conflict would help. I suggested notifying everything that was changed but I guess that's impossible

Thanks for the explanation. In that case, you can simply drop -C ble.sh from the arguments of the make command. make -C dir xxx is essentially the same as (cd dir && make xxx). There is technically a difference, but ble.sh's make configuration doesn't rely on the feature utilizing the difference between cd and -C.

Oh thanks for the explanation, I guess that's on me for not knowing make commands

akinomyoga commented 4 months ago

What is the purpose of changing intr? If you change intr for canceling the execution of the currently running commands, I think "the option to save and restore the TTY state for the user command execution" would cleanly solve the problem.

Yes that is probably the case, and yes I'm changing the external state to interrupt programs

I added the option bleopt term_stty_restore in commit e64b02b7a1558efab0bced51b0e3dac4f3021f86.

I mean that I would change other settings and it would be nice to know what other things might conflict with the script, not just stty. I haven't read all the documentation yet, but a short list of what might conflict would help. I suggested notifying everything that was changed but I guess that's impossible

The range of the settings that you are going to change is unclear. Since the line editor works by changing the state of the shell and the terminal (changing shell settings, shell variables, shell functions, characters on the terminal, colors, and all the other interactions with the terminal), if you require listing up everything, I have to explain everything about the implementation of the line editor. Or if everything is notified, the terminal display will be flooded with the notifications. It's technically possible, but it's hardly usable. If you want to experience it, maybe you can try typing the command and see what happens:

$ ble/function#push ble/base/xtrace/adjust : ; set -x

I added a section on a wiki page about the internal and external states, but it doesn't cover everything. Also, the list requires a large maintenance cost even though I don't think it's useful. We assume the users have sane settings and don't want to support the case where the user does something wrong in every aspect. When the user really wants to do it, I don't think a simple list would help. The user will finally have to read and understand the actual codebase to do that.

TheFantasticWarrior commented 4 months ago

My intention was to suggest a way for users to understand how their customizations may be affected by the script. My suggestion was specifically aimed at listing the changes that both the user and the script make, not all changes. This could help users understand how their customizations may be affected. I understand there's a lot of complexity to list all changes, especially for a script that modifies numerous settings.

I think I'll just modify the util.sh for now. Can I just change the line ble/array#push _ble_term_stty_flags_leave ... Will that break anything? Sorry for the issue and confusion I caused. Additionally, I understand if it's not feasible or necessary to incorporate the change I proposed. Do you think it's appropriate to close this issue now? Apologies once again for any inconvenience caused.

If you decide to keep the option, I don't think it is working as intended, it changes the keys to undef instead. I haven't changed stty settings yet, and I didn't do anything else between the commands. $ stty -a

speed 38400 baud; rows 36; columns 47;
line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U;
eof = ^D; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W;
lnext = <undef>; discard = <undef>;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb
cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip
-inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany
imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill
-ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl
-noflsh -xcase -tostop -echoprt echoctl echoke
-flusho -extproc

$ . ble-nightly/ble.sh [ble: reload] $ stty -a

speed 38400 baud; rows 36; columns 47;
line = 0;
intr = <undef>; quit = <undef>; erase = ^?;
kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q;
stop = ^S; susp = <undef>; rprnt = ^R;
werase = ^W; lnext = <undef>;
discard = <undef>; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb
cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip
-inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany
imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill
-ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon iexten -echo echoe echok -echonl
-noflsh -xcase -tostop -echoprt echoctl echoke
-flusho -extproc
akinomyoga commented 4 months ago

My suggestion was specifically aimed at listing the changes that both the user and the script make, not all changes.

Ah, OK. I misunderstood that you were going to change everything that shouldn't be usually changed. At the point of this reply https://github.com/akinomyoga/ble.sh/issues/412#issuecomment-1953401143, I thought you were talking about stty, so I thought

I'm asking if doing this for every setting will be possible

meant to change every setting in stty, which contains many settings that shouldn't be changed usually.

I think I'll just modify the util.sh for now. Can I just change the line ble/array#push _ble_term_stty_flags_leave ...

Actually, I initially thought to tell you about that way in the first reply, but I didn't do so because you need to be careful changing the content of the array _ble_term_stty_flags_leave: When you add something to the array _ble_term_stty_flags_leave, you also need to add a corresponding setting for the line editor in _ble_term_stty_flags_enter.

However, the proper setting for the line editor depends, so it would be difficult to explain briefly what to add in _ble_term_stty_flags_enter. For the c_cc settings, probably undef would be the ones to be added in _ble_term_stty_flags_enter. For the other settings, the default setting would be usually the one to add in _ble_term_stty_flags_enter, but there are some exceptions including ixon.

To summarize, you can add something to _ble_term_stty_flags_leave if you know what should be added to _ble_term_stty_flags_enter for the line editor.

If you decide to keep the option, I don't think it is working as intended, it changes the keys to undef instead. I haven't changed stty settings yet, and I didn't do anything else between the commands.

OK. I could reproduce the problem. I added a fix for bleopt term_stty_restore in commit ef8272a4. There were two problems:

  1. What is your Bash version? There is a workaround for Bash 5.2 with stty (which is only enabled in Bash 5.2). That workaround is interfering with bleopt term_stty_restore. The problem happens when you load ble.sh twice in the session. I adjusted the workaround in commit ef8272a4.
  2. Also, it doesn't work when the prompt attach is used (which is used when you didn't run ble-attach in ~/.bashrc). When the prompt attach is used, ble.sh captures Readline's internal TTY state as an ble.sh's external state, which causes the problem. One needs to capture an external state in ~/.bashrc. I decided to capture the external state at the point where bleopt term_stty_restore=1 is specified (yet there is limitation in this implementation; I mentioned it in bleopt term_stty_restore).

Could you update ble.sh by running ble-update and see if the problem is fixed?