Editor recommendation

On 08/29/2013 07:19 AM, chris wrote:
> On 08/29/13 03:41, bbhack wrote:
>
>>
>> Try Netbeans.
>>
>> https://netbeans.org/
>
> Wasn't that originally a Sun Micro product ?. Anyway, the fact that
> it's available for Solaris Sparc and X86 means i'll be having a look
> at that. Thanks for the pointer...
>
> Chris
>
>>

Yes, it originated at Sun. It's written in Java, but don't let that 
scare you off. Other that the fact that it takes about 20 seconds to 
start up, it works well. If it did not have Emacs keys available, I 
probably would not use it.

On 08/29/2013 09:31 AM, Habib Bouaziz-Viallet wrote:
> On 28/08/2013 22:18, Roberto Waltman wrote:
>> For some reason never got used to Emacs
>
> What are exactly the reason(s) why you have excluded Emacs ?
>
> I have been using Emacs for 15 years (sometimes extensively) and i
> always enjoy using it as an editor for C/C++. I think Emacs is one of
> few tools making you a better programmer.
>
> H

I tried for about 5 years to like Emacs. I knew it was the right way, 
since the graybeards used it exclusively.

One weekend maybe 10 years ago I set down, and did not quit until I 
could hack my way through it. It makes sense when you remember it was 
constructed for the barely usable terminals of 25-30 years ago.

These days Emacs and XEmacs are lacking many modern niceties that I 
can't seem to find the extensions for. There used to be a saying - if 
Emacs does not do it, you probably do not need to do it. Not so much 
anymore. Try to find a way to collapse scopes (no cheating, like writing 
it yourself :).

bbhack <bbhack@gmail.com> writes:

> On 08/29/2013 09:31 AM, Habib Bouaziz-Viallet wrote:
>> On 28/08/2013 22:18, Roberto Waltman wrote:
>>> For some reason never got used to Emacs
>>
>> What are exactly the reason(s) why you have excluded Emacs ?
>>
>> I have been using Emacs for 15 years (sometimes extensively) and i
>> always enjoy using it as an editor for C/C++. I think Emacs is one of
>> few tools making you a better programmer.
>>
>> H
>
> I tried for about 5 years to like Emacs. I knew it was the right way,
> since the graybeards used it exclusively.
>
> One weekend maybe 10 years ago I set down, and did not quit until I
> could hack my way through it. It makes sense when you remember it was
> constructed for the barely usable terminals of 25-30 years ago.
>
> These days Emacs and XEmacs are lacking many modern niceties that I
> can't seem to find the extensions for. There used to be a saying - if
> Emacs does not do it, you probably do not need to do it. Not so much
> anymore. Try to find a way to collapse scopes (no cheating, like
> writing it yourself :).

http://www.emacswiki.org/cgi-bin/wiki.pl?HideShow
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On 08/31/2013 12:27 PM, Randy Yates wrote:
> bbhack <bbhack@gmail.com> writes:
>
>> On 08/29/2013 09:31 AM, Habib Bouaziz-Viallet wrote:
>>> On 28/08/2013 22:18, Roberto Waltman wrote:
>>>> For some reason never got used to Emacs
>>>
>>> What are exactly the reason(s) why you have excluded Emacs ?
>>>
>>> I have been using Emacs for 15 years (sometimes extensively) and i
>>> always enjoy using it as an editor for C/C++. I think Emacs is one of
>>> few tools making you a better programmer.
>>>
>>> H
>>
>> I tried for about 5 years to like Emacs. I knew it was the right way,
>> since the graybeards used it exclusively.
>>
>> One weekend maybe 10 years ago I set down, and did not quit until I
>> could hack my way through it. It makes sense when you remember it was
>> constructed for the barely usable terminals of 25-30 years ago.
>>
>> These days Emacs and XEmacs are lacking many modern niceties that I
>> can't seem to find the extensions for. There used to be a saying - if
>> Emacs does not do it, you probably do not need to do it. Not so much
>> anymore. Try to find a way to collapse scopes (no cheating, like
>> writing it yourself :).
>
> http://www.emacswiki.org/cgi-bin/wiki.pl?HideShow
>

How did I know this was going to happen? :)

Hi Stefan,

