Re: [dev] st patch for draw() etc.

2011-04-27 Thread anonymous
On Sat, Apr 23, 2011 at 03:48:46PM +0400, anonymous wrote: > On Fri, Apr 22, 2011 at 12:31:37AM +0200, Aurélien Aptel wrote: > > On Wed, Apr 20, 2011 at 5:46 PM, Magnus Leuthner > > wrote: > > > Please note that the drawing for the selection while selecting only works > > > if > > > the -Os optio

Re: [dev] st patch for draw() etc.

2011-04-23 Thread anonymous
On Fri, Apr 22, 2011 at 12:31:37AM +0200, Aurélien Aptel wrote: > On Wed, Apr 20, 2011 at 5:46 PM, Magnus Leuthner > wrote: > > Please note that the drawing for the selection while selecting only works if > > the -Os option to GCC is omitted. I have not idea why but I would be very > > interested

Re: [dev] st patch for draw() etc.

2011-04-22 Thread Bjartur Thorlacius
On Fri, Apr 22, 2011 at 3:12 PM, Aurélien Aptel wrote: > On Fri, Apr 22, 2011 at 1:38 PM, Bjartur Thorlacius > wrote: >> While I believe we need a simple text UIO widget that doesn't >> interpret terminal escapes et cetera, I can't see why the shell should >> even be awere of user keystrokes. Or

Re: [dev] st patch for draw() etc.

2011-04-22 Thread Aurélien Aptel
On Fri, Apr 22, 2011 at 1:38 PM, Bjartur Thorlacius wrote: > While I believe we need a simple text UIO widget that doesn't > interpret terminal escapes et cetera, I can't see why the shell should > even be awere of user keystrokes. Or are you suggesting something like > rlwrap read | rc? It's jus

Re: [dev] st patch for draw() etc.

2011-04-22 Thread Bjartur Thorlacius
On Wed, Apr 20, 2011 at 7:36 PM, Claudio wrote: > 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 shou

Re: [dev] st patch for draw() etc.

2011-04-21 Thread Connor Lane Smith
Hey, On 21 April 2011 09:20, Anselm R Garbe wrote: > The best compromise we came up with is having a shared draw.c among > dwm and dmenu at least, which is on the agenda for dwm 6.0. Probably > this could also be used for st. For what it's worth, I have been running a version of dwm which uses d

Re: [dev] st patch for draw() etc.

2011-04-21 Thread Aurélien Aptel
On Wed, Apr 20, 2011 at 5:46 PM, Magnus Leuthner wrote: > Hi, > attached is a patch for st-0.1.1 that will make the following changes: >  - rewrote some of the drawing routines, should be faster now and allows to > draw the selection while selecting Nice, applied. >  - pressing ESC clears select

Re: [dev] st patch for draw() etc.

2011-04-21 Thread Aurélien Aptel
On Wed, Apr 20, 2011 at 9:36 PM, Claudio wrote: > 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 shou

Re: [dev] st patch for draw() etc.

2011-04-21 Thread Anselm R Garbe
On 21 April 2011 11:39, Nick wrote: > On Thu, Apr 21, 2011 at 10:20:41AM +0200, Anselm R Garbe wrote: >> In dwm/dmenu and probably st I see some potential to share a single >> implementation of draw.c. At first I wanted to create a lib for this, >> but when Connor tested this approach in dmenu we

Re: [dev] st patch for draw() etc.

2011-04-21 Thread Nick
On Thu, Apr 21, 2011 at 10:20:41AM +0200, Anselm R Garbe wrote: > In dwm/dmenu and probably st I see some potential to share a single > implementation of draw.c. At first I wanted to create a lib for this, > but when Connor tested this approach in dmenu we concluded, that > additional library depen

Re: [dev] st patch for draw() etc.

2011-04-21 Thread Anselm R Garbe
On 20 April 2011 21:36, Claudio wrote: > 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

Re: [dev] st patch for draw() etc.

2011-04-21 Thread Magnus Leuthner
Regardless of the inputs, there is also a bit of work against the rendering of selections in the patch, it's just very convenient to see the presently selected area while still dragging the selection. At least for me the screen draw is incredibly slow, especially with curses applications like alsam

Re: [dev] st patch for draw() etc.

2011-04-20 Thread pancake
Uhm... Maybe swk can benefit from this work.. This remembers me to libdraw.. On Apr 20, 2011, at 9:36 PM, Claudio wrote: > 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 key

Re: [dev] st patch for draw() etc.

2011-04-20 Thread Claudio
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 "termi

[dev] st patch for draw() etc.

2011-04-20 Thread Magnus Leuthner
Hi, attached is a patch for st-0.1.1 that will make the following changes: - rewrote some of the drawing routines, should be faster now and allows to draw the selection while selecting - pressing ESC clears selection - CTRL+left/right jumps words I'm not sure it's implemented to your standard