Re: vim seems to have problems rendering this utf8 sequence : හොඳ විනෝදයක්

On my computer at least, the characters each appear to be double-wide, and as a result of how gvim works, I get the left-hand side of the characters presented, which makes all the characters look all squashed up and overlapping. That's with the Terminus font on an earlier Fedora Linux.

Regards, brickviking

On Wed, 30 Apr 2025 at 05:26, 'Frank Schwidom' via vim_use <vim_use@googlegroups.com> wrote:

It is on all terminals with vim and nvim but gvim cannot display the characters.

On 2025-04-29 17:20:01, 'Paul' via vim_use wrote:
> Is it only Vim, or is it anything in your terminal (ie. your font)? Does gvim show it OK?
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> --- You received this message because you are subscribed to the Google
> Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/aBD8Mcfi69hUOsTR%40kitt.
>

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aBEKl7H80UmI76Hk%40debian64.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAHWye84xfOgHfW52t91Do_bm9eLOKNMby1bB3FCgYH%2BpM2gh8g%40mail.gmail.com.

Re: vim seems to have problems rendering this utf8 sequence : හොඳ විනෝදයක්

It is on all terminals with vim and nvim but gvim cannot display the characters.

On 2025-04-29 17:20:01, 'Paul' via vim_use wrote:
> Is it only Vim, or is it anything in your terminal (ie. your font)? Does gvim show it OK?
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> --- You received this message because you are subscribed to the Google
> Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/aBD8Mcfi69hUOsTR%40kitt.
>

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aBEKl7H80UmI76Hk%40debian64.

Re: vim seems to have problems rendering this utf8 sequence : හොඳ විනෝදයක්

Is it only Vim, or is it anything in your terminal (ie. your font)? Does gvim show it OK?

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aBD8Mcfi69hUOsTR%40kitt.

vim seems to have problems rendering this utf8 sequence : හොඳ විනෝදයක්

Hi I am on VIM - Vi IMproved 8.2 (2019 Dec 12 kompiliert am Mar 30 2025 03:33:09) (from debian 11)

It seems to be that vim has problems to render the string

හොඳ විනෝදයක් and its surroundings correctly.

How can I fix that?



--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aA%2BWhBh97spWNYRd%40debian64.

Re: Auto set xfce4-terminal tab to currently edited file?

Gary,

Thanks for the clarifications.

These are the installed packages:

$ apt list -a --installed vim*
Listing... Done
vim-common/stable,now 2:9.0.1378-2+deb12u2 all [installed]

vim-nox/stable,now 2:9.0.1378-2+deb12u2 amd64 [installed]

vim-runtime/stable,now 2:9.0.1378-2+deb12u2 all [installed,automatic]

vim-tiny/stable,now 2:9.0.1378-2+deb12u2 amd64 [installed]


Here is also:

$ vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Feb 16 2025 05:23:41)
Included patches: 1-1378, 1499, 1532, 1848, 1858, 1873, 1969, 2142
Modified by team+vim@tracker.debian.org
Compiled by team+vim@tracker.debian.org
Huge version without GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm +tcl
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
-balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +gettext +num64 +textobjects
-browse -hangul_input +packages +textprop
++builtin_terms +iconv +path_extra +timers
+byte_offset +insert_expand +perl +title
+channel +ipv6 +persistent_undo -toolbar
+cindent +job +popupwin +user_commands
-clientserver +jumplist +postscript +vartabs
-clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +vim9script
+cmdline_hist +langmap -python +viminfo
+cmdline_info +libcall +python3 +virtualedit
+comments +linebreak +quickfix +visual
+conceal +lispindent +reltime +visualextra
+cryptv +listcmds +rightleft +vreplace
+cscope +localmap +ruby +wildignore
+cursorbind +lua +scrollbind +wildmenu
+cursorshape +menu +signs +windows
+dialog_con +mksession +smartindent +writebackup
+diff +modify_fname +sodium -X11
+digraphs +mouse -sound -xfontset
-dnd -mouseshape +spell -xim
-ebcdic +mouse_dec +startuptime -xpm
+emacs_tags +mouse_gpm +statusline -xsmp
+eval -mouse_jsbterm -sun_workshop -xterm_clipboard
+ex_extra +mouse_netterm +syntax -xterm_save
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -tag_old_static
system vimrc file: "/etc/vim/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -Wdate-time -g -O2 -ffile-prefix-map=/build/reproducible-path/vim-9.0.1378=. -fstack-protector-strong -Wformat -Werror=format-security -DSYS_VIMRC_FILE=\"/etc/vim/vimrc\" -DSYS_GVIMRC_FILE=\"/etc/vim/gvimrc\" -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -Wl,-E -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim -lm -ltinfo -lselinux -lsodium -lacl -lattr -lgpm -L/usr/lib -llua5.2 -Wl,-E -fstack-protector-strong -L/usr/local/lib -L/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/python3.11/config-3.11-x86_64-linux-gnu -lpython3.11 -ldl -lm -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lm -lruby-3.1 -lm -L/usr/lib


On Fri, 25 Apr 2025 12:00:02 -0700 Gary Johnson wrote:

> :set title

This works! To achieve what I want, I added these 2 lines to my .vimrc:

set title
set titlestring=%t

> Oh! I often forget that some distributions have a vim package built
> without support for X. Why one would do that these days is beyond
> me, but they do.

Minimal software usually means less bugs/vulnerabilities.

Thanks again!

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250427065800.7769d158%40localhost.

Re: Auto set xfce4-terminal tab to currently edited file?

On 2025-04-25, Steven H. wrote:
> Thanks Garry. Answers below:
>
> On Thu, 24 Apr 2025 12:25:16 -0700 Gary Johnson wrote:
>
> > Try executing ":verbose set title?" to see if it's been set.
>
> This outputs 'notitle' in the status line (if that is the correct term).

Interesting. That suggests that vim thinks the window title can't
be restored, which further suggests that your vim was built without
the X11 feature, which you confirmed below.

> > If it hasn't, try setting it and see if just that fixes the problem.
>
> How do I do this, please? (sorry if it is a stupid question)

It's not. You can set it with the command:

:set title

but I don't know that that will help since your vim was build
without the X11 feature. That feature is in the normal build (see
":help :version"), so if your vim does not have it, it's probably
a tiny version, which doesn't have many features.

