nvimpager icon indicating copy to clipboard operation
nvimpager copied to clipboard

bad ansi escape sequences parsing?

Open name-snrl opened this issue 3 years ago • 15 comments

In some cases escape sequences are not converted to colors.


to reproduce:

nvimpager -p part.log

part.log

nvimpager full.log

full.log

I use fish, many of its man pages have the same problem, e.g. man fish-doc


I have tried several setups (with alacritty 0.11.0):

  • NVIM v0.5.1 +nvimpager-0.10.4 (nixpkgs 21.11)
  • NVIM v0.7.0 +nvimpager-0.10.4 (nixpkgs 22.05)
  • VIM 8.2 (2019 Dec 12, compiled Jan 01 1980 00:00:00) +vimpager 2.06 (nixpkgs 22.11 nix shell nixos/nixpkgs/nixos-21.11#vim nixpkgs/nixos-21.11#vimpager-latest)

Also, I tried changing TERM to xterm-256color. Everywhere the same result.

name-snrl avatar Dec 07 '22 22:12 name-snrl

What is the \e[K sequence supposed to do? If I cat part.log they don't seem to do anything.

PS: vimpager is unrelated.

lucc avatar Dec 08 '22 13:12 lucc

The full log is not highlighted because nvimpager just checks the first 100 lines to decide if we should highlight terminal escape codes (function check_escape_sequences() in pager_mode())

lucc avatar Dec 08 '22 13:12 lucc

What is the \e[K sequence supposed to do?

I don't really understand what it does. But often "less" is used with -R, this option ignores all sequences except color. I think we need implement this option.

name-snrl avatar Dec 08 '22 19:12 name-snrl

The full log is not highlighted because nvimpager just checks the first 100 lines to decide if we should highlight terminal escape codes (function check_escape_sequences() in pager_mode())

Can we use io.read() instead of vim.api.nvim_buf_get_lines()?

name-snrl avatar Dec 08 '22 19:12 name-snrl

about: io.read: why? I think it reads stdin or we need to open the file again with io.open. But nvim has opened it already so why not use nvim_buf_get_lines?

about ignoring unknown sequences: there are quite some of them: https://en.wikipedia.org/wiki/ANSI_escape_code

When stripping them from the buffer we match much more than when concealing them:

https://github.com/lucc/nvimpager/blob/2251f29e0d4a243cd83ca50bd4edcce06ea43ae9/lua/nvimpager.lua#L372-L379

https://github.com/lucc/nvimpager/blob/2251f29e0d4a243cd83ca50bd4edcce06ea43ae9/lua/nvimpager.lua#L635-L637

I have to read through the wiki article a bit and improve these regexes I think (help obviously apreciated :)

lucc avatar Dec 10 '22 14:12 lucc

io.read: why? I think it reads stdin or we need to open the file again with io.open. But nvim has opened it already so why not use nvim_buf_get_lines?

I don't like this limitation of a hundred lines. If we check the whole file, io.read will be faster.

simple test:

local function with_io_read()
  local start = os.clock()
  local file = io.open(vim.fn.expand('%'), "r"):read("*all")

  file:find('\27%[[;?]*[0-9.;]*[A-Za-z]')
  return os.clock() - start
end

local function with_for_loop()
  local start = os.clock()

  for _, line in ipairs(vim.api.nvim_buf_get_lines(0, 0, -1, false)) do
    if line:find('\27%[[;?]*[0-9.;]*[A-Za-z]') ~= nil then
      return os.clock() - start
    end
  end

  return os.clock() - start
end

local function test()
  local msg = string.format('io.read  = %s\nfor-loop = %s\n-----',
    with_io_read(), with_for_loop())
  vim.api.nvim_echo({ { msg } }, true, {})
end

vim.keymap.set('n', 't', test)

name-snrl avatar Dec 13 '22 16:12 name-snrl

I don't like this limitation of a hundred lines

OR we can simply create an option for this

name-snrl avatar Dec 13 '22 16:12 name-snrl

I introduced the limit because somebody might use nvimpager with a large log file. At work I have log files that are easily 1-10 GB in size. No idea how long it would take with these.

I tested your example with the full.log file you provided and io.read is indead faster. I will have to see with a bigger log file.

lucc avatar Dec 13 '22 19:12 lucc

What is the \e[K sequence supposed to do? If I cat part.log they don't seem to do anything.

I don't know what it does, but like I mentioned, it needs to be at least hidden.

often "less" is used with -R, this option ignores all sequences except color. I think we need implement this option.

good idea

bqv avatar Jan 20 '23 14:01 bqv

Seems like RGB colors are not parsed either. Try e.g.

printf 'normal\e[48:2:0:162:31mgreen\n'

and then open that.

illfygli avatar Sep 25 '23 13:09 illfygli

@illfygli currently only color sequences constructed with semicolon are recognized.

Reading Wikipedia it is not clear to me if the colon syntax is officially defined by the ansi standard and if so if it is the same as the semicolon syntax.

I tested xfce-termial, terminator, konsole, allacritty, kitty and xterm and all of them support your example. st does not.

lucc avatar Sep 26 '23 05:09 lucc

I tested xfce-termial, terminator, konsole, allacritty, kitty and xterm and all of them support your example. st does not.

Interesting, I didn't notice that it was not using ; when I copied an example. :sweat_smile:

With ;, the colors are filtered out, but it would be nice if they were supported, like the basic colors.

illfygli avatar Sep 26 '23 06:09 illfygli

@illfygli thanks for the heads up. I was under the impression that the escape sequences should be concealed but the colors displayed. This is a bug, I think that this did work at some point.

lucc avatar Sep 26 '23 06:09 lucc

@illfygli I checked again and it depends on the value of 'termguicolors'. So please try set tgc.

lucc avatar Sep 27 '23 08:09 lucc

@illfygli I checked again and it depends on the value of 'termguicolors'. So please try set tgc.

Ah yes, that works. Thanks!

illfygli avatar Sep 27 '23 08:09 illfygli