Re: Error make vim on termux terminal

[Eli the Bearded]

hence jack  wrote:
> According to the error message, I add the explicit declaration for "
> *setpwent"* and "*getpwent"* function at src/misc1.c, and it works,
...
> Has anyone had this problem?藍

Have you tried the build configuration in the Termux packages repo?

https://github.com/termux/termux-packages/tree/master/packages/vim

That may be better than setpwent/getpwent hacks.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4PsJxj2zLPzfYm%40panix5.panix.com.

Re: % and matchpairs

[Eli the Bearded]

On Mon, 6 Jun 2022, "'Grant Taylor' via vim_use"  
wrote:
> #TIL
>
> Thank you for sharing this Eli.  I'll be trying ~> using a subset of this.
>
> Aside:  How wrong is it that I'm thinking about adding m4's "`" and "'"
> based on file / buffer type?  a la. set matchpairs=`:'

Not wrong at all. That's a good idea.

Vaguely related: I wrote my own markup language for my blog posts. It's
a hydrid of Markdown style in-line formatting and *roff style block
formatting. _Italics_ like that, and ".p" / "./p" for open and close
paragraphs, or ".pp" to close a paragraph and start a new one. I use
"set paragraphs=ppp\ hrbri\ d\ /p" to make { and } motions work for that
filetype. "set paragraphs" is highly tuned to *roff style formatting
(namely implied initial period and max of two characters in a label)
which highly reduces the usefulness, but old Unix hands are more likely
to find/use such formatting. But I wrote the markup knowing how "set
paragraphs" works.

(The other entries in there are used for things like horizontal rules,
image tags, and image boxes.)

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4LJCsK3FsmzfYm%40panix5.panix.com.

% and matchpairs

[Eli the Bearded]

One neat thing about vim is configurability. I think it's widely known
(and done) to add < and > to matchpairs for %, but you can add Unicode
pairs in the list to, for smart quotes and quote styles not used in
English (at ast not often).

I decided to try the extreme and described my method here:

https://qaz.wtf/qz/blosxom/2022/06/02/matchpairs

But some of those, I'm never expecting to actually encounter (left and
right speech bubbles, as enclosing characters? not likely).

Here's what I've edited the list down to for my own use:

:set 
matchpairs=<:>,(:),[:],{:},«:»,턆:턇,:,:,:,:,:,:,:,卵:亂,‘:’,“:”,‹:›,⁅:⁆,⁌:⁍,⁽:⁾,₍:₎,⊣:⊢,⋉:⋊,⌈:⌉,⌊:⌋,〈:〉,⎛:⎞,⎜:⎟,⎝:⎠,⎡:⎤,⎢:⎥,⎣:⎦,⎧:⎫,⎨:⎬,⎩:⎭,⏪:⏩,⏮:⏭,⏴:⏵,◀:▶,◁:▷,◂:▸,◃:▹,◄:►,◅:▻,☛:☚,☞:☜,⚟:⚞,❨:❩,❪:❫,❬:❭,❮:❯,❰:❱,❲:❳,❴:❵,⟅:⟆,⟕:⟖,⟞:⟝,⟢:⟣,⟤:⟥,⟦:⟧,⟨:⟩,⟪:⟫,⟬:⟭,⟮:⟯,⥼:⥽,⦃:⦄,⦅:⦆,⦇:⦈,⦉:⦊,⦋:⦌,⦍:⦐,⦏:⦎,⦑:⦒,⦗:⦘,⧘:⧙,⧚:⧛,⧼:⧽,⫍:⫎,⯇:⯈,⸂:⸃,⸄:⸅,⸉:⸊,⸌:⸍,⸜:⸝,⸠:⸡,⸦:⸧,⸨:⸩,⸶:⸷,⹑:⹐,⹕:⹖,⹗:⹘,〈:〉,《:》,「:」,『:』,【:】,〔:〕,〖:〗,〘:〙,〚:〛,꧁:꧂,﴾:﴿,︵:︶,︷:︸,︹:︺,︻:︼,︽:︾,︿:﹀,﹁:﹂,﹃:﹄,﹇:﹈,﹙:﹚,﹛:﹜,﹝:﹞,（:）,［:］,｛:｝,｟:｠,｢:｣

This includes multiline bracket symbols; wide ("fullwidth") versions of
characters used in CJK contexts; vertical punctuation, also for CJK
compatibility; and some hands (for which I've switched left and right
versions).

It's also a line too long for unencoded use in SMTP or NNTP, so good
thing MIME exits.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4LGZZM17xkzfYm%40panix5.panix.com.

Re: '%' matches but it doesn't when executed

[Eli the Bearded]

Adri Verhoef  wrote:
> Hi, I've been using Vi and Vim since the eighties.  My current Vim
> version is 8.2.4579, provided by Fedora Linux.
>
> I have this line in a file:
> 
>
> When the cursor is on the first or second [, then the matching ] lights up.
> When the cursor is on the first [ and I type %, the cursor jumps to the
> second ].
> When the cursor is on the (, the ) lights up.
> When the cursor is on the ( and I type %, nothing happens.
> When the cursor is on the underscore _ and I type %, nothing happens.

I suppose you know about the M and % compatibility options?

:help cpo-M
:help cpo-%

It sounds like the matchparen plugin is showing you a "match" without
properly taking the cpoptions setting into account or is being confused
by the syntax highlighting guess of content type. Personally I find
matchparen and showmatch highly distracting and don't use them. Maybe
you'd enjoy that, too.

For the plugin:

:help pi_paren.txt

Elijah
--
will spare you the parse html-with-regexp comments

-- 
-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4KP5Ws60s1zfYm%40panix5.panix.com.

Re: Find unnamed swap file

[Eli the Bearded]

Julius Hamilton wrote:
> I am using Gvim on Andronix, Android Linux, and it suddenly goes down
> sometimes. I can recover any documents that were named with the .swp file
> recovery menu. Is there any way I can search for .swp files for files that
> hadn't been initially saved and named yet?

In the shell, I use this to find "all" swap files:

find $HOME -type f -name \*.sw\?

It's a bit loose in that it catches files that don't start with ".",
and I've been known to use those to hide stuff from git (via "*.swp"
in .gitignore). And it misses swap files outside $HOME which can be
a big issue if you've configured vim to store them somewhere else.

The \? is there for the multiple name case. I've certainly had up to
five happen for *unnamed* swap files: ~/.swp ~/.swo ~/.swn ~/.swm ~/.swl
but it could also catch random unrelated suffixes.

There's `vim -r` to list swap files which searches . and various temp
directories, and _I think_ will search the configured swap directory
(":set dir=...") but the starting.txt help is not specific on that
point. It, for me, has issues in that it doesn't seach $HOME if not
currently in $HOME for those unamed files list above. And it is a bit
dumb in listing swap files that belong to other users in /tmp and
/var/tmp (multi-user systems may be rarer, but do still exist).

$ cd ~/public_html
$ vim -r
Swap files found:
   In current directory:
  -- none --
   In directory ~/tmp:
  -- none --
   In directory /var/tmp:
1..mutt-panix5-151-23155-13042905455779035101.swp
  owned by: user-e   dated: Mon Jun 07 20:51:09 2021
 [cannot be opened]
2..mutt-panix5-905-14293-633769003522717526.swp
  owned by: user-d   dated: Tue Jul 06 14:32:05 2021
 [cannot be opened]
3..mutt-panix5-905-26039-8429083450887969313.swp
  owned by: user-d   dated: Tue Jun 08 15:40:28 2021
 [cannot be opened]
4..nn.EuY9xy.swp
  owned by: user-w   dated: Mon Jun 07 13:28:17 2021
 [cannot be opened]
   In directory /tmp:
  -- none --

$ 

Note total lack of the swap file for this reponse, which is in
$HOME/.letter.13891.swp

(I also see it misses an actual recovery file in ~ from an unexpected
reboot about a month ago.)

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4GKB942Z0GzfYm%40panix5.panix.com.

Re: Insert non-rectangular selection

[Eli the Bearded]

:r! reply-body --top '/tmp/Re1BDLjSqOg3'
On Tue, 25 May 2021, Andre Tann  wrote:
> I repeatedly have the following situation, and wonder how it can be
> handled better than I do it now. These lines must be merged
>
> /path;text
> /path;text
> /path;text
>
> with these:
>
> /subdir
> /longsubdir
> /longlongsubdir
>
> Result:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
>
> What I do now is to mark and yank the second block, go to the first
> semicolon, and press P. Result is:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
> But this is obviously not what I want. How can I avoid the extra blanks?

This is an interesting problem. I've personally found visual-block
yank / put most useful in ASCII art, where true rectangular blocks are a
feature. I see some tantalizing hints in the visual.txt help file about
padded with whitespace or not, but I can't get that to work for this
type of change.

Faced with a problem like this, I'd probably write a program to do the
change (possibly within the editor :'a,'e ! perl -wne '...' -- or
possibly as a separate true script), but I might also find a way to
do it with marks and macros. Maybe something like this tail-recursive
thing:

:map ## maf;'b"aDddmb`a"aPj0##

