Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Tue, Nov 14, 2023 at 09:57:25PM +0100, Samuel Thibault wrote: >Jason J.G. White, le mar. 14 nov. 2023 08:56:27 -0500, a ecrit: >> On 14/11/23 08:35, Christian Schoepplein wrote: >> >> After installing the two gir packages with the fix from your personal >> repo >> >> all things are good again: >> >> You'll need to mark the appropriate libvte packages as on hold until Samuel's >> patch is accepted upstream, and the upstream version enters Debian. >> Otherwise, >> Samuel's packages will be replaced every time a new upstream version enters >> the >> repository you're using. > >The debian package 0.74.1-1 does contain my fix as kindly patched by the >debian maintainer, Jeremy Bicha. Ah, OK, thats why it worked with the 0.74.1-1 package before. >Christian, can you confirm by running > >zgrep libvte-2.91-0 /var/log/dpkg.log. > >that the libvte-2.91-0 package (which really contains the binary built >with my patch) was upgraded before you noticed the issue? And thus it's >really *exactly* the upgrade of the gir packages that brought the issue? I' ve reinstalled and reconfigured all regarding packages and everything seems to be fine again. Currently the 0.74.1-1 package is installed. I have no idea what was going on yesterday where the problems with screen refreshing suddenly occured again... Sorry for the confusion... Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, This is all very odd. Jason J.G. White, le mar. 14 nov. 2023 08:56:27 -0500, a ecrit: > > On 14/11/23 08:35, Christian Schoepplein wrote: > > After installing the two gir packages with the fix from your personal repo > > all things are good again: > > You'll need to mark the appropriate libvte packages as on hold until Samuel's > patch is accepted upstream, and the upstream version enters Debian. Otherwise, > Samuel's packages will be replaced every time a new upstream version enters > the > repository you're using. The debian package 0.74.1-1 does contain my fix as kindly patched by the debian maintainer, Jeremy Bicha. So the Debian package is supposed to provide the same fix as my package. Christian, can you confirm by running zgrep libvte-2.91-0 /var/log/dpkg.log. that the libvte-2.91-0 package (which really contains the binary built with my patch) was upgraded before you noticed the issue? And thus it's really *exactly* the upgrade of the gir packages that brought the issue? (which is really odd since gir packages don't ship implementations, they just provide interfaces) Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Tue, Nov 14, 2023 at 08:56:27AM -0500, Jason J.G. White wrote: > On 14/11/23 08:35, Christian Schoepplein wrote: > > > After installing the two gir packages with the fix from your personal > > repo > > all things are good again: > > You'll need to mark the appropriate libvte packages as on hold until > Samuel's patch is accepted upstream, and the upstream version enters > Debian. Otherwise, Samuel's packages will be replaced every time a new > upstream version enters the repository you're using. OK, thanks. I've pinned Samuels packages but removed this some weeks ago. Since then everything was working fine till gir was updated... Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On 14/11/23 08:35, Christian Schoepplein wrote: After installing the two gir packages with the fix from your personal repo all things are good again: You'll need to mark the appropriate libvte packages as on hold until Samuel's patch is accepted upstream, and the upstream version enters Debian. Otherwise, Samuel's packages will be replaced every time a new upstream version enters the repository you're using.
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Mon, Sep 11, 2023 at 02:27:41AM +0200, Samuel Thibault wrote: >I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an >improved patch. Could people try it? I have also uploaded patched Debian >packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ I was using this patched packages and lately the packages for Debian Testing and it was perfectly possible to work in mate-terminal. However, a few days ago some packages where updated to an newer version and since then again the screen content is not longer refreshed in some situations. This are the currently installed packages that again cause problems with the screen refreshing in mate-terminal: cs@d5421:~$ dpkg -l | grep vte ii gir1.2-vte-2.91:amd64 0.74.1-1 ii gir1.2-vte-3.91:amd64 0.74.1-1 ii libvte-2.91-0:amd64 0.74.1-1 ii libvte-2.91-common 0.74.1-1 ii libvte-2.91-dev:amd64 0.74.1-1 ii libvte-2.91-gtk4-0:amd640.74.1-1 ii libvte-2.91-gtk4-dev:amd64 0.74.1-1 ii libvte-common 1:0.28.2-6 ii libvted-3-0:amd64 3.10.0-2+b1 After installing the two gir packages with the fix from your personal repo all things are good again: cs@d5421:~$ dpkg -l | grep vte ii gir1.2-vte-2.91:amd64 0.73.99-1+fix ii gir1.2-vte-3.91:amd64 0.73.99-1+fix ii libvte-2.91-0:amd64 0.74.1-1 ii libvte-2.91-common 0.74.1-1 ii libvte-2.91-dev:amd64 0.74.1-1 ii libvte-2.91-gtk4-0:amd640.74.1-1 ii libvte-2.91-gtk4-dev:amd64 0.74.1-1 ii libvte-common 1:0.28.2-6 ii libvted-3-0:amd64 3.10.0-2+b1 These are the packages with vte that have been updated lately: cs@d5421:~$ grep vte /var/log/dpkg.log 2023-11-10 10:28:28 upgrade libvted-3-0:amd64 3.10.0-2 3.10.0-2+b1 2023-11-10 10:28:28 status half-configured libvted-3-0:amd64 3.10.0-2 2023-11-10 10:28:28 status unpacked libvted-3-0:amd64 3.10.0-2 2023-11-10 10:28:28 status half-installed libvted-3-0:amd64 3.10.0-2 2023-11-10 10:28:28 status unpacked libvted-3-0:amd64 3.10.0-2+b1 2023-11-10 10:28:29 configure libvted-3-0:amd64 3.10.0-2+b1 2023-11-10 10:28:29 status unpacked libvted-3-0:amd64 3.10.0-2+b1 2023-11-10 10:28:29 status half-configured libvted-3-0:amd64 3.10.0-2+b1 2023-11-10 10:28:29 status installed libvted-3-0:amd64 3.10.0-2+b1 2023-11-14 14:06:31 upgrade gir1.2-vte-2.91:amd64 0.74.1-1 0.73.99-1+fix 2023-11-14 14:06:31 status half-configured gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:06:31 status unpacked gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:06:31 status half-installed gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:06:31 status unpacked gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 upgrade gir1.2-vte-3.91:amd64 0.74.1-1 0.73.99-1+fix 2023-11-14 14:06:31 status half-configured gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:06:31 status unpacked gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:06:31 status half-installed gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:06:31 status unpacked gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 configure gir1.2-vte-2.91:amd64 0.73.99-1+fix 0.73.99-1+fix 2023-11-14 14:06:31 status half-configured gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 status installed gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 configure gir1.2-vte-3.91:amd64 0.73.99-1+fix 0.73.99-1+fix 2023-11-14 14:06:31 status half-configured gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 status installed gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:13:32 upgrade gir1.2-vte-2.91:amd64 0.73.99-1+fix 0.74.1-1 2023-11-14 14:13:32 status half-configured gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:13:32 status unpacked gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:13:32 status half-installed gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:13:32 status unpacked gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:13:33 upgrade gir1.2-vte-3.91:amd64 0.73.99-1+fix 0.74.1-1 2023-11-14 14:13:33 status half-configured gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:13:33 status unpacked gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:13:33 status half-installed gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:13:33 status unpacked gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 configure gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 status unpacked gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 status half-configured gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 status installed gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 configure gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:13:33 status unpacked gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:13:33 status half-configured gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:13:33 status installed gir1.2-vte-2.91:amd64
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello,
Interesting... So it's tmux as source which poses problem,
for whatever reason. And you don't have a /etc/tmux.conf or a
~/.config/tmux/tmux.conf?
Christian Schoepplein, le mer. 25 oct. 2023 09:50:26 +0200, a ecrit:
> If I open a tmux session and copy multiline content from this session with
> the new flatfview feature from orca and not with brltty's COPY_RECT feature
Ok, how do you copy from orca exactly? The
FLAT_REVIEW_COPY = _("Copy the contents under flat review to the clipboard")
Orca command? Or braille routing keys?
Could you kill your xbrlapi, then try to run
xbrlapi -v -n 2> log
then perform the failing copy/paste, and send us the log?
Also, could you try if you can reproduce the issue with orca without
xbrlapi running?
Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello Samuel, On Tue, Oct 24, 2023 at 07:59:44PM +0200, Samuel Thibault wrote: >What do you get when you paste into another graphical application such >as pluma or gedit? And conversely when pasting into tmux? When I am in a tmux session and copy multiline text with brltty's COPY_RECT command * the text is inserted in reverse order and with broken lines in another terminal, no matter if there is a tmux session running or not * is inserted correctly in pluma. This does not happen if I copy the multiline text with brltty's COPY_RECT command when I am not in a tmux session. >> I've also tested it with the new show flatview contents feature of orca 45 >> during working in a tmux session. There the same issue is happening if I >> copy multiline text and insert it using different editors. > >I don't see the relation between flatview and copy? Are you using a copy >feature from orca? No. I just tested if the same thing occures if I do not use brltty's COPY_RECT feature to get multiline content into the clipboard. If I open a tmux session and copy multiline content from this session with the new flatfview feature from orca and not with brltty's COPY_RECT feature it is also broken when I insert this multiline text in an editor running in a terminal. Inserting the same content in pluma works fine. So it does not matter if copying content with brltty or with orca, but it seems to be related where the content of the clipboard is inserted. I hope the problem is more clear now. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, Please answer all questions :) What do you get when you paste into another graphical application such as pluma or gedit? And conversely when pasting into tmux? Christian Schoepplein, le mar. 24 oct. 2023 17:07:59 +0200, a ecrit: > I've also tested it with the new show flatview contents feature of orca 45 > during working in a tmux session. There the same issue is happening if I > copy multiline text and insert it using different editors. I don't see the relation between flatview and copy? Are you using a copy feature from orca? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi again, On Tue, Oct 24, 2023 at 04:58:12PM +0200, Christian Schoepplein wrote: >Hi samuel, > >On Sun, Oct 22, 2023 at 10:38:41PM +0200, Samuel Thibault wrote: >>Samuel Thibault, le dim. 22 oct. 2023 22:36:34 +0200, a ecrit: >>> Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: >>> > The issue is with copying content via the cliphboard feature of brltty if >>> > I >>> > am inside a tmux session which I need to use very ofthen for my daily job. >>> > >>> > The original content I like to copy looks like this: >>> > >>> > borg_backup_client_exclude_host_specific: >>> > - /rpool >>> > - /tank >>> >>> Does it happen with whatever kind of content, or is it specific to this >>> kind of content? Is this showing up in an editor? (which editor?) or as >>> output of a command? > >Its happening with any content and in different editors, e.g. vim or nano. > >>Also, I forgot: are you using COPY_LINE or COPY_RECT? > >I tried both. > >If I copy a multiline text with COPY_LINE and paste it the whole content is >inserted on one line. I think this is the expected behaviour, at least I >understand brltty's help this way. No line breaks are copied or the content >is inserted as one long line. > >If I use COPY_RECT, which is the way I normaly would copy multiline content, >the issue is happening and the content is inserted in reverse order and with >broken line breaks. > >I'll test if the internal tmux copy and paste function is working without a >problem if I've found out how to use it, currently I am to stupid to >understand how it works :-). I've also tested it with the new show flatview contents feature of orca 45 during working in a tmux session. There the same issue is happening if I copy multiline text and insert it using different editors. BTW.: I am on Debian Testing and I am using the libvte packages from your package repository. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi samuel, On Sun, Oct 22, 2023 at 10:38:41PM +0200, Samuel Thibault wrote: >Samuel Thibault, le dim. 22 oct. 2023 22:36:34 +0200, a ecrit: >> Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: >> > The issue is with copying content via the cliphboard feature of brltty if >> > I >> > am inside a tmux session which I need to use very ofthen for my daily job. >> > >> > The original content I like to copy looks like this: >> > >> > borg_backup_client_exclude_host_specific: >> > - /rpool >> > - /tank >> >> Does it happen with whatever kind of content, or is it specific to this >> kind of content? Is this showing up in an editor? (which editor?) or as >> output of a command? Its happening with any content and in different editors, e.g. vim or nano. >Also, I forgot: are you using COPY_LINE or COPY_RECT? I tried both. If I copy a multiline text with COPY_LINE and paste it the whole content is inserted on one line. I think this is the expected behaviour, at least I understand brltty's help this way. No line breaks are copied or the content is inserted as one long line. If I use COPY_RECT, which is the way I normaly would copy multiline content, the issue is happening and the content is inserted in reverse order and with broken line breaks. I'll test if the internal tmux copy and paste function is working without a problem if I've found out how to use it, currently I am to stupid to understand how it works :-). Ciao and thanks, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Samuel Thibault, le dim. 22 oct. 2023 22:36:34 +0200, a ecrit: > Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: > > The issue is with copying content via the cliphboard feature of brltty if I > > am inside a tmux session which I need to use very ofthen for my daily job. > > > > The original content I like to copy looks like this: > > > > borg_backup_client_exclude_host_specific: > > - /rpool > > - /tank > > Does it happen with whatever kind of content, or is it specific to this > kind of content? Is this showing up in an editor? (which editor?) or as > output of a command? Also, I forgot: are you using COPY_LINE or COPY_RECT? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: > The issue is with copying content via the cliphboard feature of brltty if I > am inside a tmux session which I need to use very ofthen for my daily job. > > The original content I like to copy looks like this: > > borg_backup_client_exclude_host_specific: > - /rpool > - /tank Does it happen with whatever kind of content, or is it specific to this kind of content? Is this showing up in an editor? (which editor?) or as output of a command? > Outside a tmux session copying this content works quite well. But inside a > tmux session I get this when inserting the textblock into another file: Into what are you pasting? An editor? (which editor?) What do you get when you paste into another graphical application such as pluma or gedit? And conversely when pasting into tmux? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel and all,
there is another strange issue with the terminal, but I do not know if it is
libvte, tmux or maybe brltty related.
I am using brltty in the terminal, the braille functionality of orca is
turned of in the orca profile settings for mate-terminal. In
/etc/X11/Xsession.d/90xbrlapi I have replaced the original entry to start
brltty like this:
"${brltty}" -b ba -s sd -x a2 --autospeak-threshold=good -Z on -N 2>/dev/null
The issue is with copying content via the cliphboard feature of brltty if I
am inside a tmux session which I need to use very ofthen for my daily job.
The original content I like to copy looks like this:
borg_backup_client_exclude_host_specific:
- /rpool
- /tank
Outside a tmux session copying this content works quite well. But inside a
tmux session I get this when inserting the textblock into another file:
M - /tank
M - /rpool
borg_backup_client_exclude_host_specific:
I do not have any special tmux settings configured.
Its clear to me that this is a very specific problem which might be related
to what so ever is involved, tmux, brltty, lbvte, but maybe someone
has an idea whats going on there and how to fix this. I am pretty sure that
this behaviour is new, I use the copy-paste feature of brltty quite ofthen
and I can't remember I had this issue in the past...
Ciao,
Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Fri, Oct 06, 2023 at 11:03:01PM +0200, Samuel Thibault wrote: >Which exact version are you testing? Please use > >dpkg -l libvte-2.91-0:amd64 > >otherwise I cannot say anything about your results. My package with >latest changes is versioned 0.73.99-1+fix, not 0.74. I got version 0.74.0-2 while updating my system today. Thats why your packages got overwritten. But I've managed to install the older packages with the fix from your repo now and everything is fine again. >> Whats the current state of the bug? > >We are waiting for feedback to make sure that things are fixed without >introducing regressions. OK, thanks for the update. Hope the fix will make it to the official libvte package soon. >> Can I somehow install the old 0.73 packages from your repo, > >Sure, see the readme file. > >> Samuel, or can you provide the 0.74 packages with the fix please or >> shall I try to build the new packages myself and include the patch? > >No need to build anything, just pick up my packages. As said, I've managed to install the older packages now and everything is fine again. But the newer packages from the updates still want to be installed when running apt upgrade I gues I've to pinn the libvte package to the version from your repo to exclude this packages from the updates till the fix has made it into a newer debian package? Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le ven. 06 oct. 2023 20:52:20 +0200, a ecrit: > On Mon, Sep 11, 2023 at 02:27:41AM +0200, Samuel Thibault wrote: > > > >I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an > >improved patch. Could people try it? I have also uploaded patched Debian > >packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ > > I was on vacation for three weeks and updated my Debian testing system > today. Also the libvte packages have been updated to a newer version, 0.74, > and the packages with all fixes from your repo, Samuel, Which exact version are you testing? Please use dpkg -l libvte-2.91-0:amd64 otherwise I cannot say anything about your results. My package with latest changes is versioned 0.73.99-1+fix, not 0.74. > I took a look at the bug report and into the changelogs, but its not really > clear to me, if the fixes are included in the 0.74 version now or if they > are still not included. They are not. > Whats the current state of the bug? We are waiting for feedback to make sure that things are fixed without introducing regressions. > Can I somehow install the old 0.73 packages from your repo, Sure, see the readme file. > Samuel, or can you provide the 0.74 packages with the fix please or > shall I try to build the new packages myself and include the patch? No need to build anything, just pick up my packages. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel and all, On Mon, Sep 11, 2023 at 02:27:41AM +0200, Samuel Thibault wrote: > >I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an >improved patch. Could people try it? I have also uploaded patched Debian >packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ I was on vacation for three weeks and updated my Debian testing system today. Also the libvte packages have been updated to a newer version, 0.74, and the packages with all fixes from your repo, Samuel, that worked so fine with the terminal have been overwritten. With this newer versions of the packages at least some problems that have been fixed before do occure again. E.g. the screen is ruptured again when using apt and the progressbar is displayed at the bottom of the screen. Also I was able to use vim perfectly with the 0.73 packages, with the new 0.74 versions the focus again is moved to the command line of the editor. I took a look at the bug report and into the changelogs, but its not really clear to me, if the fixes are included in the 0.74 version now or if they are still not included. Whats the current state of the bug? Is the fix included in the 0.74 packages or are the problems, that I have now, new? Can I somehow install the old 0.73 packages from your repo, Samuel, or can you provide the 0.74 packages with the fix please or shall I try to build the new packages myself and include the patch? Ciao and thanks for your help, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Tue, Sep 12, 2023 at 10:31:27PM +0200, Samuel Thibault wrote: >Samuel Thibault, le mar. 12 sept. 2023 14:07:35 +0200, a ecrit: >> Christian Schoepplein, le mar. 12 sept. 2023 10:38:02 +0200, a ecrit: >> > But I noticed another thing. When I switch away from the terminal, e.g. >> > into >> > another terminal, and then switch back into the terminal with the >> > translate >> > command everything looks good and the output is in a seperate line. >> > Strange... >> >> Ok, I guess I see what you mean. > >No, I had misunderstood, I didn't realize that you were saying that the >command and its output were getting glued together on the same line. > >Apparently brltty gets a bit confused when removing the trailing '\n'. >Better be safe with screen readers and keep it always, I have updated >the patches and the built package. Thank you very much. The new packages from yesterday evening are a big progress and IMHO the biggest issues I had with the terminal seem to be fixed now. This is so much better now, really great! There is still an issue when deleting lines in nano, but unfortunately I can not reproduce this behaviour all the time and I only have it in mutt. I'll try to find out if this is related to some settings in mutt. Also in nano sometimes empty lines are not always shown correctly on the brailledevice when navigating through a file. This seems also to be an issue with brltty I think, because it only occures if I navigate the text with the keyboard and not with the brailledisplay. I'll also try to find out more about it and report back if I have a way how to reproduce it. Ciao and thank you so much again, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Samuel Thibault, le mar. 12 sept. 2023 14:07:35 +0200, a ecrit: > Christian Schoepplein, le mar. 12 sept. 2023 10:38:02 +0200, a ecrit: > > But I noticed another thing. When I switch away from the terminal, e.g. > > into > > another terminal, and then switch back into the terminal with the translate > > command everything looks good and the output is in a seperate line. > > Strange... > > Ok, I guess I see what you mean. No, I had misunderstood, I didn't realize that you were saying that the command and its output were getting glued together on the same line. Apparently brltty gets a bit confused when removing the trailing '\n'. Better be safe with screen readers and keep it always, I have updated the patches and the built package. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le mar. 12 sept. 2023 10:38:02 +0200, a ecrit: > But I noticed another thing. When I switch away from the terminal, e.g. into > another terminal, and then switch back into the terminal with the translate > command everything looks good and the output is in a seperate line. > Strange... Ok, I guess I see what you mean. When a command produces more characters than the width of the terminal, they are put on a single ligne (from the point of view of brltty). When going out and coming back to the terminal, you do get separate lines split as per the width of the terminal. That's unrelated and will to be fixed another way. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi, Christian Schoepplein (2023/09/12 13:30 +0200): > I do have the problem not only with translate, this was just an example > command to show the issue. I have the same problems with apt and other > commands too, so the issue IMHO is not related to translate only. Yes that's what I was trying to say. I was suggesting that the issue may have to do with the difference in diwth between your terminal and Samuel's one. Seb.
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Seb and all, On Tue, Sep 12, 2023 at 10:52:39AM +0200, Sébastien Hinderer wrote: >May it be the case that translate adjusts its output to the size of the >terminal? I do have the problem not only with translate, this was just an example command to show the issue. I have the same problems with apt and other commands too, so the issue IMHO is not related to translate only. However, it seems to be related only to commands that return one line, but unfortunately not to all. E.g. git version works perfectly, the translate example or helm version show the output in the same line. Maybe there is something different how the programs crea te line breaks or whatever, I have no idea :-(. I'll post more problematic examples if I stumple over them. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, May it be the case that translate adjusts its output to the size of the terminal? That may enxplain the difference observed in behaviours between Samuel and Christian. Seb.
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Tue, Sep 12, 2023 at 09:10:56AM +0200, Samuel Thibault wrote:
>Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit:
>> The following command displays
>> the output in a long line instead dividing it into seperate lines:
>>
>> translate -i occure
>
>On my system it does output
>
>Vorkommen {n} (von etw.) [min.] | Erdölvorkommen {n} | Vorkommen [...]
On my system it looks like this:
cs@d5421:~$ translate -i occure Vorkommen {n} (von etw.) [min.] |
Erdölvorkommen {n} | Vorkommen in Linsenform; linsenförmiges Vorkommen |
schichtförmiges Vorkommen :: presence; occurrence (of sth.) | oil occurrence |
lens-shaped occurence; lenticularity | occurrence in strata
cs@d5421:~$
But I noticed another thing. When I switch away from the terminal, e.g. into
another terminal, and then switch back into the terminal with the translate
command everything looks good and the output is in a seperate line.
Strange...
>So it's the output of the command itself which is a one-liner, mate
>can't do anything about it :)
I had the same behaviour also with commands that output more then one line,
e.g. with apt. Maybe there is something wrong with refreshing the screen,
because everything seems to be fine when moving to another window
and back again in the window where the problem occured.
>> ls -1 /dev > test.txt
>>
>> Open the test.txt file, scrol down some pages and then delete a line with
>> ctrl+k.
>>
>> On my machine I have to clear the screen with ctrl+l to see that the line
>> has been removed on the braille display.
>
>You mean that the braille display is still showing the very line you
>wanted to remove?
Yes.
>I am not able to reproduce this. Just to be precise:
>
>- nano test.txt
>- press page down
>(get to some line shown on the braille display)
>- press control-k
>(the line is supposed to be replaced by the next line on the braille
>display)
Yes, thats exactly what I am doing.
>Do you perhaps have some particular configuration in nano?
No, I don't. But maybe I have some mate-terminal settings that cause this
problems. I've resetted mate-terminal with the following command now to make
sure that no mate-terminal settings cause this strange problems:
dconf reset -f /org/mate/terminal/
Ciao,
Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Tue, Sep 12, 2023 at 09:06:00AM +0200, Samuel Thibault wrote: >Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit: >> But there are still a few problematic things: > >Are these regressions over the previous state? No. Its much better now, also with the other problems I still have. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit:
> The following command displays
> the output in a long line instead dividing it into seperate lines:
>
> translate -i occure
On my system it does output
Vorkommen {n} (von etw.) [min.] | Erdölvorkommen {n} | Vorkommen [...]
So it's the output of the command itself which is a one-liner, mate
can't do anything about it :)
> Also the problem that the screen content is not refreshed when deleting
> lines in a long text e.g. in the nano editor is still there. Just try the
> following:
>
> ls -1 /dev > test.txt
>
> Open the test.txt file, scrol down some pages and then delete a line with
> ctrl+k.
>
> On my machine I have to clear the screen with ctrl+l to see that the line
> has been removed on the braille display.
You mean that the braille display is still showing the very line you
wanted to remove? I am not able to reproduce this. Just to be precise:
- nano test.txt
- press page down
(get to some line shown on the braille display)
- press control-k
(the line is supposed to be replaced by the next line on the braille
display)
Do you perhaps have some particular configuration in nano?
Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit: > But there are still a few problematic things: Are these regressions over the previous state? Not that I don't want to fix them, but I want to get something committed so we can make some progress, even if not perfect yet. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Tue, Sep 12, 2023 at 12:36:28AM +0200, Jérémy Prego wrote: >for me, everything looks good compared to the version in debian testing I've also installed the packages you build yesterday and did some testing. The problem with the statusbar from apt seems to be gone, very cool, and also a ruptured console, that I had very ofthen after leaving mutt, did not occure so far. Thats a big improvement. But there are still a few problematic things: In some situations line breaks are not interpreted correctly. E.g. if you install packages with apt and the triggers are processed you normaly get a seperate line for every trigger. With the new versions of the packages the output for all triggers are displayed in one long line. You can trigger this behaviour also with the translate tool. The following command displays the output in a long line instead dividing it into seperate lines: translate -i occure Also the problem that the screen content is not refreshed when deleting lines in a long text e.g. in the nano editor is still there. Just try the following: ls -1 /dev > test.txt Open the test.txt file, scrol down some pages and then delete a line with ctrl+k. On my machine I have to clear the screen with ctrl+l to see that the line has been removed on the braille display. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Le 11/09/2023 à 20:49, Samuel Thibault a écrit : Jérémy Prego, le lun. 11 sept. 2023 09:21:38 +0200, a ecrit: Le 11/09/2023 à 09:01, Samuel Thibault a écrit : Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: I noticed a small problem 1. when you open a large file using cat file.txt |less and press enter to go down in the file, orca almost always pronounces the first 2 letters of the line before reading the whole line. Is this a regression over the previous versions or not? yes, it's a regression. i don't have this behavior with the version in debian testing Ok, I see the issue. I have updated the patches and package to merge the additions, could you please re-test? I can confirm that it's much better! after a quick test, I don't have any more problems, I'll test it in use, but for me, everything looks good compared to the version in debian testing thanks ! Samuel Jerem libt.tld_type is 1, lib_t.tld_source_file is '/usr/local/lib/aarch64-linux-gnu/perl/5.30.0/auto/share/dist/Mail-DMARC-opendmarc/effective_tld_names.dat' ___ orca mailing list o...@freelists.org https://www.freelists.org/list/orca Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le lun. 11 sept. 2023 11:38:26 +0200, a ecrit: > A way to rupture the console is to update the packages on a system with apt. > The progress line at the bottom seems to trigger the unwanted behaviour very > reproducable :-). I know, that was the original testcase that triggered opening bug #88 ;) Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Jérémy Prego, le lun. 11 sept. 2023 09:21:38 +0200, a ecrit: > Le 11/09/2023 à 09:01, Samuel Thibault a écrit : > > Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: > > > I noticed a small problem > > > > > > 1. when you open a large file using cat file.txt |less and press enter to > > > go > > > down in the file, orca almost always pronounces the first 2 letters of the > > > line before reading the whole line. > > Is this a regression over the previous versions or not? > > yes, it's a regression. i don't have this behavior with the version in debian > testing Ok, I see the issue. I have updated the patches and package to merge the additions, could you please re-test? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Mon, Sep 11, 2023 at 09:25:44AM +0200, Samuel Thibault wrote: >Ok, is it more problematic than the various erratic behaviors that the >debian testing version has? Yes :-(. For me also the new patch brings no real improvement but thank you so much to continue working on it. A way to rupture the console is to update the packages on a system with apt. The progress line at the bottom seems to trigger the unwanted behaviour very reproducable :-). Also with the new patch I had problems to quote e.g. your email in mutt using the nano editor. I deleted the lines I did not want to quote with ctrl+k, but the screen did not refresh and nothing happens on the braille display when using the shortcut to delete the lines. I had to press ctrl+l to clear the screen to get content refreshed. Just out of curiosity: Is the problem related to libvte in general or is it related to the version in Debian? I am also using Debian testing. Because I have to use the terminal a lot I wonder if it could help to switch to another distro temporarily or on a second machine, which is really not what I want, but I need the system for my daily job... Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le lun. 11 sept. 2023 11:38:26 +0200, a ecrit: > Just out of curiosity: Is the problem related to libvte in general or is it > related to the version in Debian? It's completely a vte bug. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Jérémy Prego, le lun. 11 sept. 2023 09:21:38 +0200, a ecrit: > Le 11/09/2023 à 09:01, Samuel Thibault a écrit : > > Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: > > > I noticed a small problem > > > > > > 1. when you open a large file using cat file.txt |less and press enter to > > > go > > > down in the file, orca almost always pronounces the first 2 letters of the > > > line before reading the whole line. > > Is this a regression over the previous versions or not? > yes, it's a regression. i don't have this behavior with the version in debian > testing Ok, is it more problematic than the various erratic behaviors that the debian testing version has? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Le 11/09/2023 à 09:01, Samuel Thibault a écrit : Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: I noticed a small problem 1. when you open a large file using cat file.txt |less and press enter to go down in the file, orca almost always pronounces the first 2 letters of the line before reading the whole line. Is this a regression over the previous versions or not? yes, it's a regression. i don't have this behavior with the version in debian testing Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: > I noticed a small problem > > 1. when you open a large file using cat file.txt |less and press enter to go > down in the file, orca almost always pronounces the first 2 letters of the > line before reading the whole line. Is this a regression over the previous versions or not? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
hello, I've just tested this version out of curiosity. I noticed a small problem 1. when you open a large file using cat file.txt |less and press enter to go down in the file, orca almost always pronounces the first 2 letters of the line before reading the whole line. Jerem Le 11/09/2023 à 02:27, Samuel Thibault a écrit : Hello, I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an improved patch. Could people try it? I have also uploaded patched Debian packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ Please test so we can at last get this fixed! Samuel ___ orca mailing list o...@freelists.org https://www.freelists.org/list/orca Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an improved patch. Could people try it? I have also uploaded patched Debian packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ Please test so we can at last get this fixed! Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Sun, Sep 03, 2023 at 11:18:49PM +0200, Samuel Thibault wrote: > Alexander Epaneshnikov, le lun. 04 sept. 2023 00:08:42 +0300, a ecrit: > > in order to return this fix, where the correction of the diff algorithm > > should occur in libvte or in orca? > > In vte. Diff algorithms should be done as early as possible to avoid > overflowing the rest. OK. thanks for the answer. if there is any news please keep me posted. for now, I'll just keep this patch locally. > Samuel -- Sincerely, Alexander
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Alexander Epaneshnikov, le lun. 04 sept. 2023 00:08:42 +0300, a ecrit: > in order to return this fix, where the correction of the diff algorithm > should occur in libvte or in orca? In vte. Diff algorithms should be done as early as possible to avoid overflowing the rest. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Sun, Sep 03, 2023 at 09:39:56PM +0200, Jérémy Prego wrote: > hello, hello Jérémy. > I've just found the library that's causing the problem. > > it's the libvte-2.91-0 library in version 0.73.93-1 currently in debian > testing. downgrading to version 0.72.2-3 solves the problem. that happened because bug [1] was fixed in libvte. in fact I think this fix improved more than it got worse, so I'm sad that it was rolled back. > i'm relieved! :) > > I was thinking of making a bug report in debian against the package, but I > confess I don't know what to put in it. A question for Samuel. in order to return this fix, where the correction of the diff algorithm should occur in libvte or in orca? because as a vte-based terminal every day user, I can't imagine life without this patch. ps Well, this patch has a difficult fate. > Jerem [1]: https://gitlab.gnome.org/GNOME/vte/-/issues/88 -- Sincerely, Alexander
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
I've just seen that version 0.73.99-1, which will soon be available in sid and then in testing, solves the problem for me with this version as well. so for me the problem is closed, as it will soon be corrected in debian. Jerem Le 03/09/2023 à 23:08, Alexander Epaneshnikov a écrit : On Sun, Sep 03, 2023 at 09:39:56PM +0200, Jérémy Prego wrote: hello, hello Jérémy. I've just found the library that's causing the problem. it's the libvte-2.91-0 library in version 0.73.93-1 currently in debian testing. downgrading to version 0.72.2-3 solves the problem. that happened because bug [1] was fixed in libvte. in fact I think this fix improved more than it got worse, so I'm sad that it was rolled back. i'm relieved! :) I was thinking of making a bug report in debian against the package, but I confess I don't know what to put in it. A question for Samuel. in order to return this fix, where the correction of the diff algorithm should occur in libvte or in orca? because as a vte-based terminal every day user, I can't imagine life without this patch. ps Well, this patch has a difficult fate. Jerem [1]: https://gitlab.gnome.org/GNOME/vte/-/issues/88