When you execute ":version", one of the first few lines, the one
immediately above the list of features, will show the type of build,
e.g.,

Tiny version without GUI. Features included (+) or not (-):

or

Normal version with GTK3 GUI. Features included (+) or not (-):

My guess is that yours is the tiny version.

Oh! I often forget that some distributions have a vim package built
without support for X. Why one would do that these days is beyond
me, but they do. So you may just need to install a vim package with
X11. On Ubuntu, that would be vim-gtk3. I know the name suggests
that's it's a GUI version of vim, which it is, but the vim program
it includes has support for X11.

> > Check ":verbose set t_ts?" to see what it says.
>
> It says ' t_ts=^[]2;'

That matches mine.

> > When Vim was compiled with HAVE_X11 defined, the original title will
> > be restored if possible. The output of ":version" will include "+X11"
> > when HAVE_X11 was defined, otherwise it will be "-X11".
>
> It shows '-X11'.

That makes sense.

Regards,
Gary

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250425190002.GF30799%40phoenix.

Re: Auto set xfce4-terminal tab to currently edited file?

Thanks Garry. Answers below:

On Thu, 24 Apr 2025 12:25:16 -0700 Gary Johnson wrote:

> Try executing ":verbose set title?" to see if it's been set.

This outputs 'notitle' in the status line (if that is the correct term).

> If it hasn't, try setting it and see if just that fixes the problem.

How do I do this, please? (sorry if it is a stupid question)

> Check ":verbose set t_ts?" to see what it says.

It says ' t_ts=^[]2;'

> When Vim was compiled with HAVE_X11 defined, the original title will
> be restored if possible. The output of ":version" will include "+X11"
> when HAVE_X11 was defined, otherwise it will be "-X11".

It shows '-X11'.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250425172700.390aad8a%40localhost.

Re: Auto set xfce4-terminal tab to currently edited file?

On 2025-04-24, Steven H. wrote:
> On Thu, 24 Apr 2025 10:38:31 -0700 Gary Johnson wrote:
>
> > It works for me with no options manually set:
> >
> > $ vim -N -u NONE -i NONE testfile
>
> Doesn't work on Debian 12 and xfce-4 terminal 1.0.4.
> Any idea why?

Not off-hand. We could start by looking at ":help 'title'.

*'title'* *'notitle'*
'title' boolean (default off, on when title can be restored)
global

Try executing ":verbose set title?" to see if it's been set. If it
hasn't, try setting it and see if just that fixes the problem.

When on, the title of the window will be set to the value of
'titlestring' (if it is not empty), or to:
filename [+=-] (path) - VIM
Where:
filename the name of the file being edited
- indicates the file cannot be modified, 'ma' off
+ indicates the file was modified
= indicates the file is read-only
=+ indicates the file is read-only and modified
(path) is the path of the file being edited
- VIM the server name |v:servername| or "VIM"
Only works if the terminal supports setting window titles
(currently Amiga console, Win32 console, all GUI versions and
terminals with a non-empty 't_ts' option - these are Unix xterm and
iris-ansi by default, where 't_ts' is taken from the builtin termcap).

We know that xfce-4-terminal supports this. Maybe 't_ts' is not
being set correctly. Check ":verbose set t_ts?" to see what it
says.

*X11*
When Vim was compiled with HAVE_X11 defined, the original title will
be restored if possible. The output of ":version" will include "+X11"
when HAVE_X11 was defined, otherwise it will be "-X11". This also
works for the icon name |'icon'|.

That would be good to check, too, unless, of course, that particular
Vim works in other terminals. Does it? Also, I don't know if
HAVE_X11 affects whether the title can be set. That seems more of
a terminal and terminfo thing

But: When Vim was started with the |-X| argument, restoring the title
will not work (except in the GUI).
If the title cannot be restored, it is set to the value of 'titleold'.
You might want to restore the title outside of Vim then.
When using an xterm from a remote machine you can use this command: >

rsh machine_name xterm -display $DISPLAY &
ssh -X machine_name xterm &
<
then the WINDOWID environment variable should be inherited and the
title of the window should change back to what it should be after
exiting Vim.

That's a start, anyway.

Regards,
Gary

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250424192516.GE30799%40phoenix.

Re: Auto set xfce4-terminal tab to currently edited file?

On Thu, 24 Apr 2025 10:38:31 -0700 Gary Johnson wrote:

> It works for me with no options manually set:
>
> $ vim -N -u NONE -i NONE testfile

Doesn't work on Debian 12 and xfce-4 terminal 1.0.4.
Any idea why?

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250424180015.6f704f87%40localhost.

Re: Auto set xfce4-terminal tab to currently edited file?

On 2025-04-24, Christian Brabandt wrote:
> On Thu, 24 Apr 2025, Steven H. wrote:
>
> > Is there a way to automatically set xfce4-terminal tab's name to the
> > name of the file currently opened in vim?
>
> It may work by setting the 'titlestring' option. But not sure if this
> ends up as the tab name for xfce4. Check the help at :h 'titlestring'

It works for me with no options manually set:

$ vim -N -u NONE -i NONE testfile

The 'title' option is set automatically.

I'm using xfce4-terminal 0.8.9.1 on Ubuntu 20.04.6 over an ssh
connection.

Regards,
Gary

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250424173831.GD30799%40phoenix.

Re: Auto set xfce4-terminal tab to currently edited file?

On Thu, 24 Apr 2025, Steven H. wrote:

> Is there a way to automatically set xfce4-terminal tab's name to the
> name of the file currently opened in vim?

It may work by setting the 'titlestring' option. But not sure if this
ends up as the tab name for xfce4. Check the help at :h 'titlestring'

Thanks,
Christian
--
It is by the fortune of God that, in this country, we have three benefits:
freedom of speech, freedom of thought, and the wisdom never to use either.
-- Mark Twain

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aApzezGpk2Pp1%2Bgq%40256bit.org.

Auto set xfce4-terminal tab to currently edited file?

Hi,

Is there a way to automatically set xfce4-terminal tab's name to the
name of the file currently opened in vim?

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250424170512.0137e505%40localhost.

Re: What do you use for (fuzzy) file search?

I'm wondering whether not mentioning that 'path' can (should?) be set
locally is intentional. I typically use `setlocal path=` on
a per-filetype basis in `~/.vim/after/ftplugin` scripts.

I'm of two minds regarding that strategy.