Set up mark b at the start of the /subdir area, move to the start of
the /path;text area and start

f;  find the ;, hopefully will error out at end
ma  set mark a
'b  jump to mark b (start of line)
"pD delete to end of line, stored in p
dd  delete now blank line
mb  set a new mark b
`a  return to mark a (mid line, on ; )
"pP put buffer p
j0  move to start of next line
##  recurse

(Untested.)

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4FqzFM5wzZzfYm%40panix5.panix.com.

Re: Some basic Vim commands

[Eli the Bearded]

Julius Hamilton  wrote:
> I can jump to the beginning of some text on a line that begins with
> whitespace with v, w, h, d. Is there a single command to delete all initial
> whitespace on a line?

I'd typically do that in either of two ways:

: {range} s/^[ TAB]*//

With a {range} like ".", ".+2", "1,.", ".,$" or "'a,'e" (my standard
begin and end range marks).

Or without using ex mode commands "^" to jumpt to first non-whitespace on
the line and then "d0" to delete to first column.

> I then wanted to jump over a few words to the next number (in brackets). Is
> there any command to the effect of "find the next number"?

Save search pattern then use next:

/[0-9]/
n

> Then I wanted to say: take this word and the next two words, and send them
> down 3 newlines. Would there be a way to do that?

I'm unclear in particular what this is asking for. Maybe "d3w3jp" ?

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4FN1Td0cb7zfYm%40panix5.panix.com.

Re: How to specific the line to go to from the command line?

[Eli the Bearded]

Tony Mechelynck  wrote:
> Yes, and as icing on the cake, a variation on this one: how to go to a
> specific line and column:
>
> " Go to line and column
> function GoTo(line, column)
>   exe min([line("$"), a:line]) "| normal" a:column . "|"
> endfunction

You don't need a vim function to do that. You can run normal from the
command line. Go to line 23 column 45:

vim -c ':normal 23G45|' filename

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4F5PrD4vNjzfYm%40panix5.panix.com.

Re: How to specific the line to go to from the command line?

[Eli the Bearded]

Sven Guckes  wrote:
> * Peng Yu  [2021-03-24 01:51]:
>> I want to specify the line number to go to at the command line.
>> Could anybody let me know how to do it with vim? Thanks.
>
> how to go to line #23:
>
> jump to line 23 on startup:
> vim +23 filename

That's a good answer. The more modern version is to use -c like this:

  vim -c :23 filename

Up to ten -c commands can be given, each with an ex mode command. Note
it may need quotes from the shell:

  vim -c ':normal 23G' filename

I have a script that I use where I consider the filename to be sensitive
and I don't want it to appear in `ps` output. To invoke vim to edit that
file from script I use a temporary tags file. One could (but probably
would find it too cumbersome) use a method like that to go to line 23.

Here's the bit of sh script I use:

case "$mode" in
# ...
edit) tmp=tags
  printf "main\t%s\t1\n" "$name" > $tmp
  vim -t main
  rc=$?
  rm $tmp
  exit $rc
  ;;
# ...
esac

In the 'tags' file I create, the three columns are tagname, filename,
and line number. (In typical 'tags' files the third column is a search
pattern, not a line number. Typically they also have multiple lines with
separate entries.) I then invoke vim with the tag name.

I bring it up in case this isn't going to be cumbersome and might be
something that helps your use case:

vim -c ':set tags=/some/shared/tags/file' -t tagname

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4F5Pkq3pj8zfYm%40panix5.panix.com.

Re: vim-mnemonics for hjkl.

[Eli the Bearded]

Csaba Hoch wrote:
> Some years ago I read a mnemonic from the perspective of Japan:
>
> Kamchatka
> ^
> |
> Hong Kong   Los Angeles
> |
> V
> Java/Jakarta

That is the funniest memory trick for that I've ever seen.

> Maybe not all four place names were exactly these.
>
> I thought I read it in the Vim documentation, but I cannot find it either
> there or on the web.

I have never seen any use-a-world-map mnemonic tricks for vi / vim
before. It really is very where-you-are centric. For me, Jakarta and
Hong Kong are roughly the same direction, and Los Angeles is south.
Kamchatka is very much north-west instead of north. I could substitute
Klondike, Alaska, and Jalisco, Mexico for north / south. Maybe Lithuania
for east. Hong Kong works fine for west, even though it is really
south-west.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4Drzhr6Z0czfYm%40panix5.panix.com.

Re: How to delete from the current cursor position to a particular character on the same line?

[Eli the Bearded]

On Fri, 26 Feb 2021, Joseph Wulf  wrote:
> I've a common problem that I've never been able to find a solution for.
...
> With my cursor at "B" how can I delete from the current cursor position
> (col 18) to the first double-quote mark (") efficiently?

Delete up to a quote mark later in the line:
dt"

Delete up to the third quote mark later in the line:
d3t"

Delete up to a quote mark earlier in the line:
dT"

Delete up to and including a quote mark:
df"

Delete up to and including a quote mark earlier in the line:
dF"

Delete up to and including the second quote mark earlier in the line:
d2F"

Delete forward using a repeat of last to or including search:
d,

Delete backward using a repeat of last to or including search:
d;

Delete to column 40 (either forward or backward):
d40|

I'm a frequent user of the f/F/t/T motions. Often one or the other is
the better choice to use due to frequency of characters used and
context.

In shell scripting, say, I may want to change {foo} to {bar} and
sometimes it will be in single quotes and sometimes double quotes, so
I'll use c2fo with the cursor on the {f} and then the . command works
properly.

Other times I'm changing a bunch of variable names all terminated at
the = to new different names, so I'll use ct= first and c; later.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4DnJwm6Pb7zfYm%40panix5.panix.com.

encoding local to part of a buffer?

[Eli the Bearded]

The "Changing encoding of an already loaded buffer" thread reminds me
that there are times I'd like to be able to look at a region of a file
in one encoding, and another region in a different encoding. Say, tell
vim everything between mark j and mark k is UTF-8 while everything
between mark u and mark i is ISO-8859-1?

My current method is to write the sections to temporary files, and
then open them as new buffers. Is there another, simpler way?

A typical use case for for me is an mbox file, where different messages
have arrived in (and are still stored in) different charsets. I can
imagine as another use case, data files with messages precomposed in
different encodings, something like a translations file for a program,
but I don't typically deal with such.

In general any sort of "multiple things presented in a single file"
might trigger this: editing ar files, tar archives, disk images,
etc.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4Cr8sq5DRzzfYm%40panix5.panix.com.

W16: Warning: Mode of file has changed

[Eli the Bearded]

Help has this to say:

 *W16*
   Warning: Mode of file "{filename}" has changed since editing started

 When the timestamp for a buffer was changed and the contents are still the
 same but the mode (permissions) have changed.  This usually occurs when
 checking out a file from a version control system, which causes the read-only
 bit to be reset.  It should be safe to reload the file.  Set 'autoread' to
 automatically reload the file.

Is there a fix besides set autoread? In my usage, 100% of the time I get
this warning when I run a command like

:! chmod 755 %

I get that it is helpful to detect for some usecases, but I'd like this
to just be silenced and ignored all of the time. I'm hoping there is
some vim setting I don't know about which will take a list of
warnings to not warn about.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4CVx165qlpzfYm%40panix5.panix.com.

Re: Matching « and »

[Eli the Bearded]

gevisz  wrote:
> What line(s) of code should I add to my vimrc so that ci« behave in
> the same way with respect to « and », as ci( behaves with respect to (
> and )?

Hmmm. "set matchpairs=(:),{:},[:],<:>,«:»" works fine for %, but it
appears that i(, i<, i{, a(, and the like are special movements, not
just keying off matchpairs. 

Would it be possible to make the iX and aX family of motions use that
setting too? That's probably the more general fix.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4BmzSq3KVLzfYm%40panix5.panix.com.

Re: Usage of | character in digraphs

[Eli the Bearded]

Manas  wrote:
> For example, I want to add ℕ (symbol for natural numbers set) as N| (N
> : digraphs N| 8469
> it is throwing E474.

The | character separates commands in ex-mode. You can use it in your
digraph, but you need to backslash escape it:

  : digraphs N\| 8469

The ex-mode | thing dates back to pre-vim days of real ex and vi. It's not
used often, and easy to overlook / forget.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/49XGgm6btVzfYm%40panix5.panix.com.

Re: issue subtituting new lines

[Eli the Bearded]

Christian Brabandt  wrote:
> On Di, 19 Mai 2020, Eli the Bearded wrote:
>> And that would look like this in vi, nvi, and vim up until recently:
>> :%s/%%/^M/g
>> On the versions that break that, it instead looks like this:
>> :%s/%%/^[[27;5;109~/g
> A feature or a bug i suppose. What you are seeing are the effects of the
> modifyOtherKeys feature of Vim and xterm (see :h modifyOtherKeys).
>
> I am not sure why it happens for you when pressing CTRL-V in command
> line mode, it does work for me as expected, unless you accidentally
> pressed Shift-Ctrl-V instead of Ctrl-V

No, I was quite careful in what I typed. But reading :h modifyOtherKeys
leads me to understand what is going on.

If, when modifyOtherKeys is enabled, instead of:

  colon percent s slash percent percent slash ctrl-v ctrl-m slash g enter

I type:

  colon percent s slash percent percent slash ctrl-v enter slash g enter

I get the:

  :%s/%%/^M/g

output I expect. xterm and vim are trying to represent a  as
different than  with that setting and I'm seeing the results. But
since  is what I really want, actually using  works.

I'll have to mull over if I consider this an improvement or not.

> To disable it, set the t_TI and t_TE terminal settings to the empty
> string:
>
> let _TI=""
> let _TE=""

Why that syntax instead of "set t_TI=|set t_TE="? I'm already using
"set t_Co=0" in ~/.vimrc to disable colors. (Specifically it sets
the number of colors available to zero.) In testing, both forms seem
to work in .vimrc, and neither seems to work from the ":" prompt --
even after I ":!ls" as suggested by the help page.

Thanks for finding that.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/49RVBx4fKWzfYt%40panix5.panix.com.

issue subtituting new lines

[Eli the Bearded]

I use several versions of vim throughout the day, all inside xterms, and
some inside tmux running in an xterm. Some versions of vim I have
noticed break my long standing way of adding newlines in a :s///
substitute command.

To make all %% sequences turn into a new line, what I'd type is:

  colon percent s slash percent percent slash ctrl-v ctrl-m slash g enter

And that would look like this in vi, nvi, and vim up until recently:

  :%s/%%/^M/g

On the versions that break that, it instead looks like this:

  :%s/%%/^[[27;5;109~/g

Which will not (does not) provide the subtitution I want.

I have found the vim I'm using on NetBSD inside xterms without tmux
do this, but that same vim on NetBSD inside xterms with tmux does not
do that.

:version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan  7 2020 09:55:54)
Included patches: 1-2200
[...]

:r! uname -sr
NetBSD 8.1

Inside tmux, $TERM is "screen", outside tmux $TERM is "xterm", 
$XTERM_VERSION is "XTerm(330)". Figuring out the exact differences
between the screen and xterm terminal definitions is not something I
want to dive into.

If I use vim.old on that same system, the substitute works inside and
outside of tmux. On vim.old:

:version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Jun 11 2019 15:16:00)
Included patches: 1-1517

Is this a known bug that has been fixed in a patch after 2200? If so,
I'll request the vim here be updated. If not, can this be fixed? (And
then I'll request the update.)

thanks,
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/49RNSv1Yp1zfYt%40panix5.panix.com.

Re: Runtime of record/play feature

[Eli the Bearded]

Manas  wrote:
> Hi, I was recently working on a large CSV file in Vim. I needed to do
> some changes in the file and I utilized the recording feature for it.
> Recording feature is really awesome and worked well for my use case.
>
> However working on a file whenever applied on multiple lines, it is slow
> till the point where we can actually see the edit being done on every line.
>
> I would like to know why is it so slow? Has it something to do with the
> design pattern?
>
> Also, is there any consideration of making it faster (if possible)?

It's not exactly clear what the problem is based on your limited
description, but my guess is that you are operating on a file that is
huge relative to available RAM and the system is starting to swap to
accommodate the state save for the undo command.

If that's it, disabling undo before you run it might be a good idea.
Usually when I hit that limit, I switch to editing via Perl filter.
The undo.txt help file has a section on "undo-remarks" that provides
guidance on disabling undo effectively to avoid the memory hit.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/49NJln4kGszfYt%40panix5.panix.com.

Re: Encryption is not considered a change by the :x command

[Eli the Bearded]

Tony Mechelynck  wrote:
> Ninu-Ciprian Marginean  wrote:
>> When we look at the quickref documentation we find:
>> If we open an existing file and we do not do any changes except for
>> changing the encryption key(with the ":X" command) and then use the ":x"
>> command to exit, the changes to the encryption key will not be applied.
...
>> Is this a bug? Is it intended? Anyways, I just wanted to leave this
>> here for people to know the workaround. If it's a bug, I'm willing to
>> report one on github.
> If it's a bug (I'm not sure) most developers read this mailing list too
> anyway.

I don't think it is a bug. I make use of encrypted files regularly. I
believe it is that way to prevent any accidental encryption of a
previously plaintext file. Because that is a real pain in the neck.[*]

There are many ways cryptmethod and key can be set: $HOME/.vimrc, "set
exrc" and ./.vimrc, "set modeline" and modelines, etc. Vim can try (and
may actually do so) to protect you against key being set
non-deliberately, but it can only go so far.

Additionally using :X to encrypt-save the file is the recommended way to
set the encryption key because it is the most robust against the key
being exposed.

[*] That one time in the early 1990s when I hit  with capslock
on and vi (or vim2 or vim3) accepted a password of a bunch of
control keys like backspace, , , etc, is seared into 
*my* memory. It really made me hate programming languages with
all caps keywords and case-sensitivity. 

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/49LSR547SmzfYt%40panix5.panix.com.

Re: Meta: reading file from stdin while still interacting with the terminal

[Eli the Bearded]

(Sent directly and to list; list moderator -- if any -- is welcome
to reject this.)

Tim Chase wrote:
> I'm playing around with a curses program and would like it to behave
> similarly to how vim lets me do
>
>$ echo hello | vim -
>
> where vim reads data from stdin but then interacts with the terminal
> directrly.  What magic is vim doing here?

I don't know what vim is doing, but I suspect it works like password
prompts in pipelines, eg:

$ someprogram | ssh user@site "sh someotherprogram -"
user@site password:
$

Those read from STDERR to get keyboard input in the face of STDIN being
NOTATTY.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/495ZTJ5qJSzfYt%40panix5.panix.com.

R.I.P. John Conway

[Eli the Bearded]

Many years ago I wrote Conway's Game of Life in vi macros. 
Not vimscript, macros. I posted them, uuencoded, to comp.editors
where you might still find them with Google Groups searches.

But Bram Moolenaar liked the effort, so you can still find those
macros easily. On my Ubuntu system, they are installed at:

$VIM/vim80/macros/life/life.vim

(Where $VIM is set by vim itself, so ":e $VIM/..." to edit and 
":so $VIM/..." to source, but don't use that on the command line.)

After sourcing it, you can hit "I" to initialize the board, edit
the text in the box that says "VIM LIVES":

top---
------
------
------
-VIM -----
------
------
-   LIVES-----
------
------
------
--

(which will probably be below your cursor point) then "R"un the game.
 to interrupt it.

The game plays only in that left hand box, everything else before
and after it is there to make the game run faster by storing state
and tables in the edit buffer. Bram tweaked the game somewhat, such
as have the letter of the alphabet indicate age, with old letters
just dying.

The macros are well documented, and were originally written for the vi
on my Solaris box at the time. That program was buggy and would forget
marks after a while, which would exit the game with an error. vim
never had that problem.

It's a rather CPU intensive way to play the Game of Life, whether
you use vi, vim, nvi, or elvis.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/4924VK1FyMzfYt%40panix5.panix.com.

Re: Unwanted underline

[Eli the Bearded]

JH wrote:
> Wow, that makes different, it displays color, no underline any more,
> how can I run the vim without --clean?
>
> Also, I use .vimrc configure, what the statement can I add to .vimrc
> to turn the color off?

You might like ":syntax off". I have that in my .vimrc.

But to outright disable colors, setting the terminal setting for number
of colors supported to zero is very effective:

:set t_Co=0

All of the t_* settings are termcap overrides, using the same names as
the traditional short termcap names. On my system "man terminfo" gives
the names.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/46PZY25THszfYQ%40panix5.panix.com.

Re: :new and :tag

[Eli the Bearded]

Yegappan Lakshmanan  wrote:
> Did you try using the ":stag" command? This command splits the window and
> then jumps to the specified tag.

No, I had not. And that looks to be the command I was overlooking.
Thanks.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/46HP4x4F1rzfYT%40panix5.panix.com.

:new and :tag

[Eli the Bearded]

I find myself often wanting to open a new buffer and then lookup a tag.
In visual mode, I can use  while on top of a tag word.
In ex (command line) I have been using:

   :cmap ,nt new\|tag

and then typing ":,nt" which expands before my eyes to ":new|tag". But I
keep feeling like that's a feature that would be there as some built-in
command I can't find. Is it?

Elijah
--
has been weighing merits of :cab versus :cmap 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/46HNZz4VLxzfYT%40panix5.panix.com.

Re: Persist Clipboard after Exiting Vim

[Eli the Bearded]

Tony Mechelynck  wrote:
> Michael Partridge  wrote:
>> Is there a way to prevent the clipboard buffer from being cleared upon
>> exit?

This shows a fundamental misunderstanding of the clipboard in X11. It is
not a place where stuff is stored, but a promise to supply content by a
running app. When the app has exited, it can no longer fullfil promises
and there is no clipboard to speak of.

The Apple Macintosh clipboard dates back to Macs being single process
systems and they worked around this problem by making the system itself
own the clipboard selection. It gave it persistence through application
launch and exits but also (particularly for large copies/cuts) imposed
a noticable resource drain on the system.

However that model of clipboard has become the one that most people use
when thinking about cut and paste, which makes the very different X11
one seem to behave weirdly.

>> The behavior I'm looking for is to use the system clipboard for yank,
>> etc. procedures. I have achieved this by putting 'set
>> clipboard=unnamedplus' in my config file. This puts yanked content into
>> my system clipboard where I can Ctrl (+ Shift) + V the content anywhere
>> else in my window-space, until I close Vim, at which point the buffer
>> gets cleared.

This is why there are tools like xclip that run background daemons to
hold on to a selection for fullfilling the content supply promise of
the clipboard.

>> I have noticed that paste 'p' still works between Vim files after
>> closing, which makes it seem like the content is still in the buffer,
>> but then why isn't it accessible via Ctrl (+ Shift) + V?

Vim, I expect, is storing it out of band, such as in ~/.viminfo .

> Using Ctrl+Shift+V in konsole uses konsole's pasting mechanism, a Vim
> running in konsole sees nothing; xterm is not even aware of the X11
> clipboard and uses only the  selection.

I don't know how st or konsole does it, but in xterm middle mouse and
shift-insert are fully configurable, as part of XTerm.vt100.translations.

Default translation for shift-insert:
Shift  Insert:insert-selection(SELECT, CUT_BUFFER0)

Deault translation for middle button paste:
~Ctrl ~Meta :insert-selection(SELECT, CUT_BUFFER0)

Where "~" means "without this modifier". In the xterm manpage, the
section on ACTIONS has documentation on the "functions" like
"insert-selection", but the documentation on the right hand side is
much harder to find. (And overall, XTerm.vt100.translations is a
cumbersome control method. It's a single unquoted string that needs
embeded newlines to be interpreted correctly, and can't support
inline comments.)

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/46349k0tgwzfYL%40panix5.panix.com.

Re: Evaluating the cost to type something in vim

[Eli the Bearded]

On Thu, 24 Jan 2019, Peng Yu  wrote:
>> finding the minimal user input that yields a buffer with the input
>> falls under https://en.wikipedia.org/wiki/Code_golf
> This kind of competition is not relevant to what I am not talking
> about. One has to spend extra effort to come up with the absolute
> shortest code. That effort must be considered into the cost as well.
> What I am talking about is "cost", which ultimately map to all
> programmer's time involved in typing and thinking about what to type.
> (But not include thinking about algorithm, data structure, etc.)

Speaking from my own experiences, I use vi and vim differently under
those (increasingly rare, but not never) circumstances where I have a
slow connection. When I can type, say, a half line ahead of where the
system has echoed back my keystrokes, I find myself looking for ways
to optimize the effectiveness of what I type. 

If I'm copying something from the line above on a fast connection, I'm
likely to just hit  in insert mode a lot. On a slower connection
I'll ky5f,jpa (as an example, to copy up to the fifth comma).

I'm well aware of the "cost" differences, as you put it. Keeping my
fingers in one location and repeating a single keystroke is very fast
mentally and fairly fast in action on a good system. Over a bad network
link, it's a lot slower because I can't get the immediate visual
feedback. But I have the time to reason out the exact sequence of
movements that will minimize my typing and that increases my effective
speed over the link in two ways: each packet of TCP connection can hold
more response from the server, and I rely on fewer packets sent to the
remote end.

Vi is highly adapted to needs of such slow connection thoughtful
editing. I find the same action optimization skills useful in
constructing macros, too. Explictly separation of searching for a string
anywhere or a character within a line means I can efficiently mix "n"
and ";" searches for finding a matching line and a matching position on
that line (which might not be the start of my match string). Then add in
a "@" action and I can make tail recursive macros easily.

Consider a CSS file with a bunch of inlined images, and other
stuff nearby:

.svg {
background-image:url(data:image/svg+xml;base64,PHN2Zy)
}
.png {
   background-image: url(data:image/png;base64,iVBORw)
}
.jpg {
background-image:url(data:image/jpeg;base64,/9j/45); color:#FFF
}
.gif {
border:0;background-image:url(data:image/gif;base64,R0lGOD)
}

Let's pretend there are zillions of them and we want to replace
all of those with regular https URLs.

First key up a search:
/background-image: *url *(data:
Then find the ( with "f("
Now create a temporary line in the file:
(https://static.example.com/image.png)
And then capture the contents to register c (sans newline):
0"cD
Now reuse that temporary line to write a macro:
n;d%"cp@q
And then capture the contents to register q (sans newline), then
delete the line:
0"qDdd
Finally run the macro with @q

Presto, all instances changed! (And a single 'u' will undo all of the
changes at once.) All because of the same optimizations that help me on
slow links. (And resorting to no vim-isms.)

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

vim --cmd ':set paste'

[Eli the Bearded]

If I use "vim --cmd ':set paste' filetoedit" when one of the
exrc files[*] will "set autoindent", then I find autoindent is
in effect when I start to edit.

Tested with:

VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Feb 17 2012 10:24:10)
Included patches: 1-411

VIM - Vi IMproved 8.1 (2018 May 18, compiled Sep 12 2018 12:55:00)
Included patches: 1-216

If I check ":set" then it shows paste is on, and with showmode I
see "-- INSERT (paste) --", but it's not working how I expect "paste"
to work.

This is a bug, right? Or an unexpected (to me) problem with enabling
autoindent after enabling paste?

[*] Or vimrc.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: using "gf" or "^Wf" with symlinked files?

[Eli the Bearded]

Tim Chase  wrote:
> (the actual context is a remind(1) reminder file where ~/.reminders
> is a link to ~/.config/remind/reminders.rem which includes each of my
> individual calendar files are in that ~/.config/remind/ directory, so
> editing ~/.reminders doesn't give me quick access to the per-calendar
> subfiles that get included if I use "gf" and friends)

Can you have all of these include a path?

   include ~/.config/remind/this
or
   include $HOME/.config/remind/that

Do you actually need ~/.reminders for something, or it that just
your editing short cut? Because I'd use an env variable instead of
a symlink myself. "export REMINDERS=$HOME/.config/remind/reminders.rem"
"vi $REMINDERS"

I ask because noticing a filename is a symlink and then doing things
differently based on that seems like it will have a lot of unexpected
effects for a lot of other people.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

from the old vi faq

[Eli the Bearded]

http://www.faqs.org/faqs/editor-faq/vi/part2/
-- start quote 8< --
6.1 - Silly vi tricks
  Note: Also check out the Silly macros down below. Many macros and
tricks are interchangeable.

  xp This will delete the character under the cursor, and put it
afterwards.  In other words, it swaps the location of two characters.
 
  ddpSimilar to xp, but swapping lines.
 
  yypduplicate a line

  uu Undo and redo last change.  (This will take you to the last
modification to the file without changing anything.)  You can also use
this to compare the changes to a line.  Make the changes to the line,
press U to undo the changes to the current line, and then press u to
toggle between the two versions.

  :g/.*/m0
 This will reverse the order of the lines in the current file.
m0 is the ex command to move the line to line 0.

  :v/./d or :g/^$/d 
 Removes all blank lines.

  :g/^[ ]*$/d
 Removes all lines that only have whitespace.

  :v/./$s/$/./|'';/./-1j|$d
 Replaces multiple blank lines with just one blank line.
-- >8 end quote  --

All of that works in vim (save "uu" with modern undo settings), except
for the last one. I happen to have true vi handy ("Version 4.0 (gritter)
3/25/05"), as well as nvi ("Version (1.81.6-2013-11-20nb3)"), elvis
("2.2.0"), vim 7.4, and vim 8.1.

The replace multiple blank lines works in true vi and nvi, but not in
elvis or either vim. The trick works by the :v/./ selecting a group of
lines, $s editing the last line in that group to be a blank line and a
line with a dot, then |'' returning to the first line in the group, /./-1j
joining all but the last line of the group (so as not to join the new
dot line), and finally |$d deleting that last dot line. It's a
seriously complicated "trick", with lots of subtle compatibility tests
built right in.

Is this a known incompatiblity in vim? I don't recall seeing it
documented. And I sought out that FAQ precisely for that trick since I
recalled it existed, but not what it was.

Elijah
--
tends to use :g/^/m0 for reversing lines (even works in ed)

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the quickes way to delete spaces in front of each line?

[Eli the Bearded]

Igor Forca wrote:
> Now reading Recardo's post (second post in thread) and playing around I have 
> found there is:
> diw
> j.
> j.
> j.
> j.
>
> Which is exactly what I was looking for. No need for count (ed command), or 
> no need for selecting for video.

"diw"? That's some vim-ism, isn't it? Replace "diw" with "d^" and it
works in any version of vi you can find. As a motion command, "^" goes
to the first non-whitespace character on the line (forward or backward,
natch so "0d^" may be a better starting command). Also "d^" is a no-op
when run at the beginning of the line with no leading whitespace, but
"diw" appears to delete the first word in that case.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: editing textareas in Firefox with vim

[Eli the Bearded]

Michael Henry wrote:
> Perhaps one last idea for debugging problems with textern; you
> might close Firefox, rename ``~/.mozilla`` out of the way, then
> restart Firefox to generate a new profile, then see if you can
> make textern work.  I recently had to do this myself to solve a
> weird Firefox problem I encountered.  I never knew what
> incorrect setting or corrupted file in my profile may have been
> responsible for the problem, but the new profile fixed it.

Thanks for your debugging ideas. I have a somewhat more advanced way to
do that:

alias newfirefox='firefox -ProfileManager -no-remote'

I create new browser profiles regularly for testing things / clearing
settings. I suspect the issue more likely lies in some other aspect of
my system, although I haven't pinpointed what. My personal loathing of
Python is my current stumbling block in trying to add more debugging
output to that script.

(How anyone who grew up using vi's % could like a language with no
matched pairs is beyond me.)

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: editing textareas in Firefox with vim

[Eli the Bearded]

Michael Henry wrote:
> I've been using "textern" for this, though I don't use it
> heavily.  It's working for me on Ubuntu 16.04 with Firefox
> 61.0.1 and GVim 8.1.290.  Here are the steps I followed to
> install:
>
> - Install URL:
>   https://addons.mozilla.org/en-US/firefox/addon/textern/

This sounds great. Clear instructions, simple install. Nothing happens.
I even watched stdout / stderr from Firefox, no warnings or errors or
anything at all.

Textern thinks something is happening, though. If I hit 
a second time, it tells me the textarea is already being edited. But ps
says otherwise. :-(

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

editing textareas in Firefox with vim

[Eli the Bearded]

This is really a Firefox issue, but I figure this list might have a
better set of people to tackle it than mozilla.support.firefox.

At one time, Firefox had a wide open (read: slow and security issue
prone) extensions API. At that time I could use an extension called
"It's All Text". With one very short shell script and one line of
config, I had Firefox configured to open an xterm running vim with the
contents connected to a textarea in the page just by pushing a button
in the webpage. The browser would update on every ":w". It worked
very well and reliably. Then the API was removed.

Now extensions do not have permissions to launch external programs. To
get this kind of functionality, websocket connections to a second
separately run program are used. I know of two implementations:

withExEditor / withExEditorHost
https://addons.mozilla.org/addon/withexeditor/
https://github.com/asamuzaK/withExEditorHost

I got this working shortly after the cutoff for the old API. It's
slightly different in that it also let you edit one line text inputs,
which seems a bit overkill, but okay. I have had a lot of trouble
keeping it working, however. At present withExEditor tells me it is
"connected" to the host, but the host version is incompatible. I'm
pretty sure I have both up to date, though.

GhostText / Ghost Text Vim
https://addons.mozilla.org/en-US/firefox/addon/ghosttext/
https://github.com/falstro/ghost-text-vim

I just learned of this one this week. The vim component is using gvim,
I'm not sure if that's important or just the preference of the author.
Anyway, I installed gvim for the test rather than my preferred
vim-in-xterm setup.  It is apparently using some sort of client / server
interface with vim that aims for two way communication between the
textarea in the browser and the editor; updated when not in "insert
mode". As proof of concept, I did get it to work, but not well. On my
test page[*], it opened about twenty gvim windows, only one of which was
connected to the browser.

[*] https://qaz.wtf/ta/
It's about as simple HTML as the URL is short.

Have people here on vim-users found another method? Or have tips for
getting one of these two to work?

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim Display Corruption

[Eli the Bearded]

Richard Riegner  wrote:

> I run an xterm window on macOS and ssh into a
> remote Linux machine.  The edit session is
> displayed back to an XQuartz server running on
> the same macOS.

I have seen lots of problems with that sort of setup:

  local Mac with XQuartz and xterm used to 
  remote ssh to Linux or NetBSD and
  running vim on the remote end
 
My personal guess is that there's an issue with the xterms that come
with XQuartz, but I am not certain. And I no longer have a mac to test
with. As I recall, the workaround I found was to run screen or tmux
to provide an intermediary terminal interpreter. I don't think it is a
vim bug (but maybe vim needs to work around this bug).

> I have only seen this problem when displaying
> back to an XQuartz server running on macOS.

I've seen other people complain about this, too.

> This problem occurs with newer versions of vim,
> but not older versions.
...
> Inserting text also causes extraneous lines of
> text to be added to the body of the original
> text, corrupting the edit display.

This is the exact behavior I found most annoying.

> I suspect that I am seeing the same vim behavior
> as was reported in this incident:
>
> https://groups.google.com/forum/#!topic/vim_dev/GR9YG8TZy6o

That's a 7.3 change which would explain why your 7.2 is fine and 7.4
needs help.

> A work-around is to add this statement to the
> .vimrc file:
>
> set ambiwidth=single

Would I have known that when I had the issue.

> I do not know if this is a bug in vim, XQuartz,
> or both.  So I am asking for vim help here and
> XQuartz help in another forum.

The other fix I found was to ditch the XQuartz xterms and use iterm2.
Just as another option.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: "best" terminal library for vim

[Eli the Bearded]

On Sat, 23 Jun 2018, tu...@posteo.de wrote:
> currently I am setting up a Raspberry Pi Zero W for being used
> as "commandline server" ;)
...
> The configure stage did not find a terminal library on the system
> (which is kinda weird, since Midnight commander is installed ...
> and it looks like it would also need such a lib...)
...
> The Raspberry Pi Zero W has 512Mbyte of RAM. I am connected
> via ssh mt terminal is able to display colors.

It sounds like you don't want a library, but an interface to use
vim in a way that allows access to the colors. 

Because if you can run vim and see the output, then you already have
all the libraries you need. Display of colors in vim will be gated
(at least for standard compiles) not by terminal libraries installed,
but by terminal definition.

What does $TERM contain on the local side of your ssh connnection?
What does $TERM contain on the Pi side of your ssh connection?
That's probably where you should look first. Second is seeing if
you have compatible terminal definitions on either side. 

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

100000ii

[Eli the Bearded]

Prompted by a challenge here:

https://fivethirtyeight.com/features/pirates-monkeys-and-coconuts-oh-my/

(Near the bottom of the page, in the answers to the previous challenge
dealing with editors.)

I tried inserting a million letter "i"s into a new buffer with vim. Oh,
how insanely slow it was. I hit control-C after 20ish seconds and it was
up to about 30,000 letters inserted. I tried two different builds of vim.

Then, for comparison, I used nvi and elvis. Nvi does it too fast to measure by
wall clock. Elvis was under 5 seconds.

vim: VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 24 2016 16:44:48)
(This version is the package one for my Ubuntu release.)


vim: VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 13 2018 17:19:45)
nvi: Version (1.81.6-2013-11-20nb3) The CSRG, University of California, 
Berkeley.
elvis: elvis 2.2.0
(These three were all tried on NetBSD, the Vim and Elvis compiled from source,
the Nvi the system /usr/bin/vi.)

I don't think blinding fast is entirely necessary, but not even half-way
there in 20 seconds is Not Good.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim Android App with encrptioin support

[Eli the Bearded]

Jeffery Small wrote:
> I have an android phone.  I want to be able to view some
> blowfish2-encrypted files that I have placed on the phone.  Does anyone
> know of a vim app that supports decryption?  I have the "Vim Touch" app
> installed, but it complains that the content is "too big" when trying to
> access the encrypted file.  Any other options?

I use the vim compiled for Termux, and it supports blowfish[*]. I can't say
if it will open your file, since "too big" doesn't sound like a blowfish
encryption error. 

[*] cm=blowfish2

Anyway, Termux gives you a Linux shell, and then you can just "apt-get
vim". (You could probably even build vim on your device with Termux; I
have built trn on my phone.)

8.0.1350, ":version" says "Huge version without GUI." I use "Hacker's
Keyboard" in order to have a better typing experience.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim surprisingly slow?

[Eli the Bearded]

Tim Chase wrote:
> :g/.*name":"\([^"]*\)".*card":"\([^"]*\)".*/let
> s=substitute(getline('.'), '.*stamp":"\(\d\+\)-\(\d\+\)-\(\d\+\).*',
> '\1\2\3','').'.txt'|s//\1,\2/|exec ".w!>>".s
> which works.  But for some reason, it is *painfully* slow on my
> machine.

Just do one write.

:v/"creditcard":"[0-9][0-9-]*"/d|%s!,*"\([a-z][a-z]*\)":!;\1=!g|%s,^{;,,|%s/},*$//|%s,\(timestamp="\)-\(..\)-\(..\)[^"]*,\1\2\3,|%s!$!;echo
 '"'"$name"'"'",$creditcard" >> $timestamp.csv!|w ! /bin/sh -

That will probably work in ordinary vi, but my copy of nvi was unhappy.
I didn't try to figure out why. But I did prove to myself it works with
slight editing in ed. ("ed is the standard editor.")

v/"creditcard":"[0-9][0-9-]*"/d
1,$s!,*"\([a-z][a-z]*\)":!;\1=!g
1,$s,^{;,,
1,$s/},*$//
1,$s,\(timestamp="\)-\(..\)-\(..\)[^"]*,\1\2\3,
1,$s!$!;echo '"'"$name"'"'",$creditcard" >> $timestamp.csv!
w data.json.sh
! /bin/sh data.json.sh

The fix for taking hyphens out of the credit card number should be
obvious, I didn't see any requirement to do that there, so I didn't.

I tried to post my solution to the dev.to site, but it wouldn't let me
log in.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim surprisingly slow?

[Eli the Bearded]

Tim Chase wrote:
> :g/.*name":"\([^"]*\)".*card":"\([^"]*\)".*/let
> s=substitute(getline('.'), '.*stamp":"\(\d\+\)-\(\d\+\)-\(\d\+\).*',
> '\1\2\3','').'.txt'|s//\1,\2/|exec ".w!>>".s
> which works.  But for some reason, it is *painfully* slow on my
> machine.

Just do one write.

:v/"creditcard":"[0-9][0-9-]*"/d|%s!,*"\([a-z][a-z]*\)":!;\1=!g|%s,^{;,,|%s/},*$//|%s,\(timestamp="\)-\(..\)-\(..\)[^"]*,\1\2\3,|%s!$!;echo
 '"'"$name"'"'",$creditcard" >> $timestamp.csv!|w ! /bin/sh -

That will probably work in ordinary vi, but my copy of nvi was unhappy.
I didn't try to figure out why. But I did prove to myself it works with
slight editing in ed. ("ed is the standard editor.")

v/"creditcard":"[0-9][0-9-]*"/d
1,$s!,*"\([a-z][a-z]*\)":!;\1=!g
1,$s,^{;,,
1,$s/},*$//
1,$s,\(timestamp="\)-\(..\)-\(..\)[^"]*,\1\2\3,
1,$s!$!;echo '"'"$name"'"'",$creditcard" >> $timestamp.csv!
w data.json.sh
! /bin/sh data.json.sh

The fix for taking hyphens out of the credit card number should be
obvious, I didn't see any requirement to do that there, so I didn't.

I tried to post my solution to the dev.to site, but it wouldn't let me
log in with Firefox (nothing happened when pushing the github button).
I did not even try to login with lynx.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to handle non-ascii characters?

[Eli the Bearded]

Barry Gold wrote:

You wrote:
> I'm impressed that you can type your entire vimrc from memory. I'm
> tempted to use some of that. If only I _understood_ it.

Well the normal stuff that applies globablly. Stuff for specific classes
of files is a bit more difficult. :^) It's basically these three maps
and some :set options.


>>  " Use * to "run" a line from the edit buffer
>>  " Mnemonic: * is executible in "ls -F"
>>  " Uses register y
>>  :map * "yyy@y

:mapbegin a key remap
 *  remap key "*"
   "y   into register y
 yy yank the current line
   @y   execute the commands in register y

The beauty of this one is the ability to compose complex commands
(typically ":g/select/ s/this/that/" type stuff for me) and then
being able to 'u'ndo and fix the command if I don't get it right
the first time. It also is useful to keep commands in comments of
code.

>>  " Find previous space and split line on it
>>  " Mnemonic: 'S'pace
>>  :map S F r

:mapbegin a key remap
 S  remap key "S"
   F("F ") find previous " " on  current line
r   replace that space with carriage return

>>  " Double the character under the cursor
>>  " Mnemonic: fix C code like "if (0 = i) ..."
>>  :map = y p

:mapbegin a key remap
 =  remap key "="
   y("y ") yank character under cursor
 o  put last yank

I remember learning a lot of vi tricks from comp.editors from people
doing things like the above breakdown. Approximately no one reads or
posts there any more.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to handle non-ascii characters?

[Eli the Bearded]

Barry Gold wrote:
> None of these looks like themselves when I edit the file with vim in a
> cygwin Terminal window. I can search for [^ -~^t] to find the non-ASCII
> characters, then go to the original word document to find out what the
> correct character is. If I had only a few of these, that would be
> enough. But in a longer document, a given non-ASCII can occur hundreds
> of times. So once I've found (e.g.) an emdash, I want to replace _all_
> occurrences with  "". But I have no way of representing the
> character I want to replace on the command line.

I have a very similar problem to yours and have evolved some fixes that
I use. You've already gotten some replies, but maybe my methods would
help, too.

In my case, I paste content from web pages into Usenet posts and want to
have as much US-ASCII as possible for best readibility. To that end I
have a specific vimrc for news that fixes things with map!s. It could
easily be modified to a ':so script' usage, to fix things on command
or a 'autocmd BufRead *.html' script to fix thins on load.

In my vimrc:

   autocmd BufRead .article.* :so ~eli/.news_vimrc

And my news_vimrc looks like this: 

:r! cat ~/.news_vimrc | mmencode -q
" smart quotes
map! =E2=80=99 '
map! =E2=80=98 '
map! =E2=80=9C "
map! =E2=80=9D "
map! =E2=80=B3 "
" ellipsis
map! =E2=80=A6 ...
" n-dash
map! =E2=80=93 --
" m-dash
map! =E2=80=94 --
" U+2212 minus
map! =E2=88=92 -
" U+2010 hyphen
map! =E2=80=90 -
"
" find non-ascii
map  /[^ -~]
" add mime headers if leaving in non-ascii
map  iContent-Type: text/plain; charset=3D"UTF-8"MIME-Version: 1.=
0
map!  Content-Type: text/plain; charset=3D"UTF-8"MIME-Version: 1.=
0
" general news settings
set ai sw=3D4 tw=3D72

Basically, I'm suggesting that you take all the charcters you find and
want to replace, and save the replacements in a script you can run
easily before looking for new characters that you want to fix.

I use http://qaz.wtf/u/ "Show unicode character" if needed to identify
characters, the plugin might suit you better.

And I have a long-standing macro:

" Use * to "run" a line from the edit buffer
" Mnemonic: * is executible in "ls -F"
" Uses register y
:map * "yyy@y

If I were you, I would make the commands, test them with *, then 'p'ut
them in the fix script.

That * command is one of three macros I consider essential. The other
two I think are less likely to be universally useful, but anyway:

" Find previous space and split line on it
" Mnemonic: 'S'pace 
:map S F r
"
" Double the character under the cursor
" Mnemonic: fix C code like "if (0 = i) ..."
:map = y p

Elijah
--
can type his entire vimrc from memory, and often does

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: scrolloff side effects are bothersome

[Eli the Bearded]

Bram wrote:
> Hmm, it's possible to make these commands not use 'scrolloff' when an
> operator is pending.  It won't be consistent with other operations
> though.  But it does make sense when 'scrolloff' is a large number,
> since it's then hard to estimate what text will be covered.  While the
> first visible line or last visible line are easy to spot.
>
> With this change no tests fails, so perhaps no user will have a problem
> with it?  Still I worry about the inconsistency.  Als, "yH" will scroll
> the text.

I wonder, seriously, how many (if any) users of H and L had previously
run into this problem to be aware of what you consider "inconsistency".

Because as I noted yesterday, H and L are, I think, the ONLY vi
movements that are about what-is-currently-displayed. Everything else
is about searches, straight out character or line counts, marked
positions, and explicit positions.

I include find-match "%", end-of-paragraph "}", find-character "f"/"t",
etc, in "searches"; start-of-line-test "^" possibly that or else
"explicit positions" like character "|", end-of-line "$", start-of-line
"0", and end-of-file "G". And marked positions either named (eg "`a") or
implicit (eg "''") don't change depending on view or cursor position.