On 8/31/2013 3:05 AM, Stefan Reuther wrote:
> Don Y wrote:
>> On a *printed* (phototypeset) document, these things are really
>> easy to resolve.  On a *display*, they are much harder!
>>
>> E.g., I'm currently preparing a document on cubic Bezier curves.
>> I use a 10 pt serif typeface for body text.  This means footnote
>> text is 8 pt.  Footnote *references* (i.e., in the body text)
>> are superscripts -- so, about 5-6 pt on the 10 pt text.  Within
>> footnote text, subscripts are about 4-5 pt!
>
> Why on earth do you need to display all that in the final layout during
> document preparation?

Because document preparation involves sorting out its visual
presentation!  If you don't care what the document looks like,
"compose" it in HTML and you'll never need to *know* how it will
appear on some particular browser!

E.g., when I typed up the draft text for the Bezier article,
I had planned to have an initial illustration that showed a
set of four *fixed* control points and how the order in which
they were "visited" could radically alter the shape of the
resulting curve:  draw the bezier associated with (A,B,C,D)
in solid red; the (A,C,B,D) bezier in dotted green; and the
dashed (A,D,B,C) in blue.  This packs three illustrations
in the space of one!  (e.g., ~3 column inches)

Following this, I described the role of the control polyline
as a hint towards the shape of the resulting curve.  And,
what better way to illustrate this than to show the changes in
the shape of the control polygon for these three examples!

