[OT] Which IDE / Editor do you use?

Nick Sabalausky SeeWebsiteToContactMe at semitwist.com
Sat Sep 14 21:53:24 PDT 2013


On Sat, 14 Sep 2013 03:08:32 -0700
"H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote:

> On Sat, Sep 14, 2013 at 04:23:35AM -0400, Nick Sabalausky wrote:
> > 
> > Windows (nice):
> > % program-cli file.txt
> > % program-gui file.txt
> > 
> > Linux (wtf?!):
> > % program-cli file.txt
> > % program-gui file.txt >/dev/null 2>%1 &
> 
> That's only if you don't care about the output of the GUI program,
> which is usually an indication of errors.
> 
> Well, unless the GUI program uses one of those stupid chatty toolkits
> that like to spew EVERYTHING to stdout/stderr, no matter how inane. It
> violates the rule that programs should be silent by default, and
> verbose only when asked to be or when an error condition is important
> enough to warrant soliciting the user's attention.
> 
> But even then, I usually don't care about these random spews. They can
> be useful if the GUI program segfaults (which GUI programs are somehow
> very likely to, for some reason), then you at least have a possibly
> useful error message. Sending everything into /dev/null by default is
> a bit counterproductive.
> 

I do agree that being able to access the stdout/err of a GUI is a good
thing. I just don't usually care ;), and frankly I think that fact just
further underscores my point that launching GUI apps on Linux isn't
handled particularly great.

Even assuming the usefulness of accessing stdout/err of a GUI, I still
don't think plastering it all to the active interactive shell that
launched it is a particularly sane default. There's gotta be better
ways: Like logging it all (either as opt-in or opt-out logging - I
don't care as long as it's consistent.) Or maybe a /proc/stdout/[pid]
and /proc/stderr/[pid].  And then maybe a combined /proc/all/stdout. I
dunno, something. There's gotta be a better way.

Windows knows when a program is GUI or CLI, I think that helps give it
a leg up in (potentially) addressing the matter nicely (even if it does
currently just throw away all GUI stdout/err, AFAIK). I know
situation-specific behaviors are somewhat anti-Unix, but I think GUI vs
CLI is significant enough to justify a certain amount of differences
(And it's not like Unix doesn't have alternate behaviors where
appropriate - ex: some files have finite size and some "files" don't,
some are physically on HDD and some aren't. All perfectly justified
inconsistencies.)

Come to think of it, anyone have any idea if Plan 9 approached this
"launching gui apps" any differently than Linux? I'd be curious about
that.


> One situation where they can be annoying is when you're switching
> between vim (of course) and the gui program, and the random spewage
> messes up vim's TUI, then the solution is to hit ctrl-L, which *most*
> properly-written TUI programs understand as "something threw up all
> over your terminal, please repaint"

Cool tip! Thanks! I didn't know that. It'll certainly come in handy.


> And if I need to start multiple GUI apps from the same spewage
> terminal, I just ctrl-Z to suspend the first one, 'bg' to background
> it (the afterthought equivalent of &), then start the second app.

You know, I always keep forgetting about "bg". I always remember "fg"
because that's how I undo the mistake of hitting Ctrl-Z when I meant
Ctrl-C ;) But I keep forgetting I can stuff things into the background
after-the-fact. Which is weird - I first learned about "fg/bg" over a
decade ago :P


> Or
> better yet, with ratpoison, since it's just two keystrokes to open a
> new terminal, I'd just open a new terminal, start the gui app with
> just a single &, then *kill* that terminal (also just 2 keystrokes in
> ratpoison) so that the OS sends all output to /dev/null for me
> without me ever needing to name /dev/null manually. :) That's 4
> keystrokes compared to that idiotic verbose bash syntax for
> redirecting stdin/stderr to /dev/null (which I'm no fan of, just for
> the record), that takes ... let's see... 15+ keystrokes. Ratpoison
> FTW. :)
> 

Ehh, while I'm sure that's easy, it seems like more thought/steps than
really *should* be necessary in most cases.

> 
> > But that's not always right - sometimes you need this instead:
> > % gksudo program-gui file.txt >/dev/null 2>%1 &
> 
> GUI programs that need sudo privileges are Teh Evil. I avoid them like
> the plague. Unless they're the system package manager, but in that
> case I'd use the CLI equivalents anyway, so this baroque dance is
> never necessary for me. :-P
>

Well, I like my GUI-based text editors, and I like to be able to edit
configuration files when I need to (not that I like *needing* to). So
you do the math ;)

> 
> > But that's not always right either. On some systems it's:
> > % kdesudo program-gui file.txt >/dev/null 2>%1 &
> 
> I have an intense hatred of anything GUI that asks for root
> privileges. GUI apps are just too fragile, too fat, too crash-prone,
> to entrust with root privileges.

That may be a fair point. But I've been in the (perhaps bad) habit of
running Windows as admin since forever, and it hasn't killed me, so
ehh, whatever. ;)


> I have no confidence they will not
> also have nasty bugs that destroys or overwrites system files (a pet
> peeve of mine is gui programs that insist on creating stuff in $HOME
> that isn't their own app-specific dotfile or under their own
> dedicated dotdirectory

Actually, windows apps are pretty bad with that too. Probably even
worse since Windows is *supposed* to have at least two separate
equivalents to $HOME for each user:

- The well-known "My Documents" for files the user *explicitly* creates
  and saves (equivalent to the non-hidden files in $HOME, and usually
  something like "C:\Users\{user name}\Documents" on Vista and up)

- And a separate %APPDATA% for any data a program implicitly saves
  (equivalent to the hidden files in $HOME). Settings, game saves,
  persistent user-specific caches, etc. (Usually something like
  "C:\Users\{user name}\AppData\Roaming" on Vista and up.)

(There's actually more, including a non-roaming machine-specific
directory, and a common parent directory of all of them that's unique
to the user and ultimately contains *all* the user-centric data...at
least the user-centric data that isn't in the registry. But those two
above are the real key ones.)

But a lot of windows programs just spew all their shit into the
user-centric "My Documents" instead of "%APPDATA%/AppFooBar" where it
all belongs. Even Microsoft's own Visual Studio does this (unless
they've fixed it - they apparently change everything in every version
anyway). So then *MY* *DOCUMENTS* gets cluttered with random shit I
know perfectly well *I* didn't create. So I have to create a "MyDocs"
subdirectory to use as my *real* "My Documents". But I can't tell
Windows it's my real "My Documents" or everything will start spamming
that directory instead (Unless the program is *really* poorly behaved
and hard-codes something like "C:\Users\{user name}\Documents", though
I don't know how rare/common that is.)

Ugh...I don't know how I managed to learn that much random shit about
Windows...<g>


> > Of course, Linux *also* provides many ways to do it *wrong*, which
> > are naturally more convenient:
> > 
> [...]
> 
> None of this are an issue if you've a fast way to starting up /
> switching to a specific terminal dedicated for containing spewage. :)
> 

Yea, but then you have to actually *do* that ;)

> (Of course, the fact the majority of gui programs love spewing like
> this is a sign of a fundamental pathology common to such programs,
> but that belongs in another rant. :-P

They appear to use stdout/err as a logfile. I guess that could be
convenient during development, but...ugh.

> It's one of the many reasons I
> have an aversion to all things GUI. In fact, in *my* book, a proper
> GUI program should automatically detach itself from the terminal at
> startup -- there are well-known, standard ways of doing this, but
> alas, most GUI developers don't care enough to do it.)
> 

I would buy that book ;) Actually though, do you have a link regarding
that auto-detaching?



More information about the Digitalmars-d mailing list