And I don't include any movements that are in vim, but not vi. (Not that
I can think of any relevant for this point, but I know there's a lot in
vim I don't use.)

H and L are always the top of the view and the bottom of the view. And
they change when the *window changes size*. They are nothing like the
other vi (real vi) movements. (M, too, changes with window size, but M is
not really affected by scrolloff.)

I've been using vim since just about forever, I know have vim 2.x around
in my archives, and still sometimes think about changes like "Q" becoming
"gq". But I use vim in a very vi-like way, not in a very vim-ish way. So
how vim features interact with vi features might be more concerning to me.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: scrolloff side effects are bothersome

[Eli the Bearded]

Tony Mechelynck wrote:
> I don't use H/M/L but I do use PgUP/PgDn (whose effects are different)
> though never with an operator. My usual 'scrolloff' setting is 6.

I've been using H/M/L since before Vim existed. Frequently PgUp/PgDn did
not work without a manual :map in those days, and many keyboards I use
even today lack those keys. I am the sort of person who uses ssh from
a phone with an on-screen "soft" keyboard. Every motion that doesn't
require switching keyboard panes is my friend.

> Experiment shows that the displayed lines don't scroll for H/M/L,
> regardless of the 'scrolloff' setting, so the somewhat cryptic
> sentence «Cursor is adjusted for 'scrolloff' option.» under both
> ":help H" and ":help L" means (IIUC) that the top and bottom are to be
> understood exclusive of the 'scrolloff' lines, though there are no top

