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

[dev] surf

[Tom Butz]

Hi there,

surf is THE browser for FreeBSD! I love it, it does sound and movies just like 
that.
(Most webpages I visit do not use Flash).

How do I save webpages? Right-click ´Download..' comes up with error messgea on
the console (Blocked...). When I print to a file (PDF/PS/SVG) the text is 
unreadable
but the rest is ok. Do I need a special font?

Thanks for your help,
Tom Butz, New Zealand

FreeBSD 10.10_2, Toshiba laptop

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] [bugs] st clears up upon resize and other little things

[Roberto E. Vargas Caballero]

Hello,

On Sun, Jan 17, 2016 at 12:20:11PM -0200, Brad Luther wrote:
> Roberto Caballero

The short form of my name is Roberto Vargas. Read [1].

> so I understand that the behavior that makes
> content be lost is because it is less hungry on memory? If that's the
> case, I think this is acceptable. It's a good reason.

If you want to change it you can modify tresize() and call to realloc
only if the new size is bigger than some variable where you store
the maximum until now. It is very simple patch and it can be a place
in the wiki.

> On the geometry being a multiple of the font, you say that "In the
> past there was some work to avoid this situation adding pagging pixel
> lines, and it generated a lot of problems". But ACE said there's still
> a way touse it like that, by setting resizehints = False in config.h.
> Would this bring problems?

Uhmmm. I didn't know this part. You should ask to Christoph Lohmann
because he is who maintains this part.

> Matthew of Boswell - thanks for the explanation and zsh patch. Too bad
> I use ash. It's a pain in the ass not to be able to use Delete on st.
> I'll see if I can adapt your zsh patch. Also, by what I understand,
> this will never be provided by default because it's a fundamental
> problem outside st?

You can read the thread in [2], and you will understand why I am not
going to change this behaviour in the git version. Again the patch is
very simple, you only have to modify the values in the array Key located
in config.def.h. You can see that there are two rows for XK_KP_Delete and
XK_Delete for XK_ANY_MOD. If you join them in only one row them you will
be able to run suck programs inside of a suckless terminal. If you do
it you can add the patch to the wiki and we can add a link in the FAQ,
but again, my suggestion is send a patch to the programs that are
wrong.

Regards,

[1] http://perez.cs.vt.edu/twolastnames
[2] http://comments.gmane.org/gmane.comp.misc.suckless/20370 

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] [bugs] st clears up upon resize and other little things

[Markus Teich]

Brad Luther wrote:
> On the geometry being a multiple of the font, you say that "In the
> past there was some work to avoid this situation adding pagging pixel
> lines, and it generated a lot of problems". But ACE said there's still
> a way touse it like that, by setting resizehints = False in config.h.
> Would this bring problems?

Heyho Brad,

Just set it to 0 in dwm's config.h. It just enforces the client to use more
space than requested and st handles it fine. I've used it for years now.

--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] [bugs] st clears up upon resize and other little things

[Roberto E. Vargas Caballero]

Hi,

On Fri, Jan 15, 2016 at 10:53:30AM -0200, Brad Luther wrote:
> 1 - when you open st and some strings printed (try 'ls' for example),
> upon resizing it down and resizing it back up, the content is lost.
> Shouldn't the printed stuff remain there? This is an annoyance for
> when I, for example, 'ls' a folder, open an image that I found inside
> so dwm automatically tile st and the image, and then I close the
> image. Now the st window will not show all the content of the folder
> from when I did 'ls'. The files/folders previously printed that upon
> resize were covered are now gone and I have to 'ls' again.

St resizes the line buffers each time that the geometry of the terminal
change, then the content of the space out of the new size is lost.
It is done by a design decision. In fact it is easier the another
behaviour and not resize anything and hungry memory that you are not
using. If you really want this behaviour you can get with any terminal
session manager (dvtm, tmux, screen ...).


> 2- st is the only program on dwm that doesn't cover the entire screen
> when opening it in fullscreen tile mode. There's always a line on the
> bottom of the screen to which st refuses to expand.

This kind of situations can happen because the geometry of st must be
a multiply of the size of your font. In the past there was some work
to avoid this situation adding pagging pixel lines, and it generated
a lot of problems. Keep it simple.

> 3- the delkey patch[0] isn't working for me. As I understand it should
> make 'Delete' erase the current the highlighted character, but it does
> nothing. All I did was clone the repo and apply the patch (which is
> simple enough). Are there any users successfully using this patch?
> What could I have done wrong?

No, the objective of that patch is to change the ascii value generated
when you press backspace and delete, because at this moment, for some
very stupid historic problems, the majority of terminals generate
a DEL when you press backspace, instead of generating a BACKSPACE.
All this stuff is really well explained in the FAQ. The problem you
are haaving is that you are using bad programs that don't follow the
POSIX standard. You should send a patch to them.

Terminal keyboard have two modes, keypad mode and ascii mode. When you
are in ascii mode the terminal generates the correct ASCII code which
will generate the function labelled in the key. In the case of St it
generates ^[P, which is the sequence that st understands to delete the
current character. When the keyboard is in keypad mode it generates
a sequence thought to be an unique identifier of the key. In the
terminfo definition of the terminals you can find which is the
sequence for every special key when they are in keypad mode, and it
means that a program that wants to check against these code must to
change the mode of the terminal to keypad before reading. There is a
terminfo definition to do this. Again everything is explain in the
FAQ.

You can try to fix the problems of the other programs, or write
a patch of st that make it to send the same key in both modes and
upload it to the wiki. I will not do it because is giving the reason
to the bad written programs, instead of fixing them. But if you want
to do it and upload it to the wiki we can put the link to the patch
in the FAQ.

Regards,

Re: [dev] [bugs] st clears up upon resize and other little things

[Brad Luther]

Hello.

Roberto Caballero - so I understand that the behavior that makes
content be lost is because it is less hungry on memory? If that's the
case, I think this is acceptable. It's a good reason.
On the geometry being a multiple of the font, you say that "In the
past there was some work to avoid this situation adding pagging pixel
lines, and it generated a lot of problems". But ACE said there's still
a way touse it like that, by setting resizehints = False in config.h.
Would this bring problems?

Matthew of Boswell - thanks for the explanation and zsh patch. Too bad
I use ash. It's a pain in the ass not to be able to use Delete on st.
I'll see if I can adapt your zsh patch. Also, by what I understand,
this will never be provided by default because it's a fundamental
problem outside st?

Thanks.


On Sun, Jan 17, 2016 at 10:09 AM, Roberto E. Vargas Caballero
 wrote:
> Hi,
>
> On Fri, Jan 15, 2016 at 10:53:30AM -0200, Brad Luther wrote:
>> 1 - when you open st and some strings printed (try 'ls' for example),
>> upon resizing it down and resizing it back up, the content is lost.
>> Shouldn't the printed stuff remain there? This is an annoyance for
>> when I, for example, 'ls' a folder, open an image that I found inside
>> so dwm automatically tile st and the image, and then I close the
>> image. Now the st window will not show all the content of the folder
>> from when I did 'ls'. The files/folders previously printed that upon
>> resize were covered are now gone and I have to 'ls' again.
>
> St resizes the line buffers each time that the geometry of the terminal
> change, then the content of the space out of the new size is lost.
> It is done by a design decision. In fact it is easier the another
> behaviour and not resize anything and hungry memory that you are not
> using. If you really want this behaviour you can get with any terminal
> session manager (dvtm, tmux, screen ...).
>
>
>> 2- st is the only program on dwm that doesn't cover the entire screen
>> when opening it in fullscreen tile mode. There's always a line on the
>> bottom of the screen to which st refuses to expand.
>
> This kind of situations can happen because the geometry of st must be
> a multiply of the size of your font. In the past there was some work
> to avoid this situation adding pagging pixel lines, and it generated
> a lot of problems. Keep it simple.
>
>> 3- the delkey patch[0] isn't working for me. As I understand it should
>> make 'Delete' erase the current the highlighted character, but it does
>> nothing. All I did was clone the repo and apply the patch (which is
>> simple enough). Are there any users successfully using this patch?
>> What could I have done wrong?
>
> No, the objective of that patch is to change the ascii value generated
> when you press backspace and delete, because at this moment, for some
> very stupid historic problems, the majority of terminals generate
> a DEL when you press backspace, instead of generating a BACKSPACE.
> All this stuff is really well explained in the FAQ. The problem you
> are haaving is that you are using bad programs that don't follow the
> POSIX standard. You should send a patch to them.
>
> Terminal keyboard have two modes, keypad mode and ascii mode. When you
> are in ascii mode the terminal generates the correct ASCII code which
> will generate the function labelled in the key. In the case of St it
> generates ^[P, which is the sequence that st understands to delete the
> current character. When the keyboard is in keypad mode it generates
> a sequence thought to be an unique identifier of the key. In the
> terminfo definition of the terminals you can find which is the
> sequence for every special key when they are in keypad mode, and it
> means that a program that wants to check against these code must to
> change the mode of the terminal to keypad before reading. There is a
> terminfo definition to do this. Again everything is explain in the
> FAQ.
>
> You can try to fix the problems of the other programs, or write
> a patch of st that make it to send the same key in both modes and
> upload it to the wiki. I will not do it because is giving the reason
> to the bad written programs, instead of fixing them. But if you want
> to do it and upload it to the wiki we can put the link to the patch
> in the FAQ.
>
> Regards,
>

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