mbert / elvis Goto Github PK

If I go to https://github.com/mbert/elvis#readme the readme.html is not readable.

Probably more a support request than a bug, but where would that go...?

A recent install of elvis on a new Ubuntu 15.04 workstation is returning 1 even for (what should be) successful exits. This prevents me from using elvis as the editor for my commit log messages in a version control system, among other things.

I install as a normal user with a custom --prefix. If I blow away the ${prefix}/share/elvis directory, then elvis starts exiting properly. It also fails to read my custom elvis initialization files, so this isn't exactly desirable (maybe it's my custom init files breaking it?)

This is with a648881. I installed on another (Ubuntu 15.04) workstation ~3 months ago with the current HEAD then, and do not see the issue there. Same initialization files.

MIT uses Ubuntu on their machines, and on their athena machine, I compiled Elvis there and for some time it worked, until about a year ago. There must have been a hardware or distribution upgrade or something. THe current CPU is an Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz, running six cores. (40 gigs of RAM).

Elvis started dumping core after only moving around the file with navigation keys. My compilation flags are:
gcc -O2 -ansi
-ansi is used because getline() is confused with the one in stdio.h
This causes a flurry of warnings (this has always been my experience), so I added a -w flag. The warnings consisted of errors such as this random sampling out of the hundreds received:

osunix/osblock.c: In function ‘blkopen’:
osunix/osblock.c:201:2: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
  (void)write(fd, (char *)buf, sizeof buf->super);
  ^
osunix/osprg.c: In function ‘prgopen’:
osunix/osprg.c:97:8: warning: ignoring return value of ‘dup’, declared with attribute warn_unused_result [-Wunused-result]
     dup(r0w1[0]);
In file included from elvis.h:143:0,
                 from lowbuf.c:9:
lowbuf.c: In function ‘delblock’:
session.h:97:38: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 #define SES_MAXBLKLIST ((o_blksize - (int)(((BLK *)0)->blklist.blk)) / sizeof(((BLK *)0)->blklist.blk[0]))
lowbuf.c:445:28: note: in expansion of macro ‘SES_MAXSUPER’
  for (i = 0; (unsigned)i < SES_MAXSUPER; i++)
                            ^
osunix/tcaphelp.c: In function ‘ttywrite’:
osunix/tcaphelp.c:109:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
  write(ttyscr, buf, (size_t)len);
       ^
guix11/guix11.c: In function ‘loadresources’:
guix11/guix11.c:399:25: warning: assignment makes pointer from integer without a cast [enabled by default]
     resources[i].string = strdup(value.addr);
                         ^

and so on.

Running Elvis causes a segfault as stated earlier after a few key movements, which I shall show here:

---
reading Makefile
*** buffer overflow detected ***: elvis terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f1be18ef38f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f1be1986c9c]
/lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f1be1985b60]
elvis[0x45482a]
elvis[0x42c889]
elvis[0x42f38c]
elvis[0x430949]
elvis[0x46246a]
elvis[0x404d17]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f1be189dec5]
elvis[0x405169]
======= Memory map: ========
00400000-0048d000 r-xp 00000000 00:1a 1851037812                         /afs/athena.mit.edu/user/p/j/pjk/bin/elvis
0068c000-0068d000 r--p 0008c000 00:1a 1851037812                         /afs/athena.mit.edu/user/p/j/pjk/bin/elvis
0068d000-00699000 rw-p 0008d000 00:1a 1851037812                         /afs/athena.mit.edu/user/p/j/pjk/bin/elvis
00699000-006a1000 rw-p 00000000 00:00 0 
00922000-01b90000 rw-p 00000000 00:00 0                                  [heap]
7f1be0613000-7f1be0629000 r-xp 00000000 fc:00 794601                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7f1be0629000-7f1be0828000 ---p 00016000 fc:00 794601                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7f1be0828000-7f1be0829000 rw-p 00015000 fc:00 794601                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7f1be0829000-7f1be082e000 r-xp 00000000 fc:00 685095                     /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7f1be082e000-7f1be0a2d000 ---p 00005000 fc:00 685095                     /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7f1be0a2d000-7f1be0a2e000 r--p 00004000 fc:00 685095                     /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7f1be0a2e000-7f1be0a2f000 rw-p 00005000 fc:00 685095                     /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7f1be0a2f000-7f1be0a38000 r-xp 00000000 fc:00 684890                     /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7f1be0a38000-7f1be0c37000 ---p 00009000 fc:00 684890                     /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7f1be0c37000-7f1be0c38000 r--p 00008000 fc:00 684890                     /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7f1be0c38000-7f1be0c39000 rw-p 00009000 fc:00 684890                     /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7f1be0c39000-7f1be0c42000 r-xp 00000000 fc:00 674276                     /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7f1be0c42000-7f1be0e41000 ---p 00009000 fc:00 674276                     /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7f1be0e41000-7f1be0e42000 r--p 00008000 fc:00 674276                     /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7f1be0e42000-7f1be0e43000 rw-p 00009000 fc:00 674276                     /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7f1be0e43000-7f1be0e4e000 r-xp 00000000 fc:00 913434                     /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f1be0e4e000-7f1be104d000 ---p 0000b000 fc:00 913434                     /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f1be104d000-7f1be104e000 r--p 0000a000 fc:00 913434                     /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f1be104e000-7f1be104f000 rw-p 0000b000 fc:00 913434                     /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f1be104f000-7f1be1054000 r-xp 00000000 fc:00 662534                     /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f1be1054000-7f1be1253000 ---p 00005000 fc:00 662534                     /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f1be1253000-7f1be1254000 r--p 00004000 fc:00 662534                     /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f1be1254000-7f1be1255000 rw-p 00005000 fc:00 662534                     /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f1be1255000-7f1be1257000 r-xp 00000000 fc:00 662530                     /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f1be1257000-7f1be1457000 ---p 00002000 fc:00 662530                     /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f1be1457000-7f1be1458000 r--p 00002000 fc:00 662530                     /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f1be1458000-7f1be1459000 rw-p 00003000 fc:00 662530                     /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f1be1459000-7f1be145c000 r-xp 00000000 fc:00 913429                     /lib/x86_64-linux-gnu/libdl-2.19.so
7f1be145c000-7f1be165b000 ---p 00003000 fc:00 913429                     /lib/x86_64-linux-gnu/libdl-2.19.so
7f1be165b000-7f1be165c000 r--p 00002000 fc:00 913429                     /lib/x86_64-linux-gnu/libdl-2.19.so
7f1be165c000-7f1be165d000 rw-p 00003000 fc:00 913429                     /lib/x86_64-linux-gnu/libdl-2.19.so
7f1be165d000-7f1be167a000 r-xp 00000000 fc:00 662538                     /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f1be167a000-7f1be187a000 ---p 0001d000 fc:00 662538                     /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f1be187a000-7f1be187b000 r--p 0001d000 fc:00 662538                     /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f1be187b000-7f1be187c000 rw-p 0001e000 fc:00 662538                     /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f1be187c000-7f1be1a37000 r-xp 00000000 fc:00 847616                     /lib/x86_64-linux-gnu/libc-2.19.so
7f1be1a37000-7f1be1c36000 ---p 001bb000 fc:00 847616                     /lib/x86_64-linux-gnu/libc-2.19.so
7f1be1c36000-7f1be1c3a000 r--p 001ba000 fc:00 847616                     /lib/x86_64-linux-gnu/libc-2.19.so
7f1be1c3a000-7f1be1c3c000 rw-p 001be000 fc:00 847616                     /lib/x86_64-linux-gnu/libc-2.19.so
7f1be1c3c000-7f1be1c41000 rw-p 00000000 00:00 0 
7f1be1c41000-7f1be1c66000 r-xp 00000000 fc:00 786554                     /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f1be1c66000-7f1be1e65000 ---p 00025000 fc:00 786554                     /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f1be1e65000-7f1be1e69000 r--p 00024000 fc:00 786554                     /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f1be1e69000-7f1be1e6a000 rw-p 00028000 fc:00 786554                     /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f1be1e6a000-7f1be1f9a000 r-xp 00000000 fc:00 662546                     /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f1be1f9a000-7f1be219a000 ---p 00130000 fc:00 662546                     /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f1be219a000-7f1be219b000 r--p 00130000 fc:00 662546                     /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f1be219b000-7f1be219f000 rw-p 00131000 fc:00 662546                     /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f1be219f000-7f1be21c2000 r-xp 00000000 fc:00 847695                     /lib/x86_64-linux-gnu/ld-2.19.so
7f1be238d000-7f1be2392000 rw-p 00000000 00:00 0 
7f1be23bc000-7f1be23c1000 rw-p 00000000 00:00 0 
7f1be23c1000-7f1be23c2000 r--p 00022000 fc:00 847695                     /lib/x86_64-linux-gnu/ld-2.19.so
7f1be23c2000-7f1be23c3000 rw-p 00023000 fc:00 847695                     /lib/x86_64-linux-gnu/ld-2.19.so
7f1be23c3000-7f1be23c4000 rw-p 00000000 00:00 0 
7ffdf2ab5000-7ffdf2ad6000 rw-p 00000000 00:00 0                          [stack]
7ffdf2b07000-7ffdf2b09000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)

