On Tue, Jan 15, 2013 at 07:06:05PM +0100, Artur Skawina wrote:
> On 01/15/13 18:52, H. S. Teoh wrote:
> > Probably. And it's probably the reason I dislike today's trend of half-height^W^W I mean, half-width, monitors: I always work with maximized windows, and I don't like overly long lines, so resizing the font to approximately 80 columns at 1920x1080 would literally be half-height for me, even worse than 80x24.
> 
> xrandr  --output DVI-0 --rotate left
> 
> :^)
[...]

That's actually not a bad idea!! Y'know what, I might actually do that for my next monitor (I think 4:3 monitors are going out of fashion so fast that in 5 years, they would probably be nowhere to be found). I shall start a new trend of ultra-high monitors!


T

-- 
This sentence is false.

Andrei,

On Tue, 2013-01-15 at 12:09 -0500, Andrei Alexandrescu wrote: […]
> In book code samples you need frequently to align things vertically (e.g. comments):
> 
> int a = 42;   // the meaning of everything
> a += 0.1;     // error! cannot assign double to int

That sort of alignment is nigh on impossible in a proportional font using listing or minted. Of course there is no association between the comments so no reason why they should align.  Tab alignments definitely a bad idea for import by reference material.

> > I'll bear Bitstream Vera in mind for the book I am just starting.
> 
> Hope it's a book on D :o).

No it isn't. But it would be good if there were more books on D in the market.

> > I use the one true kitchen sink, Emacs, mostly. Using Ocean Sans Std. Eclipse, PyCharm, IntelliJ IDEA, NetBeans, GEdit, all using Ocean Sans Std.
> 
> Guess I'll just try it!!!

Definitely give it a go.

You can set things using the menu system and writing the default fonts out, or you can edit ~/.emacs.d/custom.el manually. This latter is the properly hardcore programmer approach, but does require knowing a little e-lisp.

(custom-set-variable
	…
 '(default-frame-alist (quote ((height . 40) (width . 120) (foreground-color . "black") (background-color . "#d0c4b0") (cursor-color . "red") (pointer-color . "red") (vertical-scroll-bars . right) (font . "-monotype-Ocean Sans MT-medium-r-normal--*-100-*-*-*-*-iso10646-1"))))
 '(initial-frame-alist (quote ((height . 40) (width . 120) (foreground-color . "black") (background-color . "#d0c4b0") (cursor-color . "red") (pointer-color . "red") (vertical-scroll-bars . right) (font . "-monotype-Ocean Sans MT-medium-r-normal--*-100-*-*-*-*-iso10646-1"))))
	…
)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 15 January 2013 at 16:51:34 UTC, Russel Winder wrote:
> I really cannot understand the obsession computing people have with
> using monospace fonts, I just assume it is a hang over from the line
> printer era which created a mindset that most people do not challange.
> As soon as computers moved from 80x24 terminals to editors with pixel
> based accuracy and nice fonts I ditched all use of monospace fonts.

It's not strictly a computing thing; I've known a few editors who won't work on manuscripts with a proportional font either. (Though I suspect you're familiar with the classic manuscript style guidelines.)  Personally, I find monospace makes it much easier to make glyph distinctions and spot errors.

On Tuesday, 15 January 2013 at 18:10:00 UTC, H. S. Teoh wrote:
> I shall start a new trend of ultra-high monitors!
>
About time more people showed up to this party... ;)

Make sure you're getting a panel with VESA mount; many monitors even at the fairly-high end of the spectrum have cheap stands that don't give rotation and height adjustment. My current layout is with the vertical monitor on the left, but I think I prefer it on the right, more.

On Tue, Jan 15, 2013 at 06:11:46PM +0000, Russel Winder wrote: [...]
> On Tue, 2013-01-15 at 12:09 -0500, Andrei Alexandrescu wrote: […]
> > In book code samples you need frequently to align things vertically (e.g. comments):
> > 
> > int a = 42;   // the meaning of everything
> > a += 0.1;     // error! cannot assign double to int
> 
> That sort of alignment is nigh on impossible in a proportional font using listing or minted. Of course there is no association between the comments so no reason why they should align.  Tab alignments definitely a bad idea for import by reference material.
[...]

This is exactly the sort of thing where I find proportional fonts unusable for code.

It's not inherently so, though. I've oft dreamed of a new way of displaying code, in which same-line comments are displayed in a separate pane in the editor (rather than intermixed with the code in the same pane). This comment pane can be adjustable in size and position, and comments can even be made collapsible (and the code pane would adjust the amount of space between lines to keep all comments aligned with their respective lines of code). Why should the textual representation of the code be conflated with the way it is displayed anyway? Let the code editor do all the formatting and layout, including alignment of same-line comments across lines. The actual source file can be free of all unnecessary whitespace (the compiler doesn't care anyway).

In fact, this allows for very long lines of code (say a complicated if-condition) to be formatted alongside a long comment block, something like this:

	if ((cond1 && !cond2) ||	// Check if the complicated
	    (!cond3 && cond4) ||	// conditions described earlier
	    (value1 < value2*16) ||	// are fulfilled.
	    (value1 >= minVal))
	{
		...
	}

You never have to manually wrap the code and comment lines yourself (which would be very painful if you want to keep everything aligned). The source file could very well represent this thus:

	if ((cond1 && !cond2) || (!cond3 && cond4) || (value1 < value2*16) || (value1 >= minVal)) // Check if the complicated conditions described earlier are fulfilled.
	{
		...
	}

and the code editor does the pretty layout for you.


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.

On 2013-01-15 17:00, H. S. Teoh wrote:
> reading the format string alone says nothing about what meaning is
> intended. What is found in a what? Also, it doesn't let you vary the
> word order correctly. Nor does it let you perform inflection correctly.
>
> For true ease of translation, you need:
>
> 1) Logical naming of format arguments, e.g.:
>
> 	"%{filename} is found in %{dirname}"


