Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Maxime Coste]

Hello

On Mon, Feb 15, 2016 at 05:34:58PM +0100, Marc André Tanner wrote:
> In general what kind of data structure do you use to keep track of cursors
> when the buffer changes? That is when something is inserted/deleted at a
> cursor location, do you need to update the location of all subsequent
> cursors?

Kakoune uses an array of line representation of buffers, so quite naturally
selections are represented as a pair of (line, column) coordinates.

Selections are kept sorted, so when inserting/deleting we keep track of
the actual position change before processing the next selection. A list of
buffer modifications is kept as well (separate from the undo list, this is
an append only list of (position, length, insert/erase) data. Selections
keep a timestamp so that when they are accessed and they are not up to date
(that can happen when we have two windows on the same buffer) we can update
them by applying all the modifications from last timestamp. That update
is accelerated by batching the consecutive modifications that are either
forward or backward sorted.

For more details, I recommend taking a look at SelectionList::update :)

> If you don't mind I would also like to discuss different approaches
> to a client/server design. What kind of protocol do you use? Am I right
> that the clients are rather "dumb" i.e. they just forward keyboard input
> and display stuff rendered by the server process?

Yep, the client server design has very dumb clients. A client only provides an
user interface, it sends events (keys, mouse events, resize events) and recieve
display commands. An important thing is that its totally asynchrounous, a
command never recieve an answer, so we cannot by design be waiting on a client.

The protocol is ad-hoc, sending directly the binary data of most structures,
its actually something i'd like to improve as at the moment you cannot have
a 32bit client connect to a 64bit server.

> In Kakoune external programs/plugins talk to the editor via a bunch
> of built in commands, manipulating the buffer content through regular
> keyboard shortcuts, right? Do you feel this is flexible enough? Doesn't
> this completely break if the user decides to change some keyboard mappings? 

Yep thats basically the case, external program can send commands in the same
command language the user uses to open files, save, jump to tags... Buffer
modification is the role of the normal/insert mode so scripts have to use
that as well.

It does work well enough although it has some limitations, expressing complex
logic is tricky but works, it is an interesting design challenge to try
to find a solution for script use cases that makes sense for interactive
edition as well.

One important design choice here is that the key mapping *is* the editing
language, and not a binding of keystrokes to underlying commands. That means
that, by default, the :exec command (that sends keystrokes as-if typed)
will ignore user key mappings.

> For vis I'm wondering what kind of RPC interface to expose. As an extreme
> example should it be possible to connect with both a vim like and an
> Emacs like interface to the same session/buffer? That is should the main
> editor logic be client side and the server would only propagate buffer
> changes and keep some shared state (e.g. registers, marks, macros ...)?

I guess that really depends on what your goal is for vis. I am very happy
with the asynchrounous nature of Kakoune's protocol, which I think works
well because clients are very simple. The more you put in the client, the
more complex you communication needs to be (for example you will need to
access the buffer change history to update selections in your client if the
buffer gets modified by another client, especially as with multi selection
you can get a huge set of modifications in one go).

> Looking forward to your comments and thanks for Kakoune it has some nice
> ideas!

Thanks, good luck with vis, I am happy to see it evolve on its own path
rather than as just a vi clone.

Cheers,

Maxime.

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Sun, Feb 14, 2016 at 03:17:35PM +, Maxime Coste wrote:
> On Sat, Feb 13, 2016 at 02:11:28PM +0100, Marc André Tanner wrote:
> > On Mon, Jan 18, 2016 at 08:24:14AM +0100, Jan Christoph Ebersbach wrote:
> > > - I miss that I can't align multiple cursors in insert mode, i.e. to
> > >   align all "=" over multiple lines.  The editor kakoune supports this
> > >   nicely
> > 
> > I just implemented basic support for this with Shift-Tab in insert/replace
> > mode. It is most likely not (yet?) as powerful as kakoune (it has been
> > a while since I last played around with kak).
> > 
> > For example it won't work as expected when multiple cursors are on the
> > same line.
> 
> Kakoune logic for that is to treat multiple selections on same line as 
> columns,
> so the first selections on each lines are aligned together, eventual second
> selections are aligned together and so on.
> 
> Not sure if vis uses only cursors or selections, but the logic of aligning
> cursors by inserting before the begining of selection does work well, as
> it handle left and right alignment.

Yes this makes sense. It is just that vis' selection handling is rather
primitive at the moment. There is no relation kept among selections, that
is they are not sorted (nor merged if they overlap). Thus when given a
selection it is currently not easy to determine whether another selection
is on the same line.

In general what kind of data structure do you use to keep track of cursors
when the buffer changes? That is when something is inserted/deleted at a
cursor location, do you need to update the location of all subsequent
cursors?

If you don't mind I would also like to discuss different approaches
to a client/server design. What kind of protocol do you use? Am I right
that the clients are rather "dumb" i.e. they just forward keyboard input
and display stuff rendered by the server process?

In Kakoune external programs/plugins talk to the editor via a bunch
of built in commands, manipulating the buffer content through regular
keyboard shortcuts, right? Do you feel this is flexible enough? Doesn't
this completely break if the user decides to change some keyboard mappings? 

For vis I'm wondering what kind of RPC interface to expose. As an extreme
example should it be possible to connect with both a vim like and an
Emacs like interface to the same session/buffer? That is should the main
editor logic be client side and the server would only propagate buffer
changes and keep some shared state (e.g. registers, marks, macros ...)?

Looking forward to your comments and thanks for Kakoune it has some nice
ideas!

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Maxime Coste]

On Sat, Feb 13, 2016 at 02:11:28PM +0100, Marc André Tanner wrote:
> On Mon, Jan 18, 2016 at 08:24:14AM +0100, Jan Christoph Ebersbach wrote:
> > - I miss that I can't align multiple cursors in insert mode, i.e. to
> >   align all "=" over multiple lines.  The editor kakoune supports this
> >   nicely
> 
> I just implemented basic support for this with Shift-Tab in insert/replace
> mode. It is most likely not (yet?) as powerful as kakoune (it has been
> a while since I last played around with kak).
> 
> For example it won't work as expected when multiple cursors are on the
> same line.

Kakoune logic for that is to treat multiple selections on same line as columns,
so the first selections on each lines are aligned together, eventual second
selections are aligned together and so on.

Not sure if vis uses only cursors or selections, but the logic of aligning
cursors by inserting before the begining of selection does work well, as
it handle left and right alignment.

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Mon, Jan 18, 2016 at 08:24:14AM +0100, Jan Christoph Ebersbach wrote:
> - I miss that I can't align multiple cursors in insert mode, i.e. to
>   align all "=" over multiple lines.  The editor kakoune supports this
>   nicely