And as someone who has used H/M/L since before Vim existed, consulting
the H/M/L documentation for how those would behave with a "{not in Vi}" 
setting didn't occur to me. {not in Vi} settings SHOULD document their
not in Vi behaviors at the setting level.

> IMHO the present behaviour is consistent but the help could be made
> clearer.

The motions H/M/L are the only ones that operate based on what is
*visible* on the screen. It is my firm belief that changing those motions
to ignore parts of the *visible* screen is seriously against the spirit
of the motions.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

scrolloff side effects are bothersome

[Eli the Bearded]

I've long used scrolloff intermittantly, but recently I tried adding it
to my vimrc. I'm finding myself unhappy now.

Straight from the scrolloff docs:

*'scrolloff'* *'so'*
'scrolloff' 'so'number  (default 0, set to 5 in |defaults.vim|)
global
{not in Vi}
Minimal number of screen lines to keep above and below the cursor.
This will make some context visible around where you are working.  If
you set it to a very large value (999) the cursor line will always be
in the middle of the window (except at the start or end of the file or
when long lines wrap).
For scrolling horizontally see 'sidescrolloff'.
NOTE: This option is set to 0 when 'compatible' is set.

Not at all mentioned there is that the H and L movements are changed. As
someone with a long habit of using yH and yL (or >>L, or dH, etc),
trying to use scrolloff is annoying.