Hope this helps.

Paul King

I wanted to know if it is possible still contribute to this repo. I know Neovim has now taken over vim which took over vi.
But, this project still seems quite attractive, especially for educational purposes and something might come out of this. I am looking for a good C repo to contributing, this one is on the top of the list
BTW, I apologise if 'issues' is not the right place to ask questions like this, do let me know another way to do so if this is not the correct way so I will do that next time.
Also, have the project file structure changed majorly in this project, from the original elvis codebase?
Kind Regards, Have a nice day y'all.

Currently, elvis does show multi-byte characters as multiple bytes

» shows as »

it feels like betrayal to use gvim instead of elvis to be able to edit these files

I'd love to see a 2.2.2 release, or something along those lines.

Thanks!

In syntax mode:
after typing an numbered anchor (defined in elvis.syn with a number position, not ^)
the cursor warps to the line below. With the next typed key the cursor restores to the correct line.

To reproduce:
Add a syntax to the default elvis.syn
language x extension .x anchor 1 hola

In either termcap or X11:

• TYPE ANYTHING INTO BUFFER<esc>OholaDid you saw the warp?
• Now do the same but in an empty-buffer/last-line and I get a segfault

I'd like to suggest that elvis gain support for macros like vim. vim is rather weighty to install on some of the embedded servers I use, I truly love elvis... the only thing missing that I make frequent use of is macros.

As described here: http://vim.wikia.com/wiki/Macros

The only things I've ever wanted in elvis have been macros and support for highlighting more things for 256-color terminals.

Please and thank you?

allow a flag to "color ..." statements in elvis.syn
to not let elvis.clr change those colors

for example "color fixed ..." instead of "color ..."

Why?
Maybe I'm overstretching elvis coloring capabilities but this could favour
a style I'm using declaring some "starting" tokens in one color and "ending" tokens
in another one and elvis.clr not overriding this language customization

For example, the html files are colored like this:

keyword <div <span ...
color keyword on green
font operator </div </span ...
color operator on yellow

Even more, there could be some more extra font styles to favour this style, like
"font extra1", "font extra2", "font extra3".

So, the first enhancement should be "color [fixed]"
and the next enhancement should be allow more fonts font (extra1|extra2|extra3).

How invasive would be this?

How to stop the cursor from blinking? I only have this issue with recent distributions (Slackware & Debian). Perhaps it came from latest version of libncurses ?

tried invoking elvis after regular build ./configure && make && make install:

can't load font -courier-medium-r--18-*
no such window

Checkout out this git repo on Windows fails because "IDL:Elvis:ElvisPrivate:1.0.gnorba" is not a valid Windows file name. Colons are used to indicate alternate streams, and NTFS only supports one level of stream, so "IDL:Elvis" is meaningful, but not beyond that.

In order to checkout this code:

git clone https://github.com/mbert/elvis elvis
(fails checking out working copy)
cd elvis
git sparse-checkout init
git sparse-checkout set /* !/guignome/*
git config --worktree --add core.protectntfs false
git checkout master

I looked a bit at the guignome code, and I'm wondering if it's worth keeping. It looks like it's Gnome 1 using Glade, which isn't going to be present on any semi-modern system. It's also not obvious to me (as someone who knows almost nothing about gnome) whether it's possible to rename this file to something more compatible.

I am accustomed to installing elvis, and while some bugs are fixed (meaning I don't have to go in there and change the code), there is one that has me stumped on your repo.

For one thing, I don't have <X11/Intrinsic.h> in my libraries (or it is hidden somewhere). I had to comment out the reference. It still compiled with GUI. Bit that's not the biggest problem.

I run Ubuntu Studio on my machine, and when I finally run elvis, I get an error

                        can't load font *-courier-medium-r-*-18-*

and Elvis does not run. If I run using -G termcap, then the default text in xterm appears black on black. Writing bash code shows syntax highlighting when I tried it, however. I just tried running with -G termcap in a console (not under X), and the default colors where bright yellow on black.a Minor problem. However, I remember Elvis behaving a little funny when one selects "bright" colors, especially if it's default.

Your code has similar strings as -courier-medium-r--18-* for bold and oblique, IIRC.

I don't have any fonts on my system that fits that pattern (I checked under xlsfonts and xfontsel). I do, however, have

                       *-courier-medium-r-normal-*-17-*

With absolutely no choice for another font size in that pattern. I can replace the "17" with a "0" to get the default size (which is 17 anyway). Also, note that in the closest match, there was still another "*" before the font size.

If I run the code without installation I get a tiny monospaced font and no toolbar.

Look at the pics, the "-include_lib" directive (parsed as preprocessor) displays
"-include" in color but the rest "_lib" in normal font. This commit fixes it.
I guess this also rules on C based languages too, so I post the patch here.

`
changeset: 108:805ca85ab8ba
branch: fran-stable
tag: tip
user: memo_ao756
date: Fri Jul 22 16:16:21 2016 -0300
files: dmsyntax.c
description:
fixes preprocessor parsing ends at '_' in preprocessor lines

In erlang, for example this is valid. Dont' know other languages...

diff -r c58302a54a7a -r 805ca85ab8ba dmsyntax.c
--- a/dmsyntax.c Fri Jun 24 00:16:30 2016 -0300
+++ b/dmsyntax.c Fri Jul 22 16:16:21 2016 -0300
@@ -1504,7 +1504,7 @@
{
sinfo->token = PREPWORD;
}

•       else if (sinfo->token == PREPWORD && !elvalnum(*cp))
  

•       else if (sinfo->token == PREPWORD && !elvalnum(*cp) && *cp != '_')
      {
          sinfo->token = PUNCT;
          expectprepq = ElvTrue;
  

`

Hi I have some bugfixes to the program
The thing is I still don't understand git so I made a public repo in bitbucket
https://bitbucket.org/fran_/elvis-fbrau/

I added some features (like it or not)
But it also has some bugfixes like:
https://bitbucket.org/fran_/elvis-fbrau/commits/7060a78058c53415a3f7d1a79c753a0d862809f1

https://bitbucket.org/fran_/elvis-fbrau/commits/87c390d61a7b5a9d5aceb529739b949f5c5de717

https://bitbucket.org/fran_/elvis-fbrau/commits/daced702fe4d4389ccb6cece6f83fb78ee6ba92e

Take a peek

Elvis can be used to execute arbitrary code simply by editing a downloaded text file.

https://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md

The exploit describes vim, but works in elvis too.

The patch for the documented PoCs seems to be quite simple - just ignore modelines that start with !
However, there might be other ways to execute code, such as piping part of the file through a command (e.g. :1,$!some_command)

There currently is a limited support for font-se changes once a session started.
If the font supports unlimited sizes, I's like to be able to use Shift-KP_PLUS and Shift-KP_MINUS like in xterm to grow/shrink font size. This is very useful when using elvis in presentations or screen-sharing (zoom/teams sessions).
Related issue is that the '_' sometimes is invisible in some resolutions with some fonts on some font sizes (yes, that is explicitely vague as I found no al-ways-reproducing test case), and this is regardless of the setting for aasqueeze, though I think that allowing negative values for aasqueeze might fix that

Elvis does not display the entire file, I have to scroll through the file to display it line-by-line, this becomes extra confusing when you switch from downward to upward movement, a screenshot probably helps:

Niltze [Hi]!

I get this error:

X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 42 (X_SetInputFocus)
Serial number of failed request: 144
Current serial number in output stream: 439

upon Elvis instantiation -- after an apparently successful configure (see below, please)
make, make install.

On Debian Sid (Unstable):
./configure --prefix=/usr/local --x-libraries=/usr/lib/x86_64-linux-gnu --verbose
(output)
No system type was specified, so I'm running uname(1) to guess it...
Apparently this is 'linux'
I know 'linux' -- This should be easy!
Looking for some compiler files...
Internet headers found
Skipping GNOME due to a temporary configuration bug. (For more information,
see the comment at the top of the 'configure' script)
X11 headers found
X11 libraries found
GCC found
Assuming --with-x because X11 headers were found
Enabling the use of background images since -lXpm and <X11/xpm.h> were found
Xft found -- elvis will use it
Assuming HTTP should be supported because Internet headers were found
Assuming FTP should be supported because Internet headers were found
This system has no <sys/ptem.h> file so I assume elvis doesn't need it
This system has a <termcap.h> file so I assume elvis needs it
This system has a <sys/wait.h> file so I assume elvis needs it
This system has a <sys/select.h> file so I assume elvis needs it
This system has a <sys/ioctl.h> file so I assume elvis needs it
This system has a <netinet/in.h> file so I assume elvis needs it
This system has a <sys/socket.h> file so I assume elvis needs it
This system has a <X11/Xos.h> file so I assume elvis needs it
Does this system support setpgid()?
Assuming yes, because it is declared in <unistd.h>
Does this system support freopen()?
Assuming yes, because it is declared in <stdio.h>
Does this system support XrmCombineFileDatabase()?
Assuming yes, because it is declared in <X11/Xresource.h>
Does this system support inet_aton()?
Assuming yes, because it is declared in <arpa/inet.h>
Does this system require -lresolv to use inet_aton()?
Assuming yes, because I found libresolv
Does this system support memmove()?
Assuming yes, because it is declared in <string.h> or <strings.h>
Choosing a type of ioctl() calls, since no --ioctl=... argument was given
Assuming --ioctl=termios because <termios.h> exists
For Linux, we're using curses because there is no termcap library
For Linux, elvis never needs <sys/select.h> so I'm ignoring it on your system
Assuming lpout="!lpr" because /usr/bin/lp doesn't exist
Assuming GCC should be used because it exists and the linux-specific
tweaks didn't indicate that the standard CC is better.
Options: --prefix=/usr/local --x-libraries=/usr/lib/x86_64-linux-gnu$ --with-x --ioctl=termios --libs='-lcurses'
System: linux
Compiler: gcc -O2
Bin dir: /usr/local/bin
Data dir: /usr/local/share/elvis/
Doc dir: /usr/local/share/elvis/doc/
Man dir: /usr/local/share/man/elvis/man

Thank you in advance for any insight you can provide.

Best Professional Regards.

don't know if it is a bug or what.

I wanna fix that.

Suggestions?

The html viewer is cute and sometimes it saves the day but for serious development
or viewing is pretty vague.

Setting the syntax mode on the elvis.syn wont do nothing (I read it somewhere in the docs)
I have fixed syntax mode in elvis.arf (or elvis.brf, dont remember).

But now when I open the :help I get syntax mode too.

I think elvis should accept set declarations related to the syntax in elvis.syn (currently does not)
or even better some kind of pattern to decide which mode html files get considering
the help files should always be in html mode.

Hi. I've been reading syntax mode code and it seems very clever to avoid full parsing
but I've encountered several times with cases when multiline tokens where:

considering the code:
char* hello = "hello \ world \ godbye"; int x = 1;

and having
world \ goodbye"; int x = 1;
on focus, the syntax mode 'world goodbye' are displayed in normal text and
'"; int x = 1...' is displayed a string token.

The "parser" doesnt recognize "world \ godbye" comes from a string
opening just a few lines before the focused text. I've searching a few points in the
code and there is actually a function in dmsyntax.c (setup(...)) which implements some
king of backtraking to detect this case. Managed to understand it somehow but
it is never evaluated.

I want to implement a buffer option to effect in the parsing code to
"alternate" the syntax detection considering the first token is part of
a multilinetoken (coment or string), nothing smart, just an option.

I modified the setup(...) function to do just that by this is not in the path
of syntax drawing.

Where this feature should go in the code or where begins the parsing?

Compile fails with a clang error, seen here:

https://gist.github.com/ryanpcmcquen/bce78b7feed42f5ec459