On one hand that is how I override filetype-specific stuff in general, and some of my after scripts are pretty large.

On the other hand, I have found &path to be highly framework/stack dependent instead of filetype-specific, which lead me to replicate the same setting over several files, which I didn't really like.

I've switched to a more "holistic" approach, where I set &path in my vimrc, to an exhaustive list of interesting directories typical of the kind of project I work on.

The linked gist kind of reflects my position on this, but feel free to comment on it if you feel something is missing or wrong.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/fac95e14-dfa6-47e7-8eb9-559cbcec0d2en%40googlegroups.com.

Re: What do you use for (fuzzy) file search?

Hello,

I am using fzf with ripgrep, and it is working for fairly complex project directories. It does the job. I am searching file names, and file content with fzf and ripgrep.

I also have mappings that use the quickfix window (using ripgrep).

Regards

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CA%2Bek4BFNyXM_cCBPcbA1jAjpmh%3DAwpPStGMG1SyMOXLo2mS_fg%40mail.gmail.com.

Re: What do you use for (fuzzy) file search?

On 2025-04-21, Romain Lafourcade <romainlafourcade@gmail.com> wrote:
> I have settled with :help :find in
> conjunction with a finely tuned :help 'path' for over ten years, now.
> [...]
> - and a generic &path that works for me and evolves all the time
> [...]
> See this gist if you are interested by that &path
> business: https://gist.github.com/romainl/7e2b425a1706cd85f04a0bd8b3898805

Very nice gists. A good reminder of many things I have to relearn :-)

I'm wondering whether not mentioning that 'path' can (should?) be set
locally is intentional. I typically use `setlocal path=` on
a per-filetype basis in `~/.vim/after/ftplugin` scripts.

Life.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/vubbg0%2410ak%241%40ciao.gmane.io.

Re: What do you use for (fuzzy) file search?

On Sun, 20 Apr 2025 23:51:21 -0700 (PDT)
Romain Lafourcade <romainlafourcade@gmail.com> wrote:

> My setup comprises...
>
> - a bunch of intuitive mappings:
>
> " global find
> nnoremap ,f :find *
> nnoremap ,s :sfind *
> nnoremap ,v :vert sfind *
> nnoremap ,t :tabfind *
>
> " find in directory of current buffer
> nnoremap ,F :find <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
> nnoremap ,S :sfind <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
> nnoremap ,V :vert sfind <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
> nnoremap ,T :tabfind <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
>
> - the wildmenu set how I like it:
>
> set wildmenu
> set wildignore+=*.swp,*.bak
> set wildignore+=*/.git/**/*,*/.hg/**/*,*/.svn/**/*
> set wildignore+=*/min/*,*/vendor/*,bundle.*
> set wildignore+=*/coverage/*
> set wildignore+=*/java/*,*/target/*,*/out/*
> set wildignore+=tags,cscope.*
> set wildignore+=*.tar.*
> set wildignorecase
>
> - and a generic &path that works for me and evolves all the time, as
> I work with new frameworks and such:
>
> set path-=/usr/include
> " covers nuxt, next, astro, and most JS frameworks
> set path+=app/**,assets/**
> set path+=components/**,composables/**,content/**
> set path+=layouts/**,lib/**
> set path+=middleware/**,modules/**
> set path+=pages/**,plugins/**,public/**
> set
> path+=server/**,src/**,ssl/**,static/**,store/**,styles/**,storyblok/**
> set path+=test/**,types/** set path+=utils/**
>
> See this gist if you are interested by that &path
> business:
> https://gist.github.com/romainl/7e2b425a1706cd85f04a0bd8b3898805

Thank you Romain for the detailed answer. This is exactly what I was
looking for! I will implement your approach and tweak it to my like, if
needed. The idea of a high-granularity &path is great. Thanks again!

On Mon, 21 Apr 2025 15:05:15 +0000
Igbanam Ogbuluijah <xigbanam@gmail.com> wrote:

> While this is comprehensive ÔÇö thanks for sharing this ÔÇö I get this
> same behaviour with less configuration using FZF

Igbanam, I believe one can do either: if you want to get the plugin way,
you use FZF. Otherwise, you use Romain's approach. Both are fine in my
view. After all, that's why we are using vim: to tailor it to our needs
(and small obsessions).

Roberto

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250422193501.00000715%40gmail.com.

Re: Difficulty using vim within xfce4-terminal

I believe I finally determined the cause.  xfce4-terminal does not emulate the xterm behavior where it will paste from cut buffer 0 if the primary selection is empty.  

I like some of the features of xfce4 terminal (reformat on window resize, multiple tabs), but I've decided to stick with xterm because I prefer the fonts and the pasting behavior there.  

On Mon, Mar 10, 2025 at 11:55 AM Mark Waggoner <mark@wagnell.com> wrote:

Thanks for the reply.  To answer your questions:

:echo has('clipboard') 

1

:set mouse? clipboard?

  mouse=a
  clipboard=autoselect

I've now discovered that the difference is some kind of difference in the way xterm and xfce4-terminal do the paste, not in the way vim is working.

• Open vim in xfce4-terminal
• Select some text
• Middle click paste into xterm works
• Middle click paste into a different xfce4-terminal works
• Deselect text and exit vim in the 
• Middle-click paste into xterm works
• Middle-click paste into xfce4-terminal does NOT work

This gives me some clues:

:help x11-selection

On Thu, Mar 6, 2025 at 2:20 AM 'Paul' via vim_use <vim_use@googlegroups.com> wrote:

On Wed, Feb 26, 2025 at 03:13:31PM -0800, Mark Waggoner wrote:
>   Yes, mouse support is enabled, and that's the way I want it!   (mouse=a).  As I noted, this works fine in xterm,
>   but when used in xfce4-terminal, it does not.
>   On Monday, February 24, 2025 at 6:12:26 PM UTC-8 Grant Taylor wrote:

Just to double check, when in xfce4-terminal, what do `:echo has('clipboard')` and `:set mouse? clipboard?` show?

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/Z8l2yFvvpW0EUP92%40kitt.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAJjaVfVgqLAH2D9b81370TGyoPwAHbn5Z5AePmpEnU_fOd%2BayA%40mail.gmail.com.

Re: What do you use for (fuzzy) file search?

On 2025-04-19, Enno <enno.nagel@gmail.com> wrote:
> While fzf.vim is a classic, fuzzy finding has become built-in and there is
> also a more native implementation: https://github.com/Donaldttt/fuzzyy

In the same spirit, I use my own plugin, which relies purely on Vim's
built-in features: https://github.com/lifepillar/vim-zeef. That is meant
for people who want some minimal support for dynamically filtering
a list of entries inside Vim, but they are willing to write their own
custom filters in Vim script. Although the plugin can be used to filter
the results of an external program such as ripgrep, it's not fast for
hundreds of thousands of entries or more: I would use fzf for that.

I partly sympathize with Romain's arguments. Even if my plugin supports
fuzzy matching through `matchfuzzypos()`, I prefer to use the exact
filter (enabled by default): even if it is less forgiving, it allows me
to pinpoint what I need to target (typically, another buffer, a recent
file, or a tag in the current buffer) more efficiently.

Hope this helps,
Life.




--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/vu5ufi%24tis%241%40ciao.gmane.io.

Re: What do you use for (fuzzy) file search?

While this is comprehensive — thanks for sharing this — I get this same behaviour with less configuration using FZF

1. Decide I want to edit the Avatar component
2. :Rg Avatar — this uses rip_grep. You can configure this to use the finder of your choice. A couple choices are the_silver_searcher and sharkdp/fd.
   
3. (optional) further filter down
4. Choose the candidate with a few keystrokes

I think FZF has done — and continues to do — a good job with fuzzy finding.

Igbanam

On Mon, Apr 21, 2025 at 6:51 AM Romain Lafourcade <romainlafourcade@gmail.com> wrote:

In any case, I'm eager to know how do you manage (fuzzy) file search
and editing. I'm also open to completely new approaches.

I have used a number of fuzzy finders in the past but none of them really worked for me in the long run and I have settled with :help :find in conjunction with a finely tuned :help 'path' for over ten years, now.

I don't like existing fuzzy finders for the following reasons:

- "Fuzzy" is too unnatural for me and I find the effort required for picking letters in the middle of a word too expensive. My brain doesn't do "fuzzy" at all.

- The way most fuzzy finders are designed is very inefficient and leads to what I think are silly optimizations. They start by showing you "everything" and then let you filter down the list as-you-type, which is admittedly a pretty satisfying UX, but it has a few consequences. #1 is that, at any time, most of what you see is stuff you are not interested in, which is just plain noise. #2 is that, to be usable, the filtering must be insanely fast, hence the "course à l'échalotte" that gives us a new "faster grep" every then and now. #3 the as-you-type filtering mechanism forces the user to parse the whole screen and make decisions way too many times despite the initial decision having already been made. This is incredibly wasteful.

The "fuzzy" workflow is:

1. Decide that you want to edit the "Avatar" component.

2. Bring up the fuzzy interface.

3. Scan the top of the "everything" list in case the stuff you want is already there (costly).

4. Choose a single character of the target and type it (costly).

5. Scan the results in case the target is in the list (costly).

6. Type one more character, possibly one that is in middle of the word (costly).

7. Scan the results again (costly).

(…)

X. Press a key to do what you wanted to do with the target when it is found.

The number of discrete steps is not a problem per se, IMO, but the cost and the repetition of some of them is. In practice, most users actually skip the costly "scan" steps and just spell out the target name until there is only one hit, which is nothing but a wasteful workaround.

I mean, the UX of the list becoming shorter as you type is pretty fluid and "live" so it is nice and I can definitely understand why people like it… but I don't share that sentiment.

By contrast, here is the workflow with :find and a proper &path:

1. Decide that you want to edit the "Avatar" component.

2. Bring up the :find command, by typing it or via a mapping.

3. Think of a search string and type it (costly).

4. Execute the command.

5. Choose a candidate from the wildmenu with a few tabs.

The cost is minimal and the costly operations happens only once, upfront. In practice, the user may have to press <Tab> a few times to get to the right item, which may seem wasteful, but at least they don't have to rethink the whole thing each time. And it's all instant without requiring any brute force strategy or algorithmic sophistication.

My setup comprises…

- a bunch of intuitive mappings:

" global find

nnoremap ,f :find *
nnoremap ,s :sfind *
nnoremap ,v :vert sfind *
nnoremap ,t :tabfind *

" find in directory of current buffer
nnoremap ,F :find <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
nnoremap ,S :sfind <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
nnoremap ,V :vert sfind <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
nnoremap ,T :tabfind <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>

- the wildmenu set how I like it:

set wildmenu

set wildignore+=*.swp,*.bak
set wildignore+=*/.git/**/*,*/.hg/**/*,*/.svn/**/*
set wildignore+=*/min/*,*/vendor/*,bundle.*
set wildignore+=*/coverage/*
set wildignore+=*/java/*,*/target/*,*/out/*
set wildignore+=tags,cscope.*
set wildignore+=*.tar.*
set wildignorecase

- and a generic &path that works for me and evolves all the time, as I work with new frameworks and such:

set path-=/usr/include
" covers nuxt, next, astro, and most JS frameworks
set path+=app/**,assets/**
set path+=components/**,composables/**,content/**
set path+=layouts/**,lib/**
set path+=middleware/**,modules/**
set path+=pages/**,plugins/**,public/**
set path+=server/**,src/**,ssl/**,static/**,store/**,styles/**,storyblok/**
set path+=test/**,types/**

set path+=utils/**

See this gist if you are interested by that &path business: https://gist.github.com/romainl/7e2b425a1706cd85f04a0bd8b3898805

So. I'm not here to tell you to stop using a fuzzy finder. You do what you want and… I don't really care, frankly. But it is always good to know the alternatives, even more so when they are built-in.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/0e8a0bf4-22b3-4e49-b836-31fb488dbe92n%40googlegroups.com.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAOmRJrdKGDp%2B7GBz3bVZ4ZXWN%2BuCoUMr5GgLNZZGxMLFhihxZw%40mail.gmail.com.

Re: What do you use for (fuzzy) file search?

In any case, I'm eager to know how do you manage (fuzzy) file search
and editing. I'm also open to completely new approaches.

I have used a number of fuzzy finders in the past but none of them really worked for me in the long run and I have settled with :help :find in conjunction with a finely tuned :help 'path' for over ten years, now.

I don't like existing fuzzy finders for the following reasons:

- "Fuzzy" is too unnatural for me and I find the effort required for picking letters in the middle of a word too expensive. My brain doesn't do "fuzzy" at all.

- The way most fuzzy finders are designed is very inefficient and leads to what I think are silly optimizations. They start by showing you "everything" and then let you filter down the list as-you-type, which is admittedly a pretty satisfying UX, but it has a few consequences. #1 is that, at any time, most of what you see is stuff you are not interested in, which is just plain noise. #2 is that, to be usable, the filtering must be insanely fast, hence the "course à l'échalotte" that gives us a new "faster grep" every then and now. #3 the as-you-type filtering mechanism forces the user to parse the whole screen and make decisions way too many times despite the initial decision having already been made. This is incredibly wasteful.

The "fuzzy" workflow is:

1. Decide that you want to edit the "Avatar" component.

2. Bring up the fuzzy interface.

3. Scan the top of the "everything" list in case the stuff you want is already there (costly).

4. Choose a single character of the target and type it (costly).

5. Scan the results in case the target is in the list (costly).

6. Type one more character, possibly one that is in middle of the word (costly).

7. Scan the results again (costly).

(…)

X. Press a key to do what you wanted to do with the target when it is found.

The number of discrete steps is not a problem per se, IMO, but the cost and the repetition of some of them is. In practice, most users actually skip the costly "scan" steps and just spell out the target name until there is only one hit, which is nothing but a wasteful workaround.

I mean, the UX of the list becoming shorter as you type is pretty fluid and "live" so it is nice and I can definitely understand why people like it… but I don't share that sentiment.

By contrast, here is the workflow with :find and a proper &path:

1. Decide that you want to edit the "Avatar" component.

2. Bring up the :find command, by typing it or via a mapping.

3. Think of a search string and type it (costly).

4. Execute the command.

5. Choose a candidate from the wildmenu with a few tabs.

The cost is minimal and the costly operations happens only once, upfront. In practice, the user may have to press <Tab> a few times to get to the right item, which may seem wasteful, but at least they don't have to rethink the whole thing each time. And it's all instant without requiring any brute force strategy or algorithmic sophistication.

My setup comprises…

- a bunch of intuitive mappings:

" global find

nnoremap ,f :find *
nnoremap ,s :sfind *
nnoremap ,v :vert sfind *
nnoremap ,t :tabfind *

" find in directory of current buffer
nnoremap ,F :find <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
nnoremap ,S :sfind <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
nnoremap ,V :vert sfind <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>
nnoremap ,T :tabfind <C-R>=fnameescape(expand('%:p:h')).'/*'<CR>

- the wildmenu set how I like it:

set wildmenu

set wildignore+=*.swp,*.bak
set wildignore+=*/.git/**/*,*/.hg/**/*,*/.svn/**/*
set wildignore+=*/min/*,*/vendor/*,bundle.*
set wildignore+=*/coverage/*
set wildignore+=*/java/*,*/target/*,*/out/*
set wildignore+=tags,cscope.*
set wildignore+=*.tar.*
set wildignorecase

- and a generic &path that works for me and evolves all the time, as I work with new frameworks and such:

set path-=/usr/include
" covers nuxt, next, astro, and most JS frameworks
set path+=app/**,assets/**
set path+=components/**,composables/**,content/**
set path+=layouts/**,lib/**
set path+=middleware/**,modules/**
set path+=pages/**,plugins/**,public/**
set path+=server/**,src/**,ssl/**,static/**,store/**,styles/**,storyblok/**
set path+=test/**,types/**

set path+=utils/**

See this gist if you are interested by that &path business: https://gist.github.com/romainl/7e2b425a1706cd85f04a0bd8b3898805

So. I'm not here to tell you to stop using a fuzzy finder. You do what you want and… I don't really care, frankly. But it is always good to know the alternatives, even more so when they are built-in.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/0e8a0bf4-22b3-4e49-b836-31fb488dbe92n%40googlegroups.com.

Re: What do you use for (fuzzy) file search?

> While fzf.vim is a classic, fuzzy finding has become built-in and
> there is also a more native implementation:
> https://github.com/Donaldttt/fuzzyy

Thank you, didn't know this! Looks promising.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250420144333.00001a32%40gmail.com.

Re: Can makeprg (or equivalent) be locally file-customised?

If these files reside in a (project) folder, one could define makeprg in a local vimrc https://github.com/MarcWeber/vim-addon-local-vimrc/

Le vendredi 18 avril 2025 à 10:44:43 UTC+2, dva...@internode.on.net a écrit :

Awkward apologies for the post without subject. This one is for the thread.

On 18.04.25 09:43, Marc Chantreux wrote:

> On Fri, Apr 18, 2025 at 12:08:56AM -0400, Eli the Bearded wrote:

> > :map * "yyy@y

> this is an old vi trick, vim can just source a range:

> :.so

> > That makes "*" run the line currently under the cursor. In my own files,

> > for my own use, I embed vi commands all the time.

>

> then you lose the awesome "next occurence of the current word" (see :h *, :h #

> and :h g*)

Marc, I took '*' for a placeholder, not a literal, and would likely

substitute ^M, as ":h ^M" shows it to be redundant, and it is mnemonic

for "make".

Erik

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/6993e4e9-203e-4010-9950-a3b124d468b6n%40googlegroups.com.

Re: What do you use for (fuzzy) file search?

While fzf.vim is a classic, fuzzy finding has become built-in and there is also a more native implementation: https://github.com/Donaldttt/fuzzyy

Le vendredi 18 avril 2025 à 21:26:30 UTC+2, Roberto Tonino a écrit :

Thank you Nicolas. I remember trying it in my early days, but switching
away for some reason. I also remember finding a nicely written article
that explains the two plugins well:
https://thevaluable.dev/fzf-vim-integration/

I will give it another try.

Best,

Roberto

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/e026b543-b931-4918-bacb-b96d7ed37092n%40googlegroups.com.

Re: What do you use for (fuzzy) file search?

Thank you Nicolas. I remember trying it in my early days, but switching
away for some reason. I also remember finding a nicely written article
that explains the two plugins well:
https://thevaluable.dev/fzf-vim-integration/

I will give it another try.

Best,

Roberto

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250418204952.00007ab5%40gmail.com.

Re: Mime-Version: 1.0

On Fri, 18 Apr 2025, dvalin via vim_use <vim_use@googlegroups.com> wrote:
> On 18.04.25 09:43, Marc Chantreux wrote:
>> On Fri, Apr 18, 2025 at 12:08:56AM -0400, Eli the Bearded wrote:
>>> :map * "yyy@y
>> this is an old vi trick, vim can just source a range:

I have been using it a long, long time. I should have included my once
standard explaination (used in many posts in comp.editors over the years
and now below).

>> then you lose the awesome "next occurence of the current word" (see :h *, :h #
>> and :h g*)
> Marc, I took '*' for a placeholder, not a literal, given Eli's evident Vim Fu,

Actually, I use it with * now. I have since before * did that search in
vim. To get back the next occurence of the current word, I have in my
vimrc:

:noremap _ *

Here's how I used to post it in comp.editors:

" yank current line into buffer y and execute;
" mnemonic * is executable in ls -F output
map * "yyy@y

I have two other "must have" macros that my fingers reach for and I will
find myself hand adding in enviroments[*] that lack them:

" split line on previous space character
" mnemonic "S" for split
map S F r<cr>
" double character under cursor
" mnemonic fix = in C: eg if(a=0) to if(a==0)
map = y p

The ironic thing about the = macro is I use it to fix unbalanced
parenthesis much more often than incorrect assignment versus
comparison.

[*] My work life involves opening things in vi/vim/nvi on plenty of
"machines" where I have never previously to that day logged in.
For example short lived virtual machines within network that
I need to write and run a script on to leverage ssh allowed to
that VM, but not others in the network, and firewalls blocking
access to APIs on other VMs in that network from outside the
network.

Elijah

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/4ZfNYv51DCzfYm%40panix5.panix.com.

Re: What do you use for (fuzzy) file search?

On Thu, Apr 17, 2025 at 7:28 PM Roberto Tonino
<roberto.tonino5@gmail.com> wrote:
>
> Hi everyone,
>
> I currently am in a kind of weird situation where I find myself using
> both vim and neovim, depending on the use case. While I'm fine with the
> idea, I find it cumbersome.
>
> Being a Typescript/React developer, at work I use neovim on codebases
> of such technologies because I find (i) LSP working faster and natively
> and (ii) the Telescope fuzzy finder being the customizable and
> performant type of software that I enjoy using. The same goes for my
> Python development.
>
> In editing dotfiles, text files, latex/optex, git messages,and probably
> more, I use vim.
>
> I would like to move to a setup where I use vim-lsp (even though it may
> lack some feature here and there) and vim $(fd myfile) to open files.
>
> While writing this email I remembered about vim $(fzf --multiple) which
> might be a first solution.
>
> In any case, I'm eager to know how do you manage (fuzzy) file search
> and editing. I'm also open to completely new approaches.

Hi Roberto,

I am not sure sharing this is going to be helpful, but here goes:

I usually open vim from my project directory, without giving it a filepath.
And then I use fzf via this plugin:
https://github.com/junegunn/fzf.vim to find the file I want to open.

I have it mapped this way:

nnoremap <leader>f :FZF<cr>

cheers,
nico



>
> Thank you!
>
> Roberto Tonino
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/20250417192449.00004cfd%40gmail.com.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAEUbJsTen-7D76tQceMMVki5LgLYLi%3DpeAxT%3DzpJxdf4VA_0Kw%40mail.gmail.com.

Re:

On Fri, Apr 18, 2025 at 08:41:38AM +0000, dvalin via vim_use wrote:
> Marc, I took '*' for a placeholder, not a literal

ohhh … right. I always try to think about what I would have used myself
for those kind of examples so I took it very litterally :)

> and would likely substitute ^M, as ":h ^M" shows it to be redundant, and it is
> mnemonic for "make".

I do use <c-s> to start build commands because <c-s> is often "save" in
many WIMP editors (including libreoffice).

Regards,
--
Marc Chantreux

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aAITAMHn8pw6uKBU%40prometheus.

Re: Can makeprg (or equivalent) be locally file-customised?

Awkward apologies for the post without subject. This one is for the thread.

On 18.04.25 09:43, Marc Chantreux wrote:

> On Fri, Apr 18, 2025 at 12:08:56AM -0400, Eli the Bearded wrote:

> > :map * "yyy@y

> this is an old vi trick, vim can just source a range:

> :.so

> > That makes "*" run the line currently under the cursor. In my own files,

> > for my own use, I embed vi commands all the time.

>

> then you lose the awesome "next occurence of the current word" (see :h *, :h #

> and :h g*)

Marc, I took '*' for a placeholder, not a literal, and would likely

substitute ^M, as ":h ^M" shows it to be redundant, and it is mnemonic

for "make".

Erik

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/1b78ab74-61be-4516-ad36-37472df0fb4e%40localhost.

On 18.04.25 09:43, Marc Chantreux wrote:

> On Fri, Apr 18, 2025 at 12:08:56AM -0400, Eli the Bearded wrote:

> > :map * "yyy@y

> this is an old vi trick, vim can just source a range:

> :.so

> > That makes "*" run the line currently under the cursor. In my own files,

> > for my own use, I embed vi commands all the time.

>

> then you lose the awesome "next occurence of the current word" (see :h *, :h #

> and :h g*)

Marc, I took '*' for a placeholder, not a literal, given Eli's evident Vim Fu,

and would likely substitute ^M, as ":h ^M" shows it to be redundant, and it is mnemonic for "make".

Erik

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/701fd5c8-c422-4045-8677-dc1e3dc4af03%40localhost.

Re: Can makeprg (or equivalent) be locally file-customised?

On Fri, 18 Apr 2025, dvalin via vim_use wrote:

> When Vimming a number of wildly disparate textfiles, each with a
> single custom processing requirement, it would be absolutely ideal to
> set makeprg (or equivalent) in a modeline. But for makeprg that is
> verboten: "This option cannot be set from a |modeline| or in the
> |sandbox|, for security reasons."

Yes that makes sense. You don't want to run arbitrary commands that you
are not aware of because those are set by the modeline.

> Mind you, here there is no such security concern - whether any command
> is run by ":!" or makeprg makes no real difference, so I'm not

Because this is not potentially run when reading the file. The user will
need to run this manually and hopefully he knows what he is doing.

> entirely sure why one would impose the clumsiness of having to insert
> ":!groff -k -Tpdf -ms -m hdtbl -dpaper=a4 -P-pa4 % > /tmp/vde.pdf" or
> whatever another file needs?

Define a custom command so you don't have to type it manually.

> So is there a file-local way to just alias e.g. ^m to a shell command,
> **in the modeline**? That would be much faster to invoke, and not muck
> with makeprg.

I hope this is not possibly and I won't support such a thing for
security reasons.

Thanks,
Christian
--
Better hope you get what you want before you stop wanting it.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aAIPoJuFVKoXZro/%40256bit.org.

Re: Can makeprg (or equivalent) be locally file-customised?

On 18.04.25 00:08, Eli the Bearded handed down much to be considered:

> I use autocommands like:

>

> " Set up macros for Rnmail

> autocmd BufRead .letter.* :so ~eli/.lettervimrc

That is not just a neat makefile target alternative for my simple case,

but can set up several key mappings ... and I will find patterns once

I've produced more than two sourcefiles.

...

> If you can identify which makeprg you want for a file based on

> a glob, then that's an easy fix.

That'll evolve, I'm sure. You've put me on a profitable path now, toward

a more consistent solution.

> > It's tedious that a modeline can't do an nmap either, as that would be

> > even more directly effective.

>

> I've done some research into modeline security holes in the past, and

> "drive a truck through" is a good description of how they used to be.

> If you can nmap on the sly, you can own the user. Consider editing

> any untrusted content, like a reply to a message on a mailing list.

> Is there some nasty modeline lurking in the .sig?

As I'm doing now. Your argument is succinctly powerful, not least as I

took the question for general conjecture until I got there.

> > It might be necessary to find a vimscript primer, as executing a :nmap

> > from a tagged line read from the file is beyond my current ken. My take

> > is that there would be no delay risk - the tag is found or not, the :nmap

> > is executed or not - instantly?

>

> Yes, nmap is instant. Let me suggest my simple but powerful solution, a

> mapping that can turn a line in a file into a command.

>

> :map * "yyy@y

>

> That makes "*" run the line currently under the cursor. In my own files,

> for my own use, I embed vi commands all the time.

I'm a bit slow - had to read the mapping twice to get it. It automates my

current practice of manually copying that line, at end of file, onto the

ex commandline once, then using a couple of up-arrows for repeats.

...

> > I'll look for processing commonality, as I extend the workflow. Then it may

> > well be OK to typify the source files by extension, and allow one common

> > cross-task makefile to differentiate processing. That is (for me) a high

> > level of organisation in an exploratory phase, where I'm still

> > assembling / building the toolset and forging the workflow. But using filename

> > extension might be best in the long run. Then we're back to make - nice and simple.

>

> You could create a script for makeprg that examines the file and then

> builds a command line for the makeprg you want.

Now that is tempting - hive off to awk, and avoid the vimscript learning

curve, which has scared me off for decades.

Many thanks, Elijah, for the lesson. It'll help me make order out of the

chaos of a new workflow.

Erik

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/834a4273-fc94-4e7f-83d3-1daf695374b1%40localhost.

Re: Can makeprg (or equivalent) be locally file-customised?

hi again,

On Fri, Apr 18, 2025 at 12:08:56AM -0400, Eli the Bearded wrote:
> :map * "yyy@y

this is an old vi trick, vim can just source a range:

:.so

> That makes "*" run the line currently under the cursor. In my own files,
> for my own use, I embed vi commands all the time.

then you lose the awesome "next occurence of the current word" (see :h *, :h #
and :h g*)

regards

--
Marc Chantreux

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aAICsnH_7s4AbWx0%40prometheus.

Re: Can makeprg (or equivalent) be locally file-customised?

hello Eli,

On Fri, Apr 18, 2025 at 12:08:56AM -0400, Eli the Bearded wrote:
> > autocommand suffices. It could even map more than one key, perhaps.
>
> I use autocommands like:
>
> " Set up macros for Rnmail
> autocmd BufRead .letter.* :so ~eli/.lettervimrc
> "
> " Set up macros for Pnews
> autocmd BufRead .article.* :so ~eli/.news_vimrc

you're so close to a package you can share with the community:

~/.vim/pack/start/Pnews/ftplugin/pnews.vim # your news_vimrc
~/.vim/pack/start/Pnews/ftdetect/pnews.vim #
autocmd BufRead .article.* setf pnews

regards

--
Marc Chantreux

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aAH_zLvkOpiTqqFN%40prometheus.

Re: Can makeprg (or equivalent) be locally file-customised?

Hi Dvalin,

this usecase illustrate what I said in misc@openbsd about the appliance
of vi to the vim culture because most of the solution is outside vim to
me.

A shell script will be much easier to maintain and extend as well as
resusable (from a makefile or a shell script).

wanabe is somewhere in $PATH and its content is

#!/bin/sh -eu
sed -E '/^W\($/,/^\)$/!d' "$1" |
sed '1d;$d' |
${SHELL:-} -s -- "$@"

so now I can write a roff file with

.ig

the W() script is hte way to get a document from the current file

W(
d="$1"; shift
dformat "$d" |
eqn |
pic |
soelim |
groff -Tpdf -Kutf-8 "$@"
)
..

and from vim

let &mp='wanabe % > /tmp/vbe.pdf'

regards

--
Marc Chantreux

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aAH-nsqowFzmpSUT%40prometheus.

Re: Can makeprg (or equivalent) be locally file-customised?

On Fri, 18 Apr 2025, dvalin via vim_use <vim_use@googlegroups.com> wrote:
> Ah, I'd dismissed autocommands, as a multitude of them would be a
> maintenance burden. But I get your point; I could try to synthesise a
> makeprg substitute which instead reads a custom othermodeline. Then one
> autocommand suffices. It could even map more than one key, perhaps.

I use autocommands like:

" Set up macros for Rnmail
autocmd BufRead .letter.* :so ~eli/.lettervimrc
"
" Set up macros for Pnews
autocmd BufRead .article.* :so ~eli/.news_vimrc

so that I get different specific macros for replying to Usenet
via mail or posts. I think that was the suggestion here. I
want slightly different versions of certain macros for each.

If you can identify which makeprg you want for a file based on
a glob, then that's an easy fix.

> It's tedious that a modeline can't do an nmap either, as that would be
> even more directly effective.

I've done some research into modeline security holes in the past, and
"drive a truck through" is a good description of how they used to be.
If you can nmap on the sly, you can own the user. Consider editing
any untrusted content, like a reply to a message on a mailing list.
Is there some nasty modeline lurking in the .sig?

> It might be necessary to find a vimscript primer, as executing a :nmap
> from a tagged line read from the file is beyond my current ken. My take
> is that there would be no delay risk - the tag is found or not, the :nmap
> is executed or not - instantly?

Yes, nmap is instant. Let me suggest my simple but powerful solution, a
mapping that can turn a line in a file into a command.

:map * "yyy@y

That makes "*" run the line currently under the cursor. In my own files,
for my own use, I embed vi commands all the time.

:r! head /tmp/update
# set a copied name
# :map ` k0f\|yt\|jp0s ==> <ESC>A<CR><ESC>
# set a flag
# :map \ 0i --> copied = 2<ESC>A<CR><ESC>
# :map z 0i --> ignore = 1<ESC>A<CR><ESC>
# delete an entry (note colon)
# !!! path : /path/to/bad/file


# to copy (17G)

Note that :r! is a line for the * macro. The above are commented out,
so I uncomment them when loading the file, * them, and then undo my
changes. (The /tmp/update file is | delimited text produced by one
program for another. 90% of the cases I have scripted to automatic,
but I still need some manual entries, and the maps help me.)

In sh scripts, I sometimes use an uncommented form:

: new $HOME/reference.file

This relies on ":" being a valid command in sh, but one that ignores
it's arguments.

In other contexts, I use multiline comments that don't need per line
annotation (think the C style /* ... */) or ignored multiline strings:

$_ = "
:! perldoc perlvar
";

> I'll look for processing commonality, as I extend the workflow. Then it may
> well be OK to typify the source files by extension, and allow one common
> cross-task makefile to differentiate processing. That is (for me) a high
> level of organisation in an exploratory phase, where I'm still
> assembling / building the toolset and forging the workflow. But using filename
> extension might be best in the long run. Then we're back to make - nice and simple.

You could create a script for makeprg that examines the file and then
builds a command line for the makeprg you want.

Elijah
------
ex: /sig virus!$/w!>>~/.signature : Eli's vi modeline sig virus!

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/4Zf1V03WGMzfYm%40panix5.panix.com.

Re: Can makeprg (or equivalent) be locally file-customised?

Many thanks, Salman, for your suggestions - they are thought provoking:

On 17.04.25 21:11, Salman Halim wrote:

> You could set up an autocommand that reads the first few lines of the file

> and sets any option you like from there. Maybe you'd need to put it on a

> one second timer or something.

Ah, I'd dismissed autocommands, as a multitude of them would be a

maintenance burden. But I get your point; I could try to synthesise a

makeprg substitute which instead reads a custom othermodeline. Then one

autocommand suffices. It could even map more than one key, perhaps.

It's tedious that a modeline can't do an nmap either, as that would be