I just implemented basic support for this with Shift-Tab in insert/replace
mode. It is most likely not (yet?) as powerful as kakoune (it has been
a while since I last played around with kak).

For example it won't work as expected when multiple cursors are on the
same line.

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Tue, Jan 19, 2016 at 04:14:55PM -0500, Matthew of Boswell wrote:
> On Tue, 19 Jan 2016 14:16:37 +0100
> Marc André Tanner  wrote:
> 
> > > - I also miss C-a and C-x for dealing with numbers .. but that's just a
> > >   minor inconvenience right now  
> > 
> > These seem to be popular? I'm just using change or replace/overwrite for
> > these use cases.
> 
> Haha, you wouldn't think such a minor "feature bloat" in vim would be
> so often used. I do the same thing... I a little annoyed when I use
> a vim emulator that doesn't have ctrl+a and ctrl+x support. It's
> basically a handy basic calculator. I do addition/subtraction on large
> numbers in code (handy when making adjustments and dealing with pixel
> width/padding issues).
> 
> Example:
> 0x14
> type: 8 C-a
> answer: 0x1c

I decided to implement it because:

 1) The way the underlying text management data structure is currently
implemented these repetetive changes of the same text regions presents
an (almost) worst case in terms of memory usage.

 2) It turned out to be relatively straight forward to do. It might
not support all the special cases of vim. For example it is currently
not repeatable.

Also due to conflicts with existing keybindigs ( alignment of
multiple cursors) it is currently not enabled by default. You will
need something like:

 :map! normal  
 :map! normal  

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Joshua Haase]

Marc André Tanner  writes:

> Is this still an issue? If so, please provide a failing example.

It works on gf850388 (just tested latest commit).

Thanks a lot!

> Thanks,
> Marc 
>
> -- 
>  Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Tue, Jan 19, 2016 at 11:54:38PM +, Joshua Haase wrote:
> Filter has stopped working when selection is active since at least
> commit 304b645c974118b7 (haven't done a proper bisect to
> identify the issue).
> 
> Will send a patch if I get this before someone else.

Is this still an issue? If so, please provide a failing example.

Thanks,
Marc 

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Wed, Jan 20, 2016 at 07:47:27AM +0100, Markus Teich wrote:
> Marc André Tanner wrote:
> > There were some other (slightly ugly) changes necessary, but it should now
> > work as you want?
> 
> In visual line mode it still behaves a little strange. Shifting right seems to
> work fine, but when shifting left, the selection is lost. In the character
> visual mode it works for both directions.

Should hopefully be fixed now.

> > The till/to changes are also committed.
> 
> Thanks. However there were still some corner cases with wrong behaviour, see 
> my
> other mail on hackers@ for the patch.

Thanks, applied.

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Matthew of Boswell]

On Tue, 19 Jan 2016 14:16:37 +0100
Marc André Tanner  wrote:

> > - I also miss C-a and C-x for dealing with numbers .. but that's just a
> >   minor inconvenience right now  
> 
> These seem to be popular? I'm just using change or replace/overwrite for
> these use cases.

Haha, you wouldn't think such a minor "feature bloat" in vim would be
so often used. I do the same thing... I a little annoyed when I use
a vim emulator that doesn't have ctrl+a and ctrl+x support. It's
basically a handy basic calculator. I do addition/subtraction on large
numbers in code (handy when making adjustments and dealing with pixel
width/padding issues).

Example:
0x14
type: 8 C-a
answer: 0x1c

I actually sometimes want multiplication/division in vim, but I guess
addition+subtraction is enough feature creep for one editor ;).

-- 
Matt Boswell

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Joshua Haase]

Matthew of Boswell  writes:

> On Tue, 19 Jan 2016 14:16:37 +0100
> Marc André Tanner  wrote:
>
> Haha, you wouldn't think such a minor "feature bloat" in vim would be
> so often used. I do the same thing... I a little annoyed when I use
> a vim emulator that doesn't have ctrl+a and ctrl+x support. It's
> basically a handy basic calculator. I do addition/subtraction on large
> numbers in code (handy when making adjustments and dealing with pixel
> width/padding issues).

This should be configured as a lua script when required,
or a filter should be used.

- - -

Speaking of which...

Filter has stopped working when selection is active since at least
commit 304b645c974118b7 (haven't done a proper bisect to
identify the issue).

Will send a patch if I get this before someone else.

>
> I actually sometimes want multiplication/division in vim, but I guess
> addition+subtraction is enough feature creep for one editor ;).

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Heyho Marc,

Marc André Tanner wrote:
> > I don't know the best way to fix it, but it would
> > be possible to strip the newline from within the `cmd_set` function.
> 
> I have taken this route for now. Should be fixed?

Yep, works.

> > Ah right, I see it's used for `~` now. Could you add this mapping to the
> > bindings_visual and bindings_visual_line in config.def.h?
> 
> There were some other (slightly ugly) changes necessary, but it should now
> work as you want?

In visual line mode it still behaves a little strange. Shifting right seems to
work fine, but when shifting left, the selection is lost. In the character
visual mode it works for both directions.

