Re: xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]

[debian-user]

Stefan Monnier  wrote:
> > I have not said it is more “standard for terminals”, I have that it
> > is more “standard” fullstop. It is more standard by the virtue of
> > having worked for decades, C-Ins S-Ins S-Del existed way before the
> > C-C C-V C-X tryptich, and still working today in most contexts.  
> 
> Indeed, IIUC these key bindings were part of the CUA standard:
> https://en.wikipedia.org/wiki/IBM_Common_User_Access

Indeed and CTRL-C & friends first appeared as Apple-C on the Lisa, it
seems and were appropriated by Microsoft after a while:

https://www.howtogeek.com/804030/the-origins-of-ctrlc-ctrlv-ctrlx-and-ctrlz-explained/

C-Ins vs. C-c [was: xterm PRIMARY and CLIPBOARD selection] Firefox and paste into Terminal with Vim]

[tomas]

On Wed, Feb 07, 2024 at 01:20:19PM +0100, Nicolas George wrote:
> Max Nikulin (12024-02-07):
> > It may be a convention for applications other than terminals, however I am
> > unsure what "standard" means for terminals.
> 
> I have not said it is more “standard for terminals”, I have that it is
> more “standard” fullstop. It is more standard by the virtue of having
> worked for decades, C-Ins S-Ins S-Del existed way before the C-C C-V C-X
> tryptich, and still working today in most contexts.

C-c, C-x and C-v is latest documented for the Apple Lisa, around 1983,
although it may have stolen it from the Xerox Alto [0] [1]

C-Ins, S-Del and S-Ins are IBM CUA, around 1987.

So it's the other way around :-)

Cheers

[0] https://en.wikipedia.org/wiki/Apple_Lisa
[1] https://en.wikipedia.org/wiki/Cut%2C_copy%2C_and_paste#Popularization
[2] https://en.wikipedia.org/wiki/IBM_Common_User_Access

-- 
t


signature.asc
Description: PGP signature

Re: xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]

[Max Nikulin]

On 07/02/2024 19:20, Nicolas George wrote:

Max Nikulin (12024-02-07):

It may be a convention for applications other than terminals, however I am
unsure what "standard" means for terminals.


I have not said it is more “standard for terminals”, I have that it is
more “standard” fullstop. It is more standard by the virtue of having
worked for decades, C-Ins S-Ins S-Del existed way before the C-C C-V C-X
tryptich, and still working today in most contexts.


Terminal application should leave standard hotkeys for applications 
running in terminals. It is the reason why modern terminals use 
[Ctrl+Shift+c] and [Ctrl+Shift+v] instead of conventional [Ctrl+c] and 
[Ctrl+v]. That is why I am against idea of adding [Ctrl+Insert] to xterm 
bindings.


