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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
15 matches
Mail list logo