Consider a large file, like .../libdata/vim/vim80/doc/options.txt
You can open that file with ":help scrolloff" right now. Then try
":set scrolloff=0"  and "MyH", depending on screensize you get
something like "12 lines yanked". Now try ":set scrolloff=999" and then
"MyH" again. Now only the current line is yanked.

What I would *expect* and what I would like is if H and L movements were
not affected by scrolloff, and yanks, deletes, etc worked again to top
and bottom of the screen. And if actually moving to top or bottom with a
bare H or L, I'd expect the cursor to move, *and* the screen to scroll
according to scrolloff.

Doesn't this bother other people? Or does no one use scrolloff?

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: an old "hack" of mine, shared for amusement

[Eli the Bearded]

Christian Brabandt wrote:
> Are you saying, original Vi could be tricked to execute various commands
> via modelines? That sounds pretty scary actually.

Still can, if you have real vi somewhere. (You can also embed arbitrary
ex commands in tag files for real vi.)

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: an old "hack" of mine, shared for amusement

[Eli the Bearded]

Erik Falor wrote:
> I can report that this "hack" doesn't do anything interesting as of Vim 5.5.
> It doesn't complain about the pipe characters in the modelines, though.

Everyone seems to be missing it. rot13 solution for those interested.

Guvf *unpx* jnf qrfvtarq gb *abg* jbex va ivz.

