>> > The world you're living in is the walled garden of OS X.
>> > It's your choice to either attempt to improve it, which is futile, or
>> > enter a world in which improvement is possible in the first place.
>>
>> I have to use OS X sometimes for work.
>
> I have to too, from time to time.
>
>> It
> On Sun, 17 Aug 2014 22:35:27 +0200 "Roberto E. Vargas Caballero"
> wrote:
>> > I think it would also be beneficial because it is difficult (at least
>> > for me) to keep track of a single ~4k line c file.
>>
>> I usually work in the terminal emulation part, and sometimes it is a
>> bit confusin
>> > Who’s still using Apple software in 2014 should be considered a fool.
>> > iPhones are open to everyone, Mac OS X is full of security holes, the
>> > hardware is built by slaves in the third world.
>>
>> None of which is relevant to the task at hand.
>
> It is.
> When you port somethi
> This is OS X specific and weird in my opinion, if you want multiple windows
> lauch multiple processes. It is safer, you can limit the impact of a crash
> to a single window. It is also memory efficient thanks to (haters gonna
> hate) dynamic link.
That's not how OS X users expect their apps t
> Stupid question by an ignorant prosumer: are you serious? You can have only
> one
> instance of something opened in Mac OS?
Oops, I should clarify. This is only the case with graphical programs,
which live within a .app directory, containing the actual executable
and the resources for the progr
>> You're very right: There is no point to it anymore. The changes I've
>> made are necessary for a straight-forward OS X port, because in OS X,
>> applications have only one instance, but may have many windows; thus
>> if you wanted to open multiple terminals, they would all need to live
>> in the
> What is the point?
You're very right: There is no point to it anymore. The changes I've
made are necessary for a straight-forward OS X port, because in OS X,
applications have only one instance, but may have many windows; thus
if you wanted to open multiple terminals, they would all need to live
> You have patches? Just submit them. This kind of meta discussion isn't
> worth anything.
Very good point, thank you Alex. It sounds like my changes most likely
won't be welcome, due to differences of opinion. And that's perfectly
fine.
If anyone is curious, here are the term.c and term.h files
> What is the point?
> One obvious cons is that it will bloat the code, make it less readable.
First of all, I would not agree that it would bloat the code or make
it less readable. In fact I think it will increase readability, as
object structure and hierarchy will be more readily apparent. Plus,
> What were the changes that were specific to the port to OS X? This
> particular change doesn't seem related to porting.
You're right, this change isn't related to the port. As I'm doing my
port, I'm changing existing code structure as I go along to make
porting it a little easier (since AppKit
I'm making progress on my port of st to OS X, and one of the changes
I'm making is to get rid of globals, turning most of them into fields
on Term, and making all the functions that use them take Term* as an
argument. It's a very minimal change, still very compatible with the
original st. Are these
Amadeus,
I will certainly move all the license files back when it is publicly
released. All I've done right now is moved all the files out of the
root directory into a subdirectory, so that people don't mistakenly
think the port is ready for any kind of use.
-Steven
On Fri, Aug 15, 2014 at 10:35
> It is already pushed. You can test it.
I don't have linux installed. However, I have applied the patch on my
OS X port, and although development is in a very early phase, it seems
to function as normal (briefly using vim and emacs and bash within my
terminal).
Thanks.
-Steven
> What processador do you use in your port? intel or ibm?
I'm on OS X 10.9 on an Intel Mac Pro, using LLVM + Clang.
> There was a discussion in this list sometime ago about this
> topic, and I think this was the best solution (if someone can
> find the messages ...), but I agree that if char is s
Convenience link to the line: http://git.suckless.org/st/tree/st.c#n2315
Here, techo is calling ISCONTROL(c) where c is a 'char'. But
ISCONTROLC1 is always going to return false for a char.
Perhaps it should test against ISCONTROLC0 instead? Or is this line
intended to use ISCONTROL for some reas
15 matches
Mail list logo
