pane.send_key(literal=False) not sending c-c
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
Línea de trabajo
Start at the pane.send_keys entry point and reproduce the supplied libtmux 0.8.5 and tmux 2.8 example, comparing literal and suppress_history behavior. Review how key sequences and history suppression are handled, then confirm with maintainers whether the expected outcome is a behavior change or documentation; done means the chosen behavior is implemented or clearly documented.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Running the code listed below just sends the characters c-c to the pane instead of the Control + C key combination used to close a program but if you add the suppress_history=False flag then it works as intended. I wasn't sure if there was something with my specific environment or software versions that was causing this. I am using libtmux version 0.8.5 and tmux 2.8. Is anyone else having this issue?
session = tmux.find_where({'session_name': 'TEST')
window = session.list_windows()[0]
pane = window.list_panes()[0]
pane.send_keys('c-c', literal=False)
I was going to send a pull request but could think of a couple different ways to handle this.
- The easiest way would be to just document this behavior to make everyone aware that the history suppression must be turned off in order for keys like control to be sent.
- History suppression could also be turned off by default and explain in the documentation that if it is turned on keys will not be sent. I don't see this flag being all that important (at least not to me) and since it's an extra feature which is not normal to regular tmux turning it off by default shouldn't be a huge deal.
- Another way to fix it would be to make
literal=Truethe default and remove the history prefix from the non-literal one. Since the only reason to useliteral=Falsethen would be to send actual keys instead of text having the history suppression off would not affect anything since those keys are not stored in shell history. - The only other idea I had was somehow determining what is being sent is a key not just some characters then turning history suppression off. I couldn't think of any easy way to do this so it's likely not worth considering.
- Lenguaje dominante
- Python
- Estrellas
- 1.2k
- Forks
- 127
- Merge medio
- 2 h 13 min
- PR fusionados (30 d)
- 1
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de tmux-python/libtmux
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
tmux-python/libtmux#759 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
tmux-python/libtmux#745 · 2 comentarios ·
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
tmux-python/libtmux#744 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
tmux-python/libtmux#731 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
tmux-python/libtmux#654 ·
Todos los issues de tmux-python/libtmux
Issues similares
-
[Bug] reef-hermes tells me to resume with hermes --resume, which does not work from my shell Abiertoarea: harness bug status: needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Human-Agent-Society/reef#625 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
learningequality/kolibri#15351 · 2 comentarios ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Name consistency Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
eellak/triplestore#65 · 1 comentario ·