Vg jbexf va iv. Vg znxrf iv erbcra gur svyr jvgu ivz.

(And by-the-by, I have Vim 3.0 for Mac System 7. I found it for download
last year when I was playing with the Basilisk II emulator. Vim 3: back
when 'q' did the thing 'gq' does now. And 'Q' was unimplemented.) 

Elijah
--
http://wayback.archive.org/web/19990422231919/http://www.qz.to/~eli/src/modeline.html

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

an old "hack" of mine, shared for amusement

[Eli the Bearded]

I found this today, while looking for abandoned swap files on my
computer. The file was dated 2006, but the swap file is for vim 4.2,
and the hostname is one I last used ~ 1998. I guess I copied the
file, and the swap file, from a backup or something in 2006.

  $ ls -l my-src/hacks/vi/fork my-src/hacks/vi/fork.swp
  -rw-r--r-- 1 elijah users58 Jun  6  2006 my-src/hacks/vi/fork
  -rw-r--r-- 1 elijah users 24576 Jun  6  2006 my-src/hacks/vi/fork.swp
  $ cat my-src/hacks/vi/fork
  vi: set noml | w! | ! vim % :
  vi: e! % | w! | q :

  foobar
  $ 

I don't remember writing that, but I can fully believe I did. (There's
other stuff there, I'm sure I have written.

