On Sunday, 15 September 2013 at 17:14:19 UTC, Dicebot wrote:
> On Saturday, 14 September 2013 at 10:32:26 UTC, Nick Sabalausky wrote:
>> My understanding (purely from the link below) was that /usr/local/* was
>> *specifically* for non-package-managered stuff, whereas /usr/* was
>> *specifically* for package-managered things:
>>
>> http://unix.stackexchange.com/questions/8656/usr-bin-vs-usr-local-bin-on-linux
>
> Not entirely true. You should never have anything not managed by package manager on Linux system, it is a reliable road to disaster. Better distinction is "/usr/" for packages from official repos, "/usr/local" for own custom packages.

I stick them in /opt/somthing usually, but the idea is the same.

On Sunday, 15 September 2013 at 17:18:21 UTC, Joseph Rushton Wakeling wrote:
> On 13/09/13 21:48, Namespace wrote:
>> Just out of interest.
>>
>> I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this
>> evening VisualD.
>
> Vim, on Ubuntu. :-)
>
> The actual reason is rather trivial.  I've always favoured a mixed tab-space indent style for code ("tabs for indentation, spaces for alignment"), as described here:
> http://www.emacswiki.org/emacs/SmartTabs
>
> Unfortunately, most text editors don't seem to support this very well any more.
>  In KDE 3 both Kate and KDevelop used to support it well, but since KDE 4 came out it seems to have been dropped.  If you search "mixed tab-space indentation" you'll even come across a rather forlorn post of mine from the time on the Ubuntu Forums trying to sort this out:
> http://ubuntuforums.org/showthread.php?t=1475867
>
> Vim and Emacs seem to be the only editors where it's readily possible to implement this these days, and vim is easier to use, so it wound up being the only choice.
>
> The irony is that given that standard D style is a 4-space indent, these days I've turned off the mixed tab-space style, for D at least ... but I'm still using vim, and I even find myself accidentally hitting vim-style commands if I use another editor to code.
>
> I did go through a period of using CodeBlocks for my official D contributions, with the 4-space style, and vim for my private projects, with mixed tab-space style; but eventually I decided, OK, D style is D style, follow the standard in all cases, and just went to vim for everything.
>
> I still do mixed tab-space for C/C++ though.  Yes, I know.  Burn the witch. :-)

What do you use to do that in vim ? All my attempts did fail.

On Monday, 16 September 2013 at 03:48:58 UTC, H. S. Teoh wrote:
> On Mon, Sep 16, 2013 at 04:04:24AM +0200, Adam D. Ruppe wrote:
>> [...]. But the point is that
> the system
> lets you use a minimal WM should you choose to, rather than in Windows
> where you *have* to use whatever MS has decided everyone must use, and
> it's too-bad-so-sad if you need to upgrade your hardware just to be able
> to continue using it.
>
>
> T

This is not true. Windows supported alternative window managers since the begging.

There were a few alternative ones like LiteSTEP and Stardock, just that mainstream users hardly feel the need to change the window manager.

This is not specific of Microsoft, all proper GUI based OS work this way, only UNIX does not, because X was an afterthought anyway.

--
Paulo

On 2013-09-16 05:57, Nick Sabalausky wrote:

> While I'm happy with click-to-focus[1] due to my many years with
> windows, I still have to say "click before the scroll wheel will
> actually work" is one of the biggest, most ridiculous GUI design
> blunders out there. It's exactly like requiring the user to click a
> control before right-click/middle-click/ctrl-click will work.
>
> I think I've mentioned this in other threads, but on XP I used
> KatMouse[2] to fix that, and it was a HUGE usability improvement.
> Unfortunately, on Win7 it only works a small fraction of the time. And
> that's unlikely to change because it's closed source abandonware, just
> like all-too-many freeware apps on windows. (Honestly, I never
> understood the windows developer culture of producing closed-source
> freeware.)

The most ridicules thing is having a window with two table views. To be able to scroll in these I have to click on the table view.

-- 
/Jacob Carlborg

On 2013-09-15 22:23, Nick Sabalausky wrote:

> Nice. If I ever end up with another Mac for one reason or another, I'm
> totally getting that program.

Even if it costs money it's totally worth it.

-- 
/Jacob Carlborg

On 2013-09-15 22:49, Nick Sabalausky wrote:

> I actually did the same tab/space thing for awhile. But my editors
> didn't really have a native understanding of it so it became manual
> editing of invisible characters, so now I just avoid that style of
> alignment regardless of tabs or spaces. Ie, instead of:
>
> foobar(aaaaa, bbbbb, ccccc,
>         dddd, eeeee, fffff);
>
> I'll just do:
>
> foobar(
>      aaaaa, bbbbb, ccccc,
>      dddd, eeeee, fffff
> );
>
> Not as pretty, but it works, it makes things simpler, Plus it avoids
> the former style's tendency to wind up with gigantically-sized indents.

I recently watch the Going Native talk by Chandler. He talks about the one of the biggest problem they have at Google. It's not the language (C++) itself, but it's formatting whitespace. Short, they have a tool for that now.

http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons

-- 
/Jacob Carlborg

On 2013-09-16 08:53, Jacob Carlborg wrote:

> I recently watch the Going Native talk by Chandler. He talks about the
> one of the biggest problem they have at Google. It's not the language
> (C++) itself, but it's formatting whitespace. Short, they have a tool
> for that now.
>
> http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons

Forgot to say, it automatically solves your problem.

-- 
/Jacob Carlborg

On 2013-09-16 08:19, PauloPinto wrote:

> There were a few alternative ones like LiteSTEP and Stardock, just that
> mainstream users hardly feel the need to change the window manager.

I used LiteStep for a while, when I still was running Windows. Quite nice actually. When you have finally configured it they way you like.

-- 
/Jacob Carlborg

On Monday, 16 September 2013 at 06:54:21 UTC, Jacob Carlborg wrote:
> On 2013-09-16 08:53, Jacob Carlborg wrote:
>
>> I recently watch the Going Native talk by Chandler. He talks about the
>> one of the biggest problem they have at Google. It's not the language
>> (C++) itself, but it's formatting whitespace. Short, they have a tool
>> for that now.
>>
>> http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons
>
> Forgot to say, it automatically solves your problem.

Then there is calling indent on checkin hooks on the source control system as well.

On Sep 16, 2013 4:55 AM, "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
>
> On Sun, Sep 15, 2013 at 06:59:24PM -0700, Jonathan M Davis wrote:
> > On Sunday, September 15, 2013 18:53:58 H. S. Teoh wrote:
> > > On Sun, Sep 15, 2013 at 07:14:17PM +0200, Dicebot wrote:
> > > > On Saturday, 14 September 2013 at 10:32:26 UTC, Nick Sabalausky wrote:
> > > > >My understanding (purely from the link below) was that /usr/local/* was *specifically* for non-package-managered stuff, whereas /usr/* was *specifically* for package-managered things:
> > > > >
> > > > >
http://unix.stackexchange.com/questions/8656/usr-bin-vs-usr-local-bin-on->
> >linux>
> > > > Not entirely true. You should never have anything not managed by package manager on Linux system, it is a reliable road to disaster.  Better distinction is "/usr/" for packages from official repos, "/usr/local" for own custom packages.
> > >
> > > Seriously? I installed unmanaged stuff all the time, and never had much of an issue. Though, granted, I never put them under /usr or /usr/local at all. It's usually in a dedicated subdirectory under $HOME.
> > >
> > > Installing unmanaged stuff under the /usr tree is tricky business, because when you're trying to *uninstall*, you usually don't remember where all the bits have been scattered, and leaving them lying around can lead to trouble.
> >
> > Which is exactly why you shouldn't do it normally. If fact, I would argue that you should pretty much _never_ install stuff not managed by the package manager in /usr. /usr/local is a different matter, because it's not usually managed by the package manager, but you still have to be very careful with it. Putting unmanaged stuff in dedicated subdirectories in $HOME is definitely a better approach.
> [...]
>
> For unmanaged stuff, I usually prefer to put each application in their own filesystem subtree, like /usr/src/${appname}/root (which is also just next to where I usually build the source to begin with), instead of mixing everything together like in /usr or /usr/local. That way, if something misbehaves, I can just use `rm -rf` to kill it off without needing to dig through /usr/local/bin, /usr/local/share/man/man*, /usr/local/lib, /usr/local/share, and who knows where else to find all the bits to clean up.
>

For some reason I use /opt/usr or /opt/${appname}

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';