When the draft text was done and I started building the document,
it was *really* obvious that the same "three illustrations in
one figure" trick wasn't going to work -- the control polygons
overlap (d'uh!) so its virtually impossible to see which
polygon is associated with each curve.

Now, the "one" figure has to be replaced by three NONoverlapping
figures.  Or, by three *consecutive* figures.  In either case,
now an entire column spent on those three illustrations.  This
moves a lot of text off the page -- causing the layout of subsequent
pages to change.

Similarly, when deriving the equations for the tangents to the
curve, some of the equations were too wide to fit within a column
(you only know that when the equations are typeset!).  You then
have to decide:  do I "fold" the equation so it fits in a
single column?  or, do I insert a frame in which the equation
will reside and have that frame straddle both columns?  In each
case, the layout of everything around it is altered (e.g., you
ideally want the description associated with the derivation to
be present with the equation(s) also visible).

If your documents are *just* text, its a no-brainer:  let the text
break wherever it is convenient for the typesetter.

But, when you add lots of tables, illustrations, equations, etc.
the process requires a lot more "eyes on" control.  For example,
in the first 10 pages of that document, I have:
- 31 "display" (i.e., freestanding) equations (or "derivations")
- 23 figures/illustrations
- 3 tables
- 7 interactive demos

[The document is over 30 pages -- each pretty much the same sort
of complexion as these first 10]

Each of these are "large (visual) objects" that can't be split.
I.e., can't have half an illustration on one page and the other
half on the page following!  Because of that, each causes the
surrounding text to be severely chopped up (unless you allow the
objects to "float" free of the associated text).

>> Some issues that you need to be able to resolve, "visually", while
>> updating the document:
>>
>> The first 'e' in Bezier carries an accent.
>>
>> The opening and closing quotes surrounding the first instance of
>> Bezier in (1) are different characters/glyphs.  They must be
>> differentiable from "normal" double quotes.
>
> That's a matter of Unicode support. Both � and the quotes are Unicode
> characters.

You missed the point.  This post was concerned with size of *display*.
I.e., can you discern which type of accent is present on the 'e' when
the glyph is ~6 pts?  I.e., when there are ~10 pels in its height
(so the accent is a pel or two).  You *can* when it's printed on
a sheet of paper, professionally!  (try it)

>> "Cubic" in (1) is in italics as are "G1 Continuity" and "C1 Continuity".
>
> Semantic markup For The Win! You want to mark newly introduced terms?
>    \newcommand{\term}[1]{\emph{#1}}
>    ...
>    Thus, \term{C1 Continuity} implies \term{G1 Continuity}. However, the
>    reverse is not true.

Again, it's not a question of markup language.  Rather, can you
discern that "C1 Continuity" is in the correct typeface *and* italic
while it is presented at that small *subscript* to the "footnote" text
size?

>> Each digit in the selected footnote texts above are subscripts.
>
> OK,
>    Thus, \term{$C_1$ Continuity} implies \term{$G_1$ Continuity}.
>    However, the reverse is not true.

>> "Special Cases" in (4) is bold.
>
> It's probably a reference somewhere? Let's make it a link.
>    For examples of these degenerate cases, see \ref{Special Cases}.

Again, consider what a bold typeface looks like when rendered
that small.  You don't suddenly get more pels to work with for
that glyph!  It's still got to be the same size as the non-bold
version -- yet, you need to be able to *see* that it is actually
bold (do you allow the loops in the a/e/p to close to make
room for the extra pels that need to be inked?)

>> Recall, footnote text is 8 point.  With a 150dpi display, this
>> corresponds to ~16 pels tall -- including interline leading!
>
> When working with the text, it's all the same size for me. Fixedsys
> Excelsior, 16 px (I believe).

Because you don't produce photoready publications!

Do you write everything in (la)TeX and then hand it to the printer
and say, "run off 10,000 copies"?  Or, do you run it through the
TeX executable and *preview* the result?  (even Knuth did that
with _The TeXbook_ series!)  Then, when you "notice" something
is in the wrong typeface/style/layout, go back to the TeX
originals, edit it (in EMACS, of course!) and rerun the TeX
executable?

And, how are you manipulating all of those illustrations, tables,
equations?  Just *hoping* they fall into convenient spots?

>> So, you either get used to typesetting at a much magnified scale
>> (which means you see less of the page and have a distorted view
>> of the page's overall presentation) *or* fight trying to resolve
>> these fine features in a *coarse* presentation...
>
> When working with the text, I don't care about overall page layout. And
> when dealing with overall page layout, I don't have to be able to read
> every accent and superscript. But the previewers have a Zoom function if
> I need it anyway.

Of course you have to be able to read accents and superscripts!
How do you catch errors that you may introduce while *tweeking*
the text to adjust the layout?  Fold an equation to make it fit
*in* a column:  "Does the folded form still represent the same
relation?  Or, have I omitted an operator?  Or, included a
duplicate?

How do you decide that something needs a footnote added (to
introduce an issue that qualifies the discussion without acting
as a distraction in body text)?  Then, respond to the *new*
layout changes that this causes in the document?  ("Crap!
That forced this illustration onto the next page -- leaving
a big chunk of whitespace, here and altering the visual
aesthetics of each of the subsequent pages.  I *thought*
I was just about done but I see there's a lot more tweeking
required...")

Remember, there's no compiler or lint to check to see that
what you wrote is what you wanted it to be!  And, diff(1) is
essentially useless (for any significant text motion).

>> *or*, resort
>> to other tricks (like colored tags) or custom tools to parse
>> your documents on your behalf.
>
> I wouldn't call using LaTeX a custom tool or a trick.

Have you actually *watched* how publications are made,
professionally?  On average, I produce about a thousand photo-ready
pages a year -- and that's just a "cost of doing business" (not
what I *do* for a living).  Believe me, I sorted out where the
"costs" (i.e., time) lie in this process a long time ago!  :-/
I'm probably far more efficient at it than most "departments"
charged with this sort of activity -- because I have it in mind
when writing the specifications, designing the hardware,
crafting the code, developing test procedures and preparing
user documentation.  So, I *plan* on leveraging each of these
activities into each other (instead of their "free standing"
implementations in most organizations)

That's the problem with "programmers" -- they see everything as
a piece of code instead of a specific application domain unto
itself with its own rules, traditions, criteria, etc.

[Talk to RMS and *every* problem can be solved by "just" making
the source code available.  The fact that the folks using a
product might have no idea what to *do* with the source code
is immaterial -- "they can hire someone"  :( ]

Talk to a programmer about VCS and they'll argue back and forth
CVS/GIT/Hg/SVN/RCS/p4/etc. -- totally oblivious to the fact that
there are "documents" (electronic objects) that exist that
ARE NOT "source code".  Yet, squeal like a stuck pig if "forced"
to use a VCS that more heavily favors some *other* department's
needs (though never seeing the hypocrisy of forcing that other
department to use the tools that *they* prefer!)

"Everything looks like a nail"

Don Y <this@isnotme.com> writes:
> [...]
> Hi Randy,
> OK, so what's a "150 dpi" display?  If you're viewing an 11" tall
> sheet of paper "at full scale" (i.e., 1:1), that's ~1600 dots
> vertically.

It's 1650 dots. 

>
> Using a 4:3 monitor in landscape mode would require a resolution
> of 1600x2100 in an 18.5" diag display.  A 4:3 monitor in portrait
> mode would require a resolution of 1200x1600 in a 14" diag display.
>
> Using a 16:9 monitor in landscape mode requires a resolution of
> 1600x2850 in a 22.5" display.  In portrait mode, you'd need
> 900x1600 in a 13" display.
>
> [My math may be off -- I haven't done this calculation in a few
> years!]
>
> I.e., you want *small* displays with high resolutions.  And, that
> just barely gives you the visual resolution to determine what's
> actually on the screen!
>
> Most displays with higher resolutions 

You're overloading the word "resolution." In the printing world, which
I'll call p-resolution, it's dots per inch; in the monitor world, which
I'll call m-resolution, it's dots per orientation (vertical or
horizontal). I know you know this, just pulling in the semantics a bit.

> (i.e., *better* than these
> figures!) tend to be physically larger.  

If what you need is a p-resolution of 150 DPI or better, you're not
going to get that p-resolution on any monitor that I know of, precisely
because of this.

For example, the HP ZR30Z is 2560x1600 at a 30 inch diagonal. That is

  Lv = 30 * sin(arctan(1/1.6))
     = 15.9 inches (approx.)

  Lh = 30 * cos(arctan(1/1.6))
     = 25.44 inches (approx.)

So this gets you 

   p-resolution = 1600 / 15.9 
                = 100.6 DPI (approx.)

I know of no smaller monitors that have 2560x1600 resolution. If
they existed then you could of course come closer to 150 DPI.

So yeah, if you need that p-resolution, I guess you'll have to 
view the printed form of your documents. 

Personally I think I could live with a 30-inch monitor because of my own
unique physiology - I am near-sighted and viewing large monitors
close-up best suits me.

By the way, I bought a Lexmark C760 printer a few years' back,
a native 1200x1200 color laser. Delicious output; hellish
operating costs (~$120 per cartridge i a CMYK system)...

--Randy


> Then, you start having to
> deal with "pages" that are too large to comfortably view (unless
> you can lay the monitor *into* the desk surface -- how often do
> you read an 11" tall sheet of paper "standing straight up" on
> it's edge?
>
> So, you either get used to typesetting at a much magnified scale
> (which means you see less of the page and have a distorted view
> of the page's overall presentation) *or* fight trying to resolve
> these fine features in a *coarse* presentation... *or*, resort
> to other tricks (like colored tags) or custom tools to parse
> your documents on your behalf.

-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Hi Randy,

On 8/31/2013 12:13 PM, Randy Yates wrote:
> Don Y <this@isnotme.com> writes:
>> [...]
>> Hi Randy,
>> OK, so what's a "150 dpi" display?  If you're viewing an 11" tall
>> sheet of paper "at full scale" (i.e., 1:1), that's ~1600 dots
>> vertically.
>
> It's 1650 dots.

Yes.  But you don't really need to see the top/bottom margins
(OTOH, you have to make allowances for the button bar, window
frame, etc.)  I'm trying to give a *feel* for the problem;
not "engineer a solution".

>> Using a 4:3 monitor in landscape mode would require a resolution
>> of 1600x2100 in an 18.5" diag display.  A 4:3 monitor in portrait
>> mode would require a resolution of 1200x1600 in a 14" diag display.
>>
>> Using a 16:9 monitor in landscape mode requires a resolution of
>> 1600x2850 in a 22.5" display.  In portrait mode, you'd need
>> 900x1600 in a 13" display.
>>
>> [My math may be off -- I haven't done this calculation in a few
>> years!]
>>
>> I.e., you want *small* displays with high resolutions.  And, that
>> just barely gives you the visual resolution to determine what's
>> actually on the screen!
>>
>> Most displays with higher resolutions
>
> You're overloading the word "resolution." In the printing world, which
> I'll call p-resolution, it's dots per inch; in the monitor world, which
> I'll call m-resolution, it's dots per orientation (vertical or
> horizontal). I know you know this, just pulling in the semantics a bit.
>
>> (i.e., *better* than these
>> figures!) tend to be physically larger.
>
> If what you need is a p-resolution of 150 DPI or better, you're not
> going to get that p-resolution on any monitor that I know of, precisely
> because of this.
>
> For example, the HP ZR30Z is 2560x1600 at a 30 inch diagonal. That is
>
>    Lv = 30 * sin(arctan(1/1.6))
>       = 15.9 inches (approx.)
>
>    Lh = 30 * cos(arctan(1/1.6))
>       = 25.44 inches (approx.)
>
> So this gets you
>
>     p-resolution = 1600 / 15.9
>                  = 100.6 DPI (approx.)
>
> I know of no smaller monitors that have 2560x1600 resolution. If
> they existed then you could of course come closer to 150 DPI.

Exactly.  This is the problem I face with my current monitors;
I end up needing to view the image at > 100% physical scale
(so, you're reading a single sheet of paper yet encountering
it more like you would a *newspaper*)

And, 150 dpi is a *huge* concession -- as I was trying to
illustrate with my "font" descriptions.

As I said (tongue-in-cheek) "you just can't get a monitor *big*
enough!!"

> So yeah, if you need that p-resolution, I guess you'll have to
> view the printed form of your documents.
>
> Personally I think I could live with a 30-inch monitor because of my own
> unique physiology - I am near-sighted and viewing large monitors
> close-up best suits me.

Myopia/astigmatism -- so, even with just a *mild* Rx, detail falls
off *quickly* with distance.  At a distance where you would
typically hold a sheet of paper or a book, I can see very fine
detail (assuming enough ambient light).  Put a large monitor
(or monitors) on a desktop at arm's length and all that detail
melts away.

(I.e., I want a 14" portrait monitor at half that distance but
with much higher resolution -- so it *can* reproduce that level
of detail.  I've been looking at some very high resolution B&W
LCD monitors but the loss of color capability makes that yet
another tradeoff.)

> By the way, I bought a Lexmark C760 printer a few years' back,
> a native 1200x1200 color laser. Delicious output; hellish
> operating costs (~$120 per cartridge i a CMYK system)...

I use a duplexed Phaser (solid ink) for proof copies (1000x1000).
Nice "magazine-like" finish to the page (melted wax).  Ink "sticks"
are ~$50/color (CMYK) for ~2500 pages (at "nominal" coverage rates)
so, about 12c per page.  But, I can usually find supplies being
discarded, sold at local auctions, etc.  (IME, this is a *huge*
advantage for that solid ink form -- really long shelf life even
after "opened"!)

Unfortunately, it leaves the place smelling of "melted crayons" for
the better part of the day.

[Startup has a big ink cost associated with it as it cleans
the ink wells, drum, etc.  So, I wait until I have a few hundred
pages to run off before firing it up]

When a document is "done", I have it printed at a nearby service
bureau (of course, the interactive and multimedia portions of the
documents don't "print").

For "lower quality, higher volume" output (presentations, etc.),
I use a 600/1200 dpi color laser (but the images don't seem to
be as vibrant or crisp as with the phaser).

For *much* higher volume, a duplexed 600 dpi (monochrome) laser
makes it really easy to run off hundreds of pages in a few
minutes.  But, this is usually only useful for proofreading
text and checking placements of images/tables/text/etc. in a
very coarse way.

And, for day-to-day "one offs", a low temperature 600 dpi laser.

Le 31/08/13 19:03, bbhack a �crit :
> It makes sense when you remember it was constructed for the barely
> usable terminals of 25-30 years ago.
That probably the reason my opinion is biased ... but you know, i'm 
nearly 50 old and as a consultant i sometimes work with younger 
engineers without Unix culture. i figured out how poor the tools they 
use and how enjoyed they are when sometimes i'm sharing my knowledge 
with them. Emacs is certainly a big thing to master - no one can - i 
maintain using Emacs makes you a programmer.

Don Y wrote:
> On 8/31/2013 3:05 AM, Stefan Reuther wrote:
>> Don Y wrote:
>>> On a *printed* (phototypeset) document, these things are really
>>> easy to resolve.  On a *display*, they are much harder!
>>>
>>> E.g., I'm currently preparing a document on cubic Bezier curves.
>>> I use a 10 pt serif typeface for body text.  This means footnote
>>> text is 8 pt.  Footnote *references* (i.e., in the body text)
>>> are superscripts -- so, about 5-6 pt on the 10 pt text.  Within
>>> footnote text, subscripts are about 4-5 pt!
>>
>> Why on earth do you need to display all that in the final layout during
>> document preparation?
> 
> Because document preparation involves sorting out its visual
> presentation!  If you don't care what the document looks like,
> "compose" it in HTML and you'll never need to *know* how it will
> appear on some particular browser!

Sure I check how it looks like. But not at the same time I type it. Thus
I can check whether each B�zier has its accent during editing, in a nice
large screen font size. I trust my typesetting system to preserve the �
even when the font size is reduced for a footnote.

> If your documents are *just* text, its a no-brainer:  let the text
> break wherever it is convenient for the typesetter.
> 
> But, when you add lots of tables, illustrations, equations, etc.
> the process requires a lot more "eyes on" control.

Sure. But I don't need to see all the subscripts and accents in the
formula at the same time as the headlines. To see the subscripts, I can
zoom in. To see the headlines, I can zoom out. Then I see an
indecipherable blob that looks like a formula. Fine, there's the
formula, here's the text that flows around it, done.

>>> "Cubic" in (1) is in italics as are "G1 Continuity" and "C1 Continuity".
>>
>> Semantic markup For The Win! You want to mark newly introduced terms?
>>    \newcommand{\term}[1]{\emph{#1}}
>>    ...
>>    Thus, \term{C1 Continuity} implies \term{G1 Continuity}. However, the
>>    reverse is not true.
> 
> Again, it's not a question of markup language.  Rather, can you
> discern that "C1 Continuity" is in the correct typeface *and* italic
> while it is presented at that small *subscript* to the "footnote" text
> size?

Again, I trust my typesetting system that if I set something in italic,
it will also be in italic when moved to a footnote.

I know people plan their university thesis with a work item
   2 days: check that all headings have the same font, all
   cross-references point to the right pages, etc.
just before giving it to the printer. OK, this may be needed if all you
have is Wordpad which has no stylesheets (or all you have is Word and
you have never heard of stylesheets). I am not one of them.

>>> "Special Cases" in (4) is bold.
>>
>> It's probably a reference somewhere? Let's make it a link.
>>    For examples of these degenerate cases, see \ref{Special Cases}.
> 
> Again, consider what a bold typeface looks like when rendered
> that small.  You don't suddenly get more pels to work with for
> that glyph!

Again, why would I need that? I trust my system to set a boldface
"Special Cases" if I tell it to. In a preview with standard screen
resolution, letters may become a little sludged, but looks like "Special
Cases" even from afar, and if I really want to know, I can zoom in.

>>> Recall, footnote text is 8 point.  With a 150dpi display, this
>>> corresponds to ~16 pels tall -- including interline leading!
>>
>> When working with the text, it's all the same size for me. Fixedsys
>> Excelsior, 16 px (I believe).
> 
> Because you don't produce photoready publications!
> 
> Do you write everything in (la)TeX and then hand it to the printer
> and say, "run off 10,000 copies"?  Or, do you run it through the
> TeX executable and *preview* the result?
[...]
> And, how are you manipulating all of those illustrations, tables,
> equations?  Just *hoping* they fall into convenient spots?

Sure I preview. My point being: you don't have to see all details at
once. When adjusting illustrations, I don't care about the precise
content of the illustration; I care that there is an illustration, but
don't need to see every pixel of it.


  Stefan

Habib Bouaziz-Viallet <h.bouazizviallet@free.fr> writes:

> Le 31/08/13 19:03, bbhack a &eacute;crit :
>> It makes sense when you remember it was constructed for the barely
>> usable terminals of 25-30 years ago.
> That probably the reason my opinion is biased ... but you know, i'm
> nearly 50 old and as a consultant i sometimes work with younger
> engineers without Unix culture. i figured out how poor the tools they
> use and how enjoyed they are when sometimes i'm sharing my knowledge
> with them. Emacs is certainly a big thing to master - no one can - i
> maintain using Emacs makes you a programmer.

Hear, hear!
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com