What this does is left as an exercise for the reader.

I suspect I tested it on Solaris vi of that era. Testing in Solaris vi
(Version SVR4.0, Solaris 2.5.0) today[*], I need to hit  to
unstick-it at a certain point, and I think the second line would be
better as just:

  vi: q :

Elijah
--
[*] only has one, rather old, Solaris system left to test with

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 'set paste' toggles 'set ruler': why?

[Eli the Bearded]

h_east  wrote:
} This behavior is documented.

I am 100% aware that it is documented. What is **not** documented is
why.

Christian Brabandt  wrote:

> https://github.com/vim/vim/issues/184

  | Pasting can involve a large amount of text (someone just complained
  | about pasting more than 1500 lines not working).  Keeping the ruler
  | updated adds overhead and makes pasting a bit slower.  'showmatch'
  | is even more expensive. Setting the 'paste' option is a quick way 
  | to make pasting efficient.
  | Original comment by brammool...@gmail.com on 14 Jan 2015 at 10:42

Which explains the rational, which is some small consolation.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

'set paste' toggles 'set ruler': why?

[Eli the Bearded]

Of all the things the ':set paste' setting does, only ':set noruler'
puzzles me.[*] Why should informational settings be surpressed with a
setting for input?

Can this please, please, be changed?

[*] Alright. The ':set noshowmatch' is also puzzling, but I rarely
have showmatch enabled.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.