Re: [dev] [st] Font issues
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, dtach[1] exists. Under 1k of code. > > [1] http://dtach.sourceforge.net/ and dvtm[1] if you want multiple shells [1] http://www.brain-dump.org/projects/dvtm/
Re: [dev] [st] Font issues
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.sourceforge.net/ -- # Kurt H Maier
Re: [dev] [st] Font issues
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. You can't class tmux as suckless. I tried it and the amount of options and commands etc. was intimidating! 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. Jon.
Re: [dev] [st] Font issues
> - 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 draws invisible text > (this is quite strange; not sure where the problem is...) 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. Peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] [st] Font issues
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 really don't care enough to track it down
Re: [dev] wmii floating window titlebar decoration
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 and styling part section, but nothing. I've looked at a couple of screenshots from people using wmii and some of them don't have that type of decoration in the titlebar. I'm not very familiar with older versions of wmii so could this be a feature implemented in the newest versions? If so, any clues on how to make it go away? It's not possible to remove it, nor has anyone asked for it to be removeable before. I don't see a reason for it to be possible, either, since it would add complexity for no useful end. Yes, it is a feature of recent versions. For a long time, the most requested feature was to make floating windows more distinguishable from managed windows. That's why it was added. -- Kris Maglione Programming X Windows is like trying to find the square root of Pi using roman numerals. --Henry Spencer
Re: [dev] [st] Font issues
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 xterm, but...eww. > > Terminus drew nice and quickly for me when I was using it > and Tamsyn works wonderfully as well. I'm just curious what > I could be doing wrong. > Terminus works fine. I have no issues with it, being it in st or anywhere else. st seems pretty okay, quite usable. My personal issues with it, preventing me from switching to it are: - 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 draws invisible text (this is quite strange; not sure where the problem is...) [1] http://ethanschoonover.com/solarized -- # Petr Sabata pgpNz4TmXJoMA.pgp Description: PGP signature
Re: [dev] Sandy editor
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 lesser evil. Thanks for your support!
> On 31 May 2011 17:51, Rafa Garcia Gallego
> wrote:
>> - ^U works as it should.
>> - ^C kills the next word (former META-D). Sorry, I seem to use this one a
>> lot.
>> - ^K, ^W, ^H and ^D complete your killing family as usual. I don't
>> know how much you guys use these.
>
> I use C-u, C-k and C-w constantly. I've also found myself longing for C-c.
Those are pretty standard and IMO should remain there if possible.
>> - ^X saves or quits, ^Q quits without asking (!!)
>
> imo C-q should say "unsaved changes!" and a second C-q should quit
> regardless, ed-style. This way, C-q C-q can be a quick-quit.
Sure, we'll get there.
>> - Sadly, there is no easy way to move word-by-word
>
> Can curses handle C-Left and C-Right?
Not per-se. Urxvt reports the up arrow wit no mod, shift, control as
^[[A , ^[[a and ^[Oa respectively, but Ncurses only collects KEY_LEFT
and KEY_SLEFT.
I now see that xterm reports the modifiers in a different way and st
does not report control at all, which is probably healthy if there is
no standard way of doing so.
>> - Sadly, there is no immediate way to copy to the clipboard: it is
>> either cut and paste (e.g. ^W^Y) or move your hand and press INS.
>
> Could 'go-to-line' be rebound to C-: or so, and C-t be 'copy'?
> Rationale: sam's copy command is 't'.
Again, the problem is C-: does not really report anything but ':'.
I'll try to find an alternative, but I had not thought of ^T for copy.
>> As I already said, I have mixed feelings about modality. In case we go
>> modal, we'd probably use something akin to vi's command mode bindings
>> I guess. Let's hear some opinions before acting.
>
> Don't Mode Me In.
>
> Seriously, if you want Vi, use Vi. (I do, but hope to change that.)
Yeah, actually that's pretty much why I started sandy.
>> He reached to me this morning, ought to have the repo in place tonight.
>
> Yep, it's there. What's your opinion on commits, btw? Are you happy
> with others committing, or do you want us to talk to you instead?
I'm happy with others commiting reasonable stuff as long as it does
not clutter the source much, etc, etc
> Related: you need the CPPFLAGS -D_BSD_SOURCE and -D_POSIX_SOURCE, for
> {set,get}env and kill, respectively.
Added that, thanks!
By the way, the mercurial repo for sandy is now at
http://hg.suckless.org/sandy/ , go clone it, play with it, commit
interesting changes!
Regards,
Rafa.
Re: [dev] [st] Font issues
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 release mouse or when st is compiled with -fno-strict-aliasing. Can't find how to fix it. BTW I have found out-of-bounds read which causes SIGSEGV. Function bmotion calls drawregion with y2 > term.row on line 603: drawregion(0, (starty > 0 ? starty : 0), term.col, (sel.ey < term.row ? endy+1 : term.row)); It sets endy to MAX(oldey, sel.ey). Everything is ok when sel.ey > oldey, but oldey is not checked. So if you, while selecting, move mouse out of terminal window and back, it segfaults. drawregion line should be changed to drawregion(0, (starty > 0 ? starty : 0), term.col, (endy < term.row ? endy+1 : term.row)); Another bug: while selecting, move mouse far higher than first row. Text disappears until you move mouse back.
Re: [dev] Sandy editor
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 next word (former META-D). Sorry, I seem to use this one a lot.
> - ^K, ^W, ^H and ^D complete your killing family as usual. I don't
> know how much you guys use these.
I use C-u, C-k and C-w constantly. I've also found myself longing for C-c.
> - ^X saves or quits, ^Q quits without asking (!!)
imo C-q should say "unsaved changes!" and a second C-q should quit
regardless, ed-style. This way, C-q C-q can be a quick-quit.
> - Sadly, there is no easy way to move word-by-word
Can curses handle C-Left and C-Right?
> - Sadly, there is no immediate way to copy to the clipboard: it is
> either cut and paste (e.g. ^W^Y) or move your hand and press INS.
Could 'go-to-line' be rebound to C-: or so, and C-t be 'copy'?
Rationale: sam's copy command is 't'.
> As I already said, I have mixed feelings about modality. In case we go
> modal, we'd probably use something akin to vi's command mode bindings
> I guess. Let's hear some opinions before acting.
Don't Mode Me In.
Seriously, if you want Vi, use Vi. (I do, but hope to change that.)
> He reached to me this morning, ought to have the repo in place tonight.
Yep, it's there. What's your opinion on commits, btw? Are you happy
with others committing, or do you want us to talk to you instead?
Related: you need the CPPFLAGS -D_BSD_SOURCE and -D_POSIX_SOURCE, for
{set,get}env and kill, respectively.
Thanks,
cls
Re: [dev] Sandy editor
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 has been suggested). However, a lot of >> suckless software users seem to have a non-qwerty keyboard layout. > Then bind to button three on row three, and second to fourth button on > row four. What characters they represent in insert mode (or when the > control modifier is not down) is irrelevant. That's got to be hard enough, considering the terminal just provides characters on the standard input. We can have a reverse lookup table for each keymap, but that definitely would suck hard. On Tue, May 31, 2011 at 8:43 PM, Andrew Hills wrote: > 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? So far it is the size of the text window, i.e. the terminal unless there is no status line and the status has to be printed to the window too. Would you guys be more comfortable with less (e.g. one or two lines less) than the full window size? Best regards, Rafa.
Re: [dev] Sandy editor
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
Re: [dev] Sandy editor
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 keyboard layout. Then bind to button three on row three, and second to fourth button on row four. What characters they represent in insert mode (or when the control modifier is not down) is irrelevant.
Re: [dev] [st] Font issues
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 and easy on your fonts, plus sakura uses gtk and vte. It's not exactly lightweight. > 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. > moreover, it is slow, when comes to lines of code, Rendering is slow, I'll give you that. But for normal, day-to-day tasks, it's acceptable for me. As for the lines of code, what about them? > and btw, I'm not sure there are ppl out here who actually use it that much;) ok.
Re: [dev] Sandy editor
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
Re: [dev] Sandy editor
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 the posix implementation and \< is a gnu extension,
> but both are quite
> new, and well.. after reading the code of the p9 regexp lib i realized that
> it is completely
> unnecessary, as long as you can write a (^| |\t|;|{|\(|\{|\[)... regexp that
> matches the same.
> it's a bit annoying if you have to type it manually, but this can be done in
> a #define B as I
> told you by xmpp yesterday.
>
> Please commit the fix and we will get portable regexp support.
Thanks a lot for researching this. I have commited this to the default
config file though there is some weirdness in using the boundary chars
to delimit the match (e.g. "else if" does not get coloured properly
unless you double the space). I also added $ (i.e. eol) to the list of
delimiters.
> Another thing is that it would be great to be able to disable the syntax
> highlight:
>
> diff -r e2542c05953f sandy.c
> --- a/sandy.c Tue May 31 01:39:32 2011 +0200
> +++ b/sandy.c Tue May 31 16:34:39 2011 +0200
> @@ -1614,6 +1614,8 @@
> tabstop=atoi(argv[i]);
> } else
> i_usage();
> + } else if(!strcmp(argv[i], "-S")) {
> + local_syn="";
> } else if(!strcmp(argv[i], "-s")) {
> if(++i < argc) {
> local_syn=argv[i];
>
> add this patch to have -S to not use any syntax highlight
You could already do this with -s none (or -s hjklhjkl really), but I
agree -S seems cleaner. Thanks again and commited.
> i'm preparing a control-only based keyboard layout for sandy.. i'll have a
> look
> at your version, but I still think that modes will allow us to keep some
> sane
> control commands and be more productive for moving without
> meta/control/shift
> keys on the command mode.
Yeah, me too. As agreed, mine will follow more or less the emacs
defaults. It was difficult to remove many keybindings and adding a
condition was maybe a hacky solution. I have commited my attempt as
config.control_only.h Please feel free to try and provide feedback.
Some differences from the emacs default or the default config:
- ^U works as it should.
- ^C kills the next word (former META-D). Sorry, I seem to use this one a lot.
- ^K, ^W, ^H and ^D complete your killing family as usual. I don't
know how much you guys use these.
- ^A / ^E go to bol / eol or, if already there, move by one full page.
I find this weirdly comfortable.
- ^S / ^R as for a search term or, if there is any selection (e.g.
right a search match), search for the next occurrence of the previous
search.
- ^@ sets (the one) mark
- ^O goes to the other side of the selection, or to the mark if there
is no selection.
- ^T prompts you for a line to go to.
- ^[ (also Esc) prompts you for syntax, but it may as well be a
command line writing directly to the pipe. It has a slight lag while
attempting to read a META sequence. NCurses fault, not mine. Will try
to solve.
- ^X saves or quits, ^Q quits without asking (!!), ^] extends the
selection as the former ^X.
- Sadly, there is no easy way to move word-by-word: Shift+Left/Right
is the current only binding. You can still kill words left and right
with ^W/^C.
- Sadly, there is no immediate way to copy to the clipboard: it is
either cut and paste (e.g. ^W^Y) or move your hand and press INS.
I do not intend to keep two default config files in the repo except
for tests and such, so try and report any weirdness and we can make
this the default; unless we like pancake's version more, of course. We
can have a wiki page, a separate repo or something for alternative
configurations.
> Vi is great, and it's great for something, the only bad thing is that most
> implementations
> are bloated.. but with the codebase of sandy we can do an almost decent vi
> clone.
>
> Most basic editor functionality in sandy will be possible without changing
> between
> modes, but having the possibility to use the commands mode will provide a
> more
> decent interface. (IMHO).
>
> Anybody more wanna give your opinion?
As I already said, I have mixed feelings about modality. In case we go
modal, we'd probably use something akin to vi's command mode bindings
I guess. Let's hear some opinions before acting.
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 keyboard layout.
> PD: Anselm, are you still alive?
He reached to me this morning, ought to have the repo in place tonight.
> PD: it's an already known bug, but multiline comm
Re: ***SPAM*** Re: [dev] suckless wget/curl
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 and gzip, and optionally yajl (for formatting jsons). https://github.com/falconindy/bin-scripts/blob/master/orb Perhaps this will inspire someone... Filed to look at when I work on rc-httpd next, thanks.
Re: [dev] Sandy editor
> 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 > editor to a modeless one. you're reinventing emacs badly
Re: [dev] Sandy editor
(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 belief. I honestly think a modeless editor (in the vein of a 'windows editor') but with sane home-row keybindings would be the best of both worlds - the efficiency of vi's hand placement paired with an ability to just edit text that I feel vi (and ilk) lack. Some very important commands (undo, cut, copy, paste, Save, Quit, Close) would not need to move much from the Windows world, but we'd need to come up with bindings for movement. I'd like ^j/^k/^l/^; for linewise movement and another modifier for pagewise movement - possibly ctrl +alt? but since ^j is return, we may not be able to do so without trouble. (we'd also need to devise some system for "go to end of line" and "Beginning of line") 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 editor to a modeless one.
Re: [dev] Sandy editor
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 work in
some systems (MacOS as far as we know).
We looked at alternative regex engine implementations, but they either
suck (perl and the like) or do not implement the rather-useful \b (go,
plan9). Maybe it's time for a suckless regex library? Maybe we should
extend plan9's libregexp?
Actually, it was pancake who researched all this, so kudos to him.
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 the posix implementation and \< is a gnu
extension, but both are quite
new, and well.. after reading the code of the p9 regexp lib i realized
that it is completely
unnecessary, as long as you can write a (^| |\t|;|{|\(|\{|\[)... regexp
that matches the same.
it's a bit annoying if you have to type it manually, but this can be
done in a #define B as I
told you by xmpp yesterday.
Please commit the fix and we will get portable regexp support.
Another thing is that it would be great to be able to disable the syntax
highlight:
diff -r e2542c05953f sandy.c
--- a/sandy.c Tue May 31 01:39:32 2011 +0200
+++ b/sandy.c Tue May 31 16:34:39 2011 +0200
@@ -1614,6 +1614,8 @@
tabstop=atoi(argv[i]);
} else
i_usage();
+ } else if(!strcmp(argv[i], "-S")) {
+ local_syn="";
} else if(!strcmp(argv[i], "-s")) {
if(++i < argc) {
local_syn=argv[i];
add this patch to have -S to not use any syntax highlight
2.- There is a (very) limited subset of keys we can bind to to comply
with everyone's requests: there are 33 Control chars: Control +
@A-Z[\]^_? but some are taken (^[ is ESC, ^I is TAB, ^M and/or ^J is
Enter). Because of the way terminals work, we can't bind to
Control+Shift... no wonder they used to call them dumb terminals.
I have tried to reduce the number of bindings to use, but going below
30 seems impossible if we want full keyboard control. There are a few
ways to go from here, but they mostly suck:
- Screw full keyboard control, drop things like deleting/moving
through lines, words, etc. bind the rest and end up with an
uncomfortable editor.
- Reduce our bindings as much as possible, then bind the least used
actions to the function keys, hoping they do not collide with your
software.
- Implement a very little amount of key chains (possibly one prefix
only) a-la emacs, again only for the least used actions.
- Bite the bullet and bind with Meta, trying to avoid an overlap with
other popular suckless software (read dwm, wmii).
- Go modal, though this would probably end with us writing yet another vi clone.
- Draw our text editor in an X window instead of a terminal/curses and
then bind Control+Shift; this potentially sucks the most and you
wouldn't be able to use sandy on console/ssh.
NOTE: common movement keys (arrows, home/end, repag/avpag...) are also
bound to the usual suspects; we are talking additional keybindings to
avoid leaving the default typing position here.
NOTE: in the meantime, you can use the current sandy code by tapping
on te original sucky way to use meta in the console: press ESC, then
the key within some millisecs. Go usability.
Any thoughts on either topic are more than welcome,
Rafa.
i'm preparing a control-only based keyboard layout for sandy.. i'll have
a look
at your version, but I still think that modes will allow us to keep some
sane
control commands and be more productive for moving without
meta/control/shift
keys on the command mode.
Vi is great, and it's great for something, the only bad thing is that
most implementations
are bloated.. but with the codebase of sandy we can do an almost decent
vi clone.
Most basic editor functionality in sandy will be possible without
changing between
modes, but having the possibility to use the commands mode will provide
a more
decent interface. (IMHO).
Anybody more wanna give your opinion?
PD: Anselm, are you still alive?
PD: it's an already known bug, but multiline comments are not properly
highlighted, this is
because of performance reasons.. syntax highlight is nice.. but it's
probably overbloating
the execution. Dunno if we should drop them.. at least now they work
everywhere. :)
--pancake
Re: [dev] [st] Font issues
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 slow, when comes to lines of code, and btw, I'm not sure > there are ppl out here who actually use it that much;) FWIW I use st happily as my daily terminal on my work and home machines, and have done for a few months now. It is perfectly stable for daily use. Transparency was discussed in another thread (summary: there's a patch, but not many people [myself included] want it, so it won't go into st proper). As for font issues, these are all just configuration problems, not problems with st, as far as I'm aware. It may be slightly slower than other terminals, but this is being worked on, and besides it's plenty fast enough for me.
Re: [dev] [st] Font issues
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, but...eww. > > Terminus drew nice and quickly for me when I was using it > and Tamsyn works wonderfully as well. I'm just curious what > I could be doing wrong. > > 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 slow, when comes to lines of code, and btw, I'm not sure there are ppl out here who actually use it that much;) -- Tian
Re: [dev] [st] Font issues
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 using it and Tamsyn works wonderfully as well. I'm just curious what I could be doing wrong.
Re: [dev] [st] Font issues
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 giving urxvt problems a while back so I re-encoded it > (to ISO8859-1) and tried again. Now st will launch - but the font looks > terrible.[1] I've uploaded my config.h[2], but the line that should be the > problem is: > > #define FONT "-*-dina-medium-r-*-*-13-*-*-*-*-*-*-*" > #define BOLDFONT "-*-dina-bold-r-*-*-13-*-*-*-*-*-*-*" > > That font declaration works fine in urxvt, though - so I'm lost. Are there > obvious changes that need to be made that I'm apparently missing? Is > there some difference in the way that suckless is doing this that is > affecting the way fonts are rendered or am I just doing it wrong? > > > > 1) http://ompldr.org/vOHY4OQ > 2) http://sprunge.us/XgKe > > I'm sorry won't be able to help much with your issue. But is there any need to use "st" as a terminal?. I just tried to use it, and it seems like it is a bit slow at rendering terminus font for ex. in comparison to other alternatives. And I found that it was buggy with some other fonts too. -- Tian
[dev] [st] Font issues
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) and tried again. Now st will launch - but the font looks terrible.[1] I've uploaded my config.h[2], but the line that should be the problem is: #define FONT "-*-dina-medium-r-*-*-13-*-*-*-*-*-*-*" #define BOLDFONT "-*-dina-bold-r-*-*-13-*-*-*-*-*-*-*" That font declaration works fine in urxvt, though - so I'm lost. Are there obvious changes that need to be made that I'm apparently missing? Is there some difference in the way that suckless is doing this that is affecting the way fonts are rendered or am I just doing it wrong? 1) http://ompldr.org/vOHY4OQ 2) http://sprunge.us/XgKe
