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 <Up>).
>
> > 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).