I agree that named arguments are best -- then you don't require extra comments.
As for argument positioning, it already can be specified, for example "%1$s".



> 2) Some way to indicate the function of each word so that inflection can
> be cone correctly, e.g.:
>
> 	"%{filename.nominative} is found in %{dirname.locative}"
>
> or something like that, in languages where words change form depending
> on function. There will, of course, need to be requisite mechanisms for
> interpreting these word function identifiers.


Filename and dirname don't look like good examples - they don't change.
Well, this is a problem much deeper than providing simple translation, so let's drop this for now.



> 3) Some way to indicate multiplicity:
>
> 	"1 file was found" vs. "2 files were found"
>


This is already taken care of in every gettext system I know.
The code would look something like this:

writefln(ngettext("%1$d file found in %2$s", "%1$d files found in %2$s", 2),
    2, "folder X");

where ngettext takes 3 arguments: eng_singular, eng_plural, count.

On 15/01/2013 01:11, Timon Gehr wrote:
<snip>
> I assume you are using thunderbird, because that changed its layout
> fairly recently. You can fix this by right-clicking on the button ->
> 'Customize...' IIRC.

But for some strange reason, getting rid of the Reply button gets rid of it when viewing email as well. :(

Stewart.

On 15/01/2013 07:24, Tavi Cacina wrote:
<snip>
> That piece of code is correct.
> http://en.wikipedia.org/wiki/Erase-remove_idiom

I must have misread the documentation on cplusplus.com.  I'd somehow made out that it returns an iterator that skips over the "removed" values.

So the semantics of remove are counter-intuitive, and what it actually does is to change something like [1, 3, 5, 5, 7, 5, 9] into [1, 3, 7, 9, RG, RG, RG] (RG = random garbage), and return an iterator that points to the first RG, and then erase is used to delete the elements from that point to the end of the array.  I see now.

But it goes to show that std::remove is counter-intuitve in itself, and that there ought to be a more intuitive way in STL of doing a search-and-remove operation.

Still, there's nothing to stop you from writing a function wrapper for this boilerplate code rather than writing it out every time.

Stewart.

On 15/01/2013 10:20, FG wrote:
<snip>
> All thanks to a terrible naming decision...
> It's not remove but move_to_end. Why call it remove?

It doesn't necessarily move them to the end, going by
http://www.cplusplus.com/reference/algorithm/remove/
"The relative order of the elements not removed is preserved, while the elements past the new end of range are still valid, although with unspecified values."

Just looking at the sample implementation there....

    if (!(*first == value)) *result++ = *first;

places each non-removed value in its place in the final state of the container, but doesn't do anything particular with the value where it was taken from.  In a C++11 implementation, I would expect it to become

    if (!(*first == value)) *result++ = std::move(*first);

Stewart.

On Tue, Jan 15, 2013 at 09:23:22PM +0100, FG wrote:
> On 2013-01-15 17:00, H. S. Teoh wrote:
> >reading the format string alone says nothing about what meaning is intended. What is found in a what? Also, it doesn't let you vary the word order correctly. Nor does it let you perform inflection correctly.
> >
> >For true ease of translation, you need:
> >
> >1) Logical naming of format arguments, e.g.:
> >
> >	"%{filename} is found in %{dirname}"
> 
> 
> I agree that named arguments are best -- then you don't require extra comments.  As for argument positioning, it already can be specified, for example "%1$s".

Yes, but argument positioning is easy to mix up when the format string has a lot of arguments. Named arguments are the best. Self-documenting, and also avoids careless mistakes (like mistyping %1$s when you mean %2$s).


> >2) Some way to indicate the function of each word so that inflection can be cone correctly, e.g.:
> >
> >	"%{filename.nominative} is found in %{dirname.locative}"
> >
> >or something like that, in languages where words change form depending on function. There will, of course, need to be requisite mechanisms for interpreting these word function identifiers.
> 
> Filename and dirname don't look like good examples - they don't change.  Well, this is a problem much deeper than providing simple translation, so let's drop this for now.

Yeah filename and dirname are not good examples.  A better example (for Indo-European languages at least) is with verbs:

	writeln("The cat %s the dog.", verb);

In some languages, the form of "cat" and "dog" may need to change depending on what the verb is. But then these cases are probably too complex to capture in a format string in the first place, so perhaps the point is moot.


> >3) Some way to indicate multiplicity:
> >
> >	"1 file was found" vs. "2 files were found"
> 
> This is already taken care of in every gettext system I know. The code would look something like this:
> 
> writefln(ngettext("%1$d file found in %2$s", "%1$d files found in %2$s", 2),
>     2, "folder X");
> 
> where ngettext takes 3 arguments: eng_singular, eng_plural, count.

What if there are two (or more) items in the string that have counts?


T

-- 
"Uhh, I'm still not here." -- KD, while "away" on ICQ.