On Wed, Mar 29, 2017 at 10:09:15AM +0200, Ivan Delalande wrote:
> On Sat, Mar 25, 2017 at 11:02:42PM +0300, Alexander Krotov wrote:
> > --- a/st.c
> > +++ b/st.c
> > @@ -2537,7 +2537,7 @@ tresize(int col, int row)
> > }
> >
> > /* allocate any new rows */
> > - for (/* i == minrow */; i
> purposes. Both approaches are better than writing your own configuration
> parser.
You can write your parser configurator using:
scanf(" %40s = %40s", key, value);
Regards,
On 29/03/17 10:53P, Marc André Tanner wrote:
> On Wed, Mar 29, 2017 at 08:22:04PM +0100, Snobb wrote:
> > I liked the idea of vis in its early stage until it went the "lua" way.
>
> I'm sorry that you feel that way, but you can still completely disable Lua
> during compile time and get a working e
> As others already have pointed out this metric isn't that useful in
> itself. What it does indicate is that some projects are beyond repair
> (e.g. vim).
I agree it's not useful beyond getting a ballpark estimate, esp
without taking into account external deps. The 10k figure includes
mlbuf but
On Wed, Mar 29, 2017 at 08:22:04PM +0100, Snobb wrote:
> I liked the idea of vis in its early stage until it went the "lua" way.
I'm sorry that you feel that way, but you can still completely disable Lua
during compile time and get a working editor (albeit with less features).
In my opinion Lua i
On Wed, Mar 29, 2017 at 10:54:36AM -0400, a...@php.net wrote:
> > WTF. Did you write a program to generate this much? I've seen
> > operating systems that ran really well at that line count.
>
> Not sure I follow your q, but yes some of it is codegen (the stdio
> scripting part).
>
> My definitio
> scrollback buffer built into st itself. Instead of mandating the use
> of tmux et al, I would rather put a helper tool into the st repo, that
> works as a basic shell wrapper process (no detaching). It would
It can be a separated tool integrated with st, in the same way
than utmp. I am going to
> scrollback buffer built into st itself. Instead of mandating the use
> of tmux et al, I would rather put a helper tool into the st repo, that
> works as a basic shell wrapper process (no detaching). It would
It can be a separated tool integrated with st, in the same way
than utmp. I am going to
> scrollback buffer built into st itself. Instead of mandating the use
> of tmux et al, I would rather put a helper tool into the st repo, that
> works as a basic shell wrapper process (no detaching). It would
It can be a separated tool integrated with st, in the same way
than utmp. I am going to
> I'd love to see scrollback also. I've played around a tiny bit with dumping
If you want to work in the backscroll tool I can help you [1].
Regards,
[1] http://ix.io/1vQQ
> this is a very good point! Even if this was approached with an external
> tool you probably just start implementing st again with all the bells
> and whistles, let alone the fact that you need a separate program to
> make st work as desired in a normal setup within a window manager.
No, you don'
> The idea of having php installed just to have my editor working terrifies me
> (or a mandatory dependency of any language interpreter for that matter). I
> liked the idea of vis in its early stage until it went the "lua" way.
No need for php at runtime or even build-time. It's used only for
code
> I don't think that's a typo, just a short form for "hey, watch out,
> remember we still have `i == minrow` from the last loop here!". ;)
Uh, you are right. Sadly I read your comment after pushing it.
Best regards,
> Totally inconsistent crap. Basically you have to stop using stupid
> programs that care about terminal width. It's the only real solution.
>
> I'm not even gonna talk about this curses bullshit. I don't care about
> integrating such useless programs into scrollback.
Indeed. Programs that look t
The idea of having php installed just to have my editor working terrifies me
(or a mandatory dependency of any language interpreter for that matter). I
liked the idea of vis in its early stage until it went the "lua" way.
The termbox requires python for compilation. So to get this editor working o
Wolfgang Corcoran-Mathe wrote:
> mle is too complex for my taste (scripting and syntax highlighting
> seem unecessary, though I’m in the grumpy minority here)
Personally I'd like to see more of something like mg or busybox' vi.
Unfortunately they both don't support UTF-8. nvi is pretty good as
we
On Tue, Mar 28, 2017 at 3:34 AM, Kamil Cholewiński wrote:
>> I think it might have been possible to use some other build tool to
>> achieve something similar, but I don't think it would have worked out
>> as well.
>
> http://gittup.org/tup/ ?
I think tup could have worked too, but I still prefer
> I can live without scrollback, but what I dislike about st now is
> that it loses lines when I just shuffle my terminals around with
> dwm. When I have 3 windows (1 master, 2 stack) and move terminal
As I have said in the previous mail, I can help you to write the tool
to solve this problem.
B
Hi,
Thank you for your contribution, but after thinking about it
I think I am going to reject this patch. There are important
reasons why st hasn't a scrollback buffer, and the same reasons
apply to this patch. There are so many cases and so many
interactions that is better to keep this logic out
Fuck off
> On Mar 29, 2017, at 2:00 AM, dev+h...@suckless.org wrote:
>
> Topics (messages 26105 through 26154):
>
> [dev] Surf update
> 26105 - Nick
>
> [dev] [ask] search binary file offset in file
> 26106 - Amer
>
> [dev] [ask] search binary file offset in file
> 26107 - Ale
On Wed, 29 Mar 2017 09:57:49 -0400
a...@php.net wrote:
> I am announcing mle, a small terminal-based text editor written in C:
>
> https://github.com/adsr/mle
>
> mle weighs in at ~10k sloc, has 1 external dep[0], is configurable,
> extensible / scriptable, and fast. The default setup is nano- o
> WTF. Did you write a program to generate this much? I've seen
> operating systems that ran really well at that line count.
Not sure I follow your q, but yes some of it is codegen (the stdio
scripting part).
My definition of sloc is roughly `cat *.c *.h | wc -l`. Using this
metric on other edito
tl;dr
> mle weighs in at ~10k sloc
WTF. Did you write a program to generate this much? I've seen
operating systems that ran really well at that line count.
cheers!
mar77i
hahahahaha, the right people are turning up finally.
php.net
On 3/29/17, a...@php.net wrote:
> Hello,
>
> I am announcing mle, a small terminal-based text editor written in C:
>
> https://github.com/adsr/mle
>
> mle weighs in at ~10k sloc, has 1 external dep[0], is configurable,
> extensible / sc
Hello,
I am announcing mle, a small terminal-based text editor written in C:
https://github.com/adsr/mle
mle weighs in at ~10k sloc, has 1 external dep[0], is configurable,
extensible / scriptable, and fast. The default setup is nano- or
emacs-like, but it supports modes as well. I've used it da
On Wed, 29 Mar 2017, hiro <23h...@gmail.com> wrote:
> give it up. it's all hopeless. urxvt does it the right way and it still sucks.
This.
Every single terminal in the world has broken resize handling, except
for urxvt. Just copy what urxvt does, and let's focus on more exciting
problems.
<3,K.
That is the most sensible summary on the subject I have yet come
across, chapeau.
For anything that was hard or ambiguous to explain, this is what irks
everyone about TUI, if that is even a thing, and the argument is very
much why it shouldn't be.
Whatever way we go now, I'm in favor of instead tr
give it up. it's all hopeless. urxvt does it the right way and it still sucks.
for example:
1) run busybox ps in a big terminal, then resize it so stuff would get
cut off in st -> it gets reflowed, which sucks a little cause it
breaks the layout, but at least your stuff is still there, somewhat
re
On 28 March 2017 at 18:48, Pickfire wrote:
> I see tup as a good build system but not used by many.
An interesting feature I noticed was that it automatically detects dependencies.
"The trick is that tup instruments all commands that it executes in
order to determine what files were actually rea
On Sat, Mar 25, 2017 at 11:02:42PM +0300, Alexander Krotov wrote:
> --- a/st.c
> +++ b/st.c
> @@ -2537,7 +2537,7 @@ tresize(int col, int row)
> }
>
> /* allocate any new rows */
> - for (/* i == minrow */; i < row; i++) {
> + for (/* i = minrow */; i < row; i++) {
>
On Sun, Mar 26, 2017 at 08:20:39PM +0300, Alexander Krotov wrote:
> On Sun, Mar 26, 2017 at 06:10:37PM +0200, Laslo Hunhold wrote:
>> On Sun, 26 Mar 2017 06:41:46 +0300
>> Alexander Krotov wrote:
>>> Updated patch to clear up to maxcol in some cases and avoid glitches
>>> when using ncurses progra
* Jochen Sprickerhof 2017-03-29 08:35
> I still ponder to write an experimental shell where input and output is
> separated and where the last line is input and the rest is scrollable
> output. Scrolling through the input history would give you the
> corresponding output and all output would be pre
32 matches
Mail list logo