> > > > I also was surprised, `\` works as it should. I propose to change
> > > > CURSOR_SEARCH_WORD_… to use `\` as regex instead of just `WORD` 
> > > > to
> > > > achieve the same functionality as in vim.
> > > 
> > > Yes I agree.
> > 
> > This patch for vis-motions.c works for me:
> 
> Thanks, some care must be taken with the integration into the search
> history though. I will take another look once I have more time ... 


> The till/to changes are also committed.

Thanks. However there were still some corner cases with wrong behaviour, see my
other mail on hackers@ for the patch.

--Markus

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Sun, Jan 17, 2016 at 07:59:50PM +0100, Silvan Jegen wrote:
> On Sun, Jan 17, 2016 at 07:23:06PM +0100, Marc André Tanner wrote:
> > The current source tree contains a `vis-open` shell script which
> > provides basic file system navigation by means of fuzzy matching using
> > either slmenu or dmenu. It is invoked by default if you open a directory
> > 
> >  :split .
> > 
> > or supply a path containing other shell wildcards such as *, {, or [.
> 
> I have seen the script but I was not sure how to use it from vis itself.
> Being able to open a file to edit in the same vis instance using
> "vis-open" (using the :edit command) would be welcome. I will look into
> it when I have I access to my desktop.

 :e .
 :e *.c

should work if vis-open and slmenu is in your $PATH.

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Mon, Jan 18, 2016 at 08:24:14AM +0100, Jan Christoph Ebersbach wrote:
> Hi Marc,
> 
> I like vis very much.  It's blazing fast and comes with good defaults.
> The following things I noticed:
> 
> - Setting defaults requires patching some c file instead of config.def.h

Are you referring to the white space replacement symbols hardcoded in view.c? 

As mentioned elsewhere the long term goal is to move this stuff to Lua.

> - Background/Foreground colors are only applied when syntax highlighting
>   is possible for the currently loaded file

Yes true, could also be taken care of by a default lexer.

> - I miss that I can't align multiple cursors in insert mode, i.e. to
>   align all "=" over multiple lines.  The editor kakoune supports this
>   nicely

Yes I agree multiple cursor support could certainly be improved. At the
moment it is more a proof of concept (which works surprisingly well). 

I have some ideas I would like to try out, but unfortunately a lack of time.

> - I also miss C-a and C-x for dealing with numbers .. but that's just a
>   minor inconvenience right now

These seem to be popular? I'm just using change or replace/overwrite for
these use cases.

> - It took me ages to start vis with the proper VIS_PATH and VIS_THEME
>   settings.  My installation directory for vis is ~/.local which is not
>   part of the default locations.  Furthermore, the manpage still refers
>   to ~/.vis as the location where to put my personal configuration but
>   it is actually ~/.config/vis.  I had to create a little shell script
>   that sets VIS_PATH and VIS_THEME before starting vis.  In my opinion
>   these obstacles make it very hard to start playing around with it.

Sorry about that. The man page should be updated now. Such problems are
best debugged using something like:

 $ strace -o log -e open vis && cat log

> Since I'm using a light terminal background, I recreated the papercolor
> theme.  Please feel free to integrate it:
> https://github.com/jceb/dotfiles/blob/master/config/vis/lexers/themes/papercolor.lua

Thanks, I will take a look!

Marc

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

> > > Still does not work. After enabling one of the `show` settings, I am 
> > > unable
> > > to reset it again. I have to restart vis.
> > 
> > Strange, seems to work fine here.
> 
> Okay, I got the issue. `parse_bool` is called with `0\n` as first argument. 
> The
> newline character should not be there for the intended behaviour. I also 
> managed
> to unset the setting by _not_ using the history. So it seems to be a bug with
> the history imlementation. To reproduce it, `:set show tabs` and then
> `:0`. I don't know the best way to fix it, but it 
> would
> be possible to strip the newline from within the `cmd_set` function.

I have taken this route for now. Should be fixed?

> > The vis way of doing this would be an alias to 
> > `gv`
> 
> Ah right, I see it's used for `~` now. Could you add this mapping to the
> bindings_visual and bindings_visual_line in config.def.h?

There were some other (slightly ugly) changes necessary, but it should
now work as you want?

> > > I also was surprised, `\` works as it should. I propose to change
> > > CURSOR_SEARCH_WORD_… to use `\` as regex instead of just `WORD` to
> > > achieve the same functionality as in vim.
> > 
> > Yes I agree.
> 
> This patch for vis-motions.c works for me:

Thanks, some care must be taken with the integration into the search
history though. I will take another look once I have more time ... 

The till/to changes are also committed. 

Thanks!

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Mon, Jan 18, 2016 at 03:29:48PM +0800, Pickfire wrote:
> I really like vis, I just don't like it's support for multi-window.
> I can't resize it.

That is a deliberate design decision. At some point I would like to
experiment with a client/server architecture. Then your preferred window
manager / terminal multiplexer would take care of your windows.

> Is there any reason why vis won't implement libuv like neovim

Having a proper event loop mechanism would certainly help when interfacing
with external programs (syntax/spell checking, code completion etc). Upon
first glance libuv looks like a decent choice although it accumulated
quite a few unrelated features over time. Some people where unhappy about
the Lua dependency (I made it optional for now), they probably won't
like libuv. On the other hand it would also support Windows, whether
that is positive or negative is left for the reader to decide ;)
I also need to check the status of the midipix[1] project.

> instead of using an unactive project like libtermkey?

I think you are mixing something up here. libuv does not cover the
functionality provided by libtermkey (terminal input handling).

[1] http://midipix.org/ 

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Silvan Jegen]

On Tue, Jan 19, 2016 at 01:56:32PM +0100, Marc André Tanner wrote:
> On Sun, Jan 17, 2016 at 07:59:50PM +0100, Silvan Jegen wrote:
> > On Sun, Jan 17, 2016 at 07:23:06PM +0100, Marc André Tanner wrote:
> > > The current source tree contains a `vis-open` shell script which
> > > provides basic file system navigation by means of fuzzy matching using
> > > either slmenu or dmenu. It is invoked by default if you open a directory
> > > 
> > >  :split .
> > > 
> > > or supply a path containing other shell wildcards such as *, {, or [.
> > 
> > I have seen the script but I was not sure how to use it from vis itself.
> > Being able to open a file to edit in the same vis instance using
> > "vis-open" (using the :edit command) would be welcome. I will look into
> > it when I have I access to my desktop.
> 
>  :e .
>  :e *.c
> 
> should work if vis-open and slmenu is in your $PATH.

I like that a lot.

I could not find anything about this in the README so I wrote a short
quip about that feature.


diff --git a/README.md b/README.md
index aa159e6..5bf3d3d 100644
--- a/README.md
+++ b/README.md
@@ -320,8 +320,16 @@ Operators can be forced to work line wise by specifying 
`V`.
 *  the current selection, equivalent to '<,'>
 
   History support, tab completion and wildcard expansion are other
-  worthwhile features. However implementing them inside the editor
-  feels wrong.
+  worthwhile features. However implementing them inside the editor feels
+  wrong. For now you can use the `:edit` command with a pattern or a
+  directory like this.
+
+:e *.c
+:e .
+
+  vis will call the `vis-open` script which invokes dmenu or slmenu
+  with the files corresponding to the pattern. The file you select in
+  dmenu/slmenu will be opened in vis.
 
 ### Tab <-> Space conversion and Line endings \n vs \r\n
 

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Heyho Jan,

Jan Christoph Ebersbach wrote:
> - Setting defaults requires patching some c file instead of config.def.h

have you tried the visrc.lua file in the repository root? You can do any `set`
command in there for your defaults. See my other mails in this thread.

> - It took me ages to start vis with the proper VIS_PATH and VIS_THEME
>   settings.  My installation directory for vis is ~/.local which is not
>   part of the default locations.  Furthermore, the manpage still refers
>   to ~/.vis as the location where to put my personal configuration but
>   it is actually ~/.config/vis.  I had to create a little shell script
>   that sets VIS_PATH and VIS_THEME before starting vis.  In my opinion
>   these obstacles make it very hard to start playing around with it.

I have vis checked out in ~/code/vis and just set an
`alias v="VIS_PATH=~/code/vis ~/code/vis/vis"` for my shell. Works fine so far.

--Markus

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Pickfire]

I really like vis, I just don't like it's support for multi-window.
I can't resize it.

Is there any reason why vis won't implement libuv like neovim instead of
using an unactive project like libtermkey?

On Mon, Jan 18, 2016 at 08:24:14AM +0100, Jan Christoph Ebersbach wrote:

Since I'm using a light terminal background, I recreated the papercolor
theme.  Please feel free to integrate it:
https://github.com/jceb/dotfiles/blob/master/config/vis/lexers/themes/papercolor.lua


Thanks a lot, I will make it mentioned in the project. +1

--
_
< Do what you like, like what you do. >
-
   \   ^__^
\  (oo)\___
   (__)\   )\/\
   ||w |
   || ||


signature.asc
Description: PGP signature

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Jan Christoph Ebersbach]

Hi Marc,

I like vis very much.  It's blazing fast and comes with good defaults.
The following things I noticed:

- Setting defaults requires patching some c file instead of config.def.h

- Background/Foreground colors are only applied when syntax highlighting
  is possible for the currently loaded file

- I miss that I can't align multiple cursors in insert mode, i.e. to
  align all "=" over multiple lines.  The editor kakoune supports this
  nicely

- I also miss C-a and C-x for dealing with numbers .. but that's just a
  minor inconvenience right now

- It took me ages to start vis with the proper VIS_PATH and VIS_THEME
  settings.  My installation directory for vis is ~/.local which is not
  part of the default locations.  Furthermore, the manpage still refers
  to ~/.vis as the location where to put my personal configuration but
  it is actually ~/.config/vis.  I had to create a little shell script
  that sets VIS_PATH and VIS_THEME before starting vis.  In my opinion
  these obstacles make it very hard to start playing around with it.

Since I'm using a light terminal background, I recreated the papercolor
theme.  Please feel free to integrate it:
https://github.com/jceb/dotfiles/blob/master/config/vis/lexers/themes/papercolor.lua

Keep up the good work!

Jan Christoph

On Fri 15-01-2016 16:56 +0100, Marc André Tanner wrote:
> On Thu, Dec 31, 2015 at 07:59:37PM +0100, Connor Lane Smith wrote:
>
> > I think this is pushing it for a 2015 release. But I'll be sure to
> > give it a go asap, 2016. :)
>
> Did you (or anyone else) try it? First impressions? Which features did
> you miss the most?
>
-- 
Jan Christoph Ebersbach
I didn’t want some petty, inferior brand of righteousness that comes
from keeping a list of rules when I could get the robust kind that comes
from trusting Christ - God’s righteousness.  Phil 3:9


signature.asc
Description: PGP signature

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Marc André Tanner wrote:
> > Maybe a global default 'syntax highlighter' applied regardless of file type
> > could do the job?
> 
> Maybe, yes. However you probably want these features in combination with
> regular syntax highlighting. Maybe a layered approach would somehow work

Thats what I meant. It would basically run independently of the filetype
specific syntax highlighting, probably before it and create the
backgrounds/visual replacements for whitespace, the colorcolumn, another
background for all lines with a cursor and maybe even the line numbers. One
could also add such a global highlighter running after the filetype specific one
to override some stuff. First things that come to mind would be highligthing the
searchterm (hlsearch) or the word, the cursor is currently above.

> > Still does not work. After enabling one of the `show` settings, I am unable
> > to reset it again. I have to restart vis.
> 
> Strange, seems to work fine here.

Okay, I got the issue. `parse_bool` is called with `0\n` as first argument. The
newline character should not be there for the intended behaviour. I also managed
to unset the setting by _not_ using the history. So it seems to be a bug with
the history imlementation. To reproduce it, `:set show tabs` and then
`:0`. I don't know the best way to fix it, but it would
be possible to strip the newline from within the `cmd_set` function.

> The vis way of doing this would be an alias to `gv`

Ah right, I see it's used for `~` now. Could you add this mapping to the
bindings_visual and bindings_visual_line in config.def.h?

> > I also was surprised, `\` works as it should. I propose to change
> > CURSOR_SEARCH_WORD_… to use `\` as regex instead of just `WORD` to
> > achieve the same functionality as in vim.
> 
> Yes I agree.

This patch for vis-motions.c works for me:

@@ -1,3 +1,4 @@
+#include 
 #include 
 #include 
 #include "vis-core.h"
@@ -17,8 +18,12 @@ static char *get_word_at(Text *txt, size_t pos) {
 /** motion implementations */

 static size_t search_word_forward(Vis *vis, Text *txt, size_t pos) {
+   char expr[512];
char *word = get_word_at(txt, pos);
-   if (word && !text_regex_compile(vis->search_pattern, word, 
REG_EXTENDED))
+   if (!word)
+   return pos;
+   snprintf(expr, sizeof(expr), "\\<%s\\>", word);
+   if (!text_regex_compile(vis->search_pattern, expr, REG_EXTENDED))
pos = text_search_forward(txt, pos, vis->search_pattern);
free(word);
return pos;

Should be adapted for search_word_backward accordingly. I also noticed, that the
search order is not permanently stored. When using `#` or `?`, I am used to
still search backwards when pressing `n` and forwards when pressing `N`.

