Re: [dev] lock (1) - a dead simple lock script
Hi Calvin, Thanks for sharing it, it's really neat! I have the same problem with some cron jobs, but I use lockrun[1]. It's source code is quite simple[2] too. The reason why I would still stick with lockrun is that in the context of cron jobs, it is better that the task does not runs than piling up. What do you think about it? [1]: http://www.unixwiz.net/tools/lockrun.html [2]: http://www.unixwiz.net/tools/lockrun.c On Tue, Apr 08, 2014 at 11:48:17AM -0400, Calvin Morrison wrote: > Hi, > > I've just written lock, a simple little script to ensure that two > programs won't run at once. I am using this to ensure my users don't > overwrite the same shared folder in a set of genomic analysis scripts. > I thought it might be useful. > > The script will either create the lock and exit, or ping the lock > every two seconds until the lock is gone (via rmdir). I chose > directories as lock because they are atomic on Linux, so that avoids > some issue of locks overriding eachother. > > Usage is pretty simple, if you were to spawn this script twice, only > one do_work would execute at a time. > > lock mylock > do_work > sleep 10 > rmdir mylock > > This time I won't forget my link: https://github.com/mutantturkey/lock > > Cheers, > Calvin >
Re: [dev] lock (1) - a dead simple lock script
Was not aware of flock, thanks! I agree with you, using more small shell scripts is preferable. On Tue, Apr 08, 2014 at 12:25:55PM -0400, Calvin Morrison wrote: > On 8 April 2014 12:19, Amadeus Folego wrote: > > Hi Calvin, > > > > Thanks for sharing it, it's really neat! > > > > I have the same problem with some cron jobs, but I use lockrun[1]. > > > > It's source code is quite simple[2] too. > > That code is simple enough, but it did leave a poor taste in my mouth. > A clean rewrite would be easy. > > > > > The reason why I would still stick with lockrun is that > > in the context of cron jobs, it is better that the task does not > > runs than piling up. > > > > What do you think about it? > > > > [1]: http://www.unixwiz.net/tools/lockrun.html > > [2]: http://www.unixwiz.net/tools/lockrun.c > > > > Yes, I've used lockrun quite a bit, but since it wasn't available on > all platforms I am targeting, and flock also wasn't (I would prefer > flock mostly over the others), I wanted to have something that I can > use elsewhere. > > As to the piling, versus just exiting, my application needs to execute > both eventually, so I had it do that. It would probably be trivial to > do both. > > This brings up another thought. Most utilities in the standard > distribution of binaries, and even more in moreutils often are hard > coded C, where a few liner shell script would work. Any thoughts on > one versus the other? > > Calvin >
Re: [dev] lock (1) - a dead simple lock script
That's great Calvin! On Wed, Apr 09, 2014 at 10:40:43AM -0400, Calvin Morrison wrote: > I added a lock gif. Check it out. > > https://github.com/mutantturkey/lock/blob/master/README.markdown > > that should clarify >
[dev] [st] Understading st behaviour
Hi Guys, I wanted some help to understand some things that happen with me using st 0.5 that are kinda new, (coming from urxvt and other terms), these are: 1. If you open a program like mutt, ssh, or newsbeuter and kill the window with the wm (like xmonad) the process will not be killed. 2. When installing packages with yaourt it hangs when asking if you want to continue building a package and you can't pass keys to stdin, they are printed on the screen. Are these design decisions, features that were not developed yet, or bugs?
Re: [dev] [st] Understading st behaviour
On Thu, Apr 10, 2014 at 08:08:51PM +0200, Roberto E. Vargas Caballero wrote: > > 1. If you open a program like mutt, ssh, or newsbeuter and kill the > > window with the wm (like xmonad) the process will not be killed. > > I think it is a bug, because in this case a SIGHUP should be sent to the > process. How do you kill the terminal? It's the default keybinding for xmonad to kill a window: Mod + Shift + c It looks like xmonad sends the delete protocol if the program accepts it instead of killing. See [1] for details. [1]: http://xmonad.org/xmonad-docs/xmonad/src/XMonad-Operations.html#killWindow > > 2. When installing packages with yaourt it hangs when asking if you want > > to continue building a package and you can't pass keys to stdin, they > > are printed on the screen. > > I'm sorry, but I cannot understand you here. Could you explain a bit more > about this problem? I was not able to reproduce this behaviour, you can ignore this one. Thanks!
Re: [dev] [st] Understading st behaviour
I probably discovered why this happens. The WM_DELETE_WINDOW command is being received with success, I tested it. The issue is that the command xmonad uses to spawn st double-forks the process, making the SIGHUP signal not being sent to the correct pid. See [1]. So the question remains if we should cover this case or not, since xmonad's approach is probably nonsense. I never experienced this with other applications though. [1]: http://xmonad.org/xmonad-docs/xmonad/src/XMonad-Core.html#spawn
Re: [dev] [st] Understading st behaviour
Hi Guys, thank you for your feedback and taking your time to help me! I identified the issue. It looks like I am spawning st with tmux (e.g. st -e tmux), and the issue is that tmux is reparenting the process id to tmux's daemon. Example: tmux | \_newsbeuter | \_vim st.c It is not an issue with xmonad after all, and I can confirm that the issue happens on urxvt as well (e.g. urxvt -e tmux). I did not find any tmux option to disable this reparenting behaviour, so I guess I'll have to find another way to scroll the screen with st. :( Since this is described on st's page on suckless.org as a viable way to have scrolling can we at least update it to warn about this? Thanks, Amadeus.
Re: [dev] [st] Understading st behaviour
Yeah, I think you're right, that's why I said I'll have to find another way to have scrolling. But at least we should warn on the section we recommend tmux as a viable multiplexer about this, what do you think? On Tue, Apr 15, 2014 at 05:53:13PM -0700, Ryan O’Hara wrote: > On Tue, Apr 15, 2014 at 5:36 PM, Amadeus Folego > wrote: > > It looks like I am spawning st with tmux (e.g. st -e tmux), and the issue is > > that tmux is reparenting the process id to tmux's daemon. Example: > > > > tmux > > | > > \_newsbeuter > > | > > \_vim st.c > > > > It is not an issue with xmonad after all, and I can confirm that the > > issue happens on urxvt as well (e.g. urxvt -e tmux). > > That’s this issue?: > > > 1. If you open a program like mutt, ssh, or newsbeuter and kill the > window with the wm (like xmonad) the process will not be killed. > > I am pretty sure that’s wholly by design as far as tmux goes. > Just don’t try to exit your tmux session through the WM. >
Re: [dev] [st] Understading st behaviour
It works! As I am using tmux just for the scrollback and paste capabilities I am not worried with losing sessions. Maybe I'll write a suckless multiplexer for this sometime. On Wed, Apr 16, 2014 at 06:36:15AM +0200, Christoph Lohmann wrote: > Greetings. > > On Wed, 16 Apr 2014 06:36:15 +0200 Amadeus Folego > wrote: > > Hi Guys, thank you for your feedback and taking your time to > > help me! > > > > I identified the issue. > > > > It looks like I am spawning st with tmux (e.g. st -e tmux), and the issue is > > that tmux is reparenting the process id to tmux's daemon. Example: > > > > tmux > > | > > \_newsbeuter > > | > > \_vim st.c > > > > It is not an issue with xmonad after all, and I can confirm that the > > issue happens on urxvt as well (e.g. urxvt -e tmux). > > > > I did not find any tmux option to disable this reparenting behaviour, so > > I guess I'll have to find another way to scroll the screen with st. :( > > Add > > set -g destroy-unattached on > > to your ~/.tmux.conf. Of course this will destroy every session you open > and needs to be explictly disabled. > > > Sincerely, > > Christoph Lohmann > >
Re: [dev] [st] Understading st behaviour
Thanks for the detailed explanation random! I guess I did not use the correct terms appropriatelly. Would a suckless library for handling detaching, scrolling and multiplexing be something that could have some demand and even be used? Maybe that would make adding functionality to st trivial with simple patches? In a way that we could just plugin the library if it's available and require the specific features by configuration? Just some thoughts...
Re: [dev] [st PATCH] X geometry changes
I don't usually have problems with the geometry specified by rows and columns, it would be nice if we could retain this behaviour from the patch. Even though X11 may have introduced a lot of bad stuff, this one makes sense and simplifies a lot of code and logic. If you are specifying geometry, you should be prepared to handle this, be it by floating the window or adjusting the tile size, or even resizing it by the WM if you want to override it. Never had a problem with this on tiling window managers and should not have, this would be a deficiency (and an underlying complexity) of the WM and not of the program. Just my opinion.
Re: [dev] [st PATCH] X geometry changes
> Well, then geometry is useless in dwm and it would be removed from st. > Just bloat from a distant era. > Exactly, what does specifying geometry means on a tiling window manager when the window is not floating? If you want a tile to have a certain size on your WM you should specify this on your WM, not on the program. At least, that's what would make sense for me. The geometry (as specified by rows and columns) would still be useful for the floating and non tiling WMs cases.
Re: [dev] [st PATCH] X geometry changes
So if bloat is our problem, let's remove all geometry handling code.
Re: [dev] [st PATCH] X geometry changes
> So if bloat is our problem, let's remove all geometry handling code. But the geom setting would still be useful for handling the floating and non tiled wms cases.
Re: [dev][project] soap - a simple xdg-open replacement
Yeah, mailcap format would be amazing, I would use that!
On Tue, May 06, 2014 at 02:36:58AM +0200, Dmitrij D. Czarkoff wrote:
> FRIGN said:
> > A configuration can look like this:
> >
> > { "\.mp3","st -e mplayer %s" },
> > { "\.(jpg|png|tiff)$","feh %s"},
> > { "\.gif","wget -O /tmp/tmp.gif %s && gifview -a
> > /tmp/tmp.gif" },
> > { "^(http://|https://)?(www\.)?(youtube.com/watch\?|youtu\.be/)",
> > "youtube-viewer %s" }
> >
> > where %s is the _shell-escaped_ argument given to xdg-open.
>
> Am I missing something, or mailcap files already do that?
>
> --
> Dmitrij D. Czarkoff
>
Re: [dev][project] soap - a simple xdg-open replacement
On Tue, May 06, 2014 at 02:36:58AM +0200, Dmitrij D. Czarkoff wrote: > FRIGN said: > > Am I missing something, or mailcap files already do that? > Agreed, that would be amazing! I would certainly use that!
Re: [dev] [sbase] -h/--human-readable on sbase
The -h or --human-readable option is not available on ls, and probably a lot of other places on sbase. This is something that would help me migrating to an userspace made with sbase binaries. Would implementing this be desirable, straightforward and compliant with suckless design concepts? I could go ahead and implement this. Example: ~/C/sbase ❯❯❯ /usr/bin/ls -ahl | /usr/bin/tail -3 -rw-r--r-- 1 badosu 100 184 Apr 22 11:42 yes.1 -rw-r--r-- 1 badosu 100 359 Apr 22 11:42 yes.c -rw-r--r-- 1 badosu 100 4.4K May 9 11:39 yes.o ~/C/sbase ❯❯❯ ./ls -al | ./tail -3 -rw-r--r-- 1 badosu 100 184 Apr 22 11:42 yes.1 -rw-r--r-- 1 badosu 100 359 Apr 22 11:42 yes.c -rw-r--r-- 1 badosu 100 4464 May 09 11:39 yes.o ~/C/sbase ❮❮❮ ./ls -ahl | ./tail -3 usage: ./ls [-adFilrtU] [FILE...]
Re: [dev] [ANNOUNCE] dlauncher - dmenu based launcher
Hi Xinhao Yuan! I've been using dmenu with yeganesh[1] for quite some time and I am trying dlauncher now. One thing that I found strange was the listing and use of available plugins. But let's see how I get used to it. Thanks for the release! [1]: http://dmwit.com/yeganesh/ On Sat, May 10, 2014 at 09:29:50PM -0400, Xinhao Yuan wrote: > Hi there, > > I would like to announce dlauncher, a dmenu based launcher I wrote to > replace synapse(https://launchpad.net/synapse-project) which is no > longer in development. dlauncher reuses the minimalist dmenu UI and > supports plugins that provide dynamic content. > > repository: http://github.com/xinhaoyuan/dlauncher > > highlighted plugin: > > * history - conveniently recalls your command history > * ssh - takes hostname and open ssh session in a terminal emulator > * zsh - completes command using zsh engine (I think this is really awesome!) > > Please enjoy it and I am happy to take feedback :) > > Cheers, > Xinhao >
Re: [dev] [GENERAL] License manifest
Hi there, I just noticed most of suckless projects use the MIT License, and I just wondered if there was any place on the suckless wiki that stated why this was preferred, but found none. So I thought that maybe this was something largely discussed already and searched on the mailing list archives but found nothing as well. So, given this context, is there any manifesto about this particular License choice? E.G is there a reason to avoid GPL? And if there is any consensus on this, can we display it somewhere visible on the wiki? Kind regards, Amadeus.
Re: [dev] [sbase] [PATCH] Make grep more memory-efficient
Maybe we should include a benchmark script so that we can test if a patch has a regression on performance?
Re: [dev] [GENERAL] License manifest
Hi Lohmann, On Mon, May 12, 2014 at 06:18:37PM +0200, Christoph Lohmann wrote: > History made me thinking about that stance in suckless. Yes, it’s com‐ > plete freedom, but the GPL made it possible to open up platforms not > open before. For example the US navy is using Open Source software to > kill people. I can’t really support this. Programming isn’t neutral any‐ > more. And, as OpenSSL shows, corporate assholes never really give back. > With the GPL you at least get their crown jewels, if they piss you off. > I mostly agree with your point here, and the fact that things like this happen on Open Source is what makes me more favourable to the GPL in these days. I went to FISL[1] some days ago, a really cool event about free software and stuff, so I was really excited about suckless and thinking about submitting a presentation about it on the next one. But when I saw the LICENSE that we use, I kinda lost the excitement, still probably going to submit it. Then I went to see what's FSF's position on this, surprisingly they are quite cool about it for small projects[2]. Given suckless projects are mostly foundamental, in the sense they usually are good foundations, it would be quite nice if they were GPL. [1]: http://softwarelivre.org/fisl15 [2]: https://www.gnu.org/licenses/license-list.html#X11License
Re: [dev] [dmenu] regexp with dmenu?
On Wed, May 14, 2014 at 01:46:07PM +0200, Thuban wrote: > Hi all, > I was wondering if there is any existing solution to have dmenu > understanding regular expression? There is a patch that adds fuzzy matching support to dmenu, it's not exactly the same thing, but may work for you. [1]: http://lists.suckless.org/dev/1209/12505.html [2]: https://aur.archlinux.org/packages/dmenu-xft-fuzzy/
Re: [dev] shell scripts vs makefiles for small SDKs
On Wed, Jun 25, 2014 at 08:36:33PM +0200, Sylvain BERTRAND wrote: > As rightfully requested. > > A dedicated thread. Sylvain, please don't do this. I understand why you are so angry and frustrated, it's difficult to argue about subjective things when people have such strong opinions as in the suckless community, but please do not pollute the mailing list. Guys, if you want do discuss this use the #suckless freenode channel.
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
Hadrian, please do not tell that you represent everyone, you don't. Also what you just said is like your opinion, man.
[dev] [grep-notify] A simple notifier when stdout prints a pattern
Hi Guys,
for some days I've been looking for a suckless irc client.
I've taken a look and used ii[1] but I did not find it very usable for
me.
So I've been using sic[2] which has been great for me, I had to make
some wrappers to improve the experience, like ignoring PARTs, JOINs, etc.
sic -h irc.freenode.net -n badosu |\
grep -v '< QUIT (\|< JOIN (\|< PART (\ |< NICK ('
One thing I've been missing from it though has been a notifier for when
someone would message me, so I've search the internet for something that
could trigger a notify-send when a string was matched on a line.
Since I could not find one, I've started grep-notify[3].
The idea is very simple, it would be used like this:
sic -h irc.freenode.net -n badosu |\
grep -v '< QUIT (\|< JOIN (\|< PART (\ |< NICK (' |\
grep-notify "[^(]badosu[^)]" irc.freenode.net
So that I could receive a nice message with libnotify.
It's current status is very prototypical and it's by no measure near to
something that I would like to share or tell others to use, I know it's working
for simple things though.
So, back to my original goal, I am still having some problems, output
stops being printed after a certain threshold, ~ 20 lines, when using it
with sic, I don't know yet why.
If you guys have any idea or know of another program that could help me
with this, it would be great!
Best, Amadeus.
[1]: http://tools.suckless.org/ii/
[2]: http://tools.suckless.org/sic/
[3]: https://github.com/badosu/grep-notify/blob/master/grep-notify.c
Re: [dev] [grep-notify] A simple notifier when stdout prints a pattern
On Sat, Jun 28, 2014 at 11:24:51PM +0200, Markus Teich wrote:
> Rob wrote:
> > Perhaps see how using the bell character works for you. You could even do it
> > with a shell script:
> >
> > ... | grep 'your-regex' | while read line; do printf '\x7'; done
>
> This is probably not helpful since it does only print the matching lines. Try
> sed to insert the bell character:
>
> ... | sed 's|\([^(]nickname\)|\x7\1|'
>
Hi Markus, thank you very much for the tip! I like it, is very simple.
However, it's suffering from the same problem I am having with
grep-notify.
The output of sic is being blocked from showing up, if I send :quit all
the output is printed back and the program exits.
sic -h irc.freenode.net -n badosu |\
grep -v '< QUIT (\|< JOIN (\|< PART (\|< NICK (' |\
sed 's|\([^(]badosu\)|\x7\1|'
Re: [dev] [grep-notify] A simple notifier when stdout prints a pattern
> Hi Markus, thank you very much for the tip! I like it, is very simple.
>
> However, it's suffering from the same problem I am having with
> grep-notify.
>
> The output of sic is being blocked from showing up, if I send :quit all
> the output is printed back and the program exits.
>
> sic -h irc.freenode.net -n badosu |\
> grep -v '< QUIT (\|< JOIN (\|< PART (\|< NICK (' |\
> sed 's|\([^(]badosu\)|\x7\1|'
Forget about it, the problem was with grep, for some reason having more
than one pipe is blocking stdout from printing.
Using only sic piped with sed works, but the bell has no effect as I am
on xmonad and it simply has no effect.
Re: [dev] [grep-notify] A simple notifier when stdout prints a pattern
On Sat, Jun 28, 2014 at 11:51:12PM +0200, Markus Teich wrote: > Amadeus Folego wrote: > > Using only sic piped with sed works, but the bell has no effect as I am on > > xmonad and it simply has no effect. > > That should be no problem[0]. You also have to make sure your terminal > emulator > sets the urgency hint on a bell character. st does that by default. > > --Markus > > [0] http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-UrgencyHook.html > Great! Thanks for the feedback, I will surely use it! I also addressed some of your concerns on [0], much better! [0]: https://github.com/badosu/grep-notify/blob/master/grep-notify.c
Re: [dev] Why do you use tmux/screen?
On Tue, Jul 01, 2014 at 03:51:00PM +0200, FRIGN wrote: > On Tue, 01 Jul 2014 08:42:03 +0530 > Weldon Goree wrote: > > > Lemma: does anybody know of a good environment-managing program[0]? > > This is not a lemma. > > I know a good program. It's called ".". Check it out! Please see bs[0] and envdir[1]. [0]: https://github.com/educabilia/bs [1]: http://cr.yp.to/daemontools/envdir.html
Re: [dev] [slock] Configure OOM killer as non-root
Hi FRIGN, Danilo, I also can't use it as non-root, how did you solve it? Thanks, Amadeus. On Tue, Jul 08, 2014 at 03:16:33PM +0200, FRIGN wrote: > On Tue, 08 Jul 2014 12:04:29 +0200 > Danilo wrote: > > > Oh, never mind that stupid question. Sorry about bothering you, when > > setting the suid bit I forgot to change the owner to root, so of course > > that didn't help... > > Hey Danilo, > > I ran into that issue, too, when I wrote the patch to fix the > shadow-support in slock. It took a while to debug. > > Cheers > > FRIGN > > -- > FRIGN >
Re: [dev] [slock] Configure OOM killer as non-root
Oh, Thanks! I did not know about the "make install" thing, I was just building it. On Tue, Jul 08, 2014 at 04:19:41PM +0200, Danilo wrote: > Hi Amadeus > > Am Di, 8. Jul 2014, um 16:08, schrieb Amadeus Folego: > > I also can't use it as non-root, how did you solve it? > > You need to change the owner of the binary to "root" and set the suid > bit: > > $ sudo chown root slock > $ sudo chmod u+s slock > > If you use "make install", this happens automatically. > > Cheers, > Danilo >
Re: [dev] [sandy] [PATCH] VIM key bindings.
On Sun, Jul 13, 2014 at 03:29:15AM +0300, Dimitris Zervas wrote:
> I think that the patch is ready.
Hi Dimitris, I am not being able to build it (on ad325a):
sandy.c: In function ‘i_termwininit’:
sandy.c:1397:5: error: ‘USE_TERM_STATUS’ undeclared (first use in this
function)
if(USE_TERM_STATUS && tigetflag("hs") > 0) {
^
sandy.c:1397:5: note: each undeclared identifier is reported only
once for each function it appears in
sandy.c:1403:26: error: ‘BOTTOM_TITLE’ undeclared (first use in
this function)
titlewin=newwin(1,cols,BOTTOM_TITLE?lines-1:0,0);
Re: [dev] Introducing the imagefile-format
On Mon, Jul 28, 2014 at 06:55:59PM +0200, FRIGN wrote: > As a result I came up with the first implementation, the if-tools[0], > capable of easily converting between png and imagefiles. Looks great! This would make a lot of image handling, automation and editing operations much easier and simple. Thanks!
Re: [dev] [st] possibly redundant check in techo
Steven, when you first disclose your project publicly, please adjust the proper License requirements. >From what I see, it looks like you stripped everything of the codebase and previous structure.
[dev] Re: [dvtm] Focus by id instead of order
So, I started sending a lot of commands to dvtm via the command fifo and
I noticed an odd thing.
Every window exposes a variable called $DVTM_WINDOW_ID, so one can
imagine that if you want to focus on a window you should just pass the
command 'focusn 1' where 1 would be the id of that window.
What happens is something different than this and somewhat confusing.
Maybe there's a reason for it being that way, I don't know if this is a
design decision or a bug.
In any case: I attached a patch that changes the focus command to
use the window id, so that the focus command is invariant in respect to
layout changes and scripts have a better api to interact with.
diff --git a/dvtm.c b/dvtm.c
index 71ffccb..055d982 100644
--- a/dvtm.c
+++ b/dvtm.c
@@ -787,7 +787,7 @@ copymode(const char *args[]) {
static void
focusn(const char *args[]) {
for (Client *c = clients; c; c = c->next) {
- if (c->order == atoi(args[0])) {
+ if (c->id == atoi(args[0])) {
focus(c);
if (c->minimized)
toggleminimize(NULL);
Re: [dev] Re: [dvtm] Focus by id instead of order
On Sun, Sep 07, 2014 at 05:31:07PM +0200, koneu wrote: > Why did you call the thread "Re:"? Oh, sorry! That was totally by mistake. Is there anything I can do to fix this?
Re: [dev] Re: [dvtm] Focus by id instead of order
On Mon, Sep 08, 2014 at 02:24:38PM +0200, FRIGN wrote: > The question is: Does your patch fix the behaviour > in your eyes? Yes, mostly. I must ask it because it may be this way by design, I don't know why, though.
Re: [dev] Re: [dvtm] Focus by id instead of order
On Mon, Sep 08, 2014 at 06:43:55PM +0200, Marc André Tanner wrote:
> It was designed that way because Mod+n should always focus the n-th
> window, i.e. the one with #n in the title, in the current layout.
Now it makes perfect sense, thanks for replying!
I mostly use dvtm for the scrollback and search features, now that I got
closer with the window manager functionalities.
So, on the last few days I started writing a dvtm handler for a vim
plugin called vim-dispatch[1]. It enables running long processes
asynchronously and loading their output on the quickfix list.
It has many handlers by default, I used to use tmux mostly.
Since I started using dvtm I went on and figured out how to make it
work with it.
I showed a previous version of the handler for tpope and looked like
he's open to pull it. It would be wonderful to have dvtm support on
vim-dispatch out of the box.
The plugin mostly works with today's dvtm codebase but these are
the modifications that provide the best experience:
- Provide a focus command similar to focusn but using the id
- Enable focusn, setlayout and setmfact commands
- Enable the cmd fifo by default, e.g. /tmp/dvtm-{pid}.fifo
I don't know if the drawbacks for them are big, I am just pointing out
what works best for my script.
I shared a gist of the whole setup at [2].
Thanks for dvtm and feedback!
[1]: https://github.com/tpope/vim-dispatch/
[2]: https://gist.github.com/badosu/8bab3b96ae2b364addb6
Re: [dev] [vis][PATCH] Window line up/down
On Mon, Sep 15, 2014 at 06:52:07PM +0200, Marc André Tanner wrote:
> Hi Caudio,
>
> Thanks, will incorporate your requested functionality.
>
> On Sun, Sep 14, 2014 at 06:25:30PM +0200, Claudio wrote:
> > @@ -93,8 +93,10 @@ static KeyBinding basic_movement[] = {
> > { { KEY(SRIGHT) }, movement, { .i = MOVE_WORD_START_NEXT
> > } },
> > { { KEY(UP) }, movement, { .i = MOVE_LINE_UP
> > } },
> > { { KEY(DOWN) }, movement, { .i = MOVE_LINE_DOWN
> > } },
> > - { { KEY(PPAGE) }, cursor, { .m = window_page_up
> > } },
> > - { { KEY(NPAGE) }, cursor, { .m = window_page_down
> > } },
> > + { { CONTROL('u')}, cursor, { .m = window_page_up
> > } },
> > + { { CONTROL('d')}, cursor, { .m = window_page_down
> > } },
> > + { { CONTROL('y')}, cursor, { .m = window_line_up
> > } },
> > + { { CONTROL('e')}, cursor, { .m = window_line_down
> > } },
This was the first thing I missed when I tried, thanks for pulling it!
Re: [dev] [vis][PATCH] Window line up/down
On Tue, Sep 16, 2014 at 07:55:40PM +0200, Marc André Tanner wrote:
> I have cleaned up the cursor handling code in window.[ch] and implemented
> the CTRL-{U,D,E,Y} functionality in normal mode. However I'm not sure it
> behaves the way you expect it. Please test, and report back.
CTRL-{U,D} is working identically to vim.
CTRL-{F,B} were doing what U and D do now (move half-page up/down).
Now the latest changes made them move a full-page row (up/down)
but in the reverse direction. F should be Forward, B should be Back.
I noticed some odd differences between vis and vim in regard of the number of
rows calculated to be moved, but this should be irrelevant at this
stage.
Thanks for the feedback!
Re: [dev] environment variables versus runtime configuration (rc) files versus X resources
On Mon, Nov 03, 2014 at 02:32:25PM -0500, Greg Reagle wrote: > ... > variables. Do you know of any programs that do this? I assume there > ... Greg, bs[0] is a nice little script[1] that makes setting up a config file with environment variables a breeze! There's also envdir[2] from daemontools. 0: https://github.com/educabilia/bs 1: https://raw.githubusercontent.com/educabilia/bs/master/bin/bs 2: http://cr.yp.to/daemontools/envdir.html
Re: [dev] Project ideas: goblin
On Tue, Nov 25, 2014 at 02:11:14PM -0500, Calvin Morrison wrote: > I don't think anyone here supports Go. I could be wrong but I think > Uriel was the only real supporter in the community. I would be more > interested in a Rust implementation of coreutils however. It might > have already been done There's uutils[0] 0: https://github.com/uutils/coreutils
Re: [dev] [ANNOUNCE] abduco-0.3
On Thu, Feb 19, 2015 at 06:20:47PM +0100, Marc André Tanner wrote:
> Hi,
>
> I'm pleased to announce version 0.3 of abduco, a tool for session
> {at,de}tach support which allows to run a process independently from
> its controlling terminal. In combination with dvtm it is a lightweight
> alternative to tmux and screen.
Nice to see active development on abduco! I use it extensively on a
daily basis and it's a great tool.
Thanks for it!
Amadeus.
Re: [dev] st: selecting text affects both primary and clipbaord
On Fri, Feb 20, 2015 at 12:46:20AM +0100, Wander Nauta wrote: > Hello list, > > I know this isn't a democracy, but I agree with Greg, it makes more > sense to only set PRIMARY, not CLIPBOARD, in selcopy. Removing the > clipboard-related lines from xsetsel seems to do the trick. I've > attached a patch that does just that. Huh? I always used when pasting something selected on st so I never noticed that it also sent to CLIPBOARD, got pretty surprised by this behaviour.
Re: [dev] st: selecting text affects both primary and clipbaord
On Tue, Mar 10, 2015 at 05:18:49PM -0400, Greg Reagle wrote: > It could go the other way and do a variant of Ctrl+C for copy and Ctrl+V > for paste. I wouldn't use them directly because the programs running in > st probably need those keys. So Alt+Ctrl+C/V or Shitf+Ctrl+C/V or > Alt+C/V. > > Also, it could provide key bindings for both CUA and the other way. I > don't think that would complicate the code much. I really don't like the idea of C-S-C or M3-C as these are really basic keybinds and may be used for applications. Also the proximity with C-C makes it easier to terminate a running application when you just wanted to copy some text. C-Ins looked like a nice suggestion, even though we are not inserting text into the application. So I am not really suggesting anything, I just wanted to point out these factors.
Re: [dev] st: selecting text affects both primary and clipbaord
On Wed, Mar 11, 2015 at 08:05:37AM +0100, Roberto E. Vargas Caballero wrote: > > > I really don't like the idea of C-S-C or M3-C as these are really basic > > keybinds and may be used for applications. Also the proximity with C-C > > makes it easier to terminate a running application when you just wanted > > to copy some text. > > It is impossible to use ctrl + shift combinations in the terminal world. > Shift makes an or with 0x20 and ctrl makes an and with 0x1f, so if you > press them at the same time you are going to have something like > (c | 0x20) ^ 0x1f == c & 0x1f. This is news for me, thanks for the detailed explanation.
Re: [dev] st: selecting text affects both primary and clipbaord
On Thu, Mar 12, 2015 at 04:35:58PM +0800, Kai Hendry wrote: > My 2 cents: Suggestions to use 3 keys to copy & paste SUCK > > Can we please have feature parity with MacOSX? > > cmd-c, cmd-v This can be a problem for (I think) many users of st that use this key as the modifier for tiling window managers. As much as I don't like C-S-C, C-S-V too, the reasons K0ga presented seem very sane as a default keybinding. This can be changed later anyway.
Re: [dev] st: selecting text affects both primary and clipbaord
On Thu, Mar 12, 2015 at 05:05:10PM +0100, Wander Nauta wrote: > > Do most numpad-less laptop keyboards even have Insert or a middle mouse > > button? > > Macbooks have neither, I believe, and they're fairly popular. I thought there was a gesture to perform middle button, was I wrong?
Re: [dev] [st] Problems when typing
On Mon, Mar 16, 2015 at 02:12:16PM +0800, Ivan Tham wrote: > Sorry for that, but I didn't say that I am unwilling to read a C book. Yes, you did, you are inventing reasons to justify your actions: > I want to learn C, so now I am waiting for c.learncodethehardway.org > to release as other book may seem a bit too long for me. > Thanks, but it takes time reading it. > (this will spoil my eyesight) Actually you don't need to read a book or a manual to post questions, you just need to be reasonable and not annoying. You should respect people and not waste their time and efforts asking every question imaginable without doing the minimal effort to learn. Chris is exaggerating for some reason: being funny, extreme or something like that. But he is right in the sense that we should not accept being treated like someone's personal google.
Re: [dev] [st] Flow control support
Alex, you just posted the diffstat, not the patch itself.
Re: [dev] RSS
On Thu, May 07, 2015 at 05:26:26PM +0300, stargr...@stargrave.org wrote: > Hello, > > >Maybe there is some other nice feed reader out there that I don't > >know about. tt-rss, miniflux and all the others are monsters > >unfortunately. > > I like http://www.newsbeuter.org/. It is not very suckless, but seems to > be closer to this term comparing to miniflux and tt-rss. I recommend newsbeuter, it's pretty good and easy to use.
Re: [dev] simple terminal : about fonts
As already mentioned I strongly recommend Inconsolata[0]. Another great font is Anonymous Pro[1]. 0: http://www.levien.com/type/myfonts/inconsolata.html 1: http://www.marksimonson.com/fonts/view/anonymous-pro
Re: [dev] Is Wayland really a solution to X11 cruft?
Marc, see: http://blog.mecheye.net/2012/06/the-linux-graphics-stack/#rendering-stack You'll notice how the architecture can't be improved without rewriting the whole application. On Fri, Oct 30, 2015 at 11:57:41AM -0200, Marc Collin wrote: > They don't see to know what they are trying to "fix" in the first place. > How about reimplementations of Xorg that actually sucks less? > Like https://github.com/idunham/tinyxserver for example (really far > from being suckless, but looks like a start). >