even more directly effective.

It might be necessary to find a vimscript primer, as executing a :nmap

from a tagged line read from the file is beyond my current ken. My take

is that there would be no delay risk - the tag is found or not, the :nmap

is executed or not - instantly?

> The security problem comes because you might have makeprg set to something

> for your project and then you open a new file that sets it to, say, 'rm -rf

> /' or some such. You try to build your project innocently and end up

> deleting your system.

> Salman

Hmmm, that type of problem is created only if the program is *not* read

from the file, i.e. the file doesn't customise to suit. Thus it is more

the current modeline exclusion which could create that problem, I

figure.

I'll look for processing commonality, as I extend the workflow. Then it may

well be OK to typify the source files by extension, and allow one common

cross-task makefile to differentiate processing. That is (for me) a high

level of organisation in an exploratory phase, where I'm still

assembling / building the toolset and forging the workflow. But using filename

extension might be best in the long run. Then we're back to make - nice and simple.

Erik

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/c7c80fc3-b821-483f-9c72-76babe1617bb%40localhost.

Re: Can makeprg (or equivalent) be locally file-customised?

You could set up an autocommand that reads the first few lines of the file and sets any option you like from there. Maybe you'd need to put it on a one second timer or something.

The security problem comes because you might have makeprg set to something for your project and then you open a new file that sets it to, say, 'rm -rf /' or some such. You try to build your project innocently and end up deleting your system.