> > - Could you replace the `0` in relativenumber mode with the actual line
> >   number?
> 
> should be implemented now.

Thanks.

> > > The fix is to adjust the cursor position before performing the subsequent
> > > motions similarly to how it is done for text objects with a count.
> > 
> > Hm, maybe changing the imlementation of TO_…/TILL_… to ignore the one
> > character under/after the cursor is less of a workaround?
> 
> But this would break the entering `tX` multiple times use case ...

The only stuff that "breaks" with the following patch to vis-motions.c is when
the cursor is over the `X` in `abcabcXdefdef` and you expect `td` or `Tc` to
move the cursor to the last `d` / first `c` in the line. I don't think it's that
useful to don't move the cursor, if you are directly before `d` and want to move
"till" the next `d`.  The behaviour I am proposing is nonstandard in vim (but
more consistent imho).  Little side-note: The `to` commands can more easily
distinguished from the `till` commands when thinking of them as `find` (`f`
shortcut). They move the cursor above the search char, just like a normal search
would.

@@ -57,7 +62,7 @@ static size_t to(Vis *vis, Text *txt, size_t pos) {
 }

 static size_t till(Vis *vis, Text *txt, size_t pos) {
-   size_t hit = to(vis, txt, pos);
+   size_t hit = to(vis, txt, pos+1);
if (hit != pos)
return text_char_prev(txt, hit);
return pos;
@@ -74,7 +79,7 @@ static size_t to_left(Vis *vis, Text *txt, size_t pos) {
 }

 static size_t till_left(Vis *vis, Text *txt, size_t pos) {
-   size_t hit = to_left(vis, txt, pos);
+   size_t hit = to_left(vis, txt, pos-1);
if (hit != pos)
return text_char_next(txt, hit);
return pos;

--Markus

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Sun, Jan 17, 2016 at 05:28:14PM +0100, Silvan Jegen wrote:
> The command history buffer does not yet work correctly for me but I am
> very glad to see the first version working for some cases already.

Could you give a few more details? What unexpected behaviour did you
encounter. As mentioned elsewhere it is fairly new and still rough
around the edges. 

The main idea is that it is just a regular file with slightly different
default key bindings. Maybe it should be displayed in full size as well
(currently it only expands after pressing ).

> In addition to Markus' items I am missing the following.
> 
> - commandline file completion on TAB key hit (when using `:edit` for example)

I do not like duplicating this shell functionality inside the editor.
The current source tree contains a `vis-open` shell script which
provides basic file system navigation by means of fuzzy matching using
either slmenu or dmenu. It is invoked by default if you open a directory

 :split .

or supply a path containing other shell wildcards such as *, {, or [.

The other mentioned features (as well as the filter and search commands
or more generally any potentially long running task) require some sort
of async task framework which does not block the editor core while
communicating with the spell checker / code completer etc.

Marc

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

> > > - How am I supposed to set my default theme/tabwidth/relativenumber/…
> > > settings?  I could not find the option in config.h.
> > 
> > By changing visrc.lua:
> > 
> >  vis.command('set ')
> 
> Thanks, I missed that in the README. However there should be a few examples. I
> just tried to insert the vis.command in global context and got a SEGFAULT. 
> After
> moving it to the win_open event handler context, it worked. :)

Yes I agree documentation is lacking. Also error reporting is almost
inexistent. We should open a new buffer showing a backtrace when a Lua
error occurs etc.

> > > - In vim I have setup tabs not to display a special "tab" character, but 
> > > to
> > > use a slightly different background color (base02 instead of base03). This
> > > also applies to whitespace at EOL. How could I achieve that with vis 
> > > without
> > > patching every syntax lexer?
> > 
> > At the moment this can not be done easily. The tab replacement symbols are
> > currently hard coded in view.c and there is no distinction made between
> > "regular" whitepace and trailing whitespace.
> > 
> > In the long term it might be a good idea to move the implementation of all
> > these display related things (i.e. :set show tabs newlines spaces, 
> > cursorline,
> > colorcolumn etc.) from the C core into Lua.
> 
> Maybe a global default 'syntax highlighter' applied regardless of file type
> could do the job?

Maybe, yes. However you probably want these features in combination with
regular syntax highlighting. Maybe a layered approach would somehow work

> > > - Using `set show newlines 0` (also for tabs and spaces) does not work.
> > 
> > Use `set show newlines=0` for now.
> 
> Still does not work. After enabling one of the `show` settings, I am unable to
> reset it again. I have to restart vis.

Strange, seems to work fine here.

> > > - What about automatic text wrapping?
> > 
> > Are you referring to the automatic insertion of new lines? Not a big fan.  I
> > prefer an external tool such as fmt(1) which is hooked up to the `=` 
> > operator. 
> 
> I have a pretty wide screen (>250 symbols in default zoom levels), where 
> editing
> long blocks of text becomes much easier with the automatic wrap after 80
> columns. Without it, navigating gets a little tedious without running the
> formater manually each time I have to jump around in the text. Maybe an event
> could be introduced as well here, so you can enter the newline from lua?

Yes maybe that would work. The Lua API is still in its infancy.

> > > - Why do you keep the default vim behaviour of `Y`? Please make it
> > > consistent and just yank until EOL and not the whole line.
> > 
> > Is this really consistent? For example `S` also operates on the whole line 
> > ...
> 
> Thats right, `s` is a little different, since it is an instantaneous action. 
> For
> applying an opperand to the whole current line, there is already the "double"
> shortcut (e.g. `dd`, `yy`, …), so I thing changing Y to only yank until EOL is
> at least making it consistent with D and C. If you want "s until EOL", you
> should use `C`. The only reason for `s` to exist would be to have a shortcut 
> for
> `cl`. `S` can also be done with `cc`.

Ok, I do tend to agree. Changed.

> > >   Also with `<` and `>` in visual mode: It should not loose the visual
> > >   selection, so you can (un)indent the lines multiple levels without using
> > >   `gv` inbetween.
> > 
> > I agree that the current vis behaviour is not ideal. The cursor placement
> > after those shifting operators is off. Furthermore vis does not support any
> > form of visual-repeat hence the dot `.` command is rather useless in this
> > case.
> > 
> > Special casing the operators `<` and `>` would be possible:
> > 
> > …
> > 
> > Not sure if it is the right thing to do though.
> 
> I tried to do it with an alias in config.h, but it was recursive and therefore
> vis froze. (aliasing `>` in visual to `>gv`).

The vis way of doing this would be an alias to `gv`

> Adding something like nonrecursive
> aliasing or allowing to chain two actions together (OPERATOR_SHIFT_… and
> SELECTION_RESTORE) would solve the issue without the hardcoded fix.

This is another part which is underdocumented. As you noticed all mappings
in vis are recursive. Instead of non recursive mappings you can use all the
names of KeyAction as found in main.c to refer to their function by means
of these special keys. This for example allows to completely unmap all core
operators, I don't think this is possible in vim?

> Another possibility would be to implement movements for jumping to the 
> beginning
> or end of the last visual selection.
> 
> I also tried aliasing `>` in visual to `I>>gv` with multi-cursors, but
> they seem to create their own selection so the `gv` at the end does not work 
> as
> I thought it would.

Yes selections are currently per cursor and once the cursor is removed it
together with its selection can not be restored. 

> Basically I don't think 

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Silvan Jegen]

On Sun, Jan 17, 2016 at 07:23:06PM +0100, Marc André Tanner wrote:
> On Sun, Jan 17, 2016 at 05:28:14PM +0100, Silvan Jegen wrote:
> > The command history buffer does not yet work correctly for me but I am
> > very glad to see the first version working for some cases already.
> 
> Could you give a few more details? What unexpected behaviour did you
> encounter. As mentioned elsewhere it is fairly new and still rough
> around the edges. 

I am travelling at the moment but I will get back to you after some more
testing. What I remember is that the only way to open the history was by
hitting the "up" key. The file content that was displayed afterwards
contained some characters I entered before pressing the "up" key which
confused me somewhat. More testing from my part is needed.


> The main idea is that it is just a regular file with slightly different
> default key bindings. Maybe it should be displayed in full size as well
> (currently it only expands after pressing ).
> 
> > In addition to Markus' items I am missing the following.
> > 
> > - commandline file completion on TAB key hit (when using `:edit` for 
> > example)
> 
> I do not like duplicating this shell functionality inside the editor.

I agree. I was actually thinking about using 'ls' output for completion
but I don't think that is the best way.


> The current source tree contains a `vis-open` shell script which
> provides basic file system navigation by means of fuzzy matching using
> either slmenu or dmenu. It is invoked by default if you open a directory
> 
>  :split .
> 
> or supply a path containing other shell wildcards such as *, {, or [.

I have seen the script but I was not sure how to use it from vis itself.
Being able to open a file to edit in the same vis instance using
"vis-open" (using the :edit command) would be welcome. I will look into
it when I have I access to my desktop.


> The other mentioned features (as well as the filter and search commands
> or more generally any potentially long running task) require some sort
> of async task framework which does not block the editor core while
> communicating with the spell checker / code completer etc.

>From a usability standpoint I still think that it will be hard to
show results asynchronously at least in case of the code completion
functionality. You don't want your cursor to undo any movement you did
while waiting for the code completion results to be displayed for example.

Aspell and ispell will just wait for your input and then return the
results after processing the input. The communication between vis and
the spell checkers is thus very restricted for each invocation. I am not
yet sure how to process and display [ai]spell results in the simplest
and most effective way however (especially if one wants to do continuous
spell checking while typing).

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Sat, Jan 16, 2016 at 07:09:26PM +0100, Markus Teich wrote:
> Marc André Tanner wrote:
> > Did you (or anyone else) try it? First impressions? Which features did you
> > miss the most?
> 
> Heyho Marc,
> 
> I built the standalone version and tried some stuff. I also went through my
> vimrc to find any features I would like to use. Here are my comments in no
> particular order.

Thanks! Exactly the kind of constructive feedback I was looking for.

> - Why did you choose to use full black instead of the base03 color from
>   solarized?
> 
> - Even after "fixing" the above the colors don't look like solarized in any 
> way.
>   If you don't know about this yet, I can provide a screenshot.

Yes I noticed this too and it is the reason why full black was used (to increase
the contrast). As vis currently uses curses there seems to be no clean way to
support true colors[0]? What happens at the moment is that the given 24bit color
is converted to the closest color of the terminal 256 color palette. This color
conversion code was imported from tmux.

Strictly speaking we do not need to display many colors we just want to specify
them as RGB values. Curses provides a init_color(3) API to change the
defintion of the color palette. However I'm not sure how many terminals actually
support these color chaning capability.

Anyway up until now I didn't realize solarized had a 256 color degraded
version[1,2]. I changed the default 256 color theme to that. Is it better now?

> - Could you make `~` an instant action? Changing stuff to upper xor lower case
>   can already be done by `gu` and `gU` and switching case on more than one
>   character rarely makes sense. Also you could use visual mode for that.

I personally don't really care, but it was requested before. Changed.

> - How am I supposed to set my default theme/tabwidth/relativenumber/… 
> settings?
>   I could not find the option in config.h.

By changing visrc.lua:

 vis.command('set ')

> - In vim I have setup tabs not to display a special "tab" character, but to 
> use
>   a slightly different background color (base02 instead of base03). This also
>   applies to whitespace at EOL. How could I achieve that with vis without
>   patching every syntax lexer?

At the moment this can not be done easily. The tab replacement symbols are
currently hard coded in view.c and there is no distinction made between 
"regular"
whitepace and trailing whitespace.

In the long term it might be a good idea to move the implementation of all
these display related things (i.e. :set show tabs newlines spaces, cursorline,
colorcolumn etc.) from the C core into Lua.

> - Using `set show newlines 0` (also for tabs and spaces) does not work.

Use `set show newlines=0` for now.

> - I miss the vim-like commandline shortcuts (`:e` instead of `:edit`)

In general this is already implemented i.e. a shortest unique prefix
match is used. The problem was that `:e` was ambiguous it could either
refer to `:edit` or `:earlier`. I have now added an explicit alias
to break the tie.

> - What about automatic text wrapping?

Are you referring to the automatic insertion of new lines? Not a big fan.
I prefer an external tool such as fmt(1) which is hooked up to the `=`
operator. 

> - Why do you keep the default vim behaviour of `Y`? Please make it consistent
>   and just yank until EOL and not the whole line.

Is this really consistent? For example `S` also operates on the whole line ...

>   Also with `<` and `>` in
>   visual mode: It should not loose the visual selection, so you can (un)indent
>   the lines multiple levels without using `gv` inbetween.

I agree that the current vis behaviour is not ideal. The cursor placement
after those shifting operators is off. Furthermore vis does not support
any form of visual-repeat hence the dot `.` command is rather useless in
this case.

Special casing the operators `<` and `>` would be possible:

diff --git a/vis.c b/vis.c
index ba220c0..1474f96 100644
--- a/vis.c
+++ b/vis.c
@@ -546,7 +546,10 @@ void action_do(Vis *vis, Action *a) {
} else if (vis->mode == _modes[VIS_MODE_OPERATOR_PENDING]) {
mode_set(vis, vis->mode_prev);
} else if (vis->mode->visual) {
-   vis_mode_switch(vis, VIS_MODE_NORMAL);
+   if (a->op != _operators[VIS_OP_SHIFT_LEFT] &&
+   a->op != _operators[VIS_OP_SHIFT_RIGHT]) {
+   vis_mode_switch(vis, VIS_MODE_NORMAL);
+   }
}
text_snapshot(txt);
vis_draw(vis);

Not sure if it is the right thing to do though.
 
> - `*` does not behave the same as in vim. When using star on `view->bla` it
>   should search for `\`, but it also found `view_draw`, so there seems 
> to
>   be something wrong with the word delimiters when used by `*` (searching for
>   `\` produces the expected result.

There are no word delimiters used 

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Silvan Jegen]

Hi Marc

I am enjoying vis a lot but the following missing functionality as
detrimental to my enjoyment...

On Sat, Jan 16, 2016 at 07:09:26PM +0100, Markus Teich wrote:
> Marc André Tanner wrote:
> > Did you (or anyone else) try it? First impressions? Which features did you
> > miss the most?
>
> [...] 
>
> - What about word/file/line completion in insert mode?

I would like that too. The infrastructure of an implementation could
potentially be used for code completion too (I know it's not very popular
around here though).

The command history buffer does not yet work correctly for me but I am
very glad to see the first version working for some cases already.

In addition to Markus' items I am missing the following.

- commandline file completion on TAB key hit (when using `:edit` for example)

- spell checking (using an external spell checker of course)

- ctags integration



Cheers,

Silvan

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Heyho Marc,

Marc André Tanner wrote:
> On Sat, Jan 16, 2016 at 07:09:26PM +0100, Markus Teich wrote:
> > - Why did you choose to use full black instead of the base03 color from
> > solarized?
> > 
> > - Even after "fixing" the above the colors don't look like solarized in any
> > way.  If you don't know about this yet, I can provide a screenshot.
> 
> Yes I noticed this too and it is the reason why full black was used (to
> increase the contrast). As vis currently uses curses there seems to be no
> clean way to support true colors[0]? What happens at the moment is that the
> given 24bit color is converted to the closest color of the terminal 256 color
> palette. This color conversion code was imported from tmux.
> 
> Strictly speaking we do not need to display many colors we just want to
> specify them as RGB values. Curses provides a init_color(3) API to change the
> defintion of the color palette. However I'm not sure how many terminals
> actually support these color chaning capability.
> 
> Anyway up until now I didn't realize solarized had a 256 color degraded
> version[1,2]. I changed the default 256 color theme to that. Is it better now?

Actually it did not help. Here is a screenshot of the new standalone build of
vis with the solarized.lua file opened in st:
http://fs.tum.de/~teichm/Media/vis_wrong_colors.png

My st already has the solarized theme set up for the first 16 color slots, so
setting theme to default-16 kind of works (background color is base02 instead of
base03, but I might figure that out myself).

> > - Could you make `~` an instant action? Changing stuff to upper xor lower
> > case can already be done by `gu` and `gU` and switching case on more than
> > one character rarely makes sense. Also you could use visual mode for that.
> 
> I personally don't really care, but it was requested before. Changed.

Thanks.

> > - How am I supposed to set my default theme/tabwidth/relativenumber/…
> > settings?  I could not find the option in config.h.
> 
> By changing visrc.lua:
> 
>  vis.command('set ')

Thanks, I missed that in the README. However there should be a few examples. I
just tried to insert the vis.command in global context and got a SEGFAULT. After
moving it to the win_open event handler context, it worked. :)

> > - In vim I have setup tabs not to display a special "tab" character, but to
> > use a slightly different background color (base02 instead of base03). This
> > also applies to whitespace at EOL. How could I achieve that with vis without
> > patching every syntax lexer?
> 
> At the moment this can not be done easily. The tab replacement symbols are
> currently hard coded in view.c and there is no distinction made between
> "regular" whitepace and trailing whitespace.
> 
> In the long term it might be a good idea to move the implementation of all
> these display related things (i.e. :set show tabs newlines spaces, cursorline,
> colorcolumn etc.) from the C core into Lua.

Maybe a global default 'syntax highlighter' applied regardless of file type
could do the job?

> > - Using `set show newlines 0` (also for tabs and spaces) does not work.
> 
> Use `set show newlines=0` for now.

Still does not work. After enabling one of the `show` settings, I am unable to
reset it again. I have to restart vis.

> > - I miss the vim-like commandline shortcuts (`:e` instead of `:edit`)
> 
> In general this is already implemented i.e. a shortest unique prefix match is
> used. The problem was that `:e` was ambiguous it could either refer to `:edit`
> or `:earlier`. I have now added an explicit alias to break the tie.

Thanks.

> > - What about automatic text wrapping?
> 
> Are you referring to the automatic insertion of new lines? Not a big fan.  I
> prefer an external tool such as fmt(1) which is hooked up to the `=` 
> operator. 

I have a pretty wide screen (>250 symbols in default zoom levels), where editing
long blocks of text becomes much easier with the automatic wrap after 80
columns. Without it, navigating gets a little tedious without running the
formater manually each time I have to jump around in the text. Maybe an event
could be introduced as well here, so you can enter the newline from lua?

> > - Why do you keep the default vim behaviour of `Y`? Please make it
> > consistent and just yank until EOL and not the whole line.
> 
> Is this really consistent? For example `S` also operates on the whole line ...

Thats right, `s` is a little different, since it is an instantaneous action. For
applying an opperand to the whole current line, there is already the "double"
shortcut (e.g. `dd`, `yy`, …), so I thing changing Y to only yank until EOL is
at least making it consistent with D and C. If you want "s until EOL", you
should use `C`. The only reason for `s` to exist would be to have a shortcut for
`cl`. `S` can also be done with `cc`.

> >   Also with `<` and `>` in visual mode: It should not loose the visual
> >   selection, so you can (un)indent the lines multiple levels without 

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Fri, Jan 15, 2016 at 10:14:25PM -0800, Eric Pruitt wrote:
> On Fri, Jan 15, 2016 at 04:56:37PM +0100, Marc André Tanner wrote:
> > Did you (or anyone else) try it? First impressions? Which features did
> > you miss the most?
> 
> I used Vis a while back when the project was still in its infancy, but I
> can't compile the current release without fetching tarballs manually
> (which I have been too lazy to do).

You may try "make local" to fetch & compile libtermkey and lua.
Or even "make standalone" to build a self contained binary statically
linked against musl.

> You're using libtermkey which is
> dead according to the project's own page and no longer packaged by my
> Linux distro (Debian) as a result

This came up before[0]. libtermkey offers a sensible API and is reasonably
simple (it consists of ~3 C files). The last release was in October and
the latest commit 18 days ago. The replacement library, intended to provide
similar functionality to curses, is not ready yet. Also at least Debian
testing and unstable seem to have it packaged[1].
 
> and at the same time, the project
> requires Lua 5.2+ which is too new to be in the latest Debian release.

Supporting Lua 5.1 might be interesting because it is the last release
fully supported by luajit. However if we conclude this is not worth the
effort then depending on the latest Lua release 5.3 might make sense ...

[0] https://github.com/martanne/vis/issues/79
[1] 
https://packages.debian.org/search?keywords=libtermkey=names=all=all

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Eric Pruitt]

On Sat, Jan 16, 2016 at 03:31:21PM +0100, Marc André Tanner wrote:
> This came up before[0]. libtermkey offers a sensible API and is reasonably
> simple (it consists of ~3 C files). The last release was in October and
> the latest commit 18 days ago. The replacement library, intended to provide
> similar functionality to curses, is not ready yet. Also at least Debian
> testing and unstable seem to have it packaged[1].

I always run Debian stable. Many moons ago, I ran a Franken-Debian
installation that was a mixture of testing and unstable, and it was a
very unpleasant experience.

> > and at the same time, the project
> > requires Lua 5.2+ which is too new to be in the latest Debian release.
>
> Supporting Lua 5.1 might be interesting because it is the last release
> fully supported by luajit. However if we conclude this is not worth the
> effort then depending on the latest Lua release 5.3 might make sense ...

Someone pointed out to me off list that I misread twice -- 5.2 is in
fact available for Debian stable.

> You may try "make local" to fetch & compile libtermkey and lua.
> Or even "make standalone" to build a self contained binary statically
> linked against musl.

I tried this and ultimately the build failed because the linker can't
find libncurses despite libncurses-dev being installed, so more
debugging is required. I also had to install libtool-bin, but libtool
isn't mentioned in the README as a dependency unless I am overlooking
something again.

Eric

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Markus Teich]

Marc André Tanner wrote:
> Did you (or anyone else) try it? First impressions? Which features did you
> miss the most?

Heyho Marc,

I built the standalone version and tried some stuff. I also went through my
vimrc to find any features I would like to use. Here are my comments in no
particular order.

- Why did you choose to use full black instead of the base03 color from
  solarized?

- Even after "fixing" the above the colors don't look like solarized in any way.
  If you don't know about this yet, I can provide a screenshot.

- Could you make `~` an instant action? Changing stuff to upper xor lower case
  can already be done by `gu` and `gU` and switching case on more than one
  character rarely makes sense. Also you could use visual mode for that.

- How am I supposed to set my default theme/tabwidth/relativenumber/… settings?
  I could not find the option in config.h.

- In vim I have setup tabs not to display a special "tab" character, but to use
  a slightly different background color (base02 instead of base03). This also
  applies to whitespace at EOL. How could I achieve that with vis without
  patching every syntax lexer?

- Using `set show newlines 0` (also for tabs and spaces) does not work.

- I miss the vim-like commandline shortcuts (`:e` instead of `:edit`)

- What about automatic text wrapping?

- Why do you keep the default vim behaviour of `Y`? Please make it consistent
  and just yank until EOL and not the whole line. Also with `<` and `>` in
  visual mode: It should not loose the visual selection, so you can (un)indent
  the lines multiple levels without using `gv` inbetween.

- `*` does not behave the same as in vim. When using star on `view->bla` it
  should search for `\`, but it also found `view_draw`, so there seems to
  be something wrong with the word delimiters when used by `*` (searching for
  `\` produces the expected result. Also the search string generated by
  pressing `*` should be added to the search history.

- Is hlsearch planned?

- I frequently use C-a and C-x to do basic addition/subtraction in vim.

- Any possibility to hook up a setting depending on the currently active mode? I
  like to have relativenumber in normal+visual mode while having normal line
  numbers in insert mode. Changing all the bindings in config.h seems a little
  tedious.

- Could you replace the `0` in relativenumber mode with the actual line number?
  Moving up/down 0 lines is not that hard without having the `0` in front. ;)

- Could you explain the concept behind the commandline history? When I used it
  to run a slightly changed previous command, the history was changed as well.

- Why the `:saveas` command? Couldn't you just use an optional argument to `:w`?

- Are you planning to implement buffers / having multiple files open at the same
  time? I often use the `switch to last used buffer` feature of vim.

- I noticed `d2tX` is not working as it is in vim. Is there a way to achieve the
  same deletion within vis in >= 4 keystrokes or is this also the "bug"
  mentioned in the README?

- What about word/file/line completion in insert mode?

- Why you no implement `g?`? ;)

I can probably help implementing a few of the mentioned features, but I would
like to hear your oppinion on them first. Great work so far, I planned to check
vis out quite a while ago and finally found the time.

--Markus

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

On Thu, Dec 31, 2015 at 07:59:37PM +0100, Connor Lane Smith wrote:
> I think this is pushing it for a 2015 release. But I'll be sure to
> give it a go asap, 2016. :)

Did you (or anyone else) try it? First impressions? Which features did
you miss the most?

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Eric Pruitt]

On Fri, Jan 15, 2016 at 04:56:37PM +0100, Marc André Tanner wrote:
> Did you (or anyone else) try it? First impressions? Which features did
> you miss the most?

I used Vis a while back when the project was still in its infancy, but I
can't compile the current release without fetching tarballs manually
(which I have been too lazy to do). You're using libtermkey which is
dead according to the project's own page and no longer packaged by my
Linux distro (Debian) as a result, and at the same time, the project
requires Lua 5.2+ which is too new to be in the latest Debian release. I
find this to be an amusing juxtaposition.

Eric

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Eric Pruitt]

On Fri, Jan 15, 2016 at 10:14:25PM -0800, Eric Pruitt wrote:
> [...] requires Lua 5.2+ which is too new to be in the latest Debian
> release.

I take that back; I just noticed that Lua is listed as an optional
dependency.

Eric

[dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Marc André Tanner]

Hi,

I'm pleased to announce the first release of vis, a vim-like editor:

 http://www.brain-dump.org/projects/vis/vis-0.1.tar.gz

What started out with curiosity for an interesting data structure
evolved into my main text editor.

Some of vis' properties which might be interesting to some of you:

 - built around a modern, maintainable, legacy free, relatively
   small C core which uses Lua for scriptability. The goal is to
   provide a solid base that should be fun to hack on and encourage
   experimentation with various ideas.

 - large file support, the core data structure used for text
   management is designed to efficiently handle arbitrary data.

 - native multiple cursor/selection support (integration into
   the vi(m) workflow can certainly still be improved).

 - convenient and efficient syntax highlighting based on
   Parsing Expression Grammars using Lua.

 - lightweight footprint ideal for resource constraint systems.

In the future I would like to improve the command prompt by treating
it as a regular file and experiment with a client/server architecture.
I also hope to explore features based on the append only nature of
the underlying piece chain data structure.

To get you started you will need the curses and libtermkey headers
and if you want syntax highlighting also Lua and LPeg (see the README
for details).

 $ git clone https://github.com/martanne/vis
 $ $EDITOR config.mk
 $ make
 $ VIS_PATH=. ./vis config.h

Comments and patches welcome.

Cheers,
Marc

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Connor Lane Smith]

I think this is pushing it for a 2015 release. But I'll be sure to
give it a go asap, 2016. :)

cls