In Emacs C- is bound to `kill-ring-save'.


Works for me. The author of XTerm is quite reactive if you can explain
the issue clearly, I am not surprised it was fixed.


My impression, it was a decision to support only single storage for 
handling selection. I like that it was changed.

Re: xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]

[Stefan Monnier]

> I have not said it is more “standard for terminals”, I have that it is
> more “standard” fullstop. It is more standard by the virtue of having
> worked for decades, C-Ins S-Ins S-Del existed way before the C-C C-V C-X
> tryptich, and still working today in most contexts.

Indeed, IIUC these key bindings were part of the CUA standard:
https://en.wikipedia.org/wiki/IBM_Common_User_Access


Stefan

Re: Copy from Firefox and paste into Terminal with Vim

[Max Nikulin]

On 07/02/2024 19:19, Greg Wooledge wrote:

On Tue, Feb 06, 2024 at 11:02:09PM -0800, David Christensen wrote:

* Pressing " then + then p seems to paste from the default Vim buffer --
what I seem to recall being referred to as the "yank buffer" (?).

* Pressing " then * then p seems to paste from the default Vim buffer.


These are the same results that I had.  You're most likely running a
vim package built without the full suite of GUI options, just like I am.


Only vim.gtk3 and vim.motif support PRIMARY selection and CLIPBOARD 
registers (you do not need to run gvim). There is no support in 
vim.tiny, vim.basic (package "vim"), vim.nox. They are built from the 
same source package with different configure options. It seems neovim 
(different project) require an external tool for clipboard.

Re: xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]

[Nicolas George]

Max Nikulin (12024-02-07):
> It may be a convention for applications other than terminals, however I am
> unsure what "standard" means for terminals.

I have not said it is more “standard for terminals”, I have that it is
more “standard” fullstop. It is more standard by the virtue of having
worked for decades, C-Ins S-Ins S-Del existed way before the C-C C-V C-X
tryptich, and still working today in most contexts.

> Thanks, it seems, it works in bookworm. Several years ago xterm did not
> support ownership of independent CLIPBOARD and PRIMARY simultaneously. It
> was a workaround for the following scenario:
> 
> - select some text
> - copy it to CLIPBOARD
> - select another fragment of text (PRIMARY)
> - switch to another application
> - paste from PRIMARY
> - paste from CLIPBOARD

Works for me. The author of XTerm is quite reactive if you can explain
the issue clearly, I am not surprised it was fixed.

Regards,

-- 
  Nicolas George

Re: Copy from Firefox and paste into Terminal with Vim

[Greg Wooledge]

On Tue, Feb 06, 2024 at 11:02:09PM -0800, David Christensen wrote:
> * Pressing " then + then p seems to paste from the default Vim buffer --
> what I seem to recall being referred to as the "yank buffer" (?).
> 
> * Pressing " then * then p seems to paste from the default Vim buffer.

These are the same results that I had.  You're most likely running a
vim package built without the full suite of GUI options, just like I am.

(Do you get a terminal bell after "+ or is your terminal bell disabled?)

> The behavior is the same with .vimrc disabled.
> 
> So, my Debian, X, Xfce, Terminal, and/or Vim are not working as documented
> (?).

Try:

vim --version | sed -n -e 1,2p -e /GUI/p -e /clip/p

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/6/24 06:25, Max Nikulin wrote:

On 06/02/2024 13:28, David Christensen wrote:

On 2/5/24 19:03, Max Nikulin wrote:

    xclip -o -selection PRIMARY
    xclip -o -selection CLIPBOARD


That is useful.


I expected that you would try both commands when vim is unable to paste. 
It would allow to discriminate whether it is Firefox or Vim issue.



I tried using those commands, but was getting confusing results.  If and 
when my Debian, X, Xfce, Terminal, and/or Vim misbehave again, I will 
see if those commands produce any clues.




If I start Firefox, browse to https://www.toyota.com/dealers, select the
the first dealer contents, start Vim, press and release the 
double-quote key, press and release the asterisk key, and press and 
release the p key, Vim inserts a blank line.


What is the effect of ["], [+], [p] keystrokes?



https://lists.debian.org/debian-user/2024/02/msg00277.html


or C-R* in insert mode. 


I do not understand your notation:

 C-R*


[Ctrl+R], [*] or [Ctrl+R], [+]

     :help i_CTRL-R



In command mode:

* Pressing Ctrl+R causes the bottom line to say:

Already at newest change

* Pressing Ctrl+R then + causes the cursor to move down one line.

* Pressing Ctrl+R then * causes the bottom line to say:

search hit BOTTOM, continuing at TOP


In insert mode:

* Pressing Ctrl+R causes the following two characters to be inserted 
into columns 53 and 54 of the bottom line:


^R

* Pressing Ctrl+R then + causes the two characters to be removed from 
the bottom line


* Pressing Ctrl+R then * causes the two characters to be removed from 
the bottom line




... Ctrl+Shift+V


I was trying to recommend against it, despite currently bracketed paste 
is enabled by default in BASH.



https://lists.debian.org/debian-user/2024/02/msg00276.html



https://security.stackexchange.com/questions/39118/how-can-i-protect-myself-from-this-kind-of-clipboard-abuse



Yuck.


I wonder if the https://www.toyota.com/dealers content I was attempting 
to paste into Vim contained exploits (?).  I have rebooted several 
times; perhaps the effects were not persistent (?).  Toyota's web site 
is different today; perhaps Toyota removed the exploits (?).



I wonder if the following will display exploits (?):

$ xclip -o -selection PRIMARY

$ xclip -o -selection CLIPBOARD


I wonder if my Vim has blocked "+p and "*p as a means to protect against 
clipboard attacks?




As to vim docs

     :help gui-selection
     :help quoteplus



https://lists.debian.org/debian-user/2024/02/msg00277.html



and for completeness

     :help registers



It seems that I have been conflating the terms and concepts "buffer" and 
"register".




Perhaps

     :help user-manual

contains description as well



Vim has more features than I know or use.


David

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/6/24 05:48, John Hasler wrote:

My .vimrc contains

syntax on
set mouse-=a

And pasting works.



Thank you for the reply.  :-)


If and when Firefox, Debian, X, Xfce, Terminal, and/or Vim misbehave 
again, I will try your suggestions.




VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Nov 20 2023 16:05:25)
Included patches: 1-2116



2024-02-06 23:39:21 dpchrist@laalaa ~
$ cat /etc/debian_version ; uname -a ; vim --version | head -n 2
11.8
Linux laalaa 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) 
x86_64 GNU/Linux

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 01 2021 01:51:08)
Included patches: 1-2434


David

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/6/24 03:33, Ralph Aichinger wrote:

On Mon, 2024-02-05 at 15:14 -0800, David Christensen wrote:

I am unable to determine if the problem is Firefox, Vim, or something
else.

Comments or suggestions?


As others have written, vim has changed copy+paste defaults some time
ago. Some even call this changing defaults "they broke copy+paste" ;).
One easy thing you might want to check is if this also happens in
neovim. Neovim did not make this copy+paste change, and it might
behave subtly different. It's quick to install and check.

/ralph



Thank you for the reply.  :-)


I prefer to use Vim, as it seems to be available and/or installed on all 
of the various hosts I use (including those I do not administer).



David

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/6/24 00:12, Klaus Singvogel wrote:

David Christensen wrote:

On 2/5/24 21:45, to...@tuxteam.de wrote:

Try ":set mouse=" and see whether it helps. Perhaps it's that.


That's the way. That's the fix for the root cause.



Thank you for the reply.  :-)


Currently, Firefox, Vim, select, copy, and/or paste seem to be behaving. 
 If and when the gremlins wake up, I'll try your suggestion.



David

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/6/24 04:28, Greg Wooledge wrote:

On Mon, Feb 05, 2024 at 10:28:53PM -0800, David Christensen wrote:

Continuing from above in Vim in Insert mode, if I then simultaneously press
the Ctrl, Shift, and v keys, and then release all keys, Vim inserts the
contents of the clipboard; as confirmed by:

 xclip -o -selection CLIPBOARD


How's that possible?



Thank you for the reply.  :-)


Apparently, something in the 920M bytes of my boot file system and/or in 
the 8009M bytes of my root file system make it possible.




Are you running a GUI version of vim (gvim?)



No.



instead of running vim in a terminal?



I am running Vim in Terminal.



Or are you using an exotic terminal?



I do not believe so.



If you're using a terminal that isn't xterm, please specify which.



I used the Xfce Panel Preferences dialog to create a Launcher item with 
one Terminal Emulator item:


Name:   Terminal Emulator
Comment:Use the command line
Command:exo-open --launch TerminalEmulator
Working Directory:
Icon:   org.xfce.terminalemulator
Options:
checked Use startup notification
unchecked   Run in terminal


I click on the panel icon to start Terminal.



In xterm and urxvt, Ctrl-Shift-v is identical to Ctrl-v ("literal
next"), so there's no way vim can distinguish the two.  And yes, I
tested it just to be sure.  In both xterm and urxvt, vim, insert > mode, 
Ctrl-Shift-v acts exactly like Ctrl-v.



I am seeing similar behavior:

https://lists.debian.org/debian-user/2024/02/msg00276.html



This applies in general to *any* issue that involves exotic key
combinations, because different terminals handle them differently.



Okay.


David

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/6/24 03:15, Dan Ritter wrote:

David Christensen wrote:

On 2/5/24 16:48, Dan Ritter wrote:

David Christensen wrote:

Please provide a URL that describes the Vim "+ and "* buffers, how to
interact with them within Vim, how to interact with them from other apps,
etc..


https://www.oreilly.com/library/view/learning-the-vi/9780596529833/ch04s03.html



Thank you for the reply.  :-)


Interesting.  Perhaps I should try to add buffers to my Vim skill set.



The "+ and "* buffers will get filled with primary and clipboard
selections when they occur, or you can fill them yourself so
that other applications can read from them.



In a window running Terminal running Vim in command mode:

* Pressing " then + then p seems to paste from the default Vim buffer -- 
what I seem to recall being referred to as the "yank buffer" (?).


* Pressing " then * then p seems to paste from the default Vim buffer.



:set clipboard=unnamed, unnamedplus


Vim says:

E518: Unknown option: unnamedplus


If I run the command:

:set clipboard=unnamed,unnamedplus


Vim does not complain, and "+p and "*p behave as above.


Perhaps my .vimrc is interfering (?).  Here it is again FYI:

2024-02-06 22:50:35 dpchrist@laalaa ~
$ grep -v '"' .vimrc | grep .
map q 
set autoindent
set backspace=indent,eol,start
set nocompatible
set nomodeline
set number
set numberwidth=8
set paste
set shiftwidth=4
set wildmode=longest,list


Disabling .vimrc and testing "+p, "*p, and :set 
clipboard=unnamed,unnamedplus again, the behavior is the same.




makes the basic vim clipboard -- the one without a name, the one
that you use if you just dd or y a line -- be the same as the
X11 primary selection buffer.



Not on my Debian, X, Xfce, Terminal, and/or Vim.



https://vimdoc.sourceforge.net/htmldoc/gui.html#clipboard



In a window running Terminal running Vim in command mode with .vimrc 
enabled:


* "*dd deletes the line containing the insertion point.  The line is not 
copied to the keyboard.


* "*p pastes the line previously deleted after the line containing the 
insertion point.



The behavior is the same with .vimrc disabled.


So, my Debian, X, Xfce, Terminal, and/or Vim are not working as 
documented (?).



David

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/5/24 16:29, DdB wrote:

Am 06.02.2024 um 00:14 schrieb David Christensen:

Comments or suggestions?

This may be unrelated, but ...
I can copy/paste using the mouse, or - if i use the keyboard - i need to
copy paste using CTRL-Shift-C and CTRL-Shift-V (when in the terminal
emulator like gnome-terminal or terminator)



Thank you for the reply.  :-)


Firefox and Vim seem to be playing nice today -- I can select text in 
Firefox and paste via middle-click into a window running Terminal 
running Vim.  I tried several times, but was unable to get them to 
malfunction.



Similarly, Ctrl+Shift+C and Ctrl+Shift+V within a window running 
Terminal running Vim in either command mode or insert mode -- I can 
select and copy text to the (X primary?) clipboard and I can paste text 
from the (X primary?) clipboard; respectively.



So, it appears the gremlins must be asleep.  When the wake up, I'll try 
again.



Back in the day, I worked on a Windows hardware/ software validation 
project.  Some of the team members had a tool that could record a 
Windows desktop GUI session, save it to a script, and replay a script on 
demand.  Creating useful scripts was tedious and difficult, but the 
benefits were huge.  Is there a FOSS equivalent for Debian, X, Xfce, etc.?



David

Re: Copy from Firefox and paste into Terminal with Vim

[Max Nikulin]

On 07/02/2024 00:35, Ralph Aichinger wrote:

On Tue, 2024-02-06 at 21:31 +0700, Max Nikulin wrote:

is active in terminal, it is possible to hold [Shift] to get mouse
events handled by terminal instead of Vim or another application
running in terminal.


I think pressing shift does not work here in e.g. gnome-terminal,
because there paste is Shift-Ctrl-V and interpreted by gnome-terminal.
Have not tried it though, vim taking care of the mouse is just nuts
in my opinion ;)


[Ctrl+Shift+V] is not a mouse event. Consider vim with enabled mouse on 
a remote host when X11 forwarding is disabled in ssh. Local selection is 
not available through + and * registers. It is handy to use Shift to be 
able to select some text (unless it is multiline text in a vertically 
split window) or to paste in insert mode by Shift+middle mouse button.

xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]

[Max Nikulin]

On 07/02/2024 00:38, Nicolas George wrote:

Max Nikulin (12024-02-07):

 Shift Ctrl C:


CtrlInsert is the standard counterpart to ShiftInsert.


It may be a convention for applications other than terminals, however I 
am unsure what "standard" means for terminals. Konsole has "reverted" 
bindings: [Shift+Insert] for CLIPBOARD and [Ctrl+Shift+Insert] for 
PRIMARY. Unsure if it was so before appearance of Wayland (it did not 
support PRIMARY at first). I have seen a (likely) KDE bug that paste 
from PRIMARY by middle click is a security issue, so it should not be 
supported.


Certainly, it is up to you if you wish to have [Ctrl+Insert] binding. I 
am unaware of any conflicts with applications running in terminals.



exec-formatted("sh -c 'xsel --output --primary | \
 exec xsel --input --clipboard'", PRIMARY)\n\


copy-selection(CLIPBOARD)

… is simpler.


Thanks, it seems, it works in bookworm. Several years ago xterm did not 
support ownership of independent CLIPBOARD and PRIMARY simultaneously. 
It was a workaround for the following scenario:


- select some text
- copy it to CLIPBOARD
- select another fragment of text (PRIMARY)
- switch to another application
- paste from PRIMARY
- paste from CLIPBOARD

I have the following note

! Allow both primary selection and clipboard copy-paste
! Ctrl+Shift+V, Ctrl+Shift+Insert, Ctrl+Shift+C similar to gnome-terminal
! Should work out of the box:
! Shift  Insert:insert-selection(SELECT, CUT_BUFFER0)
! Notice that copy-selection(CLIPBOARD) binds PRIMARY and SELECTION, see
! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588785#108
! There is no point to use CUT_BUFFER1 as in xterm(1) "Custom Key Bindings"
! insert-selection(CLIPBOARD, CUT_BUFFER1)

Likely the related changes
https://invisible-island.net/xterm/xterm.log.html#xterm_336
Patch #336 - 2018/09/19

ensure that only one of PRIMARY and CLIPBOARD is owned by xterm
at a given time (Debian #901249).

https://invisible-island.net/xterm/xterm.log.html#xterm_338
Patch #338 - 2018/12/09

revert the change which prevented concurrent ownership
of different selection targets, and instead modify selection storage
so that different concurrent requests for different selection
targets will be stored/retrieved independently (Debian #901249).

For me it is not easy to follow discussions of xterm bugs and to read 
man page selections related to selection.

Re: Copy from Firefox and paste into Terminal with Vim

[Ralph Aichinger]

On Tue, 2024-02-06 at 21:31 +0700, Max Nikulin wrote:
> is active in terminal, it is possible to hold [Shift] to get mouse 
> events handled by terminal instead of Vim or another application
> running in terminal.

I think pressing shift does not work here in e.g. gnome-terminal,
because there paste is Shift-Ctrl-V and interpreted by gnome-terminal.
Have not tried it though, vim taking care of the mouse is just nuts
in my opinion ;)

/ralph

Re: Copy from Firefox and paste into Terminal with Vim

[Nicolas George]

Max Nikulin (12024-02-07):
> Shift Ctrl C:

CtrlInsert is the standard counterpart to ShiftInsert.

>   exec-formatted("sh -c 'xsel --output --primary |
> \
> exec xsel --input --clipboard'", PRIMARY)\n\

copy-selection(CLIPBOARD)

… is simpler.

Regards,

-- 
  Nicolas George

Re: Copy from Firefox and paste into Terminal with Vim

[Max Nikulin]

On 06/02/2024 21:57, Greg Wooledge wrote:

Anything that came from a desktop environment is pretty exotic to me.
I'm pretty old-school.  If xterm can't do it, then I'll call it exotic.


Rewrap on window resize is a convenient feature of libvte.

Ctrl+Shift+V for xterm:

xterm*vt100.translations: #override \n\
Shift~Ctrl  Insert:insert-selection(PRIMARY, CUT_BUFFER0) \n\
Shift Ctrl  Insert:insert-selection(CLIPBOARD) \n\
Shift Ctrl C: exec-formatted("sh -c 'xsel --output 
--primary | \

exec xsel --input --clipboard'", PRIMARY)\n\
Shift Ctrl V: insert-selection(CLIPBOARD)


As to + and * registers. What kind of vim do you use? At least vim-gtk3
provides console vim binary built with x11 support. Perhaps it is
+xterm_clipboard option.

unicorn:~$ vim --version | sed -n -e 1,2p -e /GUI/p -e /clip/p
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled May 04 2023 10:24:44)
Included patches: 1-1378, 1499
Huge version without GUI.  Features included (+) or not (-):
-clipboard +keymap+printer   +vertsplit
+eval  -mouse_jsbterm -sun_workshop  -xterm_clipboard


If you do not like vim-gtk3, perhaps vim-motif has support of * and + 
registers.

Re: Copy from Firefox and paste into Terminal with Vim

[Greg Wooledge]

On Tue, Feb 06, 2024 at 03:36:23PM +, debian-u...@howorth.org.uk wrote:
> I know I don't like xterm so I never use it. I mainly use lxterminal
> and sometimes gnome-terminal but they both must be 'exotic' since they
> behave as David said.

The following NEW packages will be installed:
  libvte-2.91-0 libvte-2.91-common lxterminal

Hmm, OK, that's not bad.

First thing I try: Ctrl-v Ctrl-v (at a bash prompt).  This gives ^V as
expected.

Second thing I try: Ctrl-v Shift-Ctrl-v.  This gives a long-ish paste
of what appears to be base64-encoded content, but beginning with ^[[200~
(start of bracketed paste).  There's probably another escape sequence
at the end (end of bracketed paste?) but with no Ctrl-V acting upon it,
it's not visible.

So I guess this Shift-Ctrl-v is something that's handled directly by
the terminal emulator, and does *not* result in a byte sequence that's
interpreted by the application.  That answers one of my questions, at
least.

There is ... almost no documentation, however.  "man lxterminal" gives
a stub man page written by the Debian maintainer.  The /usr/share/doc
directory is barren as well:

unicorn:/usr/share/doc/lxterminal$ ls
changelog.Debian.gz  changelog.gz  copyright

So I guess people learn about lxterminal features like Shift-Ctrl-v by
word of mouth...?

The terminal has a menu bar with a Help option.  The Help menu has exactly
one choice: About.  About gives a popup window with a link to
.  Going there and clicking the WIKI button
leads me to  which is a 404 page.

*sigh*

Re: Copy from Firefox and paste into Terminal with Vim

[debian-user]

Greg Wooledge  wrote:
> On Mon, Feb 05, 2024 at 10:28:53PM -0800, David Christensen wrote:
> > Continuing from above in Vim in Insert mode, if I then
> > simultaneously press the Ctrl, Shift, and v keys, and then release
> > all keys, Vim inserts the contents of the clipboard; as confirmed
> > by:
> > 
> > xclip -o -selection CLIPBOARD  
> 
> How's that possible?  Are you running a GUI version of vim (gvim?)
> instead of running vim in a terminal?  Or are you using an exotic
> terminal?

Wow, thanks! I learned something new.

> In xterm and urxvt, Ctrl-Shift-v is identical to Ctrl-v ("literal
> next"), so there's no way vim can distinguish the two.  And yes, I
> tested it just to be sure.  In both xterm and urxvt, vim, insert
> mode, Ctrl-Shift-v acts exactly like Ctrl-v.

So it does. How bizarre! Makes vim in an xterm unusable.

> If you're using a terminal that isn't xterm, please specify which.
> This applies in general to *any* issue that involves exotic key
> combinations, because different terminals handle them differently.

I know I don't like xterm so I never use it. I mainly use lxterminal
and sometimes gnome-terminal but they both must be 'exotic' since they
behave as David said.

Re: Copy from Firefox and paste into Terminal with Vim

[Greg Wooledge]

On Tue, Feb 06, 2024 at 09:38:11PM +0700, Max Nikulin wrote:
> On 06/02/2024 19:28, Greg Wooledge wrote:
> > On Mon, Feb 05, 2024 at 10:28:53PM -0800, David Christensen wrote:
> > > Continuing from above in Vim in Insert mode, if I then simultaneously 
> > > press
> > > the Ctrl, Shift, and v keys, and then release all keys, Vim inserts the
> > > contents of the clipboard; as confirmed by:
> > > 
> > >  xclip -o -selection CLIPBOARD
> > 
> > How's that possible?  Are you running a GUI version of vim (gvim?)
> > instead of running vim in a terminal?  Or are you using an exotic
> > terminal?
> 
> Are you considering any vte-based terminal as an exotic one? GNOME terminal,
> konsole, lxterminal, and others... They have [Ctrl+Shift+v] hotkey out of
> the box in addition to [Insert]-based ones.

Anything that came from a desktop environment is pretty exotic to me.
I'm pretty old-school.  If xterm can't do it, then I'll call it exotic.

> As to + and * registers. What kind of vim do you use? At least vim-gtk3
> provides console vim binary built with x11 support. Perhaps it is
> +xterm_clipboard option.

unicorn:~$ vim --version | sed -n -e 1,2p -e /GUI/p -e /clip/p
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled May 04 2023 10:24:44)
Included patches: 1-1378, 1499
Huge version without GUI.  Features included (+) or not (-):
-clipboard +keymap+printer   +vertsplit
+eval  -mouse_jsbterm -sun_workshop  -xterm_clipboard

Re: Copy from Firefox and paste into Terminal with Vim

[Max Nikulin]

On 06/02/2024 19:28, Greg Wooledge wrote:

On Mon, Feb 05, 2024 at 10:28:53PM -0800, David Christensen wrote:

Continuing from above in Vim in Insert mode, if I then simultaneously press
the Ctrl, Shift, and v keys, and then release all keys, Vim inserts the
contents of the clipboard; as confirmed by:

 xclip -o -selection CLIPBOARD


How's that possible?  Are you running a GUI version of vim (gvim?)
instead of running vim in a terminal?  Or are you using an exotic
terminal?


Are you considering any vte-based terminal as an exotic one? GNOME 
terminal, konsole, lxterminal, and others... They have [Ctrl+Shift+v] 
hotkey out of the box in addition to [Insert]-based ones.


As to + and * registers. What kind of vim do you use? At least vim-gtk3 
provides console vim binary built with x11 support. Perhaps it is 
+xterm_clipboard option.

Re: Copy from Firefox and paste into Terminal with Vim

[tomas]

On Tue, Feb 06, 2024 at 09:31:33PM +0700, Max Nikulin wrote:

[...]

> Concerning set "mouse=", I usually use it, but even when mouse handling is
> active in terminal, it is possible to hold [Shift] to get mouse events
> handled by terminal instead of Vim or another application running in
> terminal.

Indeed! Thanks for this one, Max :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Copy from Firefox and paste into Terminal with Vim

[Max Nikulin]

On 06/02/2024 18:33, Ralph Aichinger wrote:

As others have written, vim has changed copy+paste defaults some time
ago. Some even call this changing defaults "they broke copy+paste" .


I am using vim in GUI terminal applications and I have not noticed it. 
Vim is a rare application that provides access to both PRIMARY_SELECTION 
and CLIPBOARD out of the box. E.g. in Emacs it is necessary to configure 
custom bindings, using existing user options you can choose any, but not 
both.


P.S.

Concerning set "mouse=", I usually use it, but even when mouse handling 
is active in terminal, it is possible to hold [Shift] to get mouse 
events handled by terminal instead of Vim or another application running 
in terminal.

Re: Copy from Firefox and paste into Terminal with Vim

[Max Nikulin]

On 06/02/2024 13:28, David Christensen wrote:

On 2/5/24 19:03, Max Nikulin wrote:

    xclip -o -selection PRIMARY
    xclip -o -selection CLIPBOARD


That is useful.


I expected that you would try both commands when vim is unable to paste. 
It would allow to discriminate whether it is Firefox or Vim issue.



If I start Firefox, browse to https://www.toyota.com/dealers, select the
the first dealer contents, start Vim, press and release the double-quote 
key, press and release the asterisk key, and press and release the p 
key, Vim inserts a blank line.


What is the effect of ["], [+], [p] keystrokes?

or C-R* in insert mode. 


I do not understand your notation:

     C-R*


[Ctrl+R], [*] or [Ctrl+R], [+]

:help i_CTRL-R


... Ctrl+Shift+V


I was trying to recommend against it, despite currently bracketed paste 
is enabled by default in BASH.


https://security.stackexchange.com/questions/39118/how-can-i-protect-myself-from-this-kind-of-clipboard-abuse

As to vim docs

:help gui-selection
:help quoteplus

and for completeness

:help registers

Perhaps

:help user-manual

contains description as well

Re: Copy from Firefox and paste into Terminal with Vim

[John Hasler]

My .vimrc contains

syntax on
set mouse-=a


And pasting works.

VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Nov 20 2023 16:05:25)
Included patches: 1-2116
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Copy from Firefox and paste into Terminal with Vim

[Greg Wooledge]

On Tue, Feb 06, 2024 at 06:15:39AM -0500, Dan Ritter wrote:
> https://www.oreilly.com/library/view/learning-the-vi/9780596529833/ch04s03.html
> 
> The "+ and "* buffers will get filled with primary and clipboard
> selections when they occur, or you can fill them yourself so
> that other applications can read from them.

That page does not contain a + or * character at all, and while it
does describe buffers, it does not describe buffers whose names are
anything other than lowercase letters.  In fact, it explicitly says
there are only 26 of them (a-z).

Furthermore, in my own testing just now, I'm unable to get this to
work.  vim (version 2:9.0.1378-2) running in urxvt, command mode,
pressing "+ or "* generates a terminal bell.  Pressing p after
either one of these pastes what's in vim's unnamed default buffer.

Re: Copy from Firefox and paste into Terminal with Vim

[Greg Wooledge]

On Mon, Feb 05, 2024 at 10:28:53PM -0800, David Christensen wrote:
> Continuing from above in Vim in Insert mode, if I then simultaneously press
> the Ctrl, Shift, and v keys, and then release all keys, Vim inserts the
> contents of the clipboard; as confirmed by:
> 
> xclip -o -selection CLIPBOARD

How's that possible?  Are you running a GUI version of vim (gvim?)
instead of running vim in a terminal?  Or are you using an exotic
terminal?

In xterm and urxvt, Ctrl-Shift-v is identical to Ctrl-v ("literal
next"), so there's no way vim can distinguish the two.  And yes, I
tested it just to be sure.  In both xterm and urxvt, vim, insert
mode, Ctrl-Shift-v acts exactly like Ctrl-v.

If you're using a terminal that isn't xterm, please specify which.
This applies in general to *any* issue that involves exotic key
combinations, because different terminals handle them differently.

Re: Copy from Firefox and paste into Terminal with Vim

[Ralph Aichinger]

On Mon, 2024-02-05 at 15:14 -0800, David Christensen wrote:
> I am unable to determine if the problem is Firefox, Vim, or something
> else.
> 
> Comments or suggestions?

As others have written, vim has changed copy+paste defaults some time
ago. Some even call this changing defaults "they broke copy+paste" ;).
One easy thing you might want to check is if this also happens in
neovim. Neovim did not make this copy+paste change, and it might 
behave subtly different. It's quick to install and check.

/ralph

Re: Copy from Firefox and paste into Terminal with Vim

[Dan Ritter]

David Christensen wrote: 
> On 2/5/24 16:48, Dan Ritter wrote:
> > David Christensen wrote:
> 
> 
> Please provide a URL that describes the Vim "+ and "* buffers, how to
> interact with them within Vim, how to interact with them from other apps,
> etc..

https://www.oreilly.com/library/view/learning-the-vi/9780596529833/ch04s03.html

The "+ and "* buffers will get filled with primary and clipboard
selections when they occur, or you can fill them yourself so
that other applications can read from them.

:set clipboard=unnamed, unnamedplus

makes the basic vim clipboard -- the one without a name, the one
that you use if you just dd or y a line -- be the same as the
X11 primary selection buffer.

https://vimdoc.sourceforge.net/htmldoc/gui.html#clipboard

-dsr-

Re: Copy from Firefox and paste into Terminal with Vim

[Klaus Singvogel]

David Christensen wrote:
> On 2/5/24 21:45, to...@tuxteam.de wrote:
> > Try ":set mouse=" and see whether it helps. Perhaps it's that.

That's the way. That's the fix for the root cause.

> I am unable to correlate that Vim setting change to the Vim paste problems.

But it's vim, which is changing the way how Copy is handled for its input.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Copy from Firefox and paste into Terminal with Vim

[tomas]

On Mon, Feb 05, 2024 at 11:07:53PM -0800, David Christensen wrote:
> On 2/5/24 21:45, to...@tuxteam.de wrote:

[...]

> I am not aware of any problems pasting into other applications, just pasting
> into Vim.
> 
> 
> > Vim has changed its defaults a while ago in an annoying way.
> > 
> > Try ":set mouse=" and see whether it helps. Perhaps it's that.
> 
> 
> I am unable to correlate that Vim setting change to the Vim paste problems.

Pity. In my case it does help, but my setup is rather exotic
these days (I use X's primary selection as far as possible,
some brain dead applications don't grok that anymore).

Hope you find a solution

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/5/24 21:45, to...@tuxteam.de wrote:

On Mon, Feb 05, 2024 at 03:14:45PM -0800, David Christensen wrote:

debian-user:

I have a laptop with:


[copy in Firefox, paste in vim]


I am unable to determine if the problem is Firefox, Vim, or something else.


Are you able to paste into another application?



Thank you for the reply. :-)


I am not aware of any problems pasting into other applications, just 
pasting into Vim.




Vim has changed its defaults a while ago in an annoying way.

Try ":set mouse=" and see whether it helps. Perhaps it's that.



I am unable to correlate that Vim setting change to the Vim paste problems.


David

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/5/24 16:48, Dan Ritter wrote:

David Christensen wrote:

Normally, I can cut and paste between Xfce desktop applications.


Enter a Zip Code of "12345", highlight the first result, copy it to the
clipboard, start Terminal, open a file with Vim, press "i" to enter insert
mode, and paste, sometimes I see what I copied to the clipboard and
sometimes I see nothing.


I am unable to determine if the problem is Firefox, Vim, or something else.


Are you aware that there are at least three 'clipboards' here?

X11 primary selection: this usually get filled by selecting text
in a terminal. It usually gets pasted by Button 2. In vim, this
is the "+ buffer.

X11 clipboard: this usually gets filled by ctrl-c or
ctrl-shift-c or a menu "Copy". It usually gets pasted by ctrl-v
or ctrl-shift-v or a menu "Paste". In vim, this is the "*
buffer.



Thank you for the reply.


I was aware of the X11 clipboard and interacting with it via Edit menus, 
context menus (right-click), Ctrl+C, Ctrl+X, Ctrl+V, Shift+Delete, 
Shift+Insert, etc..



I was aware of X11 select and paste via middle-click.


Please provide a URL that describes the Vim "+ and "* buffers, how to 
interact with them within Vim, how to interact with them from other 
apps, etc..




Vim can bypass a chunk of this by combining primary and
clipboard:

:set clipboard=unnamed,unnamedplus



I entered the above command into Vim, but am unsure what behavior or 
change in behavior I am supposed to see (?).



David

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/5/24 19:03, Max Nikulin wrote:

On 06/02/2024 06:14, David Christensen wrote:

Enter a Zip Code of "12345", highlight the first result, copy it
to the clipboard,
[...]> But if I close the above Firefox window, start a Firefox 
instance,

browse to:


If you terminate an application handling selection then content is 
not available any more.



Thank you for the reply.  :-)


I did not attempt to paste from the X primary selection after closing 
Firefox.




To debug you may use xsel or xclip

xclip -o -selection PRIMARY
xclip -o -selection CLIPBOARD



That is useful.


To access primary selection or clipboard in vim use * and + 
registers: "*p in normal mode 



If I start Firefox, browse to https://www.toyota.com/dealers, select the
the first dealer contents, start Vim, press and release the double-quote 
key, press and release the asterisk key, and press and release the p 
key, Vim inserts a blank line.



or C-R* in insert mode. 



I do not understand your notation:

C-R*


Continuing from above in Vim in normal (command) mode, if I then press 
and release the i key, then simultaneously press the Ctrl, r, and 
asterisk keys, and then release all keys, nothing happens.




... Ctrl+Shift+V



Continuing from above in Vim in Insert mode, if I then simultaneously 
press the Ctrl, Shift, and v keys, and then release all keys, Vim 
inserts the contents of the clipboard; as confirmed by:


xclip -o -selection CLIPBOARD


David

Re: Copy from Firefox and paste into Terminal with Vim

[tomas]

On Mon, Feb 05, 2024 at 03:14:45PM -0800, David Christensen wrote:
> debian-user:
> 
> I have a laptop with:

[copy in Firefox, paste in vim]

> I am unable to determine if the problem is Firefox, Vim, or something else.

Are you able to paste into another application?

Vim has changed its defaults a while ago in an annoying way.

Try ":set mouse=" and see whether it helps. Perhaps it's that.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Copy from Firefox and paste into Terminal with Vim

[Max Nikulin]

On 06/02/2024 06:14, David Christensen wrote:
Enter a Zip Code of "12345", highlight the first result, copy it to the 
clipboard,

[...]> But if I close the above Firefox window, start a Firefox instance,

browse to:


If you terminate an application handling selection then content is not 
available any more. To make selection "persistent", you may try some 
clipboard manager, but it may have not always desirable side effects.


To debug you may use xsel or xclip

xclip -o -selection PRIMARY
xclip -o -selection CLIPBOARD

To access primary selection or clipboard in vim use * and + registers: 
"*p in normal mode or C-R* in insert mode. It is safer than middle click 
or [Ctrl+Shift+V] handled by terminal since selection may contain 
terminal control characters (e.g. to exit from vim and to run rm -rf ~ 
in terminal).

Re: Copy from Firefox and paste into Terminal with Vim

[Dan Ritter]

David Christensen wrote: 
> Normally, I can cut and paste between Xfce desktop applications.
> 
> 
> Enter a Zip Code of "12345", highlight the first result, copy it to the
> clipboard, start Terminal, open a file with Vim, press "i" to enter insert
> mode, and paste, sometimes I see what I copied to the clipboard and
> sometimes I see nothing.
> 
> 
> I am unable to determine if the problem is Firefox, Vim, or something else.

Are you aware that there are at least three 'clipboards' here?

X11 primary selection: this usually get filled by selecting text
in a terminal. It usually gets pasted by Button 2. In vim, this
is the "+ buffer.

X11 clipboard: this usually gets filled by ctrl-c or
ctrl-shift-c or a menu "Copy". It usually gets pasted by ctrl-v
or ctrl-shift-v or a menu "Paste". In vim, this is the "*
buffer.

X11 secondary selection: you are unlikely to encounter it, but
when you do, it will be bizarre. Read: 
http://www.cs.man.ac.uk/~lindsec/secondary-selection.html

Vim can bypass a chunk of this by combining primary and
clipboard:

:set clipboard=unnamed,unnamedplus

in which case "* and "+ will be pasted simultaneously from vim.

-dsr-

Re: Copy from Firefox and paste into Terminal with Vim

[DdB]

Am 06.02.2024 um 00:14 schrieb David Christensen:
> Comments or suggestions?
This may be unrelated, but ...
I can copy/paste using the mouse, or - if i use the keyboard - i need to
copy paste using CTRL-Shift-C and CTRL-Shift-V (when in the terminal
emulator like gnome-terminal or terminator)

Re: Copy from Firefox and paste into Terminal with Vim

[David Christensen]

On 2/5/24 15:44, Bret Busby wrote:

On 6/2/24 07:14, David Christensen wrote:

debian-user:

I have a laptop with:

2024-02-05 15:04:48 dpchrist@laalaa ~
$ cat /etc/debian_version ; uname -a ; dpkg-query -W xfce4 firefox-esr 
vim

11.8
Linux laalaa 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) 
x86_64 GNU/Linux

firefox-esr    115.7.0esr-1~deb11u1
vim    2:8.2.2434-3+deb11u1
xfce4    4.16

2024-02-05 15:10:08 dpchrist@laalaa ~
$ grep -v '"' .vimrc | grep .
map q 
set autoindent
set backspace=indent,eol,start
set nocompatible
set nomodeline
set number
set numberwidth=8
set paste
set shiftwidth=4
set wildmode=longest,list


Normally, I can cut and paste between Xfce desktop applications.


For example, if I start Firefox, disable all extensions, browse to:

https://www.toyota.com/dealers/

Enter a Zip Code of "12345", highlight the first result, copy it to 
the clipboard, and paste into this message, I see:


Lia Toyota of Colonie
2116 Central Ave., Rte. 5, Schenectady NY 12304
(5.3 miles)
Today's Hours: 7:00 AM to 7:00 PM
(518) 374-3700


But if I close the above Firefox window, start a Firefox instance, 
browse to:


https://www.toyota.com/dealers/

Enter a Zip Code of "12345", highlight the first result, copy it to 
the clipboard, start Terminal, open a file with Vim, press "i" to 
enter insert mode, and paste, sometimes I see what I copied to the 
clipboard and sometimes I see nothing.

...

How exactly are you copying and pasting?

Are you marking the text and using Copy and Paste from the menu 
generated by clicking the non-dominant mouse button, or, are you marking 
the text, and using  to copy then  to paste?



Thank you for the reply.  :-)


Copy from Firefox -- drag to highlight text, then:

1.  Press Ctrl+C, or

2.  Right-click and choose Copy.


Paste into Vim:

1.  Middle click, or

2.  Right-click and choose Paste.


What happens if you copy and paste to an editor such as gedit? 
Does that work consistently? If so, what happens if you copy and paste to gedit, 
and then, copy from gedit, and paste to the vim window?



Copying from any Xfce window and pasting into Mousepad seems to work 
consistently.



Copying from Firefox, Mousepad, and potentially other Xfce windows into 
Vim does not work consistently.



Does it make any difference whether you have the vim session open, and 
the file open, into which you want to paste, before you copy the text 
that you want to paste into it?



No.


Have you tried the text editor that is the default editor for alpine 
(previously known as pine) - I think it is either nano or pico?



No.


David

Re: Copy from Firefox and paste into Terminal with Vim

[Bret Busby]

On 6/2/24 07:14, David Christensen wrote:

debian-user:

I have a laptop with:

2024-02-05 15:04:48 dpchrist@laalaa ~
$ cat /etc/debian_version ; uname -a ; dpkg-query -W xfce4 firefox-esr vim
11.8
Linux laalaa 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) 
x86_64 GNU/Linux

firefox-esr    115.7.0esr-1~deb11u1
vim    2:8.2.2434-3+deb11u1
xfce4    4.16

2024-02-05 15:10:08 dpchrist@laalaa ~
$ grep -v '"' .vimrc | grep .
map q 
set autoindent
set backspace=indent,eol,start
set nocompatible
set nomodeline
set number
set numberwidth=8
set paste
set shiftwidth=4
set wildmode=longest,list


Normally, I can cut and paste between Xfce desktop applications.


For example, if I start Firefox, disable all extensions, browse to:

https://www.toyota.com/dealers/

Enter a Zip Code of "12345", highlight the first result, copy it to the 
clipboard, and paste into this message, I see:


Lia Toyota of Colonie
2116 Central Ave., Rte. 5, Schenectady NY 12304
(5.3 miles)
Today's Hours: 7:00 AM to 7:00 PM
(518) 374-3700


But if I close the above Firefox window, start a Firefox instance, 
browse to:


https://www.toyota.com/dealers/

Enter a Zip Code of "12345", highlight the first result, copy it to the 
clipboard, start Terminal, open a file with Vim, press "i" to enter 
insert mode, and paste, sometimes I see what I copied to the clipboard 
and sometimes I see nothing.



I am unable to determine if the problem is Firefox, Vim, or something else.


Comments or suggestions?


David


How exactly are you copying and pasting?

Are you marking the text and using Copy and Paste from the menu 
generated by clicking the non-dominant mouse button, or, are you marking 
the text, and using  to copy then  to paste?


What happens if you copy and paste to an editor such as gedit? Does that 
work consistently? If so, what happens if you copy and paste to gedit, 
and then, copy from gedit, and paste to the vim window?


Does it make any difference whether you have the vim session open, and 
the file open, into which you want to paste, before you copy the text 
that you want to paste into it?


Have you tried the text editor that is the default editor for alpine 
(previously known as pine) - I think it is either nano or pico?



Bret Busby
Armadale
Western Australia
(UTC+0800)
.

Copy from Firefox and paste into Terminal with Vim

[David Christensen]

debian-user:

I have a laptop with:

2024-02-05 15:04:48 dpchrist@laalaa ~
$ cat /etc/debian_version ; uname -a ; dpkg-query -W xfce4 firefox-esr vim
11.8
Linux laalaa 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) 
x86_64 GNU/Linux

firefox-esr 115.7.0esr-1~deb11u1
vim 2:8.2.2434-3+deb11u1
xfce4   4.16

2024-02-05 15:10:08 dpchrist@laalaa ~
$ grep -v '"' .vimrc | grep .
map q 
set autoindent
set backspace=indent,eol,start
set nocompatible
set nomodeline
set number
set numberwidth=8
set paste
set shiftwidth=4
set wildmode=longest,list


Normally, I can cut and paste between Xfce desktop applications.


For example, if I start Firefox, disable all extensions, browse to:

https://www.toyota.com/dealers/

Enter a Zip Code of "12345", highlight the first result, copy it to the 
clipboard, and paste into this message, I see:


Lia Toyota of Colonie
2116 Central Ave., Rte. 5, Schenectady NY 12304
(5.3 miles)
Today's Hours: 7:00 AM to 7:00 PM
(518) 374-3700


But if I close the above Firefox window, start a Firefox instance, 
browse to:


https://www.toyota.com/dealers/

Enter a Zip Code of "12345", highlight the first result, copy it to the 
clipboard, start Terminal, open a file with Vim, press "i" to enter 
insert mode, and paste, sometimes I see what I copied to the clipboard 
and sometimes I see nothing.



I am unable to determine if the problem is Firefox, Vim, or something else.


Comments or suggestions?


David

Re: RIP VIM

[Charles Plessy]

Le Mon, Aug 07, 2023 at 11:22:23AM +0200, ajh-valmer a écrit :
> 
> Sans le mode graphique, combien de fois VIM m'a sauvé,
> que j'ai remplacé par NANO car VIM à partir d'une nouvelle version 
> a du mal avec les copier/coller.

C'est un changement de configuration par défaut d'il y a quelques années.

https://unix.stackexchange.com/questions/318824/vim-cutpaste-not-working-in-stretch-debian-9

https://stackoverflow.com/questions/44389107/vimrc-not-accepting-mouse-a-command

Et quand on n'a pas pu changer la configuration, on peut appuyer sur
shift pendant qu'on utilise la souris pour copier-coller.

Bonne journée,

Charles

Re: RIP VIM

[Haricophile]

Le Mon, 7 Aug 2023 11:22:23 +0200,
"ajh-valmer"  a écrit :

> car VIM à partir d'une nouvelle version 
> a du mal avec les copier/coller.

C'est pas plutôt la Widowisation de Linux qui a du mal a copier-coller,
Gnome en tête ? Fusionner les presse-papiers est une solution de
contournement.

Re: RIP VIM

[Jean-Michel OLTRA]

Bonjour,


Le lundi 07 août 2023, ajh-valmer a écrit...


> >   https://groups.google.com/g/vim_announce/c/tWahca9zkt4   RIP
> 
> Triste nouvelle, à 62 ans...

C'est vrai. Vim, avec Mutt, c'est mon quotidien.

Mais il part en laissant une œuvre immense, et c'est déjà pas mal.

-- 
jm

Re: RIP VIM

[ajh-valmer]

On Sunday 06 August 2023 18:37:09 David Pinson wrote:
> J'utilise beaucoup VIM à la place de VI ou NANO et peut-être certains 
> d'entre vous...
> Je me permets de vous relayer la triste nouvelle:
> Le développeur, initiateur du projet VIM, Bram MOOLENAAR, n'est plus de 
> ce monde depuis le 3 aout.
>   https://groups.google.com/g/vim_announce/c/tWahca9zkt4   RIP

Triste nouvelle, à 62 ans...

Sans le mode graphique, combien de fois VIM m'a sauvé,
que j'ai remplacé par NANO car VIM à partir d'une nouvelle version 
a du mal avec les copier/coller.

Il fallait annoncer cette nouvelle, merci.

Re: RIP VIM

[didier gaumet]

Il a été d'un apport bénéfique au logiciel libre comme à l'action 
caritative, a priori, donc chapeau.

RIP VIM

[David Pinson]

Bonjour,
J'utilise beaucoup VIM à la place de VI ou NANO et peut-être certains 
d'entre vous...

Je me permets de vous relayer la triste nouvelle:
Le développeur, initiateur du projet VIM, Bram MOOLENAAR, n'est plus de 
ce monde depuis le 3 aout.

 https://groups.google.com/g/vim_announce/c/tWahca9zkt4
RIP
Librement vôtre,
David PINSON

Re: [HS] Identification des caractères unicode dans Vim (Re: Bridge: config manuelle OK mais KO par /etc/network/interfaces [RESOLU])

[Jean Bernon]

La commande od peut aussi aider à repérer des caractères parasites cachés.

>
> > Le 2023-05-19 16:47, Olivier a écrit :
> > > À l'origine, le fichier était généré par un script Ansible.
> > > À l'oeil nu, avec vim, il ne présentait aucune anomalie visible.
> > > À l'évidence, il me semble indispensable d'utiliser un éditeur
> > > qui
> > > m'aiderait à repérer des caractères cachés.
> >
> > Et voilà :)
> >
> > https://github.com/vim-utils/vim-troll-stopper
> >
> > Sébastien
> >

Re: [HS] Identification des caractères unicode dans Vim (Re: Bridge: config manuelle OK mais KO par /etc/network/interfaces [RESOLU])

[Olivier]

Génial !

J'avais imaginé utiliser l'option ":set list" de vim mais le résultat
semblait insuffisant.
Dès que possible, je testerai cet autre module.

Quand il s'agit de code code source YAML ou Python, une autre source
serait d'utiliser un outil de mise en forme qui détecterait ce type de
piège.

Merci pour le tuyau.

Le mar. 23 mai 2023 à 07:54, Sébastien NOBILI
 a écrit :
>
> Bonjour,
>
> Le 2023-05-19 16:47, Olivier a écrit :
> > À l'origine, le fichier était généré par un script Ansible.
> > À l'oeil nu, avec vim, il ne présentait aucune anomalie visible.
> > À l'évidence, il me semble indispensable d'utiliser un éditeur qui
> > m'aiderait à repérer des caractères cachés.
>
> Et voilà :)
>
> https://github.com/vim-utils/vim-troll-stopper
>
> Sébastien
>

[HS] Identification des caractères unicode dans Vim (Re: Bridge: config manuelle OK mais KO par /etc/network/interfaces [RESOLU])

[Sébastien NOBILI]

Bonjour,

Le 2023-05-19 16:47, Olivier a écrit :

À l'origine, le fichier était généré par un script Ansible.
À l'oeil nu, avec vim, il ne présentait aucune anomalie visible.
À l'évidence, il me semble indispensable d'utiliser un éditeur qui
m'aiderait à repérer des caractères cachés.


Et voilà :)

https://github.com/vim-utils/vim-troll-stopper

Sébastien

Re: Choosing neovim over vim as default

[Oliver Schoede]

Hello!

On Fri, 04 Nov 2022 20:30:51 +0530
Bharatvaj P H  wrote:

>vimscript9
> feels like a bad decision, it is incompatible with vimscript2 and
> does not match performance with lua.

Probably not many scripting languages do. But then I'm not sure
performance is the be-all and end-all when it comes to editor plugins.
Certainly not for the Vim folks and even though speed was one the
grounds for the change, as far as I'm aware it's not the most important.

>Until vim9 I thought vim as a slimmer version of neovim but 
>it's the opposite.

I've never heard this before. The whole point of Neovim was getting rid
of what those folks identify or consider as "legacy" baggage. It is
slimmer, hence maybe faster. That's good for Neovim, but not crucial
for all of us.

>Currently there is confusion among developers when
>writing a plugin whether to choose vimscript9 or lua. And the only
>point vimscript9 has is tha it is available in all distros. Is it time
>to switch over to neovim? Choosing lua over vimscript9 reduces the
>cognitive load of many people.

I'm not to answer, just a user, though I would strongly oppose it. We
also ship I believe quite a few emacs forks, clones or variations, I
guess no one is ever seriously about to consider changing the default.
Vim is Vim. Neovim is Neovim. Anyone is free to use whatever they
prefer, and that's surely more people than those who write their own
plugins, or need to adapt one, they may still care about what editor
they use. Once they have to, chances are they're going to learn a new
language anyway, because Lua isn't exactly popular.


Oliver

Choosing neovim over vim as default

[Bharatvaj P H]

vimscript9
 feels like a bad decision, it is incompatible with vimscript2 and does 
not match performance with lua. We definitely don't need another 
language. Until vim9 I thought vim as a slimmer version of neovim but 
it's the opposite. Currently there is confusion among developers when writing a 
plugin whether to choose vimscript9 or lua. And the only point vimscript9 has 
is tha it is available in all distros. Is it time to switch over to neovim? 
Choosing lua over vimscript9 reduces the cognitive 
load of many people.

Should debian ship neovim as the default vi?

Re: Re : vim / sed : subsitution de codes hexa

[kaliderus]

Bonsoir,

Une piste : Je pense que awk devrait répondre à ton besoin, il m'est
arrivé de faire des choses assez " besogneuses " sur de longues
chaînes de caractères dans le passé avec cet outil.
En mixant avec iconv pour l'encodage (à passer dans le script) tu
devrai t'en sortir.
Bon courage

Le sam. 14 mai 2022 à 13:33,  a écrit :
>
> Le 12/05/2022 22:11:50, Alain Vaugham a écrit :
>
> > Il s'agit d'un export provenant d'un logiciel de comptabilité.
> > Je l'ai encodé en utf8 et je veux substituer les caractères hexa:
> > <82> par é
>
> Je me demande si ça ne passerait pas avec konwert, par exemple :
> konwert any-utf8 tonfichier.txt>tonfichier-utf8.txt
>
> nicolas patrois : pts noir asocial
> --
> RÉALISME
>
> M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains 
> ? Un cerveau plus gros ?
> P : Non... Une carte bleue suffirait...
>

Re : vim / sed : subsitution de codes hexa

[nicolas . patrois]

Le 12/05/2022 22:11:50, Alain Vaugham a écrit :

> Il s'agit d'un export provenant d'un logiciel de comptabilité.
> Je l'ai encodé en utf8 et je veux substituer les caractères hexa:
> <82> par é

Je me demande si ça ne passerait pas avec konwert, par exemple :
konwert any-utf8 tonfichier.txt>tonfichier-utf8.txt

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: [Résolu] Re: vim / sed : subsitution de codes hexa

[Bernard Schoenacker]

- Mail original -
> De: "Alain Vaugham" 
> À: debian-user-french@lists.debian.org
> Envoyé: Vendredi 13 Mai 2022 14:00:03
> Objet: [Résolu] Re: vim / sed : subsitution de codes hexa
> 
> Le Thu, 12 May 2022 22:38:16 +,
> Hugues Larrive  a écrit :
> 
> 
> Il est produit lors de l'export émis par un logiciel de comptabilité.
> Pareil pour 0x85, 0x8a, 0x88...
> 
> [...]
> 
> 
> Merci beaucoup pour ce bout de code en c.
> J'ai essayé de l'utiliser mais sans succès. Non pas à cause du code,
> mais parce que je n'ai pas su installer/paramétrer les outils pour la
> compilation.
> Vu le temps que ça prend pour moi de me mettre à un nouveau langage,
> j'ai continué à chercher une alternative en Bash. J'en ai trouvée
> une.
> Je garde précieusement ce code en référence pour le jour où je serai
> obligé de me mettre au c.
> 
> La solution que j'ai trouvée a été d'utiliser vim dans mon script:
> vim -c "%s/\%x82/é/g|wq" mon_fichier
> 
> Encore merci pour la tentative de réponse.
> 

Bonjour Alain,

J'ai pris le temps de faire quelques recherches et j'ai vu 
qu'avec Sed il était possible de le faire...

Documentation de base :
https://superuser.com/questions/517847/use-sed-to-replace-nbsp-160-hex-00a0-octal-240-non-breaking-space
https://www.cyberciti.biz/faq/unix-linux-sed-ascii-control-codes-nonprintable/

application :

sed -i 's/'$(echo "\082")'/é/g'  mon_fichier

Au fait que donne la commande file  ?

Ensuite, en recherchant plus encore, j'ai vu qu'il existait une solution qui 
permet à grep d'effectuer une recherche sur les caractères binaires :

https://github.com/tmbinc/bgrep

Merci pour votre aimable attention

Bien à vous

Bernard

[Résolu] Re: vim / sed : subsitution de codes hexa

[Alain Vaugham]

Le Thu, 12 May 2022 22:38:16 +,
Hugues Larrive  a écrit :

> Je me suis créé un petit fichier test avec 0x82 à la place d'un é
> pour tester. (Je me demande d'où sort ce 0x82...)

Il est produit lors de l'export émis par un logiciel de comptabilité.
Pareil pour 0x85, 0x8a, 0x88...

[...]

> L'utiliser à la place de sed :
> cat ma_source | ./0x82to0xc3a9 > ma_cible
> 
> Voilà qui devrait faire le travail aussi bien qu'un éditeur hexa.

Merci beaucoup pour ce bout de code en c.
J'ai essayé de l'utiliser mais sans succès. Non pas à cause du code,
mais parce que je n'ai pas su installer/paramétrer les outils pour la
compilation.
Vu le temps que ça prend pour moi de me mettre à un nouveau langage,
j'ai continué à chercher une alternative en Bash. J'en ai trouvée une.
Je garde précieusement ce code en référence pour le jour où je serai
obligé de me mettre au c.

La solution que j'ai trouvée a été d'utiliser vim dans mon script:
vim -c "%s/\%x82/é/g|wq" mon_fichier

Encore merci pour la tentative de réponse.


-- 
Alain Vaugham
Clef GPG : 0xDB77E054673ECFD2


pgpWAk1mTB97N.pgp
Description: Signature digitale OpenPGP

Re: vim / sed : subsitution de codes hexa

[Alain Vaugham]

Le Thu, 12 May 2022 23:14:50 +0200,
didier gaumet  a écrit :

> je me demande dans quel mesure tu n'as pas une différence
> d'environnement linguistique interactif/batch (par exemple examiner
> $LANG dans ton script pour vérifier?)

Dans le scripts
echo $LANG
donne:
fr_FR.UTF-8


-- 
Alain Vaugham
Clef GPG : 0xDB77E054673ECFD2

Re : Re: vim / sed : subsitution de codes hexa

[Hugues Larrive]

Bonjour,

Je me suis créé un petit fichier test avec 0x82 à la place d'un é
pour tester. (Je me demande d'où sort ce 0x82...)

Chez moi (debian 11 / sed 4.7) ta commande sed donne le même résultat que vi ce 
qui confirmerait ce qu'a dit Didier.

Une solution sûre pour effectuer cette conversion est de la faire entièrement 
en hexa avec un petit programme en C, en UTF-8 le caractère 'é' est codé 0xc3a9 
ce qui donne le programme 0x82to0xc3a9.c suivant :
#include 
int main()
{
int c;
while ((c = getchar()) != EOF) {
if (c == 0x82) printf("%c%c", 0xc3, 0xa9);
else printf("%c", c);
}
}

Le compiler :
cc 0x82to0xc3a9.c -o 0x82to0xc3a9

L'utiliser à la place de sed :
cat ma_source | ./0x82to0xc3a9 > ma_cible

Voilà qui devrait faire le travail aussi bien qu'un éditeur hexa.

Cordialement,
Hugues

--- Original Message ---
Le jeudi 12 mai 2022 à 23:14, didier gaumet  a écrit :
ère

> 

> 

> 

> 

> Le jeudi 12 mai 2022 à 22:11 +0200, Alain Vaugham a écrit :
> 

> > Bonjour la liste,
> > 

> > Il s'agit d'un export provenant d'un logiciel de comptabilité.
> > Je l'ai encodé en utf8 et je veux substituer les caractères hexa:
> > <82> par é
> > 

> > Sous vim les substitutions se font correctement
> > :%s/\%x82/é/g
> > 

> > Vu la quantité de substitutions à faire je souhaite scripter
> > l'opération avec sed:
> > cat ma_source | sed 's/\x82/é/g' > ma_cible
> > Malheureusement ça se passe mal car le résultat obtenu est
> > �é
> > soit:
> > 000 C2 C3 A9
> > 

> > D'après ce que je comprends de la faq
> > http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt
> > dans sed v1.5 il y aurait une autre syntaxe pour borner la chaîne à
> > substituer
> > \<...\>
> > cat ma_source | sed 's/\/é/g' > ma_cible
> > Là aussi ça ne se passe pas comme souhaité.
> > Le sed de Buster que j'utilise est en v4.7
> > 

> > Y aurait-il une autre syntaxe ou est-ce qu'une solution de
> > contournement existerai sous bash?
> > 

> > Merci par avance
> 

> 

> Bonsoir,
> 

> Je connais très peu les scripts bash et encore moins sed donc je dis
> peut-être n'importe quoi, mais vu qu'il s'agit d'un caractère accentué,
> je me demande dans quel mesure tu n'as pas une différence
> d'environnement linguistique interactif/batch (par exemple examiner
> $LANG dans ton script pour vérifier?)

publickey - hlarrive@pm.me - 0xE9429B87.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: vim / sed : subsitution de codes hexa

[didier gaumet]

Le jeudi 12 mai 2022 à 22:11 +0200, Alain Vaugham a écrit :
> Bonjour la liste,
> 
> Il s'agit d'un export provenant d'un logiciel de comptabilité.
> Je l'ai encodé en utf8 et je veux substituer les caractères hexa:
> <82> par é
> 
> Sous vim les substitutions se font correctement
> :%s/\%x82/é/g
> 
> Vu la quantité de substitutions à faire je souhaite scripter
> l'opération avec sed:
> cat ma_source | sed 's/\x82/é/g' > ma_cible
> Malheureusement ça se passe mal car le résultat obtenu est
> �é
> soit:
> 000   C2 C3 A9
> 
> D'après ce que je comprends de la faq
> http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt
> dans sed v1.5 il y aurait une autre syntaxe pour borner la chaîne à
> substituer
> \<...\>
> cat ma_source | sed 's/\/é/g' > ma_cible
> Là aussi ça ne se passe pas comme souhaité.
> Le sed de Buster que j'utilise est en v4.7
> 
> 
> Y aurait-il une autre syntaxe ou est-ce qu'une solution de
> contournement existerai sous bash?
> 
> Merci par avance

Bonsoir,

Je connais très peu les scripts bash et encore moins sed donc je dis
peut-être n'importe quoi, mais vu qu'il s'agit d'un caractère accentué,
je me demande dans quel mesure tu n'as pas une différence
d'environnement linguistique interactif/batch (par exemple examiner
$LANG dans ton script pour vérifier?)

vim / sed : subsitution de codes hexa

[Alain Vaugham]

Bonjour la liste,

Il s'agit d'un export provenant d'un logiciel de comptabilité.
Je l'ai encodé en utf8 et je veux substituer les caractères hexa:
<82> par é

Sous vim les substitutions se font correctement
:%s/\%x82/é/g

Vu la quantité de substitutions à faire je souhaite scripter
l'opération avec sed:
cat ma_source | sed 's/\x82/é/g' > ma_cible
Malheureusement ça se passe mal car le résultat obtenu est
�é
soit:
000   C2 C3 A9

D'après ce que je comprends de la faq
http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt
dans sed v1.5 il y aurait une autre syntaxe pour borner la chaîne à
substituer
\<...\>
cat ma_source | sed 's/\/é/g' > ma_cible
Là aussi ça ne se passe pas comme souhaité.
Le sed de Buster que j'utilise est en v4.7


Y aurait-il une autre syntaxe ou est-ce qu'une solution de
contournement existerai sous bash?

Merci par avance

-- 
Alain Vaugham
Clef GPG : 0xDB77E054673ECFD2

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Dedeco Balaco]

Em 20/09/2021 17:36, Mark Neyhart escreveu:
> On 9/18/21 5:14 PM, Dedeco Balaco wrote:
>> Vim is one of these programs. While it is running, the terminal title
>> shows the name of the file currently being edited, and the number of
>> files that was opened with it, when it was launched.
>>
>> After the upgrade, when i quit vim, the terminal title becomes empty,
>> instead of returning to the default title "Terminal".
>>
>> Why is this happening? A bug in Vim? In mate-terminal? Or in Debian 11?
> 
> I did not see it mentioned anywhere, but $PROMPT_COMMAND (if it
> exists) might be setting the terminal title.
> 

Not here, at least, if this variable exists elsewhere. Here, it is not
defined.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Mark Neyhart]

On 9/18/21 5:14 PM, Dedeco Balaco wrote:
> Vim is one of these programs. While it is running, the terminal title
> shows the name of the file currently being edited, and the number of
> files that was opened with it, when it was launched.
> 
> After the upgrade, when i quit vim, the terminal title becomes empty,
> instead of returning to the default title "Terminal".
> 
> Why is this happening? A bug in Vim? In mate-terminal? Or in Debian 11?

I did not see it mentioned anywhere, but $PROMPT_COMMAND (if it
exists) might be setting the terminal title.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[David Wright]

On Sun 19 Sep 2021 at 21:51:57 (+0200), to...@tuxteam.de wrote:
> On Sun, Sep 19, 2021 at 02:36:14PM -0500, David Wright wrote:
> > On Sun 19 Sep 2021 at 21:27:49 (+0200), to...@tuxteam.de wrote:
> > > On Sun, Sep 19, 2021 at 04:21:56PM -0300, Dedeco Balaco wrote:
> > > > Em 19/09/2021 15:48, to...@tuxteam.de escreveu:
> > > > > On Sun, Sep 19, 2021 at 03:06:28PM -0300, Dedeco Balaco wrote:
> > > 
> > > [...]
> > > 
> > > > Fine. I understand that you say that i could change my PS1 to always
> > > > reset the title.
> > > 
> > > Specifically this is desirable whenever you want the title to show
> > > a "changing" property (in this case, for example, the current
> > > working directory).
> > > 
> > > >      But there is something this would hide, and which i did
> > > > not yet found an explanation for: sometimes, the default title is reset
> > > > after quitting vim, and sometimes not.
> > > 
> > > That was my question: did you really observe vim resetting the title at
> > > program end, or was it something set dynamically by your shell (you
> > > said you changed your PS1 before the upgrade and the title was "fixed"
> > > at vim's exit, so there's evidence for both hypotheses :-)
> > 
> > I did come across this:
> > 
> > https://unix.stackexchange.com/questions/28500/is-it-possible-to-obtain-the-current-name-of-the-xterm-window
> > 
> > There are quite a few tricks that xprop can help with, but there
> > just aren't enough rainy days here to find time to play with them.
> 
> Yes, I think I mentioned xprop elsethread. I don't yet know how
> to get the window id of the shell's parent, but hey.
> 
> It seems xterm has even a better trick up its sleeve: it has
> a window title /stack/ [1] which you can control via escape
> sequences.
> 
> Now it's getting really dangerous: I must resist looking into
> that -- I have a paying customer I've got to make happy :-D
> 
> [1] 
> https://stackoverflow.com/questions/3232655/can-i-get-terminal-title-or-otherwise-restore-old-one

Yes, that link is mentioned in the first reference. So that depends
on how closely Mate terminal (which I've never seen) follows xterm.
OTOH xprop depends on the X server, I presume.

So, for the present, try the stack method first, then xprop if it
doesn't work. Whether stretch's method is still of interest to you, IDK.

Cheers,
David.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[tomas]

On Sun, Sep 19, 2021 at 04:53:09PM -0300, Dedeco Balaco wrote:

[...]

> The PS1 change i said, i meant, is that i used a changed PS1 since many
> years ago [...]  Thus, i expected that everything should continue
> working as before [...]

Yes, definitely: something changed which is breaking your expectations.

> So, i do not know if Vim restored the title it received. This is
> something that makes sense, since vim always changes the title, when
> called from a terminal.
> 
> But, on another path of thought that makes sense, the shell and the
> terminal restoring the title every time a command end, it also makes sense.

The research up to now shows that both are possible. And that
restoring the xterm's title is even possible in (at least) two
ways.

No idea how your old setup was doing it, honestly :-)

And, to make matters even more confusing, my vim setup doesn't
set the title (I know it is configurable, but I never made use
of it).

> In the end, i do not know where exactly it would be better to start
> searching. I betted on this list because i imagine here is a good place
> to find people that know Debian deeply. And here we are. (:

Yeah. Seemed so easy at the beginning. Anyway, the stack (not
not sure Mate-terminal supports it, skimming the reference seems
to suggest that it's not a widespread feature) seems like made
for your use case...

Cheers
 - t


signature.asc
Description: Digital signature

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[tomas]

On Sun, Sep 19, 2021 at 02:36:14PM -0500, David Wright wrote:
> On Sun 19 Sep 2021 at 21:27:49 (+0200), to...@tuxteam.de wrote:
> > On Sun, Sep 19, 2021 at 04:21:56PM -0300, Dedeco Balaco wrote:
> > > Em 19/09/2021 15:48, to...@tuxteam.de escreveu:
> > > > On Sun, Sep 19, 2021 at 03:06:28PM -0300, Dedeco Balaco wrote:
> > 
> > [...]
> > 
> > > Fine. I understand that you say that i could change my PS1 to always
> > > reset the title.
> > 
> > Specifically this is desirable whenever you want the title to show
> > a "changing" property (in this case, for example, the current
> > working directory).
> > 
> > >  But there is something this would hide, and which i did
> > > not yet found an explanation for: sometimes, the default title is reset
> > > after quitting vim, and sometimes not.
> > 
> > That was my question: did you really observe vim resetting the title at
> > program end, or was it something set dynamically by your shell (you
> > said you changed your PS1 before the upgrade and the title was "fixed"
> > at vim's exit, so there's evidence for both hypotheses :-)
> 
> I did come across this:
> 
> https://unix.stackexchange.com/questions/28500/is-it-possible-to-obtain-the-current-name-of-the-xterm-window
> 
> There are quite a few tricks that xprop can help with, but there
> just aren't enough rainy days here to find time to play with them.

Yes, I think I mentioned xprop elsethread. I don't yet know how
to get the window id of the shell's parent, but hey.

It seems xterm has even a better trick up its sleeve: it has
a window title /stack/ [1] which you can control via escape
sequences.

Now it's getting really dangerous: I must resist looking into
that -- I have a paying customer I've got to make happy :-D

Cheers

[1] 
https://stackoverflow.com/questions/3232655/can-i-get-terminal-title-or-otherwise-restore-old-one

 - t


signature.asc
Description: Digital signature

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[David Wright]

On Sun 19 Sep 2021 at 21:27:49 (+0200), to...@tuxteam.de wrote:
> On Sun, Sep 19, 2021 at 04:21:56PM -0300, Dedeco Balaco wrote:
> > Em 19/09/2021 15:48, to...@tuxteam.de escreveu:
> > > On Sun, Sep 19, 2021 at 03:06:28PM -0300, Dedeco Balaco wrote:
> 
> [...]
> 
> > Fine. I understand that you say that i could change my PS1 to always
> > reset the title.
> 
> Specifically this is desirable whenever you want the title to show
> a "changing" property (in this case, for example, the current
> working directory).
> 
> >  But there is something this would hide, and which i did
> > not yet found an explanation for: sometimes, the default title is reset
> > after quitting vim, and sometimes not.
> 
> That was my question: did you really observe vim resetting the title at
> program end, or was it something set dynamically by your shell (you
> said you changed your PS1 before the upgrade and the title was "fixed"
> at vim's exit, so there's evidence for both hypotheses :-)

I did come across this:

https://unix.stackexchange.com/questions/28500/is-it-possible-to-obtain-the-current-name-of-the-xterm-window

There are quite a few tricks that xprop can help with, but there
just aren't enough rainy days here to find time to play with them.

Cheers,
David.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[tomas]

On Sun, Sep 19, 2021 at 04:21:56PM -0300, Dedeco Balaco wrote:
> 
> Em 19/09/2021 15:48, to...@tuxteam.de escreveu:
> > On Sun, Sep 19, 2021 at 03:06:28PM -0300, Dedeco Balaco wrote:

[...]

> Fine. I understand that you say that i could change my PS1 to always
> reset the title.

Specifically this is desirable whenever you want the title to show
a "changing" property (in this case, for example, the current
working directory).

>  But there is something this would hide, and which i did
> not yet found an explanation for: sometimes, the default title is reset
> after quitting vim, and sometimes not.

That was my question: did you really observe vim resetting the title at
program end, or was it something set dynamically by your shell (you
said you changed your PS1 before the upgrade and the title was "fixed"
at vim's exit, so there's evidence for both hypotheses :-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Nate Bargmann]

* On 2021 19 Sep 12:26 -0500, Dedeco Balaco wrote:
> 
> 
> Em 19/09/2021 14:07, Greg Wooledge escreveu:
> > Since your TERM variable begins with "xterm", you can simply copy the
> > case command directly from the Debian .bashrc file into yours:
> > 
> > 
> > # If this is an xterm set the title to user@host:dir
> > case "$TERM" in
> > xterm*|rxvt*)
> > PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
> > ;;
> > *)
> > ;;
> > esac
> > 
> > 
> > Put that chunk of code anywhere in your .bashrc after your PS1 assignment,
> > and it will add a prefix that sets the terminal's title.  You can alter
> > it to suit your own preferences.  Just make sure that whatever you add
> > is surrounded by \[ \] and contains one of the sequences for changing
> > the terminal title.  (There are three of them in xterm, depending on
> > whether you want to set the title, or the icon's name, or both.  Debian
> > is using the one that sets both.)
> > 
> 
> I do not understand you. I have said my prompt is (and always were)
> fancy. Then, you say that this might be the cause of the problem - BUT,
> as a possible try to solve, you tell me to make another fancy prompt.

This is not "another fancy prompt", it is code to set the terminal title
and does not affect nor replace your prompt as it adds code that is not
displayed in the prompt to the PS1 variable.  Any user setting of PS1 is
undisturbed as shown by the $PS1 at the end.

> And do not forget one thing: the tabs' titles are working almost as they
> were before. With vim, sometimes, it does not reset when vim exits, as
> it always did, since around 20 years ago.

I've not used Vim as a main editor until very recently, right about the
time that Bullseye was released.  I don't see Vim changing the tab
titles though I do see Midnight Commander changing them as the directory
and/or panels are switched.

> I check all lines in /etc/skel/.bashrc. It does not show me anything
> new. My prompt contains only things that it has, and sometimes different
> (skel does not use as many colors as i do, for PS1).

My PS1 is very complex (I posted its code here a few weeks back), yet
the path when I cd to a directory is reflected in the tab title (gnome
terminal) as is whatever mc sets it to.

As I cannot say whether Vim formerly set tab titles, I must stop here.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[tomas]

On Sun, Sep 19, 2021 at 03:06:28PM -0300, Dedeco Balaco wrote:
> 
> 
> Em 19/09/2021 14:41, to...@tuxteam.de escreveu:
> > On Sun, Sep 19, 2021 at 01:58:16PM -0300, Dedeco Balaco wrote:
> >>
> >>
> >>>   tomas@trotzki:~$ echo $PS1
> >>>   \[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$
> >>>
> >>
> >> There has been a lot of time that i use a fancy PS1. But it does not
> >> touch the terminal title, it never did. I just worked in it to get a
> >> satisfying informative prompt.
> > 
> > Interesting. In my box it seems to be PS1 what is setting the
> > term title...
> > 
> 
> That is because you use a  enclosed between "\e]0;" and "\]",
> and i never wanted to do it. Notice that, in the PS1 value you gave
> above, you have "\u@\h: \w\a\" written twice. This is because one (the
> first) is to set the title, and another (the second) is to set the prompt.

I know, I know (after all, I analysed that in another mail). I was
just trying to reverse-engineer how things are working (by default)
on my Debian box.

In any case, here it's not vim cleaning up its title after itself,
but rather the shell's PS1 restoring it at the next prompt after
vim.

I just hoped this data point might help you pin-pointing your
problem (BTW: vim could only restore the term's title if there
were... an escape sequence to either query the title or tell the
term to save/restore it.

As to how to get xterm's [1] window title, I think you might
have to fool around with xprop. Here [2] is some example code.

Have fun :)

[1] I'm always talking xterm. I guess that this parts are
   pretty similar (if not identical) to other X based terminal
   emulators.

[2] http://www.shelldorado.com/scripts/cmds/xtitle

 - tomás


signature.asc
Description: Digital signature

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[tomas]

On Sun, Sep 19, 2021 at 01:58:16PM -0300, Dedeco Balaco wrote:
> 
> 
> >   tomas@trotzki:~$ echo $PS1
> >   \[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$
> > 
> 
> There has been a lot of time that i use a fancy PS1. But it does not
> touch the terminal title, it never did. I just worked in it to get a
> satisfying informative prompt.

Interesting. In my box it seems to be PS1 what is setting the
term title...

Cheers
 - t


signature.asc
Description: Digital signature

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Greg Wooledge]

On Sun, Sep 19, 2021 at 02:25:25PM -0300, Dedeco Balaco wrote:
> Em 19/09/2021 14:07, Greg Wooledge escreveu:

> > Oh, are you saying that you're not using Debian's default PS1?  That's
> > probably why it's no longer working the way you expected.

> I do not understand you. I have said my prompt is (and always were)
> fancy. Then, you say that this might be the cause of the problem - BUT,
> as a possible try to solve, you tell me to make another fancy prompt.
> 
> And do not forget one thing: the tabs' titles are working almost as they
> were before. With vim, sometimes, it does not reset when vim exits, as
> it always did, since around 20 years ago.
> 
> I check all lines in /etc/skel/.bashrc. It does not show me anything
> new. My prompt contains only things that it has, and sometimes different
> (skel does not use as many colors as i do, for PS1).

You customized your .bashrc and changed your prompt (the PS1 variable)
yourself.  That's fine.  You're absolutely allowed to do that (I do it
too).

If you want the terminal title to be set to a useful value when vim exits,
then the most obvious way to do it is to change PS1 as I said in the
previous message.  You could copy the code that Debian uses, or you could
write your own additional code.

I'm trying to give you the *simplest* answer that will work.  Copying
a small chunk of code from Debian's /etc/skel/.bashrc file to your
~/.bashrc file is the simplest answer.

But you also seem to be determined to find out how it used to work
in stretch.  I don't know how it worked in stretch.  I don't use
mate-terminal, or Mate, or even a desktop environment.  So I can't help
you figure out how it worked before.

All I can help you with is making it work *now*.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Dedeco Balaco]

Em 19/09/2021 14:07, Greg Wooledge escreveu:
> On Sun, Sep 19, 2021 at 01:54:48PM -0300, Dedeco Balaco wrote:
>>> Once we know what $TERM is, we can advise.
>>>
>>
>> $  echo $TERM
>> xterm-256color
> 
> Huh... OK.
> 
> 
> On Sun, Sep 19, 2021 at 01:58:16PM -0300, Dedeco Balaco wrote:
>>
>>
>>>   tomas@trotzki:~$ echo $PS1
>>>   \[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$
>>>
>>
>> There has been a lot of time that i use a fancy PS1. But it does not
>> touch the terminal title, it never did. I just worked in it to get a
>> satisfying informative prompt.
> 
> Oh, are you saying that you're not using Debian's default PS1?  That's
> probably why it's no longer working the way you expected.
> 
> If you'd like to return to the previous behavior, you'll want to add
> something like what Debian has in /etc/skel/.bashrc to your own .bashrc
> file.
> 
> Since your TERM variable begins with "xterm", you can simply copy the
> case command directly from the Debian .bashrc file into yours:
> 
> 
> # If this is an xterm set the title to user@host:dir
> case "$TERM" in
> xterm*|rxvt*)
> PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
> ;;
> *)
> ;;
> esac
> 
> 
> Put that chunk of code anywhere in your .bashrc after your PS1 assignment,
> and it will add a prefix that sets the terminal's title.  You can alter
> it to suit your own preferences.  Just make sure that whatever you add
> is surrounded by \[ \] and contains one of the sequences for changing
> the terminal title.  (There are three of them in xterm, depending on
> whether you want to set the title, or the icon's name, or both.  Debian
> is using the one that sets both.)
> 

I do not understand you. I have said my prompt is (and always were)
fancy. Then, you say that this might be the cause of the problem - BUT,
as a possible try to solve, you tell me to make another fancy prompt.

And do not forget one thing: the tabs' titles are working almost as they
were before. With vim, sometimes, it does not reset when vim exits, as
it always did, since around 20 years ago.

I check all lines in /etc/skel/.bashrc. It does not show me anything
new. My prompt contains only things that it has, and sometimes different
(skel does not use as many colors as i do, for PS1).

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Greg Wooledge]

On Sun, Sep 19, 2021 at 01:54:48PM -0300, Dedeco Balaco wrote:
> > Once we know what $TERM is, we can advise.
> > 
> 
> $  echo $TERM
> xterm-256color

Huh... OK.


On Sun, Sep 19, 2021 at 01:58:16PM -0300, Dedeco Balaco wrote:
> 
> 
> >   tomas@trotzki:~$ echo $PS1
> >   \[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$
> > 
> 
> There has been a lot of time that i use a fancy PS1. But it does not
> touch the terminal title, it never did. I just worked in it to get a
> satisfying informative prompt.

Oh, are you saying that you're not using Debian's default PS1?  That's
probably why it's no longer working the way you expected.

If you'd like to return to the previous behavior, you'll want to add
something like what Debian has in /etc/skel/.bashrc to your own .bashrc
file.

Since your TERM variable begins with "xterm", you can simply copy the
case command directly from the Debian .bashrc file into yours:


# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac


Put that chunk of code anywhere in your .bashrc after your PS1 assignment,
and it will add a prefix that sets the terminal's title.  You can alter
it to suit your own preferences.  Just make sure that whatever you add
is surrounded by \[ \] and contains one of the sequences for changing
the terminal title.  (There are three of them in xterm, depending on
whether you want to set the title, or the icon's name, or both.  Debian
is using the one that sets both.)

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Dedeco Balaco]

>   tomas@trotzki:~$ echo $PS1
>   \[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$
> 

There has been a lot of time that i use a fancy PS1. But it does not
touch the terminal title, it never did. I just worked in it to get a
satisfying informative prompt.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Dedeco Balaco]

> 
> Assuming the OP is using Debian's provided .bashrc file (and other
> shell dotfiles), PS1 is changed when .bashrc is read, which normally
> means when bash is started as an interactive, non-login shell.
> 
> Running "bash" would do that.  I prefer "exec bash" because it gives
> a cleaner starting point.
> 
> But... changing the TERM variable isn't the correct solution.  If
> mate-terminal sets TERM to something like "mate-terminal" (speculation),
> then there must be a good reason for it.  Maybe they've diverged enough
> from xterm that setting TERM to xterm would break something.
> 
> If you want the title-changing behavior of bash in a terminal whose $TERM
> doesn't begin with xterm or rxvt, it would be better to change .bashrc
> and simply allow that PS1 addition to happen on other $TERM values as
> well.
> 
> Once we know what $TERM is, we can advise.
> 

$  echo $TERM
xterm-256color
$

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Greg Wooledge]

On Sun, Sep 19, 2021 at 05:13:34PM +0200, to...@tuxteam.de wrote:
> I can't imagine MATE terminal to implement its own escaping machinery.
> They'll probably copy that of the Xterm, to stay compatible (although
> these days you never know).
> 
> So perhaps the OP gets away with pretending he has an xterm.

That's not would I would suggest.

> @Dedeco: what happens if you say "export TERM=xterm", start a new
> shell [1] (i.e. you say "bash") and then start vim?

It would be more useful to know what $TERM is *currently* set to.
(And also what it was set to by a stretch mate-terminal, but that
may not be important now, or may not be easily discoverable, unless
there's another reader out there running mate-terminal on stretch
who can test it for us.)

> [1] I don't know when PS1 gets refreshed, so being carefully here

Assuming the OP is using Debian's provided .bashrc file (and other
shell dotfiles), PS1 is changed when .bashrc is read, which normally
means when bash is started as an interactive, non-login shell.

Running "bash" would do that.  I prefer "exec bash" because it gives
a cleaner starting point.

But... changing the TERM variable isn't the correct solution.  If
mate-terminal sets TERM to something like "mate-terminal" (speculation),
then there must be a good reason for it.  Maybe they've diverged enough
from xterm that setting TERM to xterm would break something.

If you want the title-changing behavior of bash in a terminal whose $TERM
doesn't begin with xterm or rxvt, it would be better to change .bashrc
and simply allow that PS1 addition to happen on other $TERM values as
well.

Once we know what $TERM is, we can advise.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[tomas]

On Sun, Sep 19, 2021 at 09:58:17AM -0400, Greg Wooledge wrote:
> On Sun, Sep 19, 2021 at 09:44:58AM +0200, to...@tuxteam.de wrote:

[...]

> Ah yes, good old Debian /etc/skel/.bashrc at work.  Presumably you
> mean this section:
> 
> # If this is an xterm set the title to user@host:dir
> case "$TERM" in
> xterm*|rxvt*)
> PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
> ;;

Most probably, so thanks for spotting it :)

> I don't know what mate-terminal uses for $TERM, or what it used back
> in stretch, but it's something the OP could research, I suppose.  If
> it changed from "xterm" to "mate-terminal" or something along those
> lines, that would certainly explain the change.

I can't imagine MATE terminal to implement its own escaping machinery.
They'll probably copy that of the Xterm, to stay compatible (although
these days you never know).

So perhaps the OP gets away with pretending he has an xterm.

@Dedeco: what happens if you say "export TERM=xterm", start a new
shell [1] (i.e. you say "bash") and then start vim?

Cheers

[1] I don't know when PS1 gets refreshed, so being carefully here

 - t


signature.asc
Description: Digital signature

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Greg Wooledge]

On Sun, Sep 19, 2021 at 09:44:58AM +0200, to...@tuxteam.de wrote:
> I've no Mate terminal here (just plain xterm), but this fourth way is
> the one Debian chose for me: the shell prompt (via the PS1 variable)
> is the one working the magic. I guess Mate terminal works as Xterm
> here.
> 
> It's defined to be
> 
>   tomas@trotzki:~$ echo $PS1
>   \[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$

Ah yes, good old Debian /etc/skel/.bashrc at work.  Presumably you
mean this section:

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;

I don't know what mate-terminal uses for $TERM, or what it used back
in stretch, but it's something the OP could research, I suppose.  If
it changed from "xterm" to "mate-terminal" or something along those
lines, that would certainly explain the change.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Greg Wooledge]

On Sun, Sep 19, 2021 at 06:49:15AM -0300, Dedeco Balaco wrote:
> Is there a log where the previous version of Mate and mate-terminal are
> written?

It should be in /var/log/dpkg* assuming those didn't get rotated away.
I've got files up to dpkg.log.12.gz dated Sep 28, 2020.

Try this: zgrep 'upgrade mate-terminal' /var/log/dpkg.log*

I don't have that package installed, but for comparison:

unicorn:/var/log$ zgrep 'upgrade rxvt-unicode' dpkg.log*
dpkg.log.4.gz:2021-05-30 09:14:30 upgrade rxvt-unicode:amd64 9.22-10 9.22-11
dpkg.log.5.gz:2021-04-07 07:19:01 upgrade rxvt-unicode:amd64 9.22-8+b1 9.22-10
dpkg.log.8.gz:2021-01-29 18:05:56 upgrade rxvt-unicode:amd64 9.22-6 9.22-8+b1

This shows me that I upgraded rxvt-unicode from 9.22-6 to 9.22-8+b1
and then to 9.22-10 and then to 9.22-11.  There were probably many other
upgrades, in logs that I no longer have because they're over a year ago.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[tomas]

On Sat, Sep 18, 2021 at 10:23:06PM -0400, Greg Wooledge wrote:
> On Sat, Sep 18, 2021 at 10:14:39PM -0300, Dedeco Balaco wrote:
> > My window manager is Mate Desktop. The terminal i most use is its own.
> > And i use vim a lot,

[...]

> Vim has another setting called "titleold".  If this is set to a non-empty
> string, vim will use the value of this variable as the new title.  So,
> for example, if you would like the title to be changed to "Terminal"
> every time you exit vim, you can put these lines in your .vimrc file:
> 
> set title
> set titleold=Terminal
> 
> If titleold is set to the empty string, then the title isn't changed at
> all on exit -- it just stays as the filename.
> 
> If there's a *third* option (to make vim somehow read the previous title
> from the terminal, if that's even possible), then I don't know how to
> achieve it.  It would probably be specific to the terminal as well.
> 
> If you want more answers than this, I suggest asking on a vim mailing
> list.  They may have more expertise than we do.
> 
> A *fourth* option that some people use is to have their shell change the
> terminal's title on a regular or semi-regular basis [...]

I've no Mate terminal here (just plain xterm), but this fourth way is
the one Debian chose for me: the shell prompt (via the PS1 variable)
is the one working the magic. I guess Mate terminal works as Xterm
here.

It's defined to be

  tomas@trotzki:~$ echo $PS1
  \[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$

Now it's a bit tough to read with all that escape voodoo (part of this
are "real" escapes sent to the terminal, part of them are interpreted
by the shell while preparing the prompt string out of this mumbo-jumbo
template) but I'll try (the PROMPTING section from the bash manual
is of help here). Those digested by the shell prompt I label with [P],
those passed through to the term as escape sequences with [E] (cf.
[1] for the latter):

  \[->  [P]  begin sequence of non-printing chars
  \e]0; ->  [E] ESC ] 0 ;(Xterm) set window title
  \u->  [P]  useername
  @ ->   literal @
  \h->  [P]  hostname
  : ->   again, a literal
  [space]   ->   literal (this gets boring :)
  \w->  [P]  current working directory (CWD)
  \a->  [E]  bell: close "set window title" escape
  \]->  [P]  end sequence of non-printing chars

...the rest is boring prompt matter. What this cooks down to is to
set the terminal title to @: .

This has to be done at every prompt, otherwise the title wouldn't
"follow along" when I do cd, for example (or when I ssh into
another host).

When exiting vim, a new prompt is issued, so this is the one which
should take care of this.

So Dedeco -- I'd look into whatever is providing your shell prompt
as a first guess.

Cheers

[1] https://en.wikipedia.org/wiki/ANSI_escape_code

 - t


signature.asc
Description: Digital signature

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Greg Wooledge]

On Sat, Sep 18, 2021 at 10:14:39PM -0300, Dedeco Balaco wrote:
> My window manager is Mate Desktop. The terminal i most use is its own.
> And i use vim a lot,

> After the upgrade, when i quit vim, the terminal title becomes empty,
> instead of returning to the default title "Terminal".

The real question is how it worked in stretch.  There are several
moving pieces here, and it's not at all clear how they all fit together.

The terminal's title bar is set whenever some program writes the
appropriate bytes to the terminal.  Once the title is set to something,
it stays that way, until something changes it again.

So: under stretch, what program was writing what bytes to the terminal,
at what time?

We know that vim can be configured to set the title when you start it.
This is controlled by the "title" setting.  If you have "set title"
in your .vimrc file, then at startup, vim will change the terminal's
title to the name of the file you're editing.

But what happens when vim exits?  Vim doesn't know what the *previous*
title was, so how can it change the title back?  Therefore, when vim
exits (with "set title" in your .vimrc file), it changes the title
to "Thanks for flying Vim".

Vim has another setting called "titleold".  If this is set to a non-empty
string, vim will use the value of this variable as the new title.  So,
for example, if you would like the title to be changed to "Terminal"
every time you exit vim, you can put these lines in your .vimrc file:

set title
set titleold=Terminal

If titleold is set to the empty string, then the title isn't changed at
all on exit -- it just stays as the filename.

If there's a *third* option (to make vim somehow read the previous title
from the terminal, if that's even possible), then I don't know how to
achieve it.  It would probably be specific to the terminal as well.

If you want more answers than this, I suggest asking on a vim mailing
list.  They may have more expertise than we do.

A *fourth* option that some people use is to have their shell change the
terminal's title on a regular or semi-regular basis.  For example, some
people unilaterally override the title from the shell prompt every time
the prompt is drawn.  Other people override the title when the shell
changes directory.  These might be viable solutions for you as well, if
you choose.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Dedeco Balaco]

Em 18/09/2021 22:49, Jeremy Hendricks escreveu:
> I apologize for assuming you upgraded from 9 to 11 directly (skipping
> 10). It’s a common misconception that is acceptable.
> 

No problem. Actually, my first try to update was directly from a not
completely updated Debian 9 to the current Debian 11. But this did not
work at all, and i ended up discovering, after a complicated fight, that
i needed to be completely updated with the 9, and then i should upgrade
to 10, and then check if it is updated too (which naturally happened,
since i was just upgrading to it, in that moment). After that, finally,
i upgraded to 11. There are strange things, now, though. A friend of
mine said they are possible, even if we are doing everything as it
should - something that is bad and sad, for me.

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Jeremy Hendricks]

I apologize for assuming you upgraded from 9 to 11 directly (skipping 10).
It’s a common misconception that is acceptable.

On Sat, Sep 18, 2021 at 9:46 PM Dedeco Balaco 
wrote:

> I did not leap any release. I did everything correctly, step by step.
>
> The issue is not being reprodutible. I do not find a clear condition to
> make it happen. Searching about your suggestion, I found that vim has a
> few very important arguments, where 2 of them interest me a lot, to
> isolate this issue (I guess):
>
> $ vim -u NORC # does not load any RC file, global or user's
>
> $ vim -u NONE # does not load any RC file, and also no plugin
>
> More information can be found in vim man page, and inside vim:
>
> :h initialization
>
>
> Em 18/09/2021 22:27, Jeremy Hendricks escreveu:
> > Generally it’s not recommended to leap frog over releases and you should
> > upgrade in order (Ex. From 9 to 10). I suspect you might need to delete
> > some of the config files in your home directory (rename them it .bak) as
> > the version of vim, etc might be considerable different from 9 to 11 and
> > might have odd results. I’d recommend first renaming .vimrc to
> > .vimrc.bak and see if that fixes it.
> >
> > The next step might be to rename the config files for the mate-terminal
> > and test to see if it’s fixed.
> >
> > On Sat, Sep 18, 2021 at 9:15 PM Dedeco Balaco  > <mailto:dedeco.bal...@yahoo.com>> wrote:
> >
> > Hello,
> >
> > I recently upgraded my Debian 9 to Debian 11. But there are strange
> > or wrong things happening right now, that did not exist before.
> >
> > My window manager is Mate Desktop. The terminal i most use is its
> > own. And i use vim a lot, and i basically never use gvim, i prefer
> > it through a terminal window.
> >
> > Each mate-terminal window can have several tabs in it. I use this
> > feature a lot too. Each tab has its own title, which works pretty
> > fine. There are several programs that change the title shown while
> > they run.
> >
> > Vim is one of these programs. While it is running, the terminal
> > title shows the name of the file currently being edited, and the
> > number of files that was opened with it, when it was launched.
> >
> > After the upgrade, when i quit vim, the terminal title becomes
> > empty, instead of returning to the default title "Terminal".
> >
> > Why is this happening? A bug in Vim? In mate-terminal? Or in Debian
> 11?
> >
>
>

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Dedeco Balaco]

I did not leap any release. I did everything correctly, step by step.

The issue is not being reprodutible. I do not find a clear condition to
make it happen. Searching about your suggestion, I found that vim has a
few very important arguments, where 2 of them interest me a lot, to
isolate this issue (I guess):

$ vim -u NORC # does not load any RC file, global or user's

$ vim -u NONE # does not load any RC file, and also no plugin

More information can be found in vim man page, and inside vim:

:h initialization


Em 18/09/2021 22:27, Jeremy Hendricks escreveu:
> Generally it’s not recommended to leap frog over releases and you should
> upgrade in order (Ex. From 9 to 10). I suspect you might need to delete
> some of the config files in your home directory (rename them it .bak) as
> the version of vim, etc might be considerable different from 9 to 11 and
> might have odd results. I’d recommend first renaming .vimrc to
> .vimrc.bak and see if that fixes it.
> 
> The next step might be to rename the config files for the mate-terminal
> and test to see if it’s fixed.
> 
> On Sat, Sep 18, 2021 at 9:15 PM Dedeco Balaco  <mailto:dedeco.bal...@yahoo.com>> wrote:
> 
> Hello,
> 
> I recently upgraded my Debian 9 to Debian 11. But there are strange
> or wrong things happening right now, that did not exist before.
> 
> My window manager is Mate Desktop. The terminal i most use is its
> own. And i use vim a lot, and i basically never use gvim, i prefer
> it through a terminal window.
> 
> Each mate-terminal window can have several tabs in it. I use this
> feature a lot too. Each tab has its own title, which works pretty
> fine. There are several programs that change the title shown while
> they run.
> 
> Vim is one of these programs. While it is running, the terminal
> title shows the name of the file currently being edited, and the
> number of files that was opened with it, when it was launched.
> 
> After the upgrade, when i quit vim, the terminal title becomes
>     empty, instead of returning to the default title "Terminal".
> 
> Why is this happening? A bug in Vim? In mate-terminal? Or in Debian 11?
> 

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Jeremy Hendricks]

Generally it’s not recommended to leap frog over releases and you should
upgrade in order (Ex. From 9 to 10). I suspect you might need to delete
some of the config files in your home directory (rename them it .bak) as
the version of vim, etc might be considerable different from 9 to 11 and
might have odd results. I’d recommend first renaming .vimrc to .vimrc.bak
and see if that fixes it.

The next step might be to rename the config files for the mate-terminal and
test to see if it’s fixed.

On Sat, Sep 18, 2021 at 9:15 PM Dedeco Balaco 
wrote:

> Hello,
>
> I recently upgraded my Debian 9 to Debian 11. But there are strange or
> wrong things happening right now, that did not exist before.
>
> My window manager is Mate Desktop. The terminal i most use is its own. And
> i use vim a lot, and i basically never use gvim, i prefer it through a
> terminal window.
>
> Each mate-terminal window can have several tabs in it. I use this feature
> a lot too. Each tab has its own title, which works pretty fine. There are
> several programs that change the title shown while they run.
>
> Vim is one of these programs. While it is running, the terminal title
> shows the name of the file currently being edited, and the number of files
> that was opened with it, when it was launched.
>
> After the upgrade, when i quit vim, the terminal title becomes empty,
> instead of returning to the default title "Terminal".
>
> Why is this happening? A bug in Vim? In mate-terminal? Or in Debian 11?
>

A bug in Vim, in Mate Terminal or in Debian 11?

[Dedeco Balaco]

Hello,

I recently upgraded my Debian 9 to Debian 11. But there are strange or
wrong things happening right now, that did not exist before.

My window manager is Mate Desktop. The terminal i most use is its own.
And i use vim a lot, and i basically never use gvim, i prefer it through
a terminal window.

Each mate-terminal window can have several tabs in it. I use this
feature a lot too. Each tab has its own title, which works pretty fine.
There are several programs that change the title shown while they run.

Vim is one of these programs. While it is running, the terminal title
shows the name of the file currently being edited, and the number of
files that was opened with it, when it was launched.

After the upgrade, when i quit vim, the terminal title becomes empty,
instead of returning to the default title "Terminal".

Why is this happening? A bug in Vim? In mate-terminal? Or in Debian 11?

Re: vim not seeing many Unicode chars

[Tom Browder]

On Tue, May 18, 2021 at 11:37 IL Ka  wrote
…

Thanks!

-Tom

Re: vim not seeing many Unicode chars

[Tom Browder]

 On Tue, May 18, 2021 at 09:36 Greg Wooledge  wrote:

> On Tue, May 18, 2021 at 09:25:30AM -0500,

…

Thanks, Greg.

-Tom

Re: vim not seeing many Unicode chars [SOLVED]

[Tom Browder]

On Tue, May 18, 2021 at 11:38 Steve Dondley  wrote:

> On 2021-05-18 12:23 PM, Tom Browder wrote:
>
> On Tue, May 18, 2021 at 11:08 Steve Dondley  wrote:
>
>> On 2021-05-18 10:25 AM, Tom Browder wrote:
>>
>> I'm running Debian Buster. Inside a terminal window I can use Emacs and
>> can see and enter Unicode chars.
>>
>> But in the same terminal, when I run vim, I have trouble editing or
>> seeing most Unicode chars above ASCII.
>>
>>
>>
>>
>>
>> Type ":set fileencoding?" from inside vim.
>>
>> What do you see?
>>
>
> I see at the bottom of the window (without the square brackets):
>
> [   fileencoding=  ]
>
> -Tom
>
> OK, that's one issue. In your vimrc file, add "set fileencoding=utf8".
> Restart vim. Your files will be saved with utf8.
>
> Now check "set encoding?"
>
> What does that say?
>
> If it says nothing, add "set encoding=utf8" to the vimrc file. Now vim
> should show the files with utf8 encoding.
>
I did all you suggested, and eventually boiled it down to one and only one
line in my $HOME/.vimrc file:

set encoding=utf8

and all works when I vim the file with utf8 chars! I can see them, delete
them, and enter them.

Thanks so much, Steve. As you said, that's the first issue.

Now I'll start cleaning up the locale mess and use the rest of the
suggestions.

Best regards,

-Tom

Re: vim not seeing many Unicode chars

[deloptes]

Eike Lantzsch ZP6CGE wrote:

> To noboy in particular:
> Yes, that is so and for whatever reasons there might be, it is extremely
> confusing causing frustration, despair and eventually anger.
> It is especially exasperating if one works with several DE which,
> contrary to the underlying distribution, also change their behaviour
> once in awhile.
> I used to have en_US language with German keyboard and SA-paraguaian
> monetary symbols. That is an edge-case which worked fine for many years
> but recently gives me trouble with KDE and also Perl.
> Cheers to everybody on the list

This is why I decided to stick to the continuation of KDE3 now called TDE -
using Cyrillic, German and English - no issues.
I refused to be victim of developers/designers dictatorship.
TDE might not be perfect, but the community wants to have stable desktop.

It could also work with newer KDE if it were possible to find one stable
version and stick to it. However your post and similar are not very
motivational to try newer KDE again soon.

Re: vim not seeing many Unicode chars

[Eike Lantzsch ZP6CGE]

On Dienstag, 18. Mai 2021 13:04:00 -04 hdv@gmail wrote:
> On 2021-05-18 18:37, IL Ka wrote:
> > Thanks all. I looked at my config files (which go back at least
> > 15
> > years) and found lots of explicitly setting both LC_ALL=C and
> > LC_LANG=C.
> >
> > Should I remove all, or just remove the LC_ALL?
> >  >
> >  > Using LC_ALL is strongly discouraged as it overrides everything.
> >
> > Please use it only when testing and never set it in a startup file.
> > https://wiki.debian.org/Locale 
> >
> > It is better to set everything explicitly in "/etc/default/locale"
> >
> > Even better: use
> > $ sudo dpkg-reconfigure locales
> > it will generate all locales you need AND set the default one in
> > this file.
> >
> > There is NO reason to use anything except UTF-8 in 2021
>
> Please, be aware that not all Desktop Environments (like KDE's Plasma)
> honour this setting. Often, they have their own mechanisms for
> setting the locale within the DE itself.
>
> Grx HdV

To noboy in particular:
Yes, that is so and for whatever reasons there might be, it is extremely
confusing causing frustration, despair and eventually anger.
It is especially exasperating if one works with several DE which,
contrary to the underlying distribution, also change their behaviour
once in awhile.
I used to have en_US language with German keyboard and SA-paraguaian
monetary symbols. That is an edge-case which worked fine for many years
but recently gives me trouble with KDE and also Perl.
 Cheers to everybody on the list

--
Eike Lantzsch ZP6CGE

Re: vim not seeing many Unicode chars

[Greg Wooledge]

On Tue, May 18, 2021 at 11:24:39AM -0500, Tom Browder wrote:
> Thanks all. I looked at my config files (which go back at least 15 years)
> and found lots of explicitly setting both LC_ALL=C and LC_LANG=C.
> 
> Should I remove all, or just remove the LC_ALL?

LC_LANG isn't even a variable that actually gets used.  Maybe it's a typo
that you made which had no observable negative effects, so it just hung
around.

I would remove both, for sure.

Re: vim not seeing many Unicode chars

[hdv@gmail]

On 2021-05-18 18:37, IL Ka wrote:


Thanks all. I looked at my config files (which go back at least 15
years) and found lots of explicitly setting both LC_ALL=C and LC_LANG=C.

Should I remove all, or just remove the LC_ALL?


 > Using LC_ALL is strongly discouraged as it overrides everything. 
Please use it only when testing and never set it in a startup file.

https://wiki.debian.org/Locale 

It is better to set everything explicitly in "/etc/default/locale"

Even better: use
$ sudo dpkg-reconfigure locales
it will generate all locales you need AND set the default one in this file.

There is NO reason to use anything except UTF-8 in 2021


Please, be aware that not all Desktop Environments (like KDE's Plasma) 
honour this setting. Often, they have their own mechanisms for setting 
the locale within the DE itself.


Grx HdV

Re: vim not seeing many Unicode chars

[Steve Dondley]

On 2021-05-18 12:23 PM, Tom Browder wrote:

> On Tue, May 18, 2021 at 11:08 Steve Dondley  wrote: 
> 
> On 2021-05-18 10:25 AM, Tom Browder wrote: 
> 
> I'm running Debian Buster. Inside a terminal window I can use Emacs and can 
> see and enter Unicode chars. 
> 
> But in the same terminal, when I run vim, I have trouble editing or seeing 
> most Unicode chars above ASCII. 
> 
> Type ":set fileencoding?" from inside vim. 
> 
> What do you see?

I see at the bottom of the window (without the square brackets): 

[   fileencoding=  ] 

-Tom 

OK, that's one issue. In your vimrc file, add "set fileencoding=utf8".
Restart vim. Your files will be saved with utf8. 

Now check "set encoding?" 

What does that say? 

If it says nothing, add "set encoding=utf8" to the vimrc file. Now vim
should show the files with utf8 encoding.

Re: vim not seeing many Unicode chars

[IL Ka]

>
>
> Thanks all. I looked at my config files (which go back at least 15 years)
> and found lots of explicitly setting both LC_ALL=C and LC_LANG=C.
>
> Should I remove all, or just remove the LC_ALL?
>

> Using LC_ALL is strongly discouraged as it overrides everything. Please
use it only when testing and never set it in a startup file.
https://wiki.debian.org/Locale

It is better to set everything explicitly in "/etc/default/locale"

Even better: use
$ sudo dpkg-reconfigure locales
it will generate all locales you need AND set the default one in this file.

There is NO reason to use anything except UTF-8 in 2021




>

Re: vim not seeing many Unicode chars

[Tom Browder]

On Tue, May 18, 2021 at 09:25 Tom Browder  wrote:

> I'm running Debian Buster. Inside a terminal window I can use Emacs and
> can see and enter Unicode chars.
>
...

Thanks all. I looked at my config files (which go back at least 15 years)
and found lots of explicitly setting both LC_ALL=C and LC_LANG=C.

Should I remove all, or just remove the LC_ALL?

-Tom

Re: vim not seeing many Unicode chars

[Tom Browder]

On Tue, May 18, 2021 at 11:08 Steve Dondley  wrote:

> On 2021-05-18 10:25 AM, Tom Browder wrote:
>
> I'm running Debian Buster. Inside a terminal window I can use Emacs and
> can see and enter Unicode chars.
>
> But in the same terminal, when I run vim, I have trouble editing or seeing
> most Unicode chars above ASCII.
>
>
>
>
>
> Type ":set fileencoding?" from inside vim.
>
> What do you see?
>

I see at the bottom of the window (without the square brackets):

[   fileencoding=  ]

-Tom

Re: vim not seeing many Unicode chars

[Steve Dondley]

On 2021-05-18 10:25 AM, Tom Browder wrote:

> I'm running Debian Buster. Inside a terminal window I can use Emacs and can 
> see and enter Unicode chars. 
> 
> But in the same terminal, when I run vim, I have trouble editing or seeing 
> most Unicode chars above ASCII.

Type ":set fileencoding?" from inside vim. 

What do you see?