Salman

On Thu, Apr 17, 2025, 20:31 dvalin via vim_use <vim_use@googlegroups.com> wrote:

When Vimming a number of wildly disparate textfiles, each with a single custom processing requirement, it would be absolutely ideal to set makeprg (or equivalent) in a modeline. But for makeprg that is verboten: "This option cannot be set from a |modeline| or in the |sandbox|, for security reasons."

Mind you, here there is no such security concern - whether any command is run by ":!" or makeprg makes no real difference, so I'm not entirely sure why one would impose the clumsiness of having to insert ":!groff -k -Tpdf -ms -m hdtbl -dpaper=a4 -P-pa4 % > /tmp/vde.pdf" or whatever another file needs?

So is there a file-local way to just alias e.g. ^m to a shell command, **in the modeline**? That would be much faster to invoke, and not muck with makeprg.

Vim can do everything; it's finding the clue in the :help that is the challenge, even going in with a packed lunch.

Erik

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/d896d28d-744e-4f17-a397-6032c2e0db34%40localhost.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CANuxnEeJrrioUqmeMPPLhv%2Bhfb9me-kTapDwDj1QOrdnWuNCsw%40mail.gmail.com.

Can makeprg (or equivalent) be locally file-customised?

When Vimming a number of wildly disparate textfiles, each with a single custom processing requirement, it would be absolutely ideal to set makeprg (or equivalent) in a modeline. But for makeprg that is verboten: "This option cannot be set from a |modeline| or in the |sandbox|, for security reasons."

Mind you, here there is no such security concern - whether any command is run by ":!" or makeprg makes no real difference, so I'm not entirely sure why one would impose the clumsiness of having to insert ":!groff -k -Tpdf -ms -m hdtbl -dpaper=a4 -P-pa4 % > /tmp/vde.pdf" or whatever another file needs?

So is there a file-local way to just alias e.g. ^m to a shell command, **in the modeline**? That would be much faster to invoke, and not muck with makeprg.

Vim can do everything; it's finding the clue in the :help that is the challenge, even going in with a packed lunch.

Erik

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/d896d28d-744e-4f17-a397-6032c2e0db34%40localhost.