Re: [hackers][vis][RFC][PATCH 0/2] Suggestion for basic autocomplete functionality
Hi Silvan, After some refactoring the functionality of your patches should now be merged, thanks! It should now also work with slmenu, I guess you only used it with dmenu? The behavior could still be improved. It would be handy to pass the prefix as the initial prompt value to the menu tool which would start with the filter applied. Instead of removing the prefix from the returned text (as you did with sed(1)), we would replace the whole word/prefix with whatever is returned from the external process. Conceptually the syntax would become: $ extract_words | grep '^prefix' | sort | uniq | slmenu 'prefix' or even: $ extract_words | sort | uniq | slmenu 'prefix' I'm considering importing slmenu into the vis repository as vis-menu and implementing the necessary changes. This would ease packaging by distributions and make vis behave always the same independent of whether it is run in a X11 environment. It would however also make it more difficult for users who prefer dmenu, opinions? -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][RFC][PATCH 0/2] Suggestion for basic autocomplete functionality
On Mon, May 16, 2016 at 01:00:57PM +0200, Silvan Jegen wrote: > Heyhey > > I have implemented basic autocomplete functionality by sending the text > at cursor position as a context to shell commands and dmenu. The user > then chooses the autocompletion text he wants to use in dmenu which is > then inserted at cursor position. > > Ideally the same approach should be used for code completion by sending > some context to a code completion daemon (like gocode[0] for example). The > daemon's output can then be sent to dmenu and selected by the user. > > The patches are still rough but I did not want to invest more time > without knowing if such an approach would be considered for inclusion > or not. Let me know what you think. Just a couple of comments from glancing over the patches (I will have to take a closer look once I have more time): - use vis-menu (part of lattest git) as a wrapper around dmenu and slmenu - this should also work for unsaved or unnamed files, instead of using `cat filename` you should pipe the current file content to the external application - completion should probably be based on the primary (view_cursors_primary_get) not the the first cursor (view_cursors) Thanks, Marc -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][PATCH] Handle quote matching in its own function
On Mon, Feb 15, 2016 at 06:22:58PM +0100, Silvan Jegen wrote: > On Mon, Feb 15, 2016 at 05:50:12PM +0100, Marc André Tanner wrote: > > On Mon, Feb 15, 2016 at 04:01:48PM +0100, Silvan Jegen wrote: > > > > [...] > > > > What would be more interesting is to add a way to define motions and > > text objects in Lua. Integration with the LPeg based lexers should > > then be relatively easy ... > > That would mean that you would call out to lua each time you want to > use one of these motions/objects, if I understand correctly. Yes. The latest commits add the necessary infrastructure to implement motions and text objects as Lua functions. Documentation is currently sparse, but there is an example "ii" is a text object based on syntax tokens. Roughly speaking it should match everything that is colored the same way as the current cursor position. Suggestions for a more suitable key binding are also welcome ... -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][PATCH] Handle quote matching in its own function
On Mon, Feb 15, 2016 at 04:01:48PM +0100, Silvan Jegen wrote: > Unlike other paired characters neither of the quote types allow for the > search for the closing occurrence to be optimised because there is no > directionality implied. This means theoretically we always have to start > from the beginning of a file to check whether all the quotes until the > occurrence of the one in question have been properly closed before we > can say which one is the closing occurrence of the quote. > > This is the justification for introducing this new function that > duplicates some code. Instead of searching from the beginning of a > file we start our search for the corresponding quote character at > an arbitrarily chosen offset of 500 bytes before the occurrence in > question. > --- > Consider this to be a bug report for a pet peeve of mine. When you > position the cursor at line 797 of vis.c in vis on the quote after > __DATE__ the quote highlighting will be wrong. The text motion for > "select inner quote" is wrong as well but I think it makes more sense > there to select the text between the quotes instead of selecting nothing > only because the quotes are not actually corresponding to each other. > > This patch fixes the highlighting case but it may be overkill for such > marginal issue. Yes it is. The highlighting feature is just a convenience which should work most of the time. As you noted making this work correctly for all cases would need integration with a lexer. Simply counting a couple of quotes like it is currently done will only work for the common case. Things which are not handled correctly include: - escaped quotes as in "some \"string\"" - quotes can also appear on their own, an example from your patch (case '"':). For single quotes this is frequently the case with english comments. What would be more interesting is to add a way to define motions and text objects in Lua. Integration with the LPeg based lexers should then be relatively easy ... -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][PATCH] Implement a first version of the 'gf' family of commands
On Mon, Feb 08, 2016 at 11:02:03AM +0100, Silvan Jegen wrote: > I assume you mean that you're not sure if this functionality should go > in at all? Yes vis is becoming bloated ;-) Anyway I merged it, does it work for your use case? Any other important pending issues? I would like to do another release fairly soon ... Thanks. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][PATCH] Implement a first version of the 'gf' family of commands
The attached patches on top of current git HEAD should provide the same
functionality you provided.
Not sure whether they should be merged. Could be useful when displaying
grep search results in a window as in:
:| grep something *.c
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
>From 76426e46fe2936e22f517385d057a9445d3fe67c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marc=20Andr=C3=A9=20Tanner?=
Date: Sun, 7 Feb 2016 16:06:31 +0100
Subject: [PATCH 1/2] vis: export vis_window_closable
---
vis-cmds.c | 10 ++
vis.c | 10 ++
vis.h | 3 +++
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/vis-cmds.c b/vis-cmds.c
index 3f612f4..b3dad5b 100644
--- a/vis-cmds.c
+++ b/vis-cmds.c
@@ -429,19 +429,13 @@ static bool cmd_open(Vis *vis, Filerange *range, enum CmdOpt opt, const char *ar
return openfiles(vis, &argv[1]);
}
-static bool is_view_closeable(Win *win) {
- if (!text_modified(win->file->text))
- return true;
- return win->file->refcount > 1;
-}
-
static void info_unsaved_changes(Vis *vis) {
vis_info_show(vis, "No write since last change (add ! to override)");
}
static bool cmd_edit(Vis *vis, Filerange *range, enum CmdOpt opt, const char *argv[]) {
Win *oldwin = vis->win;
- if (!(opt & CMD_OPT_FORCE) && !is_view_closeable(oldwin)) {
+ if (!(opt & CMD_OPT_FORCE) && !vis_window_closable(oldwin)) {
info_unsaved_changes(vis);
return false;
}
@@ -463,7 +457,7 @@ static bool has_windows(Vis *vis) {
}
static bool cmd_quit(Vis *vis, Filerange *range, enum CmdOpt opt, const char *argv[]) {
- if (!(opt & CMD_OPT_FORCE) && !is_view_closeable(vis->win)) {
+ if (!(opt & CMD_OPT_FORCE) && !vis_window_closable(vis->win)) {
info_unsaved_changes(vis);
return false;
}
diff --git a/vis.c b/vis.c
index b65724c..42bc0a0 100644
--- a/vis.c
+++ b/vis.c
@@ -284,6 +284,12 @@ bool vis_window_new(Vis *vis, const char *filename) {
return true;
}
+bool vis_window_closable(Win *win) {
+ if (!text_modified(win->file->text))
+ return true;
+ return win->file->refcount > 1;
+}
+
void vis_window_close(Win *win) {
Vis *vis = win->vis;
if (vis->event && vis->event->win_close)
@@ -1090,6 +1096,10 @@ View *vis_view(Vis *vis) {
return vis->win->view;
}
+Win *vis_window(Vis *vis) {
+ return vis->win;
+}
+
Text *vis_file_text(File *file) {
return file->text;
}
diff --git a/vis.h b/vis.h
index 3bcd9c7..eb84695 100644
--- a/vis.h
+++ b/vis.h
@@ -67,6 +67,8 @@ void vis_suspend(Vis*);
bool vis_window_new(Vis*, const char *filename);
/* reload the file currently displayed in the window from disk */
bool vis_window_reload(Win*);
+/* check whether closing the window would loose unsaved changes */
+bool vis_window_closable(Win*);
/* close window, redraw user interface */
void vis_window_close(Win*);
/* split the given window. changes to the displayed text will be reflected
@@ -405,6 +407,7 @@ bool vis_signal_handler(Vis*, int signum, const siginfo_t *siginfo, const void *
/* TODO: expose proper API to iterate through files etc */
Text *vis_text(Vis*);
View *vis_view(Vis*);
+Win *vis_window(Vis*);
Text *vis_file_text(File*);
const char *vis_file_name(File*);
--
2.1.4
>From b02aff69f90ffb5fe214d10e11386cadab2df55c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marc=20Andr=C3=A9=20Tanner?=
Date: Sun, 7 Feb 2016 16:07:44 +0100
Subject: [PATCH 2/2] vis: implement gf and gf to open filename under
cursor
Based on a patch by Silvan Jegen.
---
config.def.h | 2 ++
main.c | 40
2 files changed, 42 insertions(+)
diff --git a/config.def.h b/config.def.h
index 47ed326..774871b 100644
--- a/config.def.h
+++ b/config.def.h
@@ -233,6 +233,8 @@ static const KeyBinding bindings_normal[] = {
{ "gP", ACTION(PUT_BEFORE_END) },
{ "~", ALIAS("l") },
{ "", ALIAS("$") },
+ { "gf", ACTION(OPEN_FILE_UNDER_CURSOR) },
+ { "gf",ACTION(OPEN_FILE_UNDER_CURSOR_NEW_WINDOW) },
{ 0 /* empty last element, array terminator */ },
};
diff --git a/main.c b/main.c
index c3ae7a3..21a1066 100644
--- a/main.c
+++ b/main.c
@@ -111,6 +111,8 @@ static const char *unicode_info(Vis*, const char *keys, const Arg *arg);
static const char *percent(Vis*, const char *keys, const Arg *arg);
/* either increment (arg->i > 0) or decrement (arg->i < 0) number under cursor */
static const char *number_increment_decrement(Vis*, const char *keys, const Arg *arg);
+/* open a filename under cursor in same (!arg->b) or new (arg->b) window */
+static const char *open_file_under
Re: [hackers] [vis] [PATCH] fix {, }, (, ) movements
On Wed, Feb 03, 2016 at 01:07:00PM +0100, Markus Teich wrote:
> - simplify text_line_empty_{prev,next}
I applied the patch, but for now left out those "simplifications".
Except for the return value if no empty line is found these changes
do not change the functionality, right?
There was also a lot of code churn from unrelated cleanups, let
me know if they broke anything ...
As for the strange cursor placement you noticed. Yes it is a display
bug affecting movements just out of the current view port. For example
try inserting a new line in insert mode when you are at the end of the
last line i.e. LA
See also[1], cff6ed5b and 2f4b69cc.
Thanks,
Marc
[1] https://github.com/martanne/vis/issues/148#issuecomment-172090470
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][PATCH] Implement a first version of the 'gf' family of commands
On Wed, Feb 03, 2016 at 09:22:19AM +0100, Silvan Jegen wrote: > On Tue, Feb 2, 2016 at 11:18 PM, Marc André Tanner > wrote: > > Instead of introducing these one should write a > > > > Filerange text_object_filename(Text *txt, size_t pos) > > > > which would also take care of any needed offsets. Also I'm not sure > > whether using the "customword" functions is a good idea due to their > > behavior if you are already at the start/end of the word. > > Yes, their behavior surprised me. I will look into implementing that function. Well they also need to work if you are already on the first/last character of a word which is not what you want in this case. Checkout text_object_range it should apply to your use case. > > Maybe the actual file opening should be implemented using the :edit > > command via vis_cmd(...) this would also take care about detecting > > unsaved changes etc. > > That's what I wanted to do at first but then I saw that > "info_unsaved_changes" would show "... (add ! to override)" which does > not make sense. I will think about how to deal with that. Then rename/export is_view_closeable from vis-cmds.c to something like vis_window_closable and use it from main.c. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers] [vis] [PATCH] fix {, }, (, ) movements
On Tue, Feb 02, 2016 at 10:14:52PM +0100, Markus Teich wrote:
> - Split the functions, so the algorithms are more clear
> - Paragraph movements work backwards
> - Paragraph movements work consistently with \r\n line breaks always placing
> the
> cursor on the first character of the first empty line before/after the
> paragraph
> - Sentence movements now work better at BOF/EOF
> - save a few lines of code
Thanks for cleaning up this mess. This sort of thing would really
benefit from some sort of testsuite. In principle there exists
basic infrastructure to compare behaviour with vim in the "test"
branch. The the test/vim subdirectory would be a starting point
for anybody interested ...
Did you also consider implementing text_paragraph_{next,prev} by
skipping to actual content i.e. a loop while (c == '\n' || c == '\r')
followed by a call to text_line_empty_{next,prev}?
I think this should work, but maybe I'm missing something?
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][PATCH] Implement a first version of the 'gf' family of commands
On Mon, Feb 01, 2016 at 09:55:32PM +0100, Silvan Jegen wrote:
> There are still a lot of rough edges. We don't change the jumplist for
> example, which means that we won't be able to jump back to the old
> file.
The jumplist is almost inexistent anyway, for starters it is
currently only local to the current file.
A few remarks about the implementation below ...
> + [VIS_ACTION_OPEN_FILE_UNDER_CURSOR] = {
> + "open-file-under-cursor",
> + "Open file under the cursor",
> + call, { .f = vis_open_file }
> + },
> + [VIS_ACTION_OPEN_FILE_UNDER_CURSOR_NEW_WINDOW] = {
> + "open-file-under-cursor-new_window",
> + "Open file under the cursor in a new window",
> + call, { .f = vis_open_file_new_window }
> + },
Instead of adding new functions to vis.[ch] and using indirection via
"call", add one "open_file_under_cursor" function to main.c. This
function should inspect its arg->b parameter and depending on that
open the new file either in the current or a new window.
> +int is_filename_boundry(int c) {
> + return isspace(c) || (c == ';' ||
> + c == '"' || c == '\'' );
Should be static, funny indentation, useless parenthesis?
> +size_t text_filename_start_prev(Text *txt, size_t pos) {
> + return text_customword_start_prev(txt, pos, is_filename_boundry);
> +}
> +
> +size_t text_filename_end_next(Text *txt, size_t pos) {
> + return text_customword_end_next(txt, pos, is_filename_boundry);
> +}
Instead of introducing these one should write a
Filerange text_object_filename(Text *txt, size_t pos)
which would also take care of any needed offsets. Also I'm not sure
whether using the "customword" functions is a good idea due to their
behavior if you are already at the start/end of the word.
Maybe the actual file opening should be implemented using the :edit
command via vis_cmd(...) this would also take care about detecting
unsaved changes etc.
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers] [vis] [PATCH] Rename stderr field to err
On Sun, Jan 31, 2016 at 05:36:49PM +0100, Markus Teich wrote: > The name `stderr` was confused by the compiler with the following defines: Thanks, applied. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][PATCH] Don't use an offset of 1 for the 'L' command by default
Thanks for the patch! I think I fixed the issue in a slightly different way. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][PATCH] Use VisMotionType enum consistently
I agree this is a bit of a mess. The current code assumes that: LINEWISE == VIS_MOTIONTYPE_LINEWISE && CHARWISE == VIS_MOTIONTYPE_CHARWISE and that the values are distinct from the other flags. However your patch is the wrong way around. The idea was to only expose the the char / linewise properties in the public API as the other flags are implementation details. An improvement would probably be to initialize LINEWISE and CHARWISE in vis-core.h with the constants from vis.h. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers][vis][PATCH] Make normal mode 'S' behave like in Vim
On Tue, Dec 15, 2015 at 07:35:04PM +0100, Silvan Jegen wrote:
> + { "S", ALIAS("^c$")},
Thanks, I applied the patch because it improves the common case of
changing only one line. However it breaks count handling i.e.
something like "3S" will only affect the current line. Also Vim
seems to behave more like "g0c$", however I personally find your
version more useful (for a single line) as it preserves indentation.
Notice that "cc" without a count is still broken. Maybe the best
solution would be to check within the change operator whether the
range is linewise and if so insert a line break after the deletion.
This should result in the desired behaviour when given a count.
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers] dvtm: fix Mod-C and eliminate redundant shell process
On Tue, Nov 24, 2015 at 10:19:34AM -0500, Greg Reagle wrote: > See attached. Thanks committed. Could you please confirm that my clean up patch did not break anything? Thanks -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [hackers] [dvtm] Command keys in status bar patch
On Fri, Oct 02, 2015 at 01:38:14PM -0400, Ross Mohn wrote: > The attached patch is to display command keypresses in the status bar > while a multiple keypress command is being entered. Almost all commands > in dvtm begin with MOD, so require multiple keypresses. Command keys are > displayed as they are pressed, and appear between the layout symbol and > the status text. The keys are cleared from the status bar after the > final key of a command is pressed, or if the key combination is not > bound to a command. For example, if your MOD is set to ^G and you are > toggling the view of tag 4, it first displays '^g' after you press MOD, > then '^gV' after you press 'V', and then is cleared after you complete > the command by pressing '4'. Please review. Thanks, I will try it out and see whether I like it. Otherwise we could also add it to the patches section. I would place curly braces around the while block. Also maybe drawbar should reposition the cursor in the selected window (yes the (re)drawing code is a bit of a mess). -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [hackers] [dvtm] pertag patch addition
On Mon, Oct 05, 2015 at 03:43:34PM -0400, Ross Mohn wrote: > I've updated my pertag patch for dvtm so that it now includes the > runinall setting, as well. The patch is also available here: > http://waxandwane.org/dvtm.html Thanks, for now I've added a patches section to the README where your page is referenced. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [hackers] [abduco] [PATCH] Allow squashing of command line flags together
On Fri, Jul 31, 2015 at 10:17:48AM +1200, David Phillips wrote: > Currently, abduco only supports command line flags kept separate, eg > `abduco -c -f foo bar`. This patch changes the parser to treat `-abc` > as being equal to `-a -b -c`, effectively allowing options to be > 'squashed' together. This would mean `abduco -c -f foo bar` could > equally be expressed as `abduco -cf foo bar`. > > As an additional note, I had a play around with switching to getopt > rather than reinventing the wheel as abduco currently does. I could > submit that patch also/instead if it would be preferred over this one. Yes please also submit the getopt based one. From a quick glance the one you posted probably has issues handling the -e option which takes an argument (and hence advances the arg variable). -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [hackers] [dvtm] [PATCH] Redraw border with URGENT_ATTR as soon as possible
On Wed, Aug 05, 2015 at 10:08:53PM -0300, Marcel Rodrigues wrote:
> When a visible window other than the selected one receives a bell
> ('\a'), I expect its border to be redrawn immediately with the
> corresponding attributes (URGENT_ATTR). Currently this does not
> happen: the border will remain the same until draw_border() is
> eventually called as a result of other events, such as layout
> changing. The following patch is intended to fix this:
Thanks, applied!
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [hackers] [PATCH][vis] Change op_put to repeat put operation count times
On Thu, Jul 30, 2015 at 09:14:06PM +0200, Silvan Jegen wrote: > On Thu, Jul 30, 2015 at 06:51:21PM +0200, Marc André Tanner wrote: > > On Wed, Jul 29, 2015 at 08:52:07PM +0200, Silvan Jegen wrote: > > > This is the quick-and-dirty way to implement a feature I miss from Vim. > > > > Thanks. Yes the count/repetition code needs an overhaul. I'm not sure > > whether it makes sense to move it into the operator implementation > > themselves though. Feels wrong. Also there are multiple "operators" which > > will need it. For example when . repeats the last insertion a count > > Yes, that is what I thought as well. If we put it into the operators we > will have to duplicate the repetition code for each operator. Ideally, > we would not have to do that. Turns out this is not that simple. I went with your approach for now. gp and gP should now also be recognized, hope it works as expected. Thanks! -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [hackers] [PATCH][vis] Change op_put to repeat put operation count times
On Wed, Jul 29, 2015 at 08:52:07PM +0200, Silvan Jegen wrote: > This is the quick-and-dirty way to implement a feature I miss from Vim. Thanks. Yes the count/repetition code needs an overhaul. I'm not sure whether it makes sense to move it into the operator implementation themselves though. Feels wrong. Also there are multiple "operators" which will need it. For example when . repeats the last insertion a count should also be supported. Then there is the question of what to do with "n operator m movement" where vim multiplies them i.e. count is n*m. However there seem to be cases like the shift operators > and < where it would make sense to keep them separate. Needs some more thought ... -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [hackers] [dvtm] Status bar aesthetic patch
On Fri, Jul 17, 2015 at 09:43:48AM -0400, Ross Mohn wrote: > Hi, > > I like to to use my own characters at the beginning and end of the > status bar message. Previously I've edited dvtm.c directly, but it's > better to have this configurable in config.h so that eveeryone can > choose their own. Thanks, applied! -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
