Re: [dev] st patch for draw() etc.
Line buffer editing/positioning shouldn't be handled by st itself, it should be delegated to an external tools (most likely the shell). Else none of ^e, ^a, and such keystrokes should be available/hardcoded into the terminal emulator. We should think in terms of "shell container" rather than "terminal emulator". Well, I'm pretty aware it's a bit extreme but hope someone else will agree with me. Regards, Claudio M. Alessi
Re: [dev] [st] 0.1 Feedback - Was: A few small patches
If you have a vim-like interface to Chrome, the best way to edit text online is jsvi[0]. It need some improvement but works quite good. OTOH, Chrome will *never* allow the extensions to run local binary code like FireFox does. You'll have to use the NPAPI plugin to achieve this goal. Regards, Claudio M. Alessi
Re: [dev] [PATCH] Simplify README
AFAIK a terminal is an hardware device. Since st is only a software implementation it's ok to call it a virtual terminal emulator, isn't? 2014-08-18 12:13 GMT+02:00 Roberto E. Vargas Caballero : >> The term 'virtual terminal emulator' was broken. There is nothing >> virtual about it, it's a terminal emulator. > > Yeah, it was a bad sentence. Usually the term 'virtual terminal' is used > for the terminal emulator built in linux kernel, but it is a non sense here. > > > Thanks, > > -- > Roberto E. Vargas Caballero >
Re: [dev] [PATCH] Simplify README
I got it. Right. 2014-08-18 15:04 GMT+02:00 Weldon Goree : > On Mon, 2014-08-18 at 12:58 +0200, Claudio wrote: >> AFAIK a terminal is an hardware device. Since st is only a software >> implementation it's ok to call it a virtual terminal emulator, isn't? >> > > A virtual terminal presents the kernel the capabilities of a physical > terminal (eg, /dev/tty3 or /dev/pts/1). A terminal emulator attaches > input and output to a virtual terminal (though these programs are often > called "virtual terminals" as well). > > A "virtual terminal emulator" would either be a virtual (terminal > emulator) or a (virtual terminal) emulator. In the first case, it would > be something like an expect script that makes a guest program think it > is running in a terminal emulator. In the second case, it would be some > sort of environment that, for instance, intercepted i/o to /dev/pts/* > and mangled it somehow. > > The point is, st could be called a terminal emulator, or (somewhat more > loosely) a virtual terminal, but it's not a virtual terminal emulator > outside of the Department of Redundancy Department. > > WG > >
[dev] [vis][PATCH] Window line up/down
Hi,
thank you for writing vis. I would ask if the attached patch makes
sense to you. Now window_line_up() and window_line_down() works
properly and I can add the following key bindings:
{ { CONTROL('y')}, cursor, { .m = window_line_up } },
{ { CONTROL('e')}, cursor, { .m = window_line_down } },
It works but I'm not sure it's the only (and right) way to do it.
Regards,
Claudio
diff --git a/config.def.h b/config.def.h
index b0b836c..cddd1aa 100644
--- a/config.def.h
+++ b/config.def.h
@@ -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 } },
{ { KEY(HOME) }, movement, { .i = MOVE_LINE_START} },
{ { KEY(END)}, movement, { .i = MOVE_LINE_FINISH } },
{ /* empty last element, array terminator */ },
diff --git a/window.c b/window.c
index eb1c8e7..e76e5a7 100644
--- a/window.c
+++ b/window.c
@@ -632,27 +632,14 @@ size_t window_page_down(Win *win) {
size_t window_line_up(Win *win) {
Cursor *cursor = &win->cursor;
- if (!cursor->line->prev) {
- window_scroll_lines_up(win, 1);
- return cursor->pos;
- }
- cursor->row--;
- cursor->line = cursor->line->prev;
- cursor->pos = pos_by_line(win, cursor->line) + cursor_offset(cursor);
- return window_cursor_update(win);
+ window_scroll_lines_up(win, 1);
+ return cursor->pos;
}
size_t window_line_down(Win *win) {
Cursor *cursor = &win->cursor;
- if (!cursor->line->next) {
- if (cursor->line == win->bottomline)
- window_scroll_lines_down(win, 1);
- return cursor->pos;
- }
- cursor->row++;
- cursor->line = cursor->line->next;
- cursor->pos = pos_by_line(win, cursor->line) + cursor_offset(cursor);
- return window_cursor_update(win);
+ window_scroll_lines_down(win, 1);
+ return cursor->pos;
}
void window_update(Win *win) {
[dev] Re: [vis][PATCH] Window line up/down
Okay, I just noticed that the original behaviour of window_line_*() is
different than the one I thought. It's used by the j and k commands so
I'll need two new ad-hoc routines for ^y and ^e.
Regards,
Claudio Alessi
2014-09-14 18:25 GMT+02:00 Claudio :
> Hi,
>
> thank you for writing vis. I would ask if the attached patch makes
> sense to you. Now window_line_up() and window_line_down() works
> properly and I can add the following key bindings:
>
> { { CONTROL('y')}, cursor, { .m = window_line_up } },
> { { CONTROL('e')}, cursor, { .m = window_line_down } },
>
> It works but I'm not sure it's the only (and right) way to do it.
>
>
> Regards,
> Claudio
[dev] Re: [vis][PATCH] Window line up/down
Here is the patch containing window_scroll_line_up() and
window_scroll_line_down().
Regards,
Claudio
2014-09-14 18:31 GMT+02:00 Claudio :
> Okay, I just noticed that the original behaviour of window_line_*() is
> different than the one I thought. It's used by the j and k commands so
> I'll need two new ad-hoc routines for ^y and ^e.
>
>
> Regards,
> Claudio Alessi
>
> 2014-09-14 18:25 GMT+02:00 Claudio :
>> Hi,
>>
>> thank you for writing vis. I would ask if the attached patch makes
>> sense to you. Now window_line_up() and window_line_down() works
>> properly and I can add the following key bindings:
>>
>> { { CONTROL('y')}, cursor, { .m = window_line_up } },
>> { { CONTROL('e')}, cursor, { .m = window_line_down } },
>>
>> It works but I'm not sure it's the only (and right) way to do it.
>>
>>
>> Regards,
>> Claudio
diff --git a/window.c b/window.c
index eb1c8e7..e1bc483 100644
--- a/window.c
+++ b/window.c
@@ -655,6 +655,18 @@ size_t window_line_down(Win *win) {
return window_cursor_update(win);
}
+size_t window_scroll_line_up(Win *win) {
+ Cursor *cursor = &win->cursor;
+ window_scroll_lines_up(win, 1);
+ return cursor->pos;
+}
+
+size_t window_scroll_line_down(Win *win) {
+ Cursor *cursor = &win->cursor;
+ window_scroll_lines_down(win, 1);
+ return cursor->pos;
+}
+
void window_update(Win *win) {
wnoutrefresh(win->win);
}
[dev] Re: [vis][PATCH] Window line up/down
Sorry for all these mails, I'm trying to make things better as I
understand how things works.
Attached is a fully working patch which allow to scroll the page
up/down by one line.
Regards,
Claudio Alessi
2014-09-14 18:37 GMT+02:00 Claudio :
> Here is the patch containing window_scroll_line_up() and
> window_scroll_line_down().
>
> Regards,
> Claudio
>
> 2014-09-14 18:31 GMT+02:00 Claudio :
>> Okay, I just noticed that the original behaviour of window_line_*() is
>> different than the one I thought. It's used by the j and k commands so
>> I'll need two new ad-hoc routines for ^y and ^e.
>>
>>
>> Regards,
>> Claudio Alessi
>>
>> 2014-09-14 18:25 GMT+02:00 Claudio :
>>> Hi,
>>>
>>> thank you for writing vis. I would ask if the attached patch makes
>>> sense to you. Now window_line_up() and window_line_down() works
>>> properly and I can add the following key bindings:
>>>
>>> { { CONTROL('y')}, cursor, { .m = window_line_up } },
>>> { { CONTROL('e')}, cursor, { .m = window_line_down } },
>>>
>>> It works but I'm not sure it's the only (and right) way to do it.
>>>
>>>
>>> Regards,
>>> Claudio
diff --git a/window.c b/window.c
index eb1c8e7..d248af7 100644
--- a/window.c
+++ b/window.c
@@ -655,6 +655,28 @@ size_t window_line_down(Win *win) {
return window_cursor_update(win);
}
+size_t window_scroll_line_up(Win *win) {
+ Cursor *cursor = &win->cursor;
+ window_scroll_lines_up(win, 1);
+ if(!cursor->line->next || !cursor->line->prev)
+ return cursor->pos;
+ cursor->row++;
+ cursor->line = cursor->line->next;
+ cursor->pos = pos_by_line(win, cursor->line) + cursor_offset(cursor);
+ return window_cursor_update(win);
+}
+
+size_t window_scroll_line_down(Win *win) {
+ Cursor *cursor = &win->cursor;
+ window_scroll_lines_down(win, 1);
+ if(!cursor->line->next || !cursor->line->prev)
+ return cursor->pos;
+ cursor->row--;
+ cursor->line = cursor->line->prev;
+ cursor->pos = pos_by_line(win, cursor->line) + cursor_offset(cursor);
+ return window_cursor_update(win);
+}
+
void window_update(Win *win) {
wnoutrefresh(win->win);
}
diff --git a/window.h b/window.h
index d575341..4e151f8 100644
--- a/window.h
+++ b/window.h
@@ -33,6 +33,8 @@ size_t window_char_next(Win*);
size_t window_char_prev(Win*);
size_t window_line_down(Win*);
size_t window_line_up(Win*);
+size_t window_scroll_line_down(Win*);
+size_t window_scroll_line_up(Win*);
/* place the cursor at the start ot the n-th window line, counting from 1 */
size_t window_line_goto(Win*, int n);
Re: [dev] [vis][PATCH] Window line up/down
Thanks Marc,
I still have much to learn, but I already love vis.
Regards,
Claudio
2014-09-15 17:06 GMT+00:00 Amadeus Folego :
> 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!
>
[dev] [dvtm][PATCH] Makefile and terminfo
Hi,
I've just installed dvtm on Ubuntu Server and it looks like the
terminfo entry gets installed into the wrong place
(/usr/share/terminfo/, while the system looks for it in
/etc/terminfo/). So I just removed the -o flag from @tic which allow
the system to place the files to the right directory. Indeed, now
things works properly.
Attached is the patch.
Regards,
Claudio
diff --git a/Makefile b/Makefile
index 207fc6b..4c304bd 100644
--- a/Makefile
+++ b/Makefile
@@ -56,7 +56,7 @@ install: dvtm
@sed "s/VERSION/${VERSION}/g" < dvtm.1 > ${DESTDIR}${MANPREFIX}/man1/dvtm.1
@chmod 644 ${DESTDIR}${MANPREFIX}/man1/dvtm.1
@echo installing terminfo description
- @tic -o ${DESTDIR}${PREFIX}/share/terminfo -s dvtm.info
+ @tic -s dvtm.info
uninstall:
@echo removing executable file from ${DESTDIR}${PREFIX}/bin
Re: [dev] [vis][PATCH] Window line up/down
Thanks Marc,
the feature works as expected. The only difference I noted is that vim
do stop scrolling if you are at the top/bottom of the buffer while vis
still move the cursor if possible, without scrolling, since it reach
the top/bottom of the buffer. Not sure what is the right behaviour but
I suspect vim is right.
As regards as dj, I think vis behaves properly while vim is wrong.
Regards,
Claudio
2014-09-17 15:14 GMT+02:00 Marc André Tanner :
> On Tue, Sep 16, 2014 at 03:41:43PM -0300, Amadeus Folego wrote:
>> 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)
>
> According to my manual they should be identical to page up/down which
> move full pages.
>
>> but in the reverse direction. F should be Forward, B should be Back.
>
> This was stupid, and now fixed. I was actually more interested whether
> CTRL-{E,Y} behaves the way you expect it.
>
>> 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.
>
> Do you mean cases such as: dj which in vim deletes 2 lines but in vis
> only the current one?
>
> --
> Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
>
[dev] [dmenu][patch] Offset problem using -l wih -p with -l
Hi dears, I noticed that vertical listing is done by indenting items at the same level as the prompt length, which to me doesn't make any sense. The attached patch make it works as I expect. Is it the intended behaviour or is it indeed a bug? Regards, Claudio dmenu-4.6-novertoff.diff Description: Binary data
Re: [dev] [dmenu][patch] Offset problem using -l wih -p with -l
Actually the prompt is highlighted (so is the selected item) which already does the trick. Indenting the items is a bit weird IMHO. Do I put the patch into the wiki or we could discuss about including it in head? Note: the previous patch had a problem which I fixed in the attached one. Regards, Claudio Il giorno dom 18 ott 2015 alle ore 11:45 Markus Teich < markus.te...@stusta.mhn.de> ha scritto: > Claudio wrote: > > I noticed that vertical listing is done by indenting items at the same > level > > as the prompt length, which to me doesn't make any sense. > > Heyho Claudio, > > it helps to differentiate between prompt and input visually. > > --Markus > > dmenu-4.6-novertoff.diff Description: Binary data
Re: [dev] [dmenu][patch] Offset problem using -l wih -p with -l
Thanks for the hint, I'm still learning the code. In my patch w was == mw, BTW. I think you've already understood my point so there's no need to discuss further. If someone feel like me then we may share ideas, for now I can use our lovely wiki. Regards, Claudio 2015-10-18 12:04 GMT+02:00 Hiltjo Posthuma : > On Sun, Oct 18, 2015 at 11:40 AM, Claudio wrote: >> Hi dears, >> >> I noticed that vertical listing is done by indenting items at the same level >> as the prompt length, which to me doesn't make any sense. The attached patch >> make it works as I expect. >> >> Is it the intended behaviour or is it indeed a bug? >> > > It is intended behaviour. I can see your point, in a vertical list the > first line is always the prompt + input bar so indentation is not > necessarily needed visually. > > Note in your patch the width is wrong, w (mw - prompt width) should be > mw (full): > > -drw_text(drw, x, y, w, bh, item->text, 0); > +drw_text(drw, 0, y, w, bh, item->text, 0); > > should be: > > -drw_text(drw, x, y, w, bh, item->text, 0); > +drw_text(drw, 0, y, mw, bh, item->text, 0); > > I will keep the current behaviour, but feel free to continue the discussion. > > Kind regards, > Hiltjo >
Re: [dev] [sent] 0.1 release
Hi, I've implemented a web-based "port" of sent called wsent[0]. I agree to not use the web for anything so I decided to abandon the project after reading the Quenting Rameau post where he suggests a slide to image conversion. Though, since I've put some effort on writing wsent (which is in still in a early stage) I though someone may be interested. I created the repository[0] again. A free web site where you upload your "sent file" to run a slide on your browser would be a nice thing. This is the only reason I may decide to resurrect wsent. Feel free to give feedback. Looking further for a suckless way of getting slides on other's people machine without installing anything. [0] https://github.com/clamiax/wsent Regards, Claudio 2015-11-19 15:01 GMT+01:00 Pickfire : > A good presentation doesn't need nice slides, but instead it needs nice > talk. > > > -- > _ > < Do what you like, like what you do. > > - >\ ^__^ > \ (oo)\___ >(__)\ )\/\ >||w | >|| || >
[dev][dwm][bug] Two bugs concerning floating windows in a dual monitor setup
my setup: external monitor (A) connected to a docking station. lets call the internal display B. A is left of B. first bug: if i move a floating window with alt-shift-, from A to B it is positioned on the left edge of B. if i try to move it back to A the window is assigned to A, but its position doesn't change. second bug: laptop is undocked. open three terminal windows on some workspace. make two of them floating. focus the window that is still tiled. if i dock my laptop now - in that case i run "xrandr --output B --auto" und "xrandr --output A --auto --left-of B" via shell script - both floating windows are hidden underneath the tiled terminal window. can someone confirm these bugs? claudio _ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009
[dev] [surf] Fix unaccessible about: pages.
Hi,
surf cannot access the about: pages since it prepends with "http://"; each uri
not containing the "://" string. The attached patch also checks for the
"about:" prefix.
The patch applies against HEAD (743fa9f3d19af8166b8466f35c464c402e31f554).
Regards,
Claudio
diff --git a/surf.c b/surf.c
index 108485b..23c49bd 100644
--- a/surf.c
+++ b/surf.c
@@ -840,7 +840,7 @@ loaduri(Client *c, const Arg *arg)
u = g_strdup_printf("file://%s", rp);
free(rp);
} else {
- u = g_strrstr(uri, "://") ? g_strdup(uri)
+ u = g_strrstr(uri, "://") || g_str_has_prefix(uri, "about:") ?
g_strdup(uri)
: g_strdup_printf("http://%s";, uri);
}
[dev] Invito a collegarsi su LinkedIn
LinkedIn dev, Vorrei aggiungerti alla mia rete professionale su LinkedIn. -Claudio Claudio Alessi Sviluppatore web presso Pubblicarrello.com Palermo, Italia Conferma che conosci Claudio Alessi: https://www.linkedin.com/e/-irrb6k-h8opyuss-5x/isd/9239720548/bHPfQWfd/?hs=false&tok=2jrrqMmpMWCBs1 -- Stai ricevendo inviti di collegamento. Clicca per annullare l'iscrizione: http://www.linkedin.com/e/-irrb6k-h8opyuss-5x/kR0kGN3Voh2avlqgOYYIPG7Jpiv/goo/dev%40suckless%2Eorg/20061/I3090743897_1/?hs=false&tok=2-qgIn6IYWCBs1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
Re: [dev] last request for a dev-only list
On Fri, Jun 12, 2009 at 01:46:20PM +0800, Samuel Baldwin wrote: > Why can't people filter out messages with [OT] is the subject line? Why can't people just stay on-topic? To me, people should avoid OT posts, should use filters (since the list configuration can't satisfy all users, while personal filters do) and should just read the archives when they only read the list without never write something. The stfu rule suggested by Gottox is also fine, at this point. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] last request for a dev-only list
On Fri, Jun 12, 2009 at 01:10:44PM +0200, Dieter Plaetinck wrote: > I have a totally different POV on this whole matter. > Imho all the threads about these issues are very entertaining reading > material, so I hope the lists stay as they are :) If you mean that you only want one list (dev@) then your POV is not so different. An unique list is all we need; filters and a correct use of the mailing list can do the rest. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] Suckless (*NIX|*BSD) Distribution?
I think you are a bit wrong. I'm not a Gentoo supporter, I used Debian since I can't image a way to handle packages better than it. OTOH the best OS I ever try is NetBSD. It uses pkgsrc as main packages system which, similar is needed in order to install most of the third party packages (without which the system is still usable but umconfortable). Needless to say that I also use it on some box. I must confess I'll use it as primary system (which actually is FreeBSD) after a conflict between azalia(4) and the noapic support will be fixed. Saying that people have to «stay away from it unless you're the kind of hopeless idealist who doesn't mind waiting hours for simple software installs and days before you have a usable system», as Gentoo and other hours-setting-up-based OS like NetBSD are, you are discredit a large part of OS users and developers which, apart the idealisms, believe in some other technical concept as, for example, efficiency, customization and modularization (which mean to have a light core where to build your OS upon). That's why I use and suggests NetBSD as KISS, power and fast OS. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] surf: web browser on archlinux
On Fri, Jul 03, 2009 at 09:51:59AM -0500, Kurt H Maier wrote: > this is the biggest reason I hate firefox too. ^u should not view > source, it should erase the damn line. I guess you (and Uriel) would be happy with the VIMperator extesion. Take in mind that FireFox is *fully* customizable; it shouldn't be much hard to make it behave as you want. Though it's quite clean at this point that all of us (and likely many others people) are waiting for a new decent web browser. Sigh! Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] surf: web browser on archlinux
On Fri, Jul 03, 2009 at 05:59:01PM +0200, Uriel wrote: > You guess wrong. Since your problem is a correct behave of ^W an such "unix" shortcuts I think I guessed right. > This is a bug and a sign of how much FireFox sucks. You are likely right; though it's obvious that you can still *fully* customize it as you like (or, there are no browsers around which can satisfy you as FireFox does, speaking about UI of course). > Actually, that is impossible, FireFox is fundamentally incompatible with the > kind of software that I want. As far as I can tell, FireFox is incompatible with the kind of software everybody here want. Though it's the only one which can fit everyone needs ATM. > The design of Chrome is a bit closer to sanity, but still a long way to go, > at the moment I really like Net-Surf http://www.netsurf-browser.org/ it is > the only browser around written in a sane language that doesn't depend on any > braindead toolkit and has the potential to be usable. I'll never going to use a web browser which I'm not able to install on GNU/Linux and NetBSD (or any other unix-like OS) with the same ease. Also the UI is very important for me, often more than efficiency. I can't use a browser which don't allow me to have a customizable UI like Vim which, for istance on X11 only the VIMperator extension of FireFox does. Further releases of Chrome will likely (and hopefully) change my POV about. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] surf: web browser on archlinux
Ok. -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] dwm-5.6.1
Hi, this with xinerama support disabled: dwm.c: In function ‘updategeom’: dwm.c:1686: warning: unused variable ‘nn’ It should be declared inside the #ifdef XINERAMA block. FWIW, I have no problems at all with dwm. I Couldn't image a better way to deal with my X clients. I'm not sure if it's due to a lack of fantasy, but I'm pretty happy this way. Thanks! Regards, Claudio M. Alessi. -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] dwm number of clients pointless?
On Sun, Sep 13, 2009 at 08:38:41PM +0100, Anselm R Garbe wrote: > Anyone disagrees that the number of clients indicating recently > introduced to dwm-5.6+ is pointless and should be removed again? I usually know exactly how many clients I have opened. But in any case, I don't know how this number can be useful in some way. It's totally useless for me, we should get rid of it. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [surf] Scrolling bug
On Thu, Sep 17, 2009 at 08:53:15PM +0100, Rory McCann wrote: > Hello > > I'm using - and loving - the latest versions of both surf and dwm but I keep > encountering a bug that means I can't scroll pages. It seems to happen > randomly, and it means that I can't use the mouse scroll wheel or the arrow > keys; I just get stuck viewing half a page. Are you sure it isn't a focus problem? As far as I can tell, dwm still need to improve the way it handles the focus. The problem shouldn't be related to surf. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [surf] Scrolling bug
On Thu, Sep 17, 2009 at 11:27:41PM +0200, pancake wrote: > Flash sucks Yeah. It may be the problem. If not, no matter: flash sucks anyway :-) Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] sic - remove stdout formatting?
On Mon, Oct 19, 2009 at 04:04:12PM -0400, Josh Rickmar wrote: > I would like to (re)write an irc bot using sic, but the formatted output > is making this harder then it could/should be. For example, the first > field, the channel or irc server, is cut off at 12 characters by a > colon. This becomes a problem when trying to parse the output because > longer field names can be cut off. It can also cause the number of > fields (seperated by whitespace) to change since a field with >=12 > characters will be missing a space between the name and the colon. > > To make this program more useful, wouldn't it be better if all the > information was presented to the user? Doing so would make writing bots > much easier and would allow the user to easily format the output any way > he/she wants to by passing sic's output to awk. > > Josh Rickmar > +1 It would be better to customize output using sic in pipe with an ad-hoc tool (likely the most useful is awk). There's no need to formatting the output, also why the actual sic output is not much more formatted than the original text sent by the server, it's just a bit reordered. It also would be nice to avoid commands like 'j' or 'l' which could easily be replaced by the original "join" and "part" commands, removing few (useless?) LOCs. Apart from this, sic is the perfect IRC client (and it's said by an old weechat user :-P). Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [surf] next release
On Thu, Oct 22, 2009 at 09:09:25AM -0700, Charlie Kester wrote: > It seems to me that the problems being discussed in this subthread arise > because the "browser" combines two very distinct concerns: > > - managing the http traffic to and from the website, which includes the > administrative details pertaining to the session > > - rendering the documents obtained from the website > > Perhaps we should be thinking about separating them? That's exactly what I was thinking about after reading the Anselm post. I'm pretty sure this is the way to go. We need a "core browser" which is just indipendent from the viewer. Well, it isn't right to call it "browser" but I don't find a better name ATM. Then you can use whatever tool you want to do each thing as you like, better and easily. Regards, Claudio M. Alessi. -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] UTF-8 copyright symbol
On Thu, Oct 22, 2009 at 11:07:03PM +0200, Uriel wrote: > This whole thread is stupid: the complaint about UTF-8 chars is > stupid, and the "copyright notice" is stupid. > > A simple mention in the readme like: "This code is released to the > public domain and under the MIT and ISC licenses, pick whichever > option suits you." should be enough, or if you feel really obnoxious > put it in a LICENSE file at the root of the project. > > That is what I do for all my code, it is short, simple, and works no > matter how retarded the laws are in your country. > > uriel +1 Remove the '-v' flag at all. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [dwm] an update of the moveresize patch
I'm not sure what you mean with "old patch" but I use this since very old dwm
releases (though with very little changes from time to time):
static void
moveresize(const Arg *arg)
{
XEvent ev;
if( ! (selmon->sel && arg && selmon->sel->isfloating && arg->v) )
return;
resize(selmon->sel, selmon->sel->x + ((int *)arg->v)[0],
selmon->sel->y + ((int *)arg->v)[1],
selmon->sel->w + ((int *)arg->v)[2],
selmon->sel->h + ((int *)arg->v)[3],
True);
while( XCheckMaskEvent(dpy, EnterWindowMask, &ev) );
}
You can avoid the "fields" postfix if you remember they are in a precise order.
In this case: x, y, w, h. In my config.h the key bindings are as follow:
{ MODKEY, XK_Down, moveresize, {.v = (int []){ 0,
25, 0, 0 }}},
{ MODKEY, XK_Up, moveresize, {.v = (int []){ 0,
-25, 0, 0 }}},
{ MODKEY, XK_Right, moveresize, {.v = (int []){ 25,
0, 0, 0 }}},
{ MODKEY, XK_Left, moveresize, {.v = (int []){ -24,
0, 0, 0 }}},
{ MODKEY|ShiftMask, XK_Down, moveresize, {.v = (int []){ 0,
0, 0, 25 }}},
{ MODKEY|ShiftMask, XK_Up, moveresize, {.v = (int []){ 0,
0, 0, -25 }}},
{ MODKEY|ShiftMask, XK_Right, moveresize, {.v = (int []){ 0,
0, 25, 0 }}},
{ MODKEY|ShiftMask, XK_Left, moveresize, {.v = (int []){ 0,
0, -25, 0 }}},
Hope this helps.
--
JID: smoppy AT gmail.com
WWW: http://cma.teroristi.org
Re: [dev] dvtm - get list of terminals
Or just use a command like the following: for P in $(pgrep -P $(pgrep -n dvtm)) ; do ps x -o ppid,tty |grep ^$P ; done This will works with the first instance of dvmt found, though it's extremely easy to make a script which handles all running instances. Hope this helps. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] Re: slock - cannot log in
On Fri, Dec 18, 2009 at 12:48:48PM -0500, doki_...@doki-pen.org wrote: > In gmane.comp.misc.suckless, you wrote: > > 2009/12/17 Tony Lainson : > > No. A screen locker locks the system completely (apart from remote logins). > > This seems odd to me. So you are saying that on a multi-user system a > normal user can lock out the root user? And the only way for the root > user to unlock is to do a remote login? > No, he was just wrong. An X11 screen locker just locks X. Because of how X works, you are still able to ^-mod-F* to a virtual terminal and login as usual. That's all. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev][dwm] window tagging
On Tue, Jan 12, 2010 at 03:47:19PM +, Anselm R Garbe wrote: > This will be solved in dwm 5.8, which should arrive soon. In the while: http://lists.suckless.org/dev/0912/2687.html Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [SLOCK] is not safe
On Sun, Jan 17, 2010 at 04:17:16PM +0100, Julien Pecqueur wrote: > Hi, Hi > I'm using slock and i am suprised to realize that is not safe at all! Oh, you are scary me. > I launched slock in my DWM session. I just have to press CTRL+ALT+F1 > and press CTRL+z (to send startx in background an get the hand on the > shell) and type "killall slock" to unlock the session... I wondering what all this have to do with security!? ^-mod-f1 is an X11 behaviour, nothing to do with slock (and it's also configurable); as regards as kill (and brothers) there is nothing concerning security: you are the owner of the process and you are, obviously, enabled to stop (or kill) it. What's wrong? If you won't slock to be killed by users, run it as root, or just trust yourself (ergo, your user). Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [OFFTOPIC] Recommended meta-build system
On Mon, Feb 01, 2010 at 01:06:09PM +, Anselm R Garbe wrote: > To be fair Uriel isn't completely wrong. In an ideal world everyone > would just use the software as is and not waste time on fiddling > around with colors and such. But obviously a lot of people like > customizing things/making them different to the default. I'm not sure > what the reason is, but people fiddle around their cars, by bigger > wheels, bigger exhausts, make the windows black etc. Same with > software and desktop setups. Yes, he is completely wrong. Using software as is means using a software with the developer's tastes, not mine. That's a totally retarded concept (almost like the previous Uriel's statement). It's not only a matter of colors, but most important things like fonts, key bindings, and so forth. That's where config.h wins againts initrc.local, where you can't also configure the PLAN9 base (well, you can't but it's useless) without have to change the shesbang of werc.bin. > So the ideal world doesn't exist, however we think the lesser options > there are, the better. The best tools are those that have no options, > like nearly no one changes the look of the vacuum cleaner once bought, > or of your micro wave, or of your iron board, or nearly no one > repaints the case of a TV. The ideal world does exists: we have suckless software and config.h. Well, we also have werc. The best tools are those which are better. Period. Less options is not better, the need to have less options converge with a better software. It's different. In the real world, you don't have any real advantages by changing how the vacuum cleaner looks like, while you obviously will find much more comfortable a font (or color) which fits well your eyes; expecially if you spend much of your time ahead a monitor. This will make you less distract, much more efficient and productive and also much happy. That's our real perfect world. > The point is people would be able doing much more useful stuff when > they won't spend their time with fiddling around with things that are > not mandatory == eg not customising cars but coming up with some great > philosophy instead ;) Philosophy is nothing if not applied to the real world. If it doesn't fits with the real world, then is a bad philosophy (or, this is the case, retarded). Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [OFFTOPIC] Recommended meta-build system
I meant werc.rc, as you can image. -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [sic] Segfault
What about removing (or commenting) line 45 by default? Who needs debug output can put (or remove comment) itself. -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [sw] Suckless web-framework
On Tue, Apr 06, 2010 at 08:50:07PM +0400, anonymous wrote: > You don't put same symlinks (to ~/doc, ~/src etc.) in every directory of > your filesystem. Most directories have only one link to them. Then why > should you put links to upper levels in every directory (and even file) > of your website? It makes sense. The '..' link allow you to directly go back to the upper level which, in the case of N sub-levels (e.g., docs/unix/foo/bar/mydoc) you have to use the browesr back feature N times (where N is the amount of sub-levels) while a '..' link allow you to switch to the upper level with only one click. E.g. on http://werc.cat-v.org/docs/web_server_setup/apache2 you have to use the back feature 2 times to back to docs/ (and 3 for the home page) while with a '..' link you only have to click it once. > For example look at http://www.fidonet.org/ When you go to "What is > FidoNet?" or "How to Join FidoNet", there is no link back. You can press > "back" in your browser, edit URL or something like this. Well, same problem here: http://www.fidonet.org/old/genlinfo.html You need two clicks to back to the home page (unless you use gU with Vimperator or other evil stuff -- which I use :P); with the dot-dot link you only need one click. > Another example is http://www.mutt.org/ There is link "more news", > but no link to main page in http://www.mutt.org/news.html. Same as above. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] stali and OpenBSD userland etc.
On Sat, Apr 10, 2010 at 09:29:10PM +0200, pancake wrote: > I wrote tac in 9base a week ago... I would really prefer 9base before other > alternatives if we can choose. Most of them are valid replacements +1 I would prefer plan 9 userland againsts OpenBSD (where possible). After all it's a suckless distribution and it seems that plan 9 userland sucks less than OpenBSD one. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] Encoding errors with umlauts in dwm statusbar and dmenu
On Mon, Apr 19, 2010 at 11:07:24PM +0200, orsch...@gmail.com wrote: > And when you are try to fix this could you please also try to correct the > flash fullscreen issue? I use this workaround without any issue: http://lists.suckless.org/dev/0912/2687.html Hope this helps. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] vimium extension for chromium
On Tue, May 18, 2010 at 11:44:08PM +0200, pancake wrote: > http://vimium.github.com/ It's a nice extension which I use since I started using Google Chrome as my daily web browser. Though some features I use much are not present so I forked the project on github. You may find it interesting: http://wiki.github.com/clamiax/vimium/ > bastards trying to cloning surf ;) Nobody want to clone anything; we just would like to use our own browsers in a more comfortable way. Regards, Claudio M. Alessi
Re: [dev] vimium extension for chromium
On Thu, May 20, 2010 at 01:32:29AM +0200, pancake wrote: > It was a joke Indeed, i'd suspect it ;-) -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] [sic] null pointer in printf
This bug is not present in tip anymore; feel free to upgrade your local sic sources ;-) Regards, Claudio M. Alessi
Re: [dev] [surf] please recheck tip
On Mon, May 24, 2010 at 04:06:00PM -0400, Josh Rickmar wrote: > Also, is there a better way of doing cookies then wget? As an (Open)BSD > user, I'd like to use something in base (I did install wget though to > test to make sure that wasn't the download problem above). IIRC you can use ftp(1) for HTTP requests. Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://cma.teroristi.org
Re: [dev] Fullscreen issue & EWMH
On Thu, May 27, 2010 at 07:59:29AM +0200, orsch...@googlemail.com wrote: > Because this is still an unsolved problem. Both problem are solved: o Chrome: see the previous post; o Flash: see http://lists.suckless.org/dev/0912/2687.html Regards, Claudio M. Alessi
Re: [dev] dwm-5.8.1 / dmenu-4.1.1
No issues here; it works perfectly. Thanks! Regards, Claudio M. Alessi -- JID: smoppy AT gmail.com WWW: http://clamiax.selfip.org
Re: [dev] Tiling windowmanager workflow (Was: [dvtm] Fibonacci layout patch)
On Fri, Jun 04, 2010 at 07:07:15PM +0200, Alexander Teinum wrote: > I use four tags: > > 1 – Web > 2 – Editing > 3 – Terminal > 4 – Spotify If you use one client per tag, then you could use only one tag and cycle between clients (like you actually do with tags). I usually have 2 tags, 1 with rxvt+dvtm, 2 with Google Chrome, which I switch with mod-tab. I'd also set mod-backspace to cycle the clients into the current tag. Though, I'd invert Caps Lock and Backspace, so it's almost the same thing to type mod-tab or mod-backspace. I know it's a matter of taste, but think about it if can improve your workflow in some way. > Since alt+numbers is used for changing tabs in Chromium, I use alt+j, > alt+k, alt+l and alt+; for switching between the tags in dwm. I don't > use much of the more advanced tag features. I have set up these > keyboard shortcuts for launching applications: Why don't you just replace all [1-9] with F[1-9] in your config.h? This way you can comfortally use all clients which already provide alt-[1-9] to change "something" (like Chromium). Regards, Claudio M. Alessi
Re: [dev] Tiling windowmanager workflow (Was: [dvtm] Fibonacci layout patch)
On Sun, Jun 06, 2010 at 11:34:08AM +0200, Alexander Teinum wrote: > I actually prefer cycling between the applications that I work with, > and I was going to create an alt+tab patch to give it the traditional > alt+tab behavior. Now I don’t have to. Thanks! You're welcome! > What is a minor annoyance for me is how the “m”-mode in dwm is > implemented. The clients that aren’t in focus are visible underneath > the focused window. At least I think that’s how it’s done, since I can > see Chromium at the bottom of urxvtc. I'm not sure to understand correct this behaviour. If "m"-mode means the default meta-m keystroke (monocle layout in vanilla config.h), how can you see more than on client in monocle. Does your focused window is floating? > One thing that might be a bit off-topic, but I have been thinking > about the placement of the left alt-key lately. I have caps lock > mapped as control, and I only use the caps key and the left alt for > controlling stuff – i.e. I don’t care about the Windows- or the > Fn-key, or anything to the left of the left alt. I have observed that > both of my thumbs rest on the space key, but I only hit space with the > right thumb. What would make the keyboard more ergonomic for my use > was if half of the space key was an alt key. What a waste of space > (pun) the way that it is now. I have to move my thumb 2–3 cm into an > awkward position every time that I want to press alt – which is > something that I do very often. Imagine doing alt+j and alt+k without > moving the thumb… What about place your awkward key to either one of the shift keys (that you use less often, or don't use at all :-)). I can't think a better solution, except to use F1[0-2] if you only have 9 or less tags; this, though, sounds uncomfortable as well. I'll think a bit about this in order to improve my layout too. Thanks for the hint. Regards, Claudio M. Alessi
Re: [dev] Presentation slides software
On Sun, Jul 04, 2010 at 02:13:38PM +0200, Uriel wrote: > I honestly and deeply hope you fail completely. Please, put this on quotes.cat-v.org. Claudio M. Alessi
Re: [dev] [dev] Usage, -h, --hel p, help, synopsis, …
On Tue, Aug 17, 2010 at 08:52:37PM +0400, anonymous wrote: > usage: cmd [-abcde] [-f file] [-g pattern] [file ...] What about cmd [-abcde] [-fg arg] [file ...]? > usage: flo [-c id] [-f from] [-r id] [-t to] [-w what] [what[,from][-to]] With the above rules this should be: flo [-cfrtw arg] [what[,from][-to]] Leaving the man page the task to teach the user what each option do. It would be nice to have a guidelines with this and other stuff there, at least for the suckless community.
Re: [dev] [dwm] combining 'moveresize' with 'pertag'
I have no idea why the pertag patch moves the Monitor struct after the config.h inclusion but I "feel" it's wrong. You should move the config.h at the end of all structures definitions in order to ``allow nested code to access above variables''. This way, everything will works properly out of the box. That's all. Regards, Claudio M. Alessi
Re: [dev] [dwm] combining 'moveresize' with 'pertag'
Well, the moveresize feature isn't provided by a patch at all. You'll have to copy/paste a function somewhere in config.h then add the relative bindings. I replaced config.h with dwm.c into the wiki. Regards, Claudio M. Alessi
Re: [dev] [dwm] patch for statuscolors improved
It seems like useless rather than suckless.
