I'm attempting to get st to use Dina as it's font. At first, I couldn't get
st to read the font at all (it would die upon launching, saying it couldn't
find the font), but I've had issues with Dina before - the CP1252
encoding was giving urxvt problems a while back so I re-encoded it
(to ISO8859-1)
On Tue, May 31, 2011 at 9:08 AM, Bryan Bennett wrote:
> I'm attempting to get st to use Dina as it's font. At first, I couldn't get
> st to read the font at all (it would die upon launching, saying it couldn't
> find the font), but I've had issues with Dina before - the CP1252
> encoding was givi
So far, this font issue and the lack of a scrollback buffer are
my only issues with st. I'm having strange problems with urxvt
under another (inferior / floating) window manager, which has
pushed me towards st. I could be using xterm, but...eww.
Terminus drew nice and quickly for me when I was usi
On Tue, May 31, 2011 at 9:33 AM, Bryan Bennett wrote:
> So far, this font issue and the lack of a scrollback buffer are
> my only issues with st. I'm having strange problems with urxvt
> under another (inferior / floating) window manager, which has
> pushed me towards st. I could be using xterm,
On Tue, May 31, 2011 at 09:46:46AM -0400, Le Tian wrote:
> Well, when I got tired of urxvt, aterm and xterm, I switched to "terminal"
> and then "sakura", both very lightweight and easy on your fonts, plus
> transparency support. In my opinion "st" seems like not very stable now,
> moreover, it is
hi,
On 05/29/11 13:00, Rafa Garcia Gallego wrote:
Thinking about a couple of issues now:
1.- The regexes used for syntax highlight relied on a GNU extension
(\< \> to mark word boundaries). We changed those to \b, which is the
POSIX equivalent, but some testing has determied this does not wor
(Consider this my thoughts on a general text editor and not a
review of Sandy - I've not tried Sandy since I found it on the
Arch forums a ways back - long before being brought up here)
I've recently thought a lot about editors, as I'm not satisfied with
vi/vim and emacs chains are shitty beyond
> Honestly, I dislike 'modal text editors' as I feel they make the task at
> hand more difficult that it was to begin with. Sure there's a lot to be
> said for the power they bring, but with some forethought and planning
> I think that most of the power and all of the 'usefulness' of a modal
> edit
On 29 May 2011, at 12:56 am, Dave Reisner wrote:
I'm sure I'll get hated for this, but it's entirely possible to read
chunked transfer with shell. I wrote a stupid proof of concept AUR
agent
in bash which handles keep-alives and chunked/gzip encoded data -- the
only other dependencies are dd
Hi,
On Tue, May 31, 2011 at 4:40 PM, pancake wrote:
> After reading the libregex9 code (1200LOC, and probably the best regexp
> library out there)
> (because openbsd regex is about 3KLOC and musl 5KLOC and have some
> documented bugs,
> gnu one is about 35.000LOC...
>
> the thing is that \b is th
On 31 May 2011 15:40, pancake wrote:
> PD: Anselm, are you still alive?
Yes, June is approaching and my agenda will start very soon :)
Cheers,
Anselm
There is a patch to support Xft somewhere (but it's slow). We have to
re-implement the GLYPH_DIRTY trick to speed the rendering.
On Tue, May 31, 2011 at 3:46 PM, Le Tian wrote:
> Well, when I got tired of urxvt, aterm and xterm, I switched to "terminal"
> and then "sakura", both very lightweight
On 5/31/11, Rafa Garcia Gallego wrote:
> A tad unrelated, but not really... I was quite sure about using
> keyboard positioned bindings before (be them hjkl, ijkl, the wordstar
> thingy or even wasd as it has been suggested). However, a lot of
> suckless software users seem to have a non-qwerty ke
On Tue, May 31, 2011 at 12:51 PM, Rafa Garcia Gallego
wrote:
> - ^A / ^E go to bol / eol or, if already there, move by one full page.
> I find this weirdly comfortable.
Is a page some standard size or is it determined by the size of the terminal?
--Andrew Hills
Hi,
Thanks for your input.
On Tue, May 31, 2011 at 8:07 PM, Bjartur Thorlacius
wrote:
> On 5/31/11, Rafa Garcia Gallego wrote:
>> A tad unrelated, but not really... I was quite sure about using
>> keyboard positioned bindings before (be them hjkl, ijkl, the wordstar
>> thingy or even wasd as it
Hey,
I've just got around to properly trying sandy. I'm not a fan of the
curses approach, but I'm otherwise quite impressed. (I've not read the
code yet, but the editor itself has a nice feel to it.)
On 31 May 2011 17:51, Rafa Garcia Gallego
wrote:
> - ^U works as it should.
> - ^C kills the nex
On Tue, May 31, 2011 at 07:19:26PM +0200, Aurélien Aptel wrote:
> > transparency support. In my opinion "st" seems like not very stable now,
>
> If you found a bug, please report it. It's the only way we can fix it.
Code for text selection is buggy. I can only see what I selected after
either I
Hi,
On Tue, May 31, 2011 at 10:56 PM, Connor Lane Smith wrote:
> I've just got around to properly trying sandy. I'm not a fan of the
> curses approach, but I'm otherwise quite impressed. (I've not read the
> code yet, but the editor itself has a nice feel to it.)
Yeah. Ncurses is really the less
On Tue, May 31, 2011 at 09:33:59AM -0400, Bryan Bennett wrote:
> So far, this font issue and the lack of a scrollback buffer are
> my only issues with st. I'm having strange problems with urxvt
> under another (inferior / floating) window manager, which has
> pushed me towards st. I could be using
On Mon, May 30, 2011 at 12:15:52PM -0500, orlando wrote:
I've recently started using wmii and I'm really liking it so far. The one
thing that is bugging me is this rectangle shown in the right side of the
titlebar (when in floating mode). How can I make it disappear? I've looked
into the guide
I've also noticed that my vim theme paints invisible text (try doing
"TERM=xterm vim somfile" and see what happens), but I've begun
using vile recently so that's really of no consequence.
Honestly, since urxvt works fine here, I'll probably just go back to that.
I can't figure this one out and I r
> - the lack of a scrollback buffer, already mentioned
> - double-click-and-drag selection, like xterm has
> (st currently supports double-click word selection; implementing this
> should be no big deal... I might look at it)
> - vim in st with Solarized [1] colorscheme draw
FWIW, if one (as I do) always run a tmux instance on top of whatever X
terminal one launches, neither the lack of scrollback buffer nor the
double-click-and-drag selection should be on the TODO list, since these
features are moot granted one uses tmux. In fact, I'd prefer they be
treated as bloat
On Tue, May 31, 2011 at 8:54 PM, Jonathan Slark
wrote:
> It's a point though, do we need a suckless screen replacement? If you use
> dwm you don't need it but lately I've been looking into cwm/tmux instead.
If all you're looking for is detach, dtach[1] exists. Under 1k of code.
[1] http://dtach
On 1 June 2011 02:00, Kurt H Maier wrote:
> On Tue, May 31, 2011 at 8:54 PM, Jonathan Slark
> wrote:
>> It's a point though, do we need a suckless screen replacement? If you use
>> dwm you don't need it but lately I've been looking into cwm/tmux instead.
>
> If all you're looking for is detach, d
25 matches
Mail list logo
