[dev] [ANNOUNCE] vis-0.7
Hi, I'm pleased to announce vis-0.7: https://www.brain-dump.org/projects/vis/vis-0.7.tar.gz This is mostly a bugfix release with fixes for a few cases of undefined behavior[1] and preliminary work for experimentation with different core text management data structures[2] and general editor architecture[3]. Changes include: - fix UB in core text management data structure - text refactoring, splitting out reusable text iterator and I/O components - new *at variants taking directory descriptor for file load/save API - more efficient initial file read, avoiding spurious syscalls and copy - text API cleanups, const correctness improvements - increased test coverage for core text data structure - support for Lua 5.4 - Lua API improvements: vis.mark, vis.register, vis.win.file.modified and support for terminal CSI events - NetBSD support - new :set ignorecase option to search case independently - new visual mode mapping to select all matching selections - fix mappings involving non-leading - minor file detection fixes for racket, node.js modules, Typescript and liliypond - new lexers for Zig, meson build system, Mikrotik RouterOS scripts, Gemini - improved inner word text object and its use for in normal mode - improved behavior in visual mode - removed ie, ae inner/outer entire text object, use :, as shorthand for :0,$ - removed pairwise selection combinators z>, z<, z-, z+, z&, z| - remove ~ as alias for g~ - use ~ instead of ! for selection complement - remove special key and window related aliases - vis-open(1) adds a trailing slash to indicate folders - add primary clipboard support to vis-clipboard(1) - support wayland clipboard using wl-clipboard(1) - new Makefile targets: distclean, testclean Marc [1] https://www.brain-dump.org/blog/finding-undefined-behavior-in-c-code/ [2] https://www.brain-dump.org/blog/rethinking-vis-text-management-data-structure/ [3] https://www.brain-dump.org/blog/vis-to-server-or-not/
[dev] [ANNOUNCE] vis-0.6
Hi I'm pleased to announce a new version of the vis editor, combining modal editing with built-in support for multiple selections, structural regular expressions and Lua scripting capabilities. https://www.brain-dump.org/projects/vis/vis-0.6.tar.gz Changes include: - bounded time syntax highlighting using the `:set redrawtime` option - support optional count for sam's text commands e.g. `:i3/-/` - make `` in visual mode match next occurence of existing selection - warn when attempting to write to an existing file - improved file change detection based on inode instead of path information - fix file saves with modifications in file pre-save events - fix save on file systems without `fsync(2)` support on directory descriptors - do not unlink `file~` when saving `file` - introduce distinct `vis-menu(1)` exit codes - modify Lua package.path to include /init.lua - performance improvements for the HTML, XML and YAML lexers - new Julia and Elm lexers, better defaults for standard text lexer - support optional exit status in `:q` and `:qall` commands - better temporary file creation using `mkstemp(2)` - performance improvements in highlight matching parentheses - improved behavior of `^` and `$` in searches and looping commands - improved search wrap around behavior - new `:set layout` option to specify window orientation - improved filetype detection by matching known filenames exactly - support DragonFly BSD in configure script - better manual page, fixed warnings - removed `gp`, `gP`, `gq` - implement `g~`, `gu` and `gU` using `tr(1)`, they are no longer operators - removed `v` and `V` in operator pending mode - avoid crash if `$TERM` is unset - keep selections after `:>` command - normalize selections after `:` command execution - show pending input queue content in status bar - make `r` insert a new line - new `:set loadmethod` option, valid values are `read`, `mmap` or `auto` - always apply `:|` command to existing selections - fix terminal UI on serial console - various code cleanups, removal of VLA - resets count, if applicable - fix `:X` and `:Y` commands which were interchanged - don't strip executables by default, provide install-strip target Marc
[dev] [ANNOUNCE] vis-0.5
Hi, vis 0.5 is out: https://github.com/martanne/vis/releases/download/v0.5/vis-v0.5.tar.gz Changes include: - Fix for a buffer overflow when dealing with invalid/incomplete Unicode sequences which caused an infinite loop/crash. With default compilation flags this should not be exploitable, but opening a malicious file would lose all unsaved changes. - Fix color support in ncurses 6.1 - New default 256 color theme: zenburn. It should hopefully work better with the default color palette. - Updated Docker based builds (`make docker`) to use latest Alpine Linux packages to produce a statically linked, self-contained binary. - Take symbolic keys into account when evaluating key prefixes (`ci<` is not a prefix of `ci`). - Improved paragraph text objects. - Reset count after handling , - Lexer updates for Clojure, Scheme, ASM, Pony, PHP, Python, Erlang, xs and ReasonML. - Correct handling of `g/^$/` construct to match empty lines in commands like: x g/^$/ d - `` now inserts `\r` rather than `\n`, this currently also affects `r` which might not be desirable. - Fix command prompt malfunction triggered by special cursor position. - Configure script can be interrupted. - Removed `!` operator, use `:|` - Ignore `SIGQUIT` - `vis-open(1)` fixes Check the git log for further details. The release tarball is signed with OpenBSD's signify tool, the signature[1] can be verified using the public key[2]. Cheers, Marc [1] https://github.com/martanne/vis/releases/download/v0.5/vis-v0.5.tar.gz.sig [2] https://martanne.github.io/vis/vis.pub
[dev] [ANNOUNCE] vis-0.4
Hi,
vis 0.4 is out:
https://github.com/martanne/vis/archive/v0.4.tar.gz
Changes include:
- Selections as core editing primitives. Cursors have been superseded
by singleton selections. Overlapping selections are now merged. This
change is also reflected in the exposed Lua API (for which still no
stability guarantee is given).
- Selections can be saved into marks on which set operations can be
performed:
m save selections
M restore selections
| set union
& set intersection
\ set minus
! set complement
z| pairwise union
z& pairwise intersection
z+ pairwise combine, choose longer
z- pairwise combine, choose shorter
z< pairwise combine, choose leftmost
z> pairwise combine, choose rightmost
Marks are specified using '{mark} analogous to "{register}.
- Jump list based on marks:
g< jump backward
g> jump forward
gs save currently active selections
- New register # to insert the current selection number.
- Drop special handling of \r\n line endings. \r will be displayed
as ^M. will always insert \n.
- Fix Unicode regex search with libtre backend.
- New count specifiers for sam's `g` and `v` commands to keep/drop
selections based on their index.
- On macOS saving files larger than INT_MAX bytes should work.
- New `:set show-eof` to toggle the display of end of file markers ~
as before it is enabled by default.
- Double leading slashes of paths are stripped.
- Improved `:<` command implementation to only use a pipe when necessary.
- New lexers for Myrddin and strace(1), updates for Elixir, Perl
and Forth.
- Fix compilation for GNU Hurd. The vis package is now built for all
supported Debian architectures.
- Improve job control of forked processes. SIGINT is now properly
delivered to child processes.
- Commands given a huge count can now be interrupted using .
This is implemented in cooperative fashion, meaning a single long
running operation can still not be interrupted.
- More efficient line wise motions based on optimized mem{r,}chr(3)
libc functions.
- Optionally support vim compatible n/N search direction.
- Reproducible, statically linked, self contained binary built using
the Alpine Docker image. The idea being that it is a single file
which can be copied to any Linux >= 2.6 system to provide a usable
editor. It has an embedded tar archive which contains the required
Lua support files which are extracted to a temporary directory using
libuntar.
- Preliminary C API documentation found at: http://vis.rtfd.io
- Updated manual page.
- Various code cleanups.
Check the git log for further details.
The release tarball is signed with OpenBSD's signify tool, the signature[1]
can be verified using the following public key[2]:
untrusted comment: vis editor signify public key
RWRbDa94LCndLy4pUdO6h1PmS1ooHOGb7p84OfQIR7+hFlZwuAXUdQ5J
[1] https://github.com/martanne/vis/releases/download/v0.4/vis-0.4.tar.gz.sig
[2] https://martanne.github.io/vis/vis.pub
Re: [dev] [announce] mle: a small terminal-based text editor
On Wed, Mar 29, 2017 at 08:22:04PM +0100, Snobb wrote: > I liked the idea of vis in its early stage until it went the "lua" way. I'm sorry that you feel that way, but you can still completely disable Lua during compile time and get a working editor (albeit with less features). In my opinion Lua is among the least sucking languages for the purpose it is used in vis. It is simple (almost everything is a table) but still versatile and powerful. Also the implementation is rather nice. Up to a point you can think of Lua as a runtime replacement for the C pre-processor commonly used by suckless projects for configuration purposes. Both approaches are better than writing your own configuration parser. Marc
Re: [dev] oasis: small linux system inspired by stali
On Tue, Mar 28, 2017 at 12:00:22AM -0700, Michael Forney wrote: > On Mon, Mar 27, 2017 at 2:44 PM, Marc André Tanner <m...@brain-dump.org> > wrote: > > Hi Michael, > > > > Overall I like your package selection, but I also have a few questions: > > > > * Did you consider using netbsd-curses[1] instead of ncurses? > > > >This probably won't work as is, because libtermkey as required by > >vis depends on the ncurses terminfo library. It might be worth > >investigating how much work it would be to either port libtermkey > >or provide the necessary terminfo symbols in netbsd-curses. > > I have not. I actually was originally very hesitant to include any > curses library at all, since it seems to me like the wrong layer to > implement a graphical UI (instead going the route of acme + 9term). In principle I agree. Unfortunately I often have to deal with systems where I'm stuck with a tty. > If you find a way to use netbsd-curses That might be more easily possible. > (or maybe no curses at all; I > saw you added a vt100 UI to vis), I'd be interested. The vt100 UI stuff cuts out the middle man (trades it for a fixed set of escape sequences and probably a lot of display flickering), but is ultimately still based on the same flawed terminal abstraction. Speaking of curses alternatives there is also http://www.leonerd.org.uk/code/libtickit/ which is advertised as the "successor" of libtermkey (currently it still depends on it though). I haven't actually looked at it in detail, partly because it uses bzr as SCM and launchpad as issue tracking system. Apparently a first version was released recently. Not sure whether it would be an improvement. > > * Did you try how much of the system can be built using a C only > >toolchain like cparser+libfirm? > > I did try cparser/libfirm at one point in the project's infancy and I > was surprised at the amount of stuff that built no problem. I have > since added more packages though, so can't give you a recent answer. It was a long time ago when I last played around with it, but it is supposedly able to build musl. Hence I thought the rest of the core system should also be doable. But maybe I'm a bit too optimistic. Also just being able to compile something isn't that interesting in itself, the result should also work as expected. I just tried to build vis, but cparser doesn't currently support multiple source files on the same command line. This of course doesn't concern oasis where you completely replaced the build system. > I also spent a week or so a while ago fixing some bugs in scc to try to > get it to build sbase. I think it would be really cool to be able to > build the core system (or more!) with a lighter toolchain. I strongly agree. I wonder whether an organization participating in GSoC would be willing to accept/mentor such a project (working on cparser+firm). Maybe OpenWRT/LEDE? Seeing that they are using musl as their libc. I'm probably a bit late to the party though ... > > * Why did you settle for perp instead of s6[2]? Again I'm not really > >familiar with either of them (besides reading their respective > >websites etc.). Just curious, it would be interesting to get your > >reasoning behind the package selection process. > > I tried both a couple of years ago, and liked perp more. It seemed > simpler and smaller in scope than s6. s6 has its own scripting > language and quite a lot of extra tools. Although, I have to admit, > one contributing factor is that the s6 tool names are just a pain to > type. Yeah, I'm not yet sure what I should think of stuff like execline. I haven't actually used either system for a sufficient amount of time to draw any meaningful conclusions.
Re: [dev] oasis: small linux system inspired by stali
Hi Michael, Overall I like your package selection, but I also have a few questions: * Did you consider using netbsd-curses[1] instead of ncurses? This probably won't work as is, because libtermkey as required by vis depends on the ncurses terminfo library. It might be worth investigating how much work it would be to either port libtermkey or provide the necessary terminfo symbols in netbsd-curses. * What is the justification for using ninja (I'm not really familiar with it). It seems like the only (non-toolchain) package requiring C++. Furthermore, you mentioned that you might write a compatible C replacement at some point, hence it must obviously be better than other existing alternatives. * Did you try how much of the system can be built using a C only toolchain like cparser+libfirm? * Why did you settle for perp instead of s6[2]? Again I'm not really familiar with either of them (besides reading their respective websites etc.). Just curious, it would be interesting to get your reasoning behind the package selection process. * Will you consider using BearSSL in the future, once it gets a bit more mature? Thanks for your work! Marc [1] https://github.com/sabotage-linux/netbsd-curses [2] http://skarnet.org/software/s6/
[dev] [ANNOUNCE] vis-0.3 with structural regexp support
Hi, I'm pleased to announce that after a year of development vis-0.3 finally was released: https://github.com/martanne/vis/releases/tag/v0.3 The release tarball is signed using signify(1), use the following public key[1] for verification purposes: untrusted comment: vis editor public key RWRbDa94LCndLy4pUdO6h1PmS1ooHOGb7p84OfQIR7+hFlZwuAXUdQ5J A lot has been improved in the meantime, the following non-exhaustive list mentions a few notable changes: - Support for sam's structural regular expression based command language - Various bug fixes related to multiple cursor/selection support. New functionality to navigate among cursors (``, ``), align (``, ``), rotate (`+`, `-`), trim (`\`) or drop (``, ``) selections. - Improved Lua API, featuring a new event subscription mechanism and the possibility to define custom operators, motions, text-objects, `:set` options and more. Notice however that at this point no API stability guarantee is provided. You might have to update your `visrc.lua` configuration file, check the Documentation for details: http://martanne.github.io/vis/doc/ - New standalone tools vis-menu (`:o .`), vis-digraph (``) and vis-complete (``) for a simple file open dialog, digraph support and word completion, respectively. - Multiple bug fixes for vi(m) functionality, including improved count and repeat handling as well as better cursor positioning, `cw`, shift, join and autoindent implementation. - New key mapping processing based on longest unique match. - Optional libtre based regex backend for more memory efficient forward searches. - Respect umask when creating new files, previously they were only read/writable by the current user. Also fsync(2) destination directory after rename(2) when performing an atomic save operation. - New `:set` options to configure the used shell, escape delay, file save method and context to consider for syntax highlighting. - True color support in lexer themes, in case the terminal supports color palette changes. - Minimal built-in `:help [pattern]` command. - Incorporated upstream changes to LPeg based lexers used for syntax highlighting from the Scintillua project. - New set of manual pages in mdoc format. HTML versions are available at: http://martanne.github.io/vis/man/ - Experimental raw vt100 UI backend for resource constraint environments. - Various code cleanups and bug fixes reported by static analysis and fuzzing tools. Check the git log for further details. We also populated the wiki with a few basic pages, including a FAQ: https://github.com/martanne/vis/wiki/FAQ I would like to thank the following people who contributed patches for this release: Adrian Room, Alexandre Rames, Alexey Dubinin, Chloe, Christian Hesse, David B. Lamkins, Eric Garver, Erlend Fagerheim, James Campos, Joshua Haase, Josh Wainwright, Josuah Demangeon, Klemens Nanni, Larry Hynes, Lawrence Luo, Luiz de Milon, Michael Forney, Michel Martens, Murray Calavera, Richard Burke, Rob Pilling, S. Gilles, Silvan Jegen, Steven Noonan, stutonk, Tim Allen, Vlad Glagolev In the future I would like to further improve Unicode handling, large file performance, enhance the Lua API and introduce support for asynchronous operations. As always, comments, bug reports and patches welcome. Cheers, Marc [1] https://martanne.github.io/vis/vis.pub
Re: [dev] [ubase] pager
On Fri, Feb 10, 2017 at 12:08:21PM -0800, Leander S. Harding wrote: > Search is indispensably useful and needful overall for general command > output, which is why it should be implemented with a powerful/good ui > at the multiplexer/TE layer, so that you're not maintaining two or > more search facilities with similar-but-slightly-differing features. > > This though leads me toward the implementation of a suckless > scrollback+select/yank/urlpick/etc handler that comes with a 'pager' > util that just toggles its scroll-lock state like this. Like an even > more suckless dvtm with the one extra feature that's on my mind right > now. :) Latest dvtm pipes the scroll back buffer content to external tools such as dvtm-pager(1) (by default a shell wrapper around less(1) preserving color escape codes) and dvtm-editor(1) a small utility invoking $EDITOR for copy mode. That way your regular editor features can be used to search, select and copy parts of the scroll back buffer content. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Mon, Feb 06, 2017 at 10:25:35AM +, Raphaël Proust wrote: > On 3 February 2017 at 20:30, Marc André Tanner <m...@brain-dump.org> wrote: > > On Fri, Feb 03, 2017 at 10:00:37AM +, Raphaël Proust wrote: > > […] > >> :x/pattern/ t h c/replacement/ > > > > Not sure this is flexible enough? How would you generalize this to > > operate on the n-th dot in a convenient way? > > :x/pattern/ t5 h c/replacement/ ← pops five matches out, selects the > sixth and replaces it. > > :x/pattern/ t2 T2 c/replacement/ ← pops the first two matches out, > then the last two matches out, then replaces all the others. > > The idea of t and h is to mimic tail(1) and head(1). The > capitalisation (t/T, h/H) corresponds to passing positive or negative > counts to those filters (head -n 10/head -n -10, and similarly for > tail). I don't like that this would introduce 4 new commands. I believe the same functionality can be better integrated in a different way. We already have commands `g` and `v` to filter existing matches based on a regular expression. Extending them to also support an optional count specifier seems natural. As for the exact syntax it could be similar to list comprehensions (e.g. to be able to express selecting every n-th match) as found in various programming languages. > > I thought about introducing a count specifier for either `x` and `y` > > or `g` and `v`. Because these commands take a regular expression not > > an address the count is unambiguous here: > > > > x3/pattern/ command > > x/pattern/ g3 command > > > > would only execute command for the third match. Similarly, `y` and `v` > > would execute it for all but the third match. > > I like this syntax, especially the g/v one (see below how it extends > better). I don't think it's sufficient. Here are example of things I > don't think this can do with suggestions on extending this syntax. > > - select the last match (albeit x-1 and g-1 could be used), Yes, -1 could work. > - select all but the first (G1 could be used, but X1 could not), That is what the `v` command is for? It executes whenever its count specifer (regex pattern) does *not* match. In this case: y1 > - select all but the n first (again Gn), Maybe `gn-` or `v1-n` ? > - select all but the n last (G-n). `g1-n` or `vn-` ? But maybe the added complexity is not worth it. > >> So currently `X` is more like vim's `windo`. I use `bufdo` more often. > >> I'm undecided whether offering both is worth the added complexity and > >> features. > > > > I think it would be much cleaner to add both variants rather than > > duplicate some functionality. If we had a proper way to loop through > > files some vi originated commands like `bdelete` might become obsolete > > and could be removed. > > W for window, X for file? > Z, Y? Or V and W, albeit V would have a conflicting meaning with v. > It's not ideal, especially because `w` is for write… > > Alternatively, because these are less frequent than the other > operators (x, g, c, etc.), maybe they don't need to be single letters. That would make them a bit alien to the rest of the commands ... > I have also started testing it and using the github issue tracker for > your project. I'll use this thread for the design discussion and the > issue tracker for minor things and other more specific improvements. > Let me know if these are not your preferred channels. That is fine. Thanks for the feedback. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Fri, Feb 03, 2017 at 10:00:37AM +, Raphaël Proust wrote: > On 2 February 2017 at 17:46, Marc André Tanner <m...@brain-dump.org> wrote: > >Sam supports a count specifier: s2/pattern/replacement/ only replaces > >the second occurrence of pattern. This is currently not supported but > >can be mimicked using: > > > > :/pattern/ // c/replacement/ > > > >A more general variant of the count concept might be later integrated > >into the x, y and/or g, v commands. Comments and syntax suggestions > >welcome. > > My sam addressing is rusty, but IIRC, `/pattern/+/pattern/` search for > the second match of `/pattern/`. (The `+` operator for addresses: > “a1+a2 The address a2 evaluated starting at the end of a1.”) That is correct, but `+` can be elided here. Also when pattern is omitted the last used one is substituted in (this might be missing from the vis man page, but it is mentioned in sam(1)). Hence `/pattern///` is an abbreviation of your `/pattern/+/pattern/`. > Maybe, rather than a special case for `s`, this suggest that the Yes special cases should be avoided, but as illustrated above this is actually not the case here. > address `n/pattern/` could be read as `n` times `/pattern/` which is > `/pattern/+…+/pattern/`. Would that interfere with the other > addressing modes? Yes, with the current semantics it searches for `pattern` at the end of line `n`. > I think it's ok because compound addresses all use > explicit operators (`+`, `-`, `,`, `;`). As a result, `2/pattern/` is > distinguishable from `2+/pattern/`, `2-/pattern/`, etc. As mentioned above `+` can be elided, hence `2+/pattern/` and `2/pattern/` are equivalent. > Alternatively, a command to manipulate dot collections could be used > to provide a "2nd match replacement" feature. In this case, new > operations say `h` and `t` (short for head and tail) would select, > respectively, the first of the multiple selected dots and all but the > first dot. > > :x/pattern/ t h c/replacement/ Not sure this is flexible enough? How would you generalize this to operate on the n-th dot in a convenient way? I thought about introducing a count specifier for either `x` and `y` or `g` and `v`. Because these commands take a regular expression not an address the count is unambiguous here: x3/pattern/ command x/pattern/ g3 command would only execute command for the third match. Similarly, `y` and `v` would execute it for all but the third match. > > * Multi file support is not really well supported: > > > > - The X and Y commands currently operate on windows, not files. > > Meaning that if a file is being displayed in multiple windows > > a given command will be executed once for every window. This is > > desired in certain cases (e.g. `:X q` to close all windows without > > unsaved changes) and unwanted in others (e.g. > > > > :X 0i,/* ISC licensed */\n > > > > to add a license template to the top of every file). > > So currently `X` is more like vim's `windo`. I use `bufdo` more often. > I'm undecided whether offering both is worth the added complexity and > features. I think it would be much cleaner to add both variants rather than duplicate some functionality. If we had a proper way to loop through files some vi originated commands like `bdelete` might become obsolete and could be removed. > IIRC, X (and Y) can only appear at the beginning of the command. I think they can be used arbitrarly, but "only one instance of either `X` or `Y` may appear in a single command". This is actually currently not enforced by vis. Thanks for your comments! -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Fri, Mar 11, 2016 at 08:08:38PM +0100, Marc André Tanner wrote:
> On Tue, Mar 01, 2016 at 05:23:11PM +, Connor Lane Smith wrote:
> > On 1 March 2016 at 17:12, Marc André Tanner <m...@brain-dump.org> wrote:
> > > I think structural regexp will integrate nicely with multiple selections.
> > >
> > > Basically if you omit the command of a structural regexp the editor
> > > would switch to visual mode and add a selection for every match. If you
> > > are already in visual mode then the existing selections would be used
> > > as ranges for an implicit leading loop construct (x/ in sam).
> > > That is for an existing selection x/ and y/ could be used to split it.
> > > Similarly the conditionals g/ and v/ would be used to keep / discard
> > > selections.
> >
> > I agree (strongly!). My main complaint with sam is its inability to
> > reflect the multiple selections implied by its command language. It
> > would be fantastic if we could get that sorted, and vis may well be a
> > good place to do it.
>
> I finally had some time to experiment with these ideas.
In the meantime lots of bugs have been fixed. I would like to encourage
all sam/acme users who are also somewhat familiar with vi(m) to try out
current master of vis and report back on their experience:
https://github.com/martanne/vis
http://repo.or.cz/w/vis.git
Some differences compared to sam (see also the man page[1]):
* Multiple "dots" (selections) can exist simultaneously.
* Commands can be interactively refined, whenever sam would invoke the
print command vis instead creates a selection matching the corresponding
range. If no selection remains after a command execution, vis switches
to normal mode. Otherwise it stays in visual mode.
* Changes do not need to be in sequence, but only non-overlapping i.e.
the following works as expected:
:x/Emacs/ { d i/V/ a/i/ }
* The s (substitute) command was dropped. Instead :x/pattern/c/replacement/
can be used for global search and replacement. The registers \1-\9 refer
to sub expression matches. & contains the complete matched text, hence:
:x/Vi/ c/>&/ a/gv
works, but a second (in normal mode) would get rid of the
cursors and hence also of all selections.
* There is currently no easy way to specify multi line commands. The
command prompt is implemented as a regular file. Hence
inserts a line break without executing the command. We should probably
investigate ways to make this a bit more convenient.
* Multi file support is not really well supported:
- The X and Y commands currently operate on windows, not files.
Meaning that if a file is being displayed in multiple windows
a given command will be executed once for every window. This is
desired in certain cases (e.g. `:X q` to close all windows without
unsaved changes) and unwanted in others (e.g.
:X 0i,/* ISC licensed */\n
to add a license template to the top of every file).
- The whole undo concept is file specific, the above insertion command
can not easily be undone. Implementing an u command would at least
give the possibility to `:X u` undo all changes. vis does currently
not allow to switch windows while in visual mode.
Comments (and patches) regarding vis in general are also welcome. Either
here, in #vis-editor on Freenode or in the Github issue tracker.
I would like to do another release relatively soon. Happy editing.
Cheers,
Marc
[1] http://martanne.github.io/vis/man/vis.1.html
Re: [dev] pledge(2) patches
On Wed, May 18, 2016 at 06:50:15PM +0200, Kamil Cholewiński wrote:
> +#if defined(__OpenBSD__)
> + if (pledge("stdio rpath dns unix prot_exec proc exec", NULL) < 0) {
> + die("pledge\n");
> + }
> +#endif
Independent of whether the functionality is desired, you probably want
to implement it along the lines of:
#ifndef __OpenBSD__
int pledge(const char *promises, const char *paths[]) { return 0; }
#endif
This way you won't clutter all the call sites and they are at least
compile tested on all platforms.
Also because you always die upon failure you might want to introduce
an xpledge(...) wrapper which could also print a more descriptive error
message (pledging for which resource failed).
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [sup] Bring the simple user privilege escalation tool back home?
On Tue, May 17, 2016 at 08:54:19AM +0200, Anselm R Garbe wrote: > On 16 May 2016 at 23:22, Marc André Tanner <m...@brain-dump.org> wrote: > > On Tue, May 10, 2016 at 01:27:40PM +0200, FRIGN wrote: > >> I think the vis editor alone is enough bloat in the suckless > >> repositories. > > > > I don't know what vis has to do with the original thread, nonetheless > > it would be interesting to know which aspects of vis you consider > > bloated? > > I can only imagine he meant sandy which I would suggest to be removed asap. In principle sandy is a fine editor, it has a few nice ideas (doing as much as possible with external tools, the prompt handling, a very simplistic approach to syntax highlighting etc.) and should be positioned as a simpler nano. It also has various limitations which I deemed unacceptable for vis, but they are mostly there by design as a result of its simplicity. My main critique concerns the introduction of vi like key bindings, which seem bolted on and in my opinion do not fit its design at all. Adding them was a mistake. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] termbox fork
On Sun, May 15, 2016 at 11:07:47PM -0800, M Farkas-Dyck wrote: > tty sucks but ain't about to die soon... The same applies to curses. The NetBSD curses library[1] was recently ported to Linux. I haven't yet tried it out myself, but the code looks much cleaner than ncurses. This might be interesting for stali or other lightweight distributions ... [1] https://github.com/sabotage-linux/netbsd-curses -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [sup] Bring the simple user privilege escalation tool back home?
On Tue, May 10, 2016 at 01:27:40PM +0200, FRIGN wrote: > I think the vis editor alone is enough bloat in the suckless > repositories. I don't know what vis has to do with the original thread, nonetheless it would be interesting to know which aspects of vis you consider bloated? -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
Hi all,
While there are still some bugs left, I'm quite happy how structural
regexp support for vis is progressing. Known issues include:
- relative line specifiers are in some cases wrongly interpreted,
as a consequence -0+,+0- rounds dot up instead of down to whole
lines
- s (substitute) is implemented in terms of sed(1) called without any
arguments, hence:
* the count in s2/foo/bar is not supported
* it defaults to basic regular expression syntax whereas the rest of
vis uses the extended variation. Specifying which kind of regexp
to use doesn't seem portable (GNU sed uses -r, BSD -E, POSIX does
not specify it). As a result this requires ugly escaping:
s/\(a\),\(b\)/\2,\1/ instead of simply s/(a),(b)/\2,\1/ as is
possible in sam.
This particular case can be achieved by means of selection content
rotation in vis, but still it is an ugly inconsistency which should
be fixed at some point. All of vis should use the same regex syntax.
- multiple file support is still completely untested/broken
- with the current command prompt it is kind of hard to enter multi line
commands. It is possible by using to insert a literal
newline. To execute the command it has to be selected, then
executes the active selection.
- grouped commands { .. } do not operate on the same (initial) text state.
As previously discussed in this thread this will likely remain that way
for the foreseeable future.
It would be nice to get some more feedback, what annoys you the most?
Current git master can be considered as a release candidate of vis-0.3:
https://github.com/martanne/vis
Thanks,
Marc
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Wed, Apr 06, 2016 at 01:07:10PM -0500, Joshua Haase wrote: > - When using sam commands, calling undo once does not restore the > previous state. > > One can restore previous state by calling undo several times, but > expected behavior is to call it once, as it is logically one > operation. This is what sam does. This should now hopefully behave a bit better. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Wed, Apr 06, 2016 at 06:40:44PM -0500, Joshua Haase wrote: > > - `!` operator only works when visual selection is active (visual mode). It can be used like any other operator. It will create a selection for the range it was applied to, switch to visual mode and open a command prompt defaulting to :| > They also can be represented in complete form to avoid misunderstandings. > > > I think the latest commit should fix the vi operators `!` and `=`. > > > >> Otherwise, `!` only works on primary cursor, even when using multiple > >> cursors. > > > > Here you are referring to the sam command `!` which redirects stdin to > > the program being launched. This is for example used for the file > > open dialog (based on the vis-open shell script) invoked by `:e .` > > I believe doing it only for the primary cursor makes sense in this > > case. > > I used the sam `:!` command without a selection to insert information > from commands at the cursor position. > > The intended behavior is not "filter my char trough command" (as I have > not selected the char) but rather: > >"insert the result from command before cursor position". > > The behavior I expected from multiple cursors and without a selection > was in the same vein: > >"insert the result from command before every cursor position." This should again be the case now? Though in the meantime a few other things have been broken ... > >> Also, if we are to keep `! cmd`, it could be an alias for `:. | cmd`. > >> This will also fix `!` on multiple cursors. > > > > See explanation above for the purpose of the `!` sam command. > > Can you elaborate on use cases? > > I can see that `:!` is needed when input from the user is expected, > but the the output is added to the current position on the file, > just as expected from the other commands. > > It may also be the case that some filter require user interaction and > fails because of user not being able to provide it. > > So I fail to see why there is a need to differenciate `:. |` and `:!` > behavior. The current modus operandi is roughly: for all selections: do something e.g. execute command Because the ! command is for interactive applications, keyboard input (stdin) is redirected to the forked process. With the above scheme the command would be executed once for every selection, and you would have to individually provide user input for every instance. This is impractical, hence the command is only executed once for the primary cursor/selection. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Tue, Apr 12, 2016 at 11:29:08AM -0700, Suraj N. Kurapati wrote: > On Wed, 06 Apr 2016 18:45:57 -0500, Joshua Haase wrote: > > Marc André Tanner <m...@brain-dump.org> writes: > > > you do not have to prefix your sam command with `ggvG` because > > > in normal mode it will by default be applied to the whole file. > > > > Or you could use `:,` to mean the whole file (i. e. `:,y/\n/i/FOO`). > > Or use `:%` instead because `%` already means the whole file in Vim. Both of these variations are currently supported. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Wed, Apr 06, 2016 at 01:07:10PM -0500, Joshua Haase wrote: > sam features work generally fine, just a few notes: > > - Since commit ab2d1ddd0 the `!` command stopped working (did bisect), > but the command is still in the documentation and default config file. > > > The commit f47ecc3518e2 claims to reimplement the command but doesn't. > > Is the intended behavior to drop `!` command in favour of sam cmds? We have to be somewhat careful with the nomenclature here. There currently exists both a vi operator `!` (filter) and a sam command `!` (launch interactive program). The former is implemented in terms of the sam command `|` (filter). This inconsistency should probably be removed, however `|` has already a meaning in vi (namely go to the count column). I think the latest commit should fix the vi operators `!` and `=`. > Otherwise, `!` only works on primary cursor, even when using multiple > cursors. Here you are referring to the sam command `!` which redirects stdin to the program being launched. This is for example used for the file open dialog (based on the vis-open shell script) invoked by `:e .` I believe doing it only for the primary cursor makes sense in this case. > - When using multiple cursors and no selection, `<` command filters the > entire line instead of adding the input of that command on the > cursor positions. > > `:. | cmd` and `:. < cmd` work fine and I think this should be the > default behavior of `|`, `<` and `>` when not specifying addresses > (this also works on selections). This might indeed be better for `<`, but does it make sense to filter a single character through an external process? I don't think this should be the default for `|` and `>`. > Also, if we are to keep `! cmd`, it could be an alias for `:. | cmd`. > This will also fix `!` on multiple cursors. See explanation above for the purpose of the `!` sam command. > - When using sam commands, calling undo once does not restore the > previous state. > > One can restore previous state by calling undo several times, but > expected behavior is to call it once, as it is logically one > operation. This is what sam does. I agree this would be better. Implementing the basic functionality is trivial (I have a local patch), making sure the cursors are all placed correctly after such an undo operation does not seem that simple ... In general there should probably exist a way to restore past selections. > Thanks and keep up the good work! Thanks for the feedback! -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Mon, Apr 04, 2016 at 01:32:01PM +0200, Marc André Tanner wrote: > Hence it would probably be a good time to get some more testing feedback I merged the sam branch into master, hope this facilitates testing and encourages more people to give it a try ... http://repo.or.cz/w/vis.git https://github.com/martanne/vis/ -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Mon, Mar 28, 2016 at 06:46:40PM +0100, Connor Lane Smith wrote: > Just a config issue I suppose, but I kept quitting the editor by > accident, having typed 'x/foo/' without ':sam' in front of it. Over the last couple of days I integrated the existing vis commands into sam's command language. Meaning the ':sam' prefix is no longer necessary. I also fixed at least one non-sam related issue which could cause a crash when using the Lua based syntax highlighting. While there are certainly still some bugs left, most invasive changes should be completed by now. Hence it would probably be a good time to get some more testing feedback ;) Thanks! -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Mon, Mar 28, 2016 at 06:46:40PM +0100, Connor Lane Smith wrote:
> On 27 March 2016 at 17:10, Marc André Tanner <m...@brain-dump.org> wrote:
> > You could also try `make local` which might or might not work ...
>
> It didn't. Anyway, today I unfortunately found myself with nowt but a
> Mac, though I did manage to get vis to compile. I had to make a couple
> of changes to get it to work. Diff attached, if you're interested. It
> needed _DARWIN_C_SOURCE because SIGWINCH is neither POSIX nor XSI.
As you noticed, ./configure && make should work. In principle I do not
like configure scripts either. However in this case it seemed more user
friendly because some dependencies are optional and could be auto detected.
Manually providing config.mk is still supported and the configure script
is not based on GNU autohell tools.
> Some problems I came across:
>
> Just a config issue I suppose, but I kept quitting the editor by
> accident, having typed 'x/foo/' without ':sam' in front of it.
Yes, I agree this is annoying. The question is how to best integrate
this with the existing vi command line. For example stuff like :wq is
muscle memory by now and should still work.
> If you write ':sam x' then I would expect it to split the selection
> into lines (defaulting to /.*/), as 'x' would in sam. Instead it says
> "bad regular expression."
Fixed. Previously only a space was recognized as /.*/ i.e (as in sam?)
you can write ':sam x g/foo'
> ':sam x/.*/g/foo/' selects those lines containing foo, but ':sam
> x/.*/' followed by ':sam g/foo/' seems to result in all but the last
> selection being lost.
Should be fixed. As of this morning duplicated cursors at the same
position are prevented. In case the regexp matches, g/ would try to
re-create the same exact selection and thus fail.
> Selections seemed dodgy after I did ':sam y/bar/'. I'm not sure what
> their behaviour was after that, but it didn't seem at all consistent
> again until I hit ESC.
We do not prevent selections from overlapping thus once your motion
commands cause an overlapping, all kinds of apparently strange things
can happen. Might this have been the issue you encountered?
If the selections span more than the current viewable area,
Ctrl-{u,d} (possibly with a count) is currently the only way to get an
overview of what actually was selected.
> I also got it to segfault on master, but there was a bit of
> key-mashing (in the command entry box) and I haven't managed to
> reproduce it.
>
> I'll let you know if I have any more progress with it.
Thanks for spending some time trying it out!
Marc
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Sun, Mar 27, 2016 at 01:37:02PM +0100, Connor Lane Smith wrote: > Hi Marc, > > On 27 March 2016 at 09:16, Marc André Tanner <m...@brain-dump.org> wrote: > > Did anyone else participating in this thread (Connor?, Greg?) bother > > to give it a try? > > Sorry, it's on my to-do list, but I had some trouble compiling and > haven't got around to giving it another go. It seems there's a new > dependency, libtermkey, which isn't on Debian stable. You could also try `make local` which might or might not work ... -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Sun, Mar 13, 2016 at 01:55:06PM +0100, Marc André Tanner wrote: > On Sun, Mar 13, 2016 at 11:07:49AM +, Raphaël Proust wrote: > > There are many bugs related to addressing and such. > > Please report more examples of the bugs you encountered. So which are the most annoying ones? Did anyone else participating in this thread (Connor?, Greg?) bother to give it a try? -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
[dev] [ANNOUNCE] vis-0.2
al regular expression support to sam's reference implementation would also be very useful. Help very much welcome. - improve/extend the Lua API for in process extensions. It should be possible to implement stuff like vim-surround or language specific automatic indentation based on it. - introducing a language agnostic RPC interface eventually allowing a client/server architecture. - using a built in regular expression library instead of relying on libc Thanks to all contributors in particular Christian Hesse, Erlend Fagerheim, Markus Teich, Michael Reed, Richard Burke, Silvan Jegen and Dimitry (xomachine). -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
[dev] [ANNOUNCE] abduco-0.6
Hi, I'm pleased to announce a new version of abduco which features a few important bug fixes: http://www.brain-dump.org/projects/abduco/abduco-0.6.tar.gz with sha1sum 5dc3eaaa8d6ea54e22378468652dc9b4bb759641 abduco-0.6.tar.gz Changes include: * properly handle EOF when reading from underlying application. At least on Mac OS X with certain applications this would previously prevent abduco from terminating and cause excessive CPU usage. * no longer set sticky bit on socket as this is not really portable and caused more problems than it solved. This should fix session creation on *BSD. * ignore redraw key if set to \0 (which is the default value) Avoids an annoying key binding conflict for Emacs users. * more portable testsuite.sh script * fixed manual page markup Cheers, Marc -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Sun, Mar 13, 2016 at 11:07:49AM +, Raphaël Proust wrote: > `ggvG:sam y/\n/i/FOO` only inserts "FOO" at the start of the first > line. It should do it on every line. > Same when using `x/^.*$/` instead of `y/\n/` These should now also work. By the way you do not have to prefix your sam command with `ggvG` because in normal mode it will by default be applied to the whole file. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
First of all, thanks for giving it a try! On Sun, Mar 13, 2016 at 11:07:49AM +, Raphaël Proust wrote: > On 12 March 2016 at 17:44, Marc André Tanner <m...@brain-dump.org> wrote: > > On Fri, Mar 11, 2016 at 08:08:38PM +0100, Marc André Tanner wrote: > >> - There will likely be bugs, memory leaks, crashes, infinite loops etc. > >>YOU are supposed to fix them and submit patches ;) > > When typing `:sam` the editor segfaults. Should be fixed. > > Hence the sam command ,x/pattern/ can be abbreviated to x/pattern > > Because of habit with sam, I started testing with `,x/pattern/` and > got an "Unknown command" message from vis. Without the comma, it > “worked” (i.e., did not print a message). Two things: > > - Are you trying for very high compatibility with vanilla sam? In principle yes, unless there is a good reason to deviate. I tried basing the implementation on the manual page and occasionally on the source if something wasn't clear. Does there exist a more formal standard/description of the command language? > - The message is very confusing. (I first thought the `sam` command > was not recognised by `vis` which lead me to triple chek I had the > correct branch and all. I think the message means that the sam > component of vis thinks I am using `,` as a command and that is > wrong.) Yes this was the case, it should be fixed now. > > - In text entry \t inserts a literal tab character (sam only recognizes > > \n). > > Is it because you plan on having be bound to something like > autocomplete on the command line? It is mainly for convenience. In the past (before the command line was implemented as a regular file) was ignored because lots of vim users would try to auto complete stuff. Also tab expansion also applies to the command line, hence depending on your setting you might not get a literal tab character. This can be worked around with . The same can also be used to enter multi line commands. But to actually execute them one has to mark the selection to execute in visual mode and then press . > There are many bugs related to addressing and such. Please report more examples of the bugs you encountered. > basic examples: > > `ggvG:sam y/\n/i/FOO` only inserts "FOO" at the start of the first > line. It should do it on every line. > Same when using `x/^.*$/` instead of `y/\n/` Haven't really looked into it yet. The problem might be that . also matches new lines. However the "idomatic" way to do this seems to be `x i/FOO` which works. > Something related to vis (but not to the sam component): when typing > `:` the command edition buffer opens. It might be because I'm used > to vim, but I'd rather have that buffer start in normal mode. (Normal > mode is what I expect new buffers to start at.) This might be better indeed. I will see what I like more ... -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] structural regular expression support for vis
On Fri, Mar 11, 2016 at 08:08:38PM +0100, Marc André Tanner wrote: > - There will likely be bugs, memory leaks, crashes, infinite loops etc. >YOU are supposed to fix them and submit patches ;) A particularly embarrassing one, preventing the use of multiple regular expressions in the same command has been fixed. I will keep rebasing the branch onto master. Did anyone try it out, comments? -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
[dev] structural regular expression support for vis
On Tue, Mar 01, 2016 at 05:23:11PM +, Connor Lane Smith wrote: > On 1 March 2016 at 17:12, Marc André Tanner <m...@brain-dump.org> wrote: > > I think structural regexp will integrate nicely with multiple selections. > > > > Basically if you omit the command of a structural regexp the editor > > would switch to visual mode and add a selection for every match. If you > > are already in visual mode then the existing selections would be used > > as ranges for an implicit leading loop construct (x/ in sam). > > That is for an existing selection x/ and y/ could be used to split it. > > Similarly the conditionals g/ and v/ would be used to keep / discard > > selections. > > I agree (strongly!). My main complaint with sam is its inability to > reflect the multiple selections implied by its command language. It > would be fantastic if we could get that sorted, and vis may well be a > good place to do it. I finally had some time to experiment with these ideas. The results can be found in the "sam" branch of the vis git repository: https://github.com/martanne/vis/tree/sam For now sam commands can be entered from the vis prompt via :sam A command behaves differently depending on the mode in which it is issued: - in visual mode it behaves as if an implicit extract x command matching the current selection(s) would be preceding it. That is the command is executed once for each selection. - in normal mode: * if an address for the command was provided it is evaluated starting from the current cursor position(s) i.e. dot is set to the current cursor position. * if no address was supplied to the command then: + if multiple cursors exist, the command is executed once for every cursor with dot set to the current line of the cursor + otherwise if there is only 1 cursor then the command is executed with dot set to the whole file The command syntax was slightly tweaked to accept more terse commands. - When specifying text or regular expressions the trailing delimiter can be elided if the meaning is unambiguous. - If only an address is provided the print command will be executed. - The print command creates a selection matching its range. - In text entry \t inserts a literal tab character (sam only recognizes \n). Hence the sam command ,x/pattern/ can be abbreviated to x/pattern If a command is successful vis switches to normal mode (and hence removes any selections), otherwise the editor is kept in visual mode. The print command "fails" by definition. Some limitations of the command language as currently implemented include: - The following commands are deliberately not implemented: * move (m) * copy (t) * print line address (=) * print character address (=#) * set current file mark (k) * quit (q) * undo (u) I don't think they make sense / are important for interactive usage. - Multi file support is very basic. While the X and Y commands are in principle supported. They are essentially untested at this stage and probably even more buggy than the rest. Also a file might be displayed in multiple windows (possibly with different selections, although currently vis does not allow switching of windows in visual mode i.e. when a selection is active). Not yet sure what the right thing to do here is. What is sam doing in this case? * the "regexp" construct to evaluate an address in a file matching regexp is currently not supported. * the following commands related to multiple file editing are not supported: b, B, n, D, f. - The I/O related commands e, r, w, <, >, |, ! and cd are not yet implemented. These should not be hard to add later on. The equivalent vi commands :r !, :w !, :! are supported hence the necessary infrastructure to implement them is already there. - Error handling is only very bare bone. For example if you have multiple regular expressions in your command and one of them has a syntax error, there is no indication as to which one causes the problem. However this is not that bad since you can build your commands incrementally. As an example, if in doubt use: :sam x g/pattern :sam x/sub-pattern instead of :sam x g/pattern/x/sub-pattern - The special grouping semantics where all commands of a group operate on the the same state is not implemented. In general grouping has not yet been really tested. Your help in doing so is appreciated. - The substitute (s) command is currently not implemented. In general this command with its additional g flag (for global substitution) feels quite alien to the rest of the command language. I wonder whether it is necessary? However the ability to refer to (sub) expression matches with \& and \d where d is a digit will probab
Re: [dev] another text user interface for sam
On Wed, Mar 02, 2016 at 06:26:23PM +, Maxime Coste wrote: > In my experience, we dont need a very powerful (and complex) regex language > for interactive use, its mostly the highlighting system that needs them, In my experience syntax highlighting is a nice fit for Parsing Expression Grammars (PEG) because they are closed under composition. Furthermore there exists a nice Lua implementation with lexers for more than 100 languages. I see no reason to build and maintain yet another custom highlighting mechansim. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] another text user interface for sam
On Wed, Mar 02, 2016 at 10:40:51AM +, Maxime Coste wrote:
> On Wed, Mar 02, 2016 at 10:14:48AM +, Raphaël Proust wrote:
> > On 1 March 2016 at 17:12, Marc André Tanner <m...@brain-dump.org> wrote:
> > > I think structural regexp will integrate nicely with multiple selections.
> > >
> > > […]
> >
> > Yes! Interactive structural regexp would definitely be a Killer
> > Feature™ IMO. I would probably use an editor like that almost
> > exclusively.
>
> That has been provided by Kakoune for a looong time, you get structural
> regex interactively as you can subselect matches in current selections,
> keep only selections matching/not matching a regex, and push/pop a set
> of selections.
But (as far as I know) you don't get a consistent command language.
In this case Kakoune is in a way too interactive.
I want the possibility to store my most freqently used commands
in a regular "favorites" file where they can be exexcuted from. I
guess you could kind of hack something together with macros but that
is not the same.
Also something like sam's /X/ /x/ combination where you can modify
multiple files is not possible.
> > On 1 March 2016 at 20:35, Marc André Tanner <m...@brain-dump.org> wrote:
> > > On Tue, Mar 01, 2016 at 05:41:00PM +, Connor Lane Smith wrote:
> > >> On 1 March 2016 at 17:12, Marc André Tanner <m...@brain-dump.org> wrote:
> > >> > All commands of a group should operate on the original state of the
> > >> > text.
> > >>
> > >> Is that strictly necessary? I know that's how sam and acme behave, but
> > >
> > > I haven't yet made my mind up. It obviously changes the semantics of the
> > > command language.
> >
> > Why not have both? A parallel grouping mechanism ({} to keep
> > compatibility with sam) and a sequential one ([], or <>, or (), or
> > whatever).
>
> That can be nicely implemented interactively by just providing a save/restore
> selections mechanism.
I don't think this is the case. Unless you mean you actually save
the selection content not just their position.
> parallel grouping is then just a sequential list of
> commands where you occasionally recall the initial set of selections.
If you do store the selection content then you essentially implemented
an undo tree since as previously illustrated your grouped commands will
all have to start from the same state, thus creating new undo branches
which you will then have to merge somehow.
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] another text user interface for sam
On Tue, Mar 01, 2016 at 06:12:32PM +, Connor Lane Smith wrote: > We agree for pretty much the same reasoning. (I'm not sure > why you assumed otherwise.) Misunderstanding on my part I guess. These are just limitations of the regex(3) API but have no particular relevance for *structural* regular expressions. I.e. it is possible to build a structural regexp library on top of this crippled interface it probably just wont be particularly efficient. > > The corresponding section of the vis README[1] also has a few links to > > existing engines / algorithms used etc. > > I'm very familiar with the literature. Good to know, in this case you are probably more up to date than I am. For example a quick search led me to "Efficiently extracting full parse trees using regular expressions with capture groups" which I hadn't seen before. What is in your opinion the current state of the art technique/algorithm? > I think it's also worth looking > at the work of Grathwohl et al. (2013, 2014). For others wanting to take a look, I guess you are referring to the following papers: - Two-pass greedy regular expression parsing - Optimally Streaming Greedy Regular Expression Parsing > Anyway, this is why I > say such a library would need "quite careful planning." I agree. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] another text user interface for sam
On Tue, Mar 01, 2016 at 05:41:00PM +, Connor Lane Smith wrote:
> On 1 March 2016 at 17:12, Marc André Tanner <m...@brain-dump.org> wrote:
> > All commands of a group should operate on the original state of the text.
>
> Is that strictly necessary? I know that's how sam and acme behave, but
I haven't yet made my mind up. It obviously changes the semantics of the
command language.
> series of commands outside those {} blocks occur in sequence (not all
> performing on the original text), and to be honest that seems like it
> might be more intuitive.
As an example, swapping two words with
,x[a-zA-Z]+/{
g/fred/ v/./ c/jim/
g/jim/ v// c/fred/
}
which is mentioned in both the sam tutorial and the cheatsheet would
no longer work.
> It would also be much easier to implement.
Yes, I agree.
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] another text user interface for sam
Hi,
I too like the concept of structural regular expressions and would like to
experiment with ways to integrate them into vis. That is the reason why
I didn't bother implementing an ex mode and instead referred to ssam(1)
in the README.
I think structural regexp will integrate nicely with multiple selections.
Basically if you omit the command of a structural regexp the editor
would switch to visual mode and add a selection for every match. If you
are already in visual mode then the existing selections would be used
as ranges for an implicit leading loop construct (x/ in sam).
That is for an existing selection x/ and y/ could be used to split it.
Similarly the conditionals g/ and v/ would be used to keep / discard
selections.
Like in sam, the underlying data structure used in vis abstracts the text
as a byte stream which is a good match for structural regexp. Also vis
already supports an undo tree which might be useful to implement command
groups/multiple changes (i.e. {} in sam). All commands of a group should
operate on the original state of the text. Hence a command group would
be handled as follows:
1) Take a snapshot of the current text (state S)
For every command part of the group do
1.1) Execute the command (changes will create a new branch in the undo tree)
1.2) Take a snapshot of the current text (new state N)
1.3) Revert changes of the command i.e. go to state N-1 which is S.
2) If the changes in state S to N do not conflict then create a new
state N+1 with all changes merged, otherwise fail the command.
Unfortunately I will most likely not have time to work on this myself
for the next couple of weeks. However if someone wants to give it a try
I would be happy to answer questions related to the current vis code
base ...
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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] [vis] dw near the end of the line
On Sun, Feb 14, 2016 at 12:49:10AM -0500, Random832 wrote: > > Recently, the question of the correctness of vim's behavior of 2dw on > the first of three lines of one word each came up on the vim mailing > list (it turns out that it's not correct according to POSIX, but is > shared with traditional vi). > > At that time, I wasn't able to build vis to see what it does. I've since > figured out my build problem, and tested vis's behavior in this > situation. > > When you delete the last word of a line in vis with the dw command, it > always deletes the newline and all following spaces and newlines > (i.e. placing the content of the next non-blank line on the current > one). This behavior differs from most other vi clones, matching only > elvis-tiny. Is this behavior intended? Not sure, in practice vim's dw behavior is probably better in this case. It was done that way in vis because it is easier to implement. There are two main differences in this area: 1) in vis a motion always works the same way independent of whether it was invoked in an operator context or not. $ printf "foo\n \nbar\n" | vim - In vim w will jump to the start of "bar", but dw will only delete the content of the first line "foo". 2) an empty line is not considered a word by vis instead it skips to the next non white space symbol. $ printf "foo\n\nbar\n" | vim - In vim w will move to the empty line whereas in vis it moves to the start of "bar". -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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
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 <m...@brain-dump.org> 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] [vis] text_line_end() in insert mode
On Mon, Feb 01, 2016 at 10:02:28AM +, Raphaël Proust wrote: > Markus, Marc, , > > On 31 January 2016 at 18:56, Markus Teich <markus.te...@stusta.mhn.de> wrote: > > Marc André Tanner wrote: > >> The END-mapping was actually using text_line_lastchar not text_line_end. I > >> now added a new key action for text_line_end. The behaviour might still be > >> inconsistent (for example in vim's visual modes `$` seems to behave like > >> ) but at least it can now be configured via config.def.h. > > > > vim seems to be inconsistent here. > > It's not that simple. > > A subtle thing that vim does is that the notion of cursor is different > in normal and insert mode. Yes I'm aware of that and think it is a stupid/unnecessary thing to do. This is also the reason why repeated switching into/out of insert mode (i.e. ii ...) moves the cursor to the left. Previous discussion of these issues and resulting inconsistencies between vis/vim can also be found at[1]. > Idea: modify `st` so it can change `cursorahape` dynamically, modify > `vis` to change the cursor on mode change. This won't work because multiple cursors are intended to be first class citizens of vis and as far as I know there is no way to create those in the terminal (emulation) world. [1] https://github.com/martanne/vis/pull/54#issuecomment-116181551 -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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] [vis] vis lua integration not working when using lua 5.3
On Thu, Jan 21, 2016 at 09:29:01AM +0100, Silvan Jegen wrote: > On Thu, Jan 21, 2016 at 9:11 AM, Silvan Jegen <s.je...@gmail.com> wrote: > > I came up with only two general approaches. Either send error messages > > to the UI (including a sleep() so that errors further down in the call > > chain don't get eclipsed) or log them to a file (both approaches feel like > > bad choices). I wonder how other TUI programs handle their error messages. > > If we get rid of my assumption that we can only show one line of error > messages in the UI we could just write all errors into some kind of > "error buffer" and then display an "error stack" that way (without > having to resort to sleep()). Yes using a dedicated error file/window is the obvious way to do it. I implemented that in one of the last commits. A syntax error or failure to load a module from visrc.lua should no longer go unnoticed but instead print a stack trace. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [sbase] diff
On Thu, Jan 28, 2016 at 04:48:22PM +0100, Markus Wichmann wrote: > Comments? I'm not really up to date with all the different algorithms and haven't looked at the code, but for source code i.e. patches the Patience diff "pre-processing" seems to have some desirable properties: http://bramcohen.livejournal.com/73318.html Might also be something to look into ... -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [vis] vis lua integration not working when using lua 5.3
On Wed, Jan 20, 2016 at 03:07:28PM +0100, Silvan Jegen wrote:
> Has anyone used vis successfully with lua 5.3?
Yes I had it running with 5.3 at some point. I guess you do
not have LPeg installed (for 5.3). A first try would be to
change into the `lexers` sub directory inside the vis source
tree and start the lua interpreter:
$ lua
...
> lex = require('lexer')
> lpeg = require('lpeg')
This will attempt to load the required modules which will
likely fail and print a nice error message?
> print(package.path)
> print(package.cpath)
Will print the default package paths of Lua. Running vis under
strace(1) likely reveils that the lpeg library can not be found
in those paths?
Hope that helps. And yes error reporting will eventually be
improved ...
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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] [vis] text_line_end() in insert mode
On Wed, Jan 20, 2016 at 07:58:39AM +0100, Markus Teich wrote: > Heyho Marc, > > something I don't seem to be able to figure out: When pressing the END key in > insert mode, in vim the cursor moves after the last regular character in the > current line, basically over the newline character, if you choose to display > it. > In vis however it does only move to the last regular character, like in normal > mode. The text_line_end function called by the END-mapping seems to do the > right > thing. I'm lost, where the differentiation between normal mode (the cursor > cannot move beyond the last regular character) and insert mode has to be done > in > this case. The END-mapping was actually using text_line_lastchar not text_line_end. I now added a new key action for text_line_end. The behaviour might still be inconsistent (for example in vim's visual modes `$` seems to behave like ) but at least it can now be configured via config.def.h. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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
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
> > > 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, `\<view\>` works as it should. I propose to change > > > CURSOR_SEARCH_WORD_… to use `\<WORD\>` 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
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
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
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 hardcoding the fix is correct. > > > > - `*` does not behave the same as in vim. When using star on `view->bla` > > > it > > > should search for `\<view\>`, but it also found `view_draw`, so there > > > seems > > > to be something wrong with the word delimiters when used by `*` (searching > > > for `\<view\>` produces the expected result. > > > > There are no word delimiters used at all for the search string. In this case > > `*` is identical to `/view`. I'm actually surprised `\<view\>` works, does > > POSIX specify that (vis currently uses regex(3) function from libc to > > implement the search functionality). > > I also was surprised, `\<view\>` works as it should. I propose to change > CURSOR_SEARCH_WORD_… to use `\<WORD\>` as regex instead of just `WORD` to > achieve the same functionality as in vim. Yes I agree. > > > - Is hlsearch planned? > > > > Not concretely, but it was requested before and seems like a useful thing to > > have. incsearch was also mentioned. > > > > In general search suffers from some architectural limitations. It is not > > cancelable (some kind of async job framework to run long running task might > > be > > handy) and doubles memory consumption because the complete buffer is copied. > > This might be done with the global "syntax highlighter" mentioned above. It > has > to do the matching once per window change and then it should complete > reasonably > fast. As a sidenote: The hlsearch should of course be disableable (nice word!) > and reenableable (even nicer word!) on the fly. > > > > - I frequently use C-a and C-x to do basic addition/subtraction in vim. > > > > Really? Never used them. Vim seems to support all kinds of formats (decimal, > > hex, octal) which is road to madness ... > > Might be done in lua as well, I only use decimal with that feature. Is it > already possible to call lua from keybindings? No currently it is not. Some people also wanted to build/use vis without Lua (hi pancake if you are reading this ;) Therefore it is currently optional. However I generally think the benefits outweight the costs of additional size/dependency etc. > > > - 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. ;) > > You seem to have missed that question. This behaviour is fairly new to vim as > well. Sorry, should be implemented now. > > > - 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? > > > > With the current design the motions do not know about the given count. > > Instead the motion is performed a second time from the resulting postion of > > the previous one. Unfortunately this does not work for motions which are > > idempotent. What vis does is equivalent to `vtXtXd` in vim. > > Interesting, I just noticed when entering `tX` multiple times vim will not go > to > the next match but when entering `fX` multiple times it will. > > > 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 ... > > > - What about word/file/line completion in insert mode? > > > > Yes, not entirely trivial, should probably done via an external process? > > Will > > probably need quite some architectural changes, a proper main loop for a > > start > > ... > > I think I've read about some dmenu port to (n)curses, but I can't find a > reference. It is called slmenu and is currently used by vis-open to provide a basic file name completion. Make sure you have vis-open and either slmenu or dmenu somewhere in your $PATH and try `:e .` > > > - Why you no implement `g?`? ;) > > > > Did not yet miss it. Although I have heard of people who use it for > > interactive tutorials/exercise sessions. Where the questions are written in > > plain text and the corresponding answers are rot13 encoded until revealed > > ... > > Wow, if we actually meet some time (slcon 2016?), you are eligible for a free > beer for actually pointing out a reasonable use-case of this "feature"! Thanks for the offer, I will gladly accept it when the occasion arises. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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 `\<view\>`, but it also found `v
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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] dvtm-0.15
On Thu, Jan 14, 2016 at 08:08:49PM -0200, Marcel Rodrigues wrote: > Very nice! > > Seems like you need to update [0] & [1]. Thanks, updated! -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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
[dev] [ANNOUNCE] dvtm-0.15
[ANNOUNCE] dvtm-0.15 Hi, I just released dvtm-0.15, the tiling window manager for the console: http://www.brain-dump.org/projects/dvtm/dvtm-0.15.tar.gz with sha1sum 9bcec7af79b2adfead88c5513fa19b53dad6e134 dvtm-0.15.tar.gz Changes include: * More complicated default key bindings for potentially destructive actions to minimize the chance of accidental presses: MOD-x-xcloses the focused window MOD-q-qquits dvtm * Simplified client creation code, elimination of useless intermediate shell. This should fix Mod-C (the creation of a new window with the same working directory as the currently focused window) for systems where procfs is available. * Copymode coloring: if enabled in config.def.h (which is currently only the case for less) the piped scrollback buffer will contain escape codes to preserve the coloring. $ DVTM_EDITOR=less dvtm Generate some colored output and press MOD-e (i.e. CTRL-g-e by default) less should now display the same content (that is with color) and provide search functionality etc. * Urgent flag indications (after a client received a bell) are redrawn as soon as possible. * Small bug fixes for terminal emulation and mouse actions. Slight cleanup of config.def.h and the dvtm-status script. Cheers, Marc -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
[dev] [ANNOUNCE] abduco-0.5
Hi, I'm pleased to announce a new version of abduco which features a few important bug fixes and tweaks to the command line interface. http://www.brain-dump.org/projects/abduco/abduco-0.5.tar.gz with sha1sum 37c51a0d5c3dd216251d84d5c1b550f119ad53c9 abduco-0.5.tar.gz Changes include: * Stale sockets, left over from unexpected abduco terminations (e.g. being killed, a crash etc.) are detected and removed. * The default location for session socket information can now be configured via config.def.h and at runtime by changing the $ABDUCO_SOCKET_DIR environment variable. * The default command (if none is given on the command line) specified by setting the $ABDUCO_CMD environment variable is now executed using the shell. Hence the command can contain arbitrary arguments. As an example the following instructs abduco to launch dvtm with a non-standard modifier if no explicit command is given: $ export ABDUCO_CMD="dvtm -m ^b" $ abduco -c demo * The session list is printed whenever neither an action nor a session name (or socket path) was given. This allows to change the default detach key by means of a shell alias $ alias abduco="abduco -e ^q" and still get an overview over currently running sessions using $ abduco * Command line arguments can now be combined i.e. $ abduco -ar demo works where previously one had to specify $ abduco -r -a demo * New -l (low priority) option which will not change the terminal size, useful for non-interactive use. * Bugfix for the handling of -A (attach to session create it if it does not yet exist). * The cursor is always made visible after session detach. * The README contains an example of how to set up read only sessions using socat(1), illustrating how simple Unix tools can be combined. It also features a new section giving some basic debugging advice. Cheers, Marc -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
[dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
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] [vis] vis editor status update
On Wed, Dec 02, 2015 at 10:35:54AM +0100, Silvan Jegen wrote:
> Heyho
>
> Shame you couldn't make it to the suckless conference. I would have
> been interested in your talk about vis.
Maybe another time.
> On Sun, Nov 29, 2015 at 8:13 PM, Marc André Tanner <m...@brain-dump.org>
> wrote:
> > On Tue, Jul 28, 2015 at 06:48:56PM +0200, Marc André Tanner wrote:
> >> Recent changes in no particular order include:
> >
> > [...]
> >
> > - new input handling based on libtermkey supporting key aliases
> > - Lua LPeg based syntax highlighting using definitions from scintillua
> >
> > The last two items introduce dependencies on libtermkey (for input
> > handling) and Lua (>= 5.1) + LPeg for Parsing Expression Grammar
> > based syntax highlighting. Some of you might not like them, but in
> > my opinion they are the least sucking solutions I could come up with
>
> As far as embedable scripting languages go Lua seems like the most
> suckless solution. For me the much lauded simple "stack-like" Lua-C
> interface is not *that* easy to understand though.
Conceptually it is really simple, it just requires some time to get
used to the adressing modes (either from top or bottom of the stack)
and to become familiar with the most important functions.
> The advantages of the libtermkey input handling were not immediately
> evident to me when briefly looking at the code. What was the
> motivation for using the library?
Basically to get keyboard input in a vim like a symbolic key format.
Therefore the default key binding configuration in config.def.h
looks something like:
{ "", ... },
{ "j", ... },
instead of
{ KEY(BACKSPACE), ... },
{ CONTROL('w'), NONE('j'), ... },
which makes them useable for the :help output and will eventually
enable run time key bindings i.e. some sort of :map command.
Not strictly related, but key binding lookup was also simplified by
storing these strings in a crit-bit tree based map.
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] scrollback with st
On Sun, Nov 29, 2015 at 07:56:37AM -0500, Greg Reagle wrote: > On Sun, Nov 29, 2015 at 12:22:18PM +0100, Rashad Kanavath wrote: > > 2. when I have something printing on console (eg: an ongoing > > compilation), it goes back to the last line or IOW it scroll down. > > I was expecting the line to be where it is whether or not I have any > > output on console. > > I know what you mean. DVTM will automatically scroll back down to the bottom > when there are new characters to be displayed. Sometimes I want this > behavior, and sometimes I don't. Within dvtm pressing MOD+e (i.e. CTRL-g e) will launch a pager / editor with the current scroll back buffer content. Giving you access to search functionality etc. This might be useful in some cases ... -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Re: [dev] [dvtm] TERMINFO problem with copymode
On Mon, Aug 31, 2015 at 12:17:06PM -0400, Ross Mohn wrote:
> Over the weekend, I finally put in the hours to figure out why dvtm's
> copymode works fine at home, but doesn't work at all on my servers at
> the office. At work, I use shared UNIX hosts without root access. I
> compile with
> PREFIX=~/local
> so that I have my own compiled apps and customizations. My dvtm terminal
> info files are installed under $PREFIX, and when I'm running inside dvtm
> I have set
> TERMINFO=~/local/share/terminfo
>
> The problem occurs when the child process of vt_forkpty() calls execvp()
> to switch to the editor program. The environment variable TERM is set to
> dvtm-256color, but TERMINFO is not set. The call to execvp() is
> successful, but the editor crashes because it doesn't understand the
> TERM (I tested with vis, vim, and less). I don't know the best way to
> fix this so for myself, for now, I just hardcoded
> setenv("TERMINFO", "~/local/share/terminfo", 1);
> after the setenv() line for TERM.
Environment variables should be passed on. I just tried the following:
$ TEST=Hello dvtm
Then within dvtm the variable is available as can be confirmed by:
$ env | grep TEST
Now enter copy mode (to vis) where we run:
:r ! env | grep TEST
The variable is read as expected ...
> I thought through some actual solutions, but none seemed to fit well.
> I'd love to hear some ideas!
>
> Incidentally, the fprintf(stderr, ...) statement after execvp() doesn't
> do anything because the child's stderr doesn't go anywhere meaningful.
I can confirm this, but do not really understand why it is happening.
There is a loop which closes any file descriptor >= 3 which should leave
stderr intact.
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dev] [dvtm] Commands document, one page PDF
Hi Ross, Thanks for your work! I agree that the documentation could be improved. A couple of comments regarding the content of your document: - The command column doesn't seem that useful for an end user. It might be better to add source code comments to the corresponding function prototypes in dvtm.c explaining what the function does and what kind of arguments it expects. - CTRL-G should be replaced by $MOD The document itself should be generated from a plain text format, be it Markdown, troff, LaTeX or something else. The source file should also be maintained in the git repository. Another idea would be to add a built in "help system" similar to the way it was done in the latest vis commits where :help prints the currently active key bindings alongside a short description. https://github.com/martanne/vis/blob/master/config.def.h#L227 This would have the advantage that it always matches the active key bindings. Might be a bit overkill though ... Thanks, Marc -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
[dev] [vis] vis editor status update
Hi, What follows is a quick overview of recent changes made to vis, my vim-like editor: https://github.com/martanne/vis I've been using it for some time now and most of my needs are covered. I hope to get a release out later this year. Unfortunately I probably won't have time to work on it during the next couple of weeks. Therefore it seems like a good time to get more testing feedback. What is still missing? Which bug/feature needs to be fixed/implemented for your daily usage? Recent changes in no particular order include: - multiple cursors/selection support This is all brand new and quite rough around the edges. For example selections are not merged if they overlap. I have a couple of ideas for further improvements but currently not enough time to pursue them. For now the (somewhat arbitrary, suggestions for better alternatives welcome) recognized key bindings are, in normal mode: CTRL-J create a new cursor on line below CTRL-K create a new cursor on line above CTRL-P remove least recently added cursor CTRL-N select word the cursor is currently over, switch to visual mode CTRL-A try to align all cursor on the same column ESC if a selection is active, clear it. Otherwise dispose all but the primary cursor. In visual mode: CTRL-N create new cursor and select next word matching current selection CTRL-X clear (skip) current selection, but select next matching word CTRL-P remove least recently added cursor CTRL-O creates a new cursor at the start of every line covered by the current selection - undo tree implementation with corresponding :later and :earlier commands - :! filter implementation, also used for :read and :read ! - :substitute implementation in terms of sed(1) - integration of slmenu/dmenu for a file open dialog (e.g. :open *.[ch]) - more robust file save implementation (e.g. does no longer destroy links, tries to preserve xattrs and hence SELinux labels if enabled) - detection of file changes outside the editor when saving - improved handling of file truncation on mmap-ed files - insertion of verbatim characters based on Unicode code point (CTRL+V u) - option to display special symbols for white spaces :set show newlines=1 tabs=1 - highlight of matching symbols (e.g. parenthesis) when cursor is over them - try to preserve column position when moving across lines - ui separation, all curses related stuff isolated into one file - introduction of some testing infrastructure for both low level unit tests and high level editor tests (see test branch) - dump piece chain and undo tree as graphviz graph (see text-dump branch) Things I would ideally like to fix/implement before a release: - improvements to repetition command (i.e. dot .) #44 - implement a minimal vim compatible swap/lock file #58 - history support for command and search prompt (although duplicating shell/readline functionality inside the editor still feels wrong) - increase test coverage (see test branch) Long term goals/ideas: - eliminate remaining global state, expose vis frontend as a library - improvements to search functionality / efficient regex engine - introduction of a proper (libuv based?) mainloop - RPC interface #59 / client+server architecture - quickfix functionality - revise syntax highlighting code, investigate whether already existing syntax definitions from other editors could be reused - runtime key binding support? - code completion (using slmenu/dmenu)? As always comments and especially patches welcome! Thanks, Marc -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [dvtm] create in $CWD not working
On Wed, Jul 15, 2015 at 12:59:33PM -0400, Ross Mohn wrote: On Wed, Jul 15, 2015 at 05:45:49PM +0200, v4hn wrote: On Wed, Jul 15, 2015 at 11:32:38AM -0400, Ross Mohn wrote: $ pstree -p 2199 dvtm(2199)─┬─sh(2239)───bash(2240)───mutt(11096) ├─sh(2324)───bash(2325) ├─sh(12015)───bash(12016)───vim(17544) └─sh(12116)───bash(12117)───pstree(21626) Fix your setup. Spawning two shells is stupid already, but to keep the outer shell (your generic sh) running is insane. exec could help, but reviewing the spawn process to avoid sh to spawn your shell would be better. Thanks, that led me to the solution! Patch is attached, and should work for all users. Please test and apply. Thanks, applied! For some reason this already worked as expected on my system. PS: I'm now also subscribed to hackers@ -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
[dev] Re: [dvtm] Default command mapping changes
On Tue, Jul 14, 2015 at 02:45:20PM -0400, Ross Mohn wrote: In an effort to bring more attention to the dvtm project, I'm working on some additional documentation. Thanks, that is appreciated. In the process, I've done a full review of all the default command keys and would like to propose the below changes to the defaults. These are probably appropiate for dwm as well, but since I no longer use that application, I'll leave that to someone else to propose. First, the killclient and quit commands are very desctructive and too easy to press by accident with sometimes disasterous results. Because of this, I propose that the key presses be doubled to the following, to be sure that they are intentional. killclient MOD+x+x quitMOD+q+q I tend to agree. Next, I'd like to have the incnmaster and setmfact defaults changed. This also allows the easy mapping of two additional commands: one for putting all windows into the master window (incnmaster(99)), and the other for resetting nmaster back to 1 (incnmaster(1)). Using '' and '' for setmfact is also consistent with resizing the width of windows in Vim. Since I'm also a heavy dwm user I would like to keep the key mappings identical where it makes sense (as is the case for incnmaster). However for those bindings which do not conflict, I'm willing to add additional vim like mappings. From your proposal these would be: setmfact(+0.05) setmfact(-0.05) setlayout(fullscreen) o setlayout(tile) = -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [PATCH][vis] Do not take a snapshot in text_range_write
On Tue, Jun 23, 2015 at 08:36:01PM +0200, Silvan Jegen wrote: This is a quick and dirty fix for the issues encountered with undoing the filter command. There are still other issues to tackle though... Thanks, applied. Could you elaborate on the remaining issues to tackle? -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][RFC][PATCH 2/2] Implement the execution of external commands and cmd_substitute
On Wed, May 27, 2015 at 06:53:11PM +0200, Silvan Jegen wrote: On Mon, May 18, 2015 at 10:28:06PM +0200, Marc André Tanner wrote: On Mon, May 18, 2015 at 09:31:22PM +0200, Silvan Jegen wrote: I did some light testing and the only issue I could find is that the undo-function is behaving strangely. Yes I noticed this too. At some point while writing the patches I also managed to trigger a segfault when redoing stuff. Might be a more general problem although in general the editor seemed rather stable during daily usage ... When tracing I found that the text_range_write function in cmd_filter creates a text snapshot when called. If I uncomment this call to text_snapshot (and the write to txt-saved_action), undoing the whole filter operation works but re-doing it is broken (the re-doing seems to be broken in other cases as well though). Uncommenting this text_snapshot function call may also have other consequences for other codepaths though so I will need more time to see whether there is another way to make undo work. Taking a snapshot in text_range_write is definitely a bug, it was done there under the assumption that the function is only ever called when saving the file. However this is no longer the case ... -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] Re: [abduco] Strange behavior with abduco -A
On Wed, Jun 03, 2015 at 10:34:44AM -0400, Ross Mohn wrote: On Tue, Jun 02, 2015 at 12:26:38PM -0400, Ross Mohn wrote: Hi, After my last pull a few weeks ago, I started noticing some strange behavior with abduco and I want to know if others can reproduce it. Here are the steps: 1) Run 'abduco -A foo ping suckless.org' 2) Press 'CTRL+\' to detach 3) Run 'abduco -A foo' to reattach 4) Press 'CTRL+\' and it flashes the screen but does not detach 5) Press 'CTRL+\' a second time and it detaches this time Here's what the output looks like: $ abduco -A foo ping suckless.org abduco: foo: detached $ abduco -A foo abduco: foo: detached abduco: foo: detached $ I found where this issue was introduced and I propose the attached patch to fix it. Thanks for your analysis and the patch, it has been applied. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [dvtm] TAGKEYS macro for dvtm
Sorry for the delay, I'm catching up ...
On Tue, May 26, 2015 at 02:35:42PM -0400, Ross Mohn wrote:
diff --git a/config.def.h b/config.def.h
index b0a68d4..b7d4769 100644
--- a/config.def.h
+++ b/config.def.h
@@ -51,7 +51,7 @@ static Color colors[] = {
/* curses attributes for not selected tags which with urgent windows */
#define TAG_URGENT (COLOR(BLUE) | A_NORMAL | A_BLINK)
-const char tags[][8] = { 1, 2, 3, 4, 5 };
+const char tags[][8] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
I left out this part for now. While I'm not generally opposed to it,
I think it should be changed independently. From time to time I work
in a 80x24 setting and wonder whether spending that much space for
tags makes sense ...
+ TAGKEYS( '1', 0)
Also it might be more intuitive to pass in the same tag number here
and subtract one inside the TAGKEYS macro? I.e.
TAGKEYS('1', 1)
But as it is the same in dwm, I will leave it for now ...
Thanks
--
Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [dvtm] Bug fix for MOD after a mouse action
On Fri, Jun 05, 2015 at 07:11:32AM -0400, Ross Mohn wrote: After a mouse action, the key_index needs to be set back to zero. You can reproduce the bug by performing a mouse action, then trying to perform a dvtm keyboard command. You'll see that the MOD key is not matched with a key binding, so will print to the current terminal instead. Thanks, applied. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [dvtm] Mouse clicks on tags patch
On Fri, Jun 05, 2015 at 11:43:27AM -0400, Ross Mohn wrote: Hi again, The attached patch allows you to assign functions to mouse clicks on the tag indicators in the status bar. The default actions are: * left click to toggle viewing that tag * left double click to view only that tag * middle click to view all tags * right click to toggle assignment of the current client to that tag I want to expand the functionality to include the ability to assign functions to mouse clicks on other parts of the status bar, such as clicking on the layout indicator to cycle through the layouts, and clicking on the text area to create a new client. But, this will be much cleaner and require much less code if we switch the mouse handling to be more like that of the current dwm code. So, I've attached this patch as is, with its functionality for pressing just on the tag indicators in the status bar, but I'm stopping there and will work on rewriting the mouse handling in general within dvtm. I agree that the mouse handling code could be cleaned up. What is the state of your rewrite? Should I wait for it, or should I consider applying the patch as is? Thanks -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [dvtm] TAGKEYS macro for dvtm
On Mon, May 25, 2015 at 04:03:17PM -0400, Ross Mohn wrote: On Mon, May 25, 2015 at 12:45:07PM -0700, Eric Pruitt wrote: On Mon, May 25, 2015 at 03:24:14PM -0400, Ross Mohn wrote: The TAGKEYS macro from dwm's config.def.h is approriate for dvtm as well. Patch is attached. The parentheses in the patch seem to be unbalanced. They may seem that way, but if you count them out they're balanced. My compiler also thinks that they are unbalanced ... -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [dvtm] Pertag patch for dvtm
Hi Ross, On Mon, May 25, 2015 at 03:22:08PM -0400, Ross Mohn wrote: Hi all, I sent this directly to Marc, but I think it would be useful to post Yes, sorry for the radio silence. I thought I replied to your mail but looking back I apparently did not. Upon first glance the implemenation seems simple enough. here as well. The attached patch for an implementation in dvtm of the dwm pertag patch. It actually plays much more nicely with multiple tags than I had anticipated. I think it's appropriate for the master branch, but that's not up to me. I'd love to hear some feedback! I personally have never used the pertag patch and will have to try it out to see whether it suits my workflow. Therefore I don't yet have an opinion on whether it should be merged into master. Also up until now dvtm didn't really have major out of tree patches nor a place to keep track of them. If there is interest I could offer to push it to a topic branch and update it before every release. Unfortunately I most likely won't have time during the next 2-3 weeks to properly try it out ... Thanks, Marc -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] dvtm: don't change master or numbering
On Fri, May 22, 2015 at 02:26:30PM -0400, Greg Reagle wrote: Hello. I would like dvtm to behave differently. I don't want creating a new shell window (Mod-c) to make the new shell window the master; I want the master to stay the master. Why would you want that? It seems natural to place the new window in the master area. It is also how dwm behaves. I also don't want creating a new shell window to renumber all the windows; I want the new window to be one plus the last window number. For me the number refers to a place where the window is being displayed hence if I select MOD+2 I always want to select the first window of the stack area. If you want a stable and unique identifier for a window (e.g. for scripting purposes) you can use its id. However since the ids only ever increase (after closing a few windows you will encounter gaps) it is probably not what you want. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][PATCH v2] Make the '.' Filerange work on one line
On Fri, May 15, 2015 at 10:16:49AM +0200, Silvan Jegen wrote:
---
The first version broke some functionality. This one doesn't by doing
some more ugly checking.
We also make sure that we include the newline by using text_line_next
instead of text_line_finish.
vis.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/vis.c b/vis.c
index 051f256..a714bf0 100644
--- a/vis.c
+++ b/vis.c
@@ -1701,6 +1701,7 @@ static Filerange parse_range(char **cmd) {
Text *txt = vis-win-file-text;
Filerange r = text_range_empty();
Mark *marks = vis-win-file-marks;
+ char orig = **cmd;
switch (**cmd) {
case '%':
r.start = 0;
@@ -1714,8 +1715,11 @@ static Filerange parse_range(char **cmd) {
break;
default:
r.start = parse_pos(cmd);
- if (**cmd != ',')
+ if (orig != ',') {
This part is wrong. I commited a (hopefully) fixed version.
--
Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][PATCH] Make the '.' Filerange work on one line
On Thu, May 07, 2015 at 09:39:23AM +0200, Silvan Jegen wrote: On Wed, May 6, 2015 at 8:35 PM, Marc André Tanner m...@brain-dump.org wrote: Also should '.' include the new line character? It seems like it does in vim. Then text_line_next should be used. I think the behavior should mirror Vim in this case. Agreed. At the moment if no range is specified the range is set to the whole file in exec_cmdline_command. This should probably be changed such that the commands are called with an empty range. Then each command can decide what its default should be. For example :write should This sounds like a good idea. Yes. default to the whole file while :s/foo/bar/ should only be applied to the current line by default. I noticed that vis behaves differently to Vim when no range is given. Considering that I think the use case of wanting to change the whole file is more common than just wanting to change only one line, I prefer vis' current behavior. Do you want to change it anyways? The current behaviour is fine by me. Do you plan to send an updated patch with the discussed changes? Thanks. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Add '--' as end of options.
On Sat, May 09, 2015 at 11:17:07PM +, non...@inventati.org wrote:
Maybe just copy and use arg.h from st or dwm?
Doesn't it stop after the first non argument occurs? In vis options
and file names can be alternated i.e.
$ vis +/pattern1 file1 +/pattern2 file2
should open file{1,2} with the cursor placed at the first occurrence
of pattern{1,2} respectively.
--
Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][RFC][PATCH 2/2] Implement the execution of external commands and cmd_substitute
On Thu, May 07, 2015 at 10:15:34AM +0200, Silvan Jegen wrote: On Wed, May 6, 2015 at 9:47 PM, Marc André Tanner m...@brain-dump.org wrote: Thanks, this will require more time to properly review than I currently have. What follows are therefore only a few general remarks. The code for the read/write loops communicating through a pipe with the external process is very ugly. There must be a better way to implement the pipe communication but I could not figure it out. This is where a proper libuv based main loop would come in handy. Ideally the editor core should remain responsive while the asynchronous I/O is beeing done. There should be some kind of progress indication and a way to cancel those long running tasks. Also while doing so the text should essentially be marked read only. I agree that having a responsive editor is of utmost importance and a progress indication would be nice to have. What I am not so sure about is the following points: * If the text is marked read only anyways, is it actually useful to have a responsive editor at all? * Measuring progress is hard when you do not know the goal. In the sed case you can only guess how much progress has been done by comparing the count of input and output bytes for example. Even then, since you can do something like 's/a//g' there is no direct correspondance. That said, there is the 'pv'[0] program that does something similar. I assume it just checks the amount of data sent through the pipe (but depending on the buffering and processing speed of the output end of the pipe, predictions on running time will probably be quite inaccurate)? Maybe progress indication is the wrong word. I wasn't thinking along the lines of percentage completed but rather an indication that there is a background task running and a way to cancel it. * Is it worth adding the libuv dependency in that case? If I ever find the time to experiment with a client/server architecture then a proper mainloop will be needed. Using something like libuv doesn't seem like the worst idea ... This approach uses a unnecessary amount of memory too since it keeps a lot of the input data for the external process This should not be necessary, it should be possible to repeatedly call text_range_write (ignoring for now that it always takes a snapshot) with a resonable range which is adjusted each time. as well as its output data in memory at the same time Similarly it should be possible to insert the data from the external process as it becomes available. One idea is to write the new data after the specified range which is being written out. This is of course true. At the same time that would mean that the external command and the text_range_write have to be called several times which has some overhead (especially with big ranges of course) while requiring more elaborate logic. It's a tradeoff. I'm not sure why you think the external command would be called multiple times? Instead of your current approach of first copying the data into a contiguous memory block you would simply repeatedly call text_range_write in a loop with different ranges. Similarly to how you are currently doing it with write(2). Assuming we want to process the range [10, 100] it would work as follows: 1) text_snapshot 2) while (data to write or data to read) if (data to write) write range [10, 20] (on next iteration [20, 30] etc ...) if (data to read) read range and insert into [100, 110] ([110, 120], ...) 3) read command exit status depending on success - either delete original range [10, 100] and snapshot - or revert to last snapshot (text_undo) I think that would work but in case that there is some text after position 100 already you would have to either 1. handle the existing text by moving it on each insertion This is of course done implicitly. However no data is moved around. Upon the first insertion a new piece is created and linked in at the respective position. Since the inserts are contiguous the piece is then simply expanded by appending the new data to the existing buffer. That is further inserts basically amount to a memcpy(3) (ok that is a bit simplified, but true in principle). The main overhead multiple text_inserts have is the mapping of a file position i.e. a byte offset to the corresponding place in the piece chain. Currently this has linear complexity in the number of non consecutive editing operations in the file. Since this mapping is used by almost everything it is a natural candidate for optimizations (if it ever turns out to be a bottleneck). -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][PATCH] Use the command name without the Filerange in argv
Thanks, will apply. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][RFC][PATCH 1/2] Replace first '/' of substitute command with \0
On Tue, May 05, 2015 at 06:25:29PM +0200, Silvan Jegen wrote: Replacing the first '/' allows the 's' command name to be correctly identified even though it is part of its own argument. Special casing '/' seems wrong, an arbitrary delimiter can be used :s,foo,bar is perfectly valid. The end of the command name should probably be detected by isalpha(3) or similar. Hence instead of doing a strdup(...) we should probably do a malloc(strlen(...)+2) in combination with a strcpy/memcpy and then memmove(...) the arguments one position to the right and NUL-terminate the name. This is hacky because afterwards we will add the '/' back in before calling the 'sed' program. Relying on the fact that cmd_set was called with (i.e. that argv[0] was set to) ':s/' is wrong, it could also be ':substitute/'. With the strategy outlined above argv[1] would contain the argument (= search pattern) which could be prefixed by 's'. Furthermore if the pattern doesn't contain the delimiter at the end, it should be appended. Please send an updated patch if you think this makes sense ... -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][RFC][PATCH 2/2] Implement the execution of external commands and cmd_substitute
Thanks, this will require more time to properly review than I currently have. What follows are therefore only a few general remarks. The code for the read/write loops communicating through a pipe with the external process is very ugly. There must be a better way to implement the pipe communication but I could not figure it out. This is where a proper libuv based main loop would come in handy. Ideally the editor core should remain responsive while the asynchronous I/O is beeing done. There should be some kind of progress indication and a way to cancel those long running tasks. Also while doing so the text should essentially be marked read only. This approach uses a unnecessary amount of memory too since it keeps a lot of the input data for the external process This should not be necessary, it should be possible to repeatedly call text_range_write (ignoring for now that it always takes a snapshot) with a resonable range which is adjusted each time. as well as its output data in memory at the same time Similarly it should be possible to insert the data from the external process as it becomes available. One idea is to write the new data after the specified range which is being written out. Assuming we want to process the range [10, 100] it would work as follows: 1) text_snapshot 2) while (data to write or data to read) if (data to write) write range [10, 20] (on next iteration [20, 30] etc ...) if (data to read) read range and insert into [100, 110] ([110, 120], ...) 3) read command exit status depending on success - either delete original range [10, 100] and snapshot - or revert to last snapshot (text_undo) -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][PATCH] Make the '.' Filerange work on one line
When an incomplete range is specified i.e. only a start position
the cursor should jump to it. This patch breaks this functionality.
For example :nn (absolute line), :+n (relative line), :'m mark
(move to mark) is broken.
You probably want something ugly like the following?
On Tue, May 05, 2015 at 06:23:53PM +0200, Silvan Jegen wrote:
Signed-off-by: Silvan Jegen s.je...@gmail.com
---
vis.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/vis.c b/vis.c
index 051f256..cf157f7 100644
--- a/vis.c
+++ b/vis.c
@@ -1714,8 +1714,10 @@ static Filerange parse_range(char **cmd) {
break;
default:
char start = **cmd;
r.start = parse_pos(cmd);
if (**cmd != ',') {
if (start == '.')
r.end = text_line_end(txt, r.start);
return r;
}
Also should '.' include the new line character? It seems like it does
in vim. Then text_line_next should be used.
At the moment if no range is specified the range is set to the whole
file in exec_cmdline_command. This should probably be changed such
that the commands are called with an empty range. Then each command
can decide what its default should be. For example :write should
default to the whole file while :s/foo/bar/ should only be applied
to the current line by default.
Thanks,
Marc
--
Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Add '--' as end of options.
Some programs (like ranger) expect the editor to have this feature. Thanks for the patch, however it doesn't do what it describes? $ vis -- -v Still prints the version instead of opening a file called -v. Also it would be nice to add a note to the man page. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Fix handling of file load errors
On Tue, Apr 14, 2015 at 05:25:15PM +0200, Willem van de Krol wrote: Permission errors are handled in text_load(). To detect these errors, and other open() errors (opening a directory, for example), check the return value of text_load(). This fixes a segmentation fault when opening a directory. Also, opening a file you are not permitted to read, will now give an error, instead of showing the file as empty. Thanks again for the patch! The issue should hopefully be fixed by http://repo.or.cz/w/vis.git/commitdiff/7aa5fcb1a8ea079dd1c8d948a170ddc56fc1c53d Cheers, -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Fix handling of file load errors
On Tue, Apr 14, 2015 at 05:25:15PM +0200, Willem van de Krol wrote: This fixes a segmentation fault when opening a directory. Also, opening a file you are not permitted to read, will now give an error, instead of showing the file as empty. Yes this needs improving, however your patch breaks the simple case of opening/creating a not yet existing file as in: $ vis fancy-new-file-name [...] # editing :wq -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Highlight null directive.
Thanks, applied! -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][PATCH] small change to syntax coloring
On Sat, Apr 04, 2015 at 07:11:29PM -0400, Aaron Burrow wrote: This patch makes it so that the syntax coloring updates when you give a document a name for the first time. Thanks, I will incorporate your changes later on. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Fixed multiline comment regexp.
On Thu, Apr 02, 2015 at 02:27:31AM +0300, noname wrote: Comments like /***/ with odd number of asterisks are handled like normal comments now. Previously they were handled like unfinished comments. Could you please provide a more complete test case? I can't seem to reproduce it here. Support for comments without opening /* at the beginning of the file is removed because people do not normally write comments backwards. At the moment vis only considers the currently visible text for syntax highlighting. The rule you removed is a hack to catch multiline comments even when their start marker /* has been scrolled off the screen. And yes the whole syntax hightlighting probably needs a redesign. At some point I should take a look how vim/sublime/other editors which supports a lot of languages configure their syntax highlighting and reuse/convert their rule set. However given the implementation complexity (~50 LOC without rules) of the current solution, it works suprisingly well (at least for C like languages) ... -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Fixed multiline comment regexp.
On Fri, Apr 03, 2015 at 07:44:22PM +, noname wrote: Comments like /***/ with odd number of asterisks are handled like normal comments now. Previously they were handled like unfinished comments. Thanks applied! -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Change behaviour of 'cw' and 'cW'
Thanks for the patch, see the inline comments below for some remarks.
---
vis.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/vis.c b/vis.c
index 11cf1af..d18948a 100644
--- a/vis.c
+++ b/vis.c
@@ -556,6 +556,13 @@ static void op_delete(OperatorContext *c) {
}
static void op_change(OperatorContext *c) {
+ if(action.movement-txt == text_word_start_next) {
+ action.movement-txt = text_word_end_next;
+ action.movement-type |= INCLUSIVE;
your permanently changing movements here, once this is executed 'w'
will behave as 'e'. What you probably wanted is something along the
lines of:
if(action.movement == moves[MOVE_WORD_START_NEXT])
action.movement = moves[MOVE_WORD_END_NEXT];
To prevent errors like these, the various pointers in the Action struct
should be marked const.
However this still won't work because when
op_delete(c);
is called, the movement has already been performed and op_delete works
based on c-range (that is the range spanned by the original movement).
The proper way to fix this is to check in movement(...) whether the
action.operator is set to ops[OP_CHANGE] and if so adjust
action.movement accordingly.
Would be nice if you sent a follow up patch.
--
Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Change behaviour of 'cw' and 'cW'
On Fri, Apr 03, 2015 at 05:44:29PM -0300, Matias Linares wrote: To prevent errors like these, the various pointers in the Action struct should be marked const. Should I add this changes on the patch? I will do it in a separate patch. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
[dev] [vis] ui separation and mainloop considerations
I just pushed a fairly invasive change which tries to separate out all the ui related code into a single file: ui-curses.c. The idea is that by implementing the interface of ui.h it should be possible to add a different user interface backend. This should also be useful if somebody finds the time and motivation to write unit tests with a dummy ui ... However this is not yet complete, for example keyboard input is still handled directly in vis.c. There is also a slight regression in that the active mode is currently not displayed in the status bar of the window. I hope to fix this later by eliminating the remaining global state found in vis.c. Please let me know if something else is broken too. Further cleanup patches are always welcome! Another feature I would like to implement is the :! i.e. to filter text through an external command. In the long term I would also like to experiment with a client/server architecture where each window would be an independent process. These features require a proper mainloop and I'm considering using libuv. What is your opinion on libuv? Is there a better alternative I should look into? What would you use for communication purposes? Sending raw structs around or using something like msgpack? http://repo.or.cz/w/vis.git https://github.com/martanne/vis -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [PATCH][RFC] bug: copy the command string in order to not sigsegv
On Sat, Mar 28, 2015 at 04:54:13PM +0100, Silvan Jegen wrote: When using the ZQ/ZZ keybindings we end up writing to a string literal which results in a sigsegv. In order to avoid that we have to copy the command name string. Signed-off-by: Silvan Jegen s.je...@gmail.com --- Heyhey With this solution to the problem we end up copying all command names which I do not like. A better approach would probably be to use function pointer *func of struct KeyBinding for ZZ/ZQ to just exit the editor (with or without saving) instead of using cmd - exec_command - exec_cmdline_command. I'm in the process of separating the ui related code and generally providing a more library like interface to the the vis core, exec_command should thus take a const pointer and not modify its argument. While I agree the copying is somewhat ugly it is probably the right thing to do. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis] buffer_alloc issues
On Wed, Mar 25, 2015 at 07:15:08PM +, non...@inventati.org wrote: I'm not sure if vis is supported in suckless mailing list, but as it was discussed here previously, i'm writing here. There are two issues with buffer_alloc function(s). First function is located in buffer.c: http://repo.or.cz/w/vis.git/blob/HEAD:/buffer.c The problem is on line 15: http://repo.or.cz/w/vis.git/blob/HEAD:/buffer.c#l15 If realloc fails, buf-data is set to NULL, but original buf-data is not freed, see realloc(3). The result of realloc should be stored in separate variable and buffer_free should be called to free buf-data and set size and len to 0 if realloc fails. I agree, thanks for the report. Do you mind sending a patch? In general all memory allocation should be checked, keeping the current state is always preferable to crashing and losing unsaved changes. Another issue is that there is another buffer_alloc in text.c: http://repo.or.cz/w/vis.git/blob/HEAD:/text.c Maybe these functions and data structures should be renamed to avoid name conflict. I'm not sure I agree, what alternative name do you suggest? -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][PATCH] Implement 'o' in visual mode: go to other end of selection.
On Tue, Mar 24, 2015 at 04:36:14PM -0300, Marcel Rodrigues wrote: Thanks for the helpful reply! I have reworked the patch (see attachment) based on your input. Thanks, applied. -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dev] [vis][PATCH] Implement 'o' in visual mode: go to other end of selection.
On Tue, Mar 24, 2015 at 12:22:14PM -0300, Marcel Rodrigues wrote: Hello, This feature makes it easier to extend the selection in both directions. The behavior is the same as in vim: in visual mode, the 'o' key toggles the cursor position between the two ends (handles) of the selection range. The attached patch seems to work as expected Thanks, I will apply it later! Did you also test it with some multi byte characters? I think your sel.end-1 should be replaced by text_char_prev(vis-win-text, sel.end). And yes the whole selection handling should be cleaned up. At the moment it is internally (in window.c) represented as an interval [start, end) that is the selection end is denoted by the start of the last selected character. However window_selection_get returns it as [start, end], notice the text_char_next call. To make things worse window_selection_set currently expects the former format. That is window_selection_set(window_selection_get(...)) will actually extend the selection. Cleanup patches welcome! Other things to consider when overhauling the selection handling - support for multiple selections (maybe a selection should not only have a start and an end point, but also an anchor?) - visual block mode, which might or might not be best represented as a set of individual selections ... but I'm not sure it's the correct way to implement this (I'm still a bit confused about the different ways that movements are implemented in vis). The way you choose via the moves[] array with a corresponding enum value is for movements which can be used in conjunction with an operator and should thus be repeatable. Other reasons to do it this way are support for a count argument as in 3j, or registration in the jump list. The other way to do it is via an independent function which simply internally calls window_cursor_to. This should be used if nothing of the previously mentioned (repeatable, count argument, jumplist ...) is necessary. Your particular case might be better suited for the second case? That was the original idea, however in practice it is not strictly followed. For example navigation of the jumplist/changelist is done via the second option which means it can't be prefixed with a count. Thanks! -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
[dev] [ANNOUNCE] abduco-0.4
Hi, This is mostly a bug fix release for non-Linux systems. http://www.brain-dump.org/projects/abduco/abduco-0.4.tar.gz with sha1sum ccd576eb57d9481d5f372e31ce84b3020f661b68 abduco-0.4.tar.gz Changes include: * Fix socket creation on non-Linux systems * More secure socket creation: the sockets are now created in a directory only accessible to the current user. Either in $HOME/.abduco or as a fallback in /tmp/abduco/$USER. When upgrading you probably want to chmod 700 $HOME/.abduco or completely remove it (it will be recreated upon first invocation). Previously the permission was set on the socket itself which is not portable. * Remove -C flag and instead introduce -f which forces session creation when combined with one of [-c|-n|-A]. * Rewritten README in markdown Cheers, Marc -- Marc André Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
