Editor recommendation

Don Y <this@isnotme.com> writes:

> Greetings Dimiter!
>
> On 8/29/2013 9:23 AM, dp wrote:
>> On Thursday, August 29, 2013 1:10:10 AM UTC+3, chris wrote:
>>> ... The most useful thing when I started using it was the
>>> rectangular cut and paste, which I still use all the time, though the rest
>>> of the world has caught up meantime.
>>
>> So the rest of the world slowly catches up I gather :-)?
>> I have had rectangular cut and paste ever since I began
>> using my own editor (around 1990), had no idea who else
>> would have it and since when.
>
> Brief had rectangular cut & paste in the early 80's (my v2.1
> manual is copyright 1984 and I'm pretty sure the feature
> was present on earlier versions -- I'll have to chase down
> a floppy .IMZ from my archives...)

I used brief back the late 80s. It was an excellent editor.

I've been using emacs/xemacs since 1998. I wish I could say it's
head-and-shoulders above the rest, but in the past year or two I've
found some quirks that make me hesitate, e.g., having a very hard time
with files that are one long line.

However, elisp makes this the most configurable/customizable editor.
Ever. I've written entire code generation templates in elisp that allow
me to, e.g., create an entire, compilable testbench template (for C) in
30 seconds.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Don Y <this@isnotme.com> writes:
> [...]
> There comes a point where you just can't get a monitor *big*
> enough!!  :-/

Not that I really need it, but I've been lusting on an HP ZR30W
for some time...  Currently using the ZR24W and it is excellent.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Robert Wessel <robertwessel2@yahoo.com> writes:

> A second video card and a 24 inch monitor in portrait mode will set
> you back, what, $200?

1920x1080 can be had at that price, but the better 1920x1200 ones start
around $300.

To me, it's not just about bigger.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Hi Randy,

On 8/30/2013 5:37 PM, Randy Yates wrote:
> Don Y <this@isnotme.com> writes:
>> [...]
>> There comes a point where you just can't get a monitor *big*
>> enough!!  :-/
>
> Not that I really need it, but I've been lusting on an HP ZR30W
> for some time...  Currently using the ZR24W and it is excellent.

If you're just writing code or drawing schematics, you can get
a lot out of a generic display.  E.g., it's easy for me to have
9 (non-overlapping) xterms open on a single display concurrently
with very little problems reading what's displayed on each.  All
you're concerned with is selecting a typeface in which '1' and
'l', '0' and 'O', etc. are readily distinguishable.  (and, diodes
are easily differentiated from caps, resistors, etc.  :> )

But, when you're actually creating documents for publication,
you need to be able to resolve different type *styles* (e.g.,
italic vs. bold vs. bold italic vs. condensed, etc.), sizes
(e.g., sub/superscript), typefaces (san serif vs serif et al.)
and spacing/kerning.

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!

Some footnotes from that document (not sure if non-USASCII characters
will be visible, here):

1 Unqualified, the term &#4294967295;B&#4294967295;zier&#4294967295;, herein, shall refer to cubic B&#4294967295;zier 
curves.

2 All curves begin from the same P0. The choice of second control point, 
P1, is varied between each of the remaining points. The final control 
point, P3, is obvious on visual inspection.

3 Thus, C1 Continuity implies G1 Continuity. However, the reverse is not 
true.

4 For examples of these degenerate cases, see Special Cases.

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.

"Cubic" in (1) is in italics as are "G1 Continuity" and "C1 Continuity".

Each digit in the selected footnote texts above are subscripts.

"Special Cases" in (4) is bold.

Recall, footnote text is 8 point.  With a 150dpi display, this
corresponds to ~16 pels tall -- including interline leading!
(i.e., the actual glyph from baseline to ascender is about 10-12
pels tall)  For subscripts within those footnotes, you're talking
about 6-8 pels.  I.e., resolving a 10 pt glyph "accidentally" copied
into footnote text (i.e., by pasting something cut from body text
*without* stripping the formatting information from it, first!) from
the normal 8 point text boils down to a few pels on each axis.
Resolving "X sub 1" vs. "X sub l" in footnote text would, at best, be
tedious/time consuming/prone to error!

[in fact, the effective bitmaps for the two subscript glyphs differ
by one -- maybe 1.5 -- pels!]

I won't even go into the issues involved with presenting complex
mathematical formulae with the large variety of symbols they
introduce.

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.

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 (i.e., *better* than these
figures!) tend to be physically larger.  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.

Hi Randy,

On 8/30/2013 5:30 PM, Randy Yates wrote:
> Don Y <this@isnotme.com> writes:
>
>> Greetings Dimiter!
>>
>> On 8/29/2013 9:23 AM, dp wrote:
>>> On Thursday, August 29, 2013 1:10:10 AM UTC+3, chris wrote:
>>>> ... The most useful thing when I started using it was the
>>>> rectangular cut and paste, which I still use all the time, though the rest
>>>> of the world has caught up meantime.
>>>
>>> So the rest of the world slowly catches up I gather :-)?
>>> I have had rectangular cut and paste ever since I began
>>> using my own editor (around 1990), had no idea who else
>>> would have it and since when.
>>
>> Brief had rectangular cut & paste in the early 80's (my v2.1
>> manual is copyright 1984 and I'm pretty sure the feature
>> was present on earlier versions -- I'll have to chase down
>> a floppy .IMZ from my archives...)
>
> I used brief back the late 80s. It was an excellent editor.
>
> I've been using emacs/xemacs since 1998. I wish I could say it's
> head-and-shoulders above the rest, but in the past year or two I've
> found some quirks that make me hesitate, e.g., having a very hard time
> with files that are one long line.

I started using it in the late 70's/early 80's.  At the time,
just one of many different ways of massaging characters in files.
I've only been running it on my own hardware since the late 80's.
Brief was far more readily available (cuz I could run that on
*any* PC).  E.g., on a 16MHz 386 it was like greased lightning!

For degenerate input files (e.g., "one long line"), I tend to
work in a hex editor.  Search and replace FOR EQUIVALENT SIZE
KEYS is a piece of cake.  Adding/removing characters in the
process gets more problematic.

[IIRC, BRIEF had a 256 character line length limitation]

I am more often concerned with long files -- e.g., 1MB+ -- and
the depth of "undo".

> However, elisp makes this the most configurable/customizable editor.
> Ever. I've written entire code generation templates in elisp that allow
> me to, e.g., create an entire, compilable testbench template (for C) in
> 30 seconds.

I see "configurable" as a double-edged sword.  Yeah, you have the
*ability* to customize it to your task.  But, you now have the
*responsibility* of customizing it for your task!  (or, hope
someone else shares your idea of *how* it should be customized,
etc.)

E.g., emacs is wonderful in how flexible it *can* be.  But, if
someone hasn't already spent the time preparing a suitable
"mode" for you, then that task falls on your shoulders.  And,
unless you can drag your environment/toolchain around *everywhere*
you might want to use it, you often end up fighting someone
else's idea of how *their* instance of the toolchain should be
configured (*assuming* they actually use it!).  Or, finding
that the tool isn't available where you are, currently.

By way of example, there is no *effective* Limbo mode.  And,
I'm the only one who is likely to write a mode for *my* IDL.

How much time do you throw into these sorts of "tool building"
tasks?  How much time do you expect them to *save* from the
"real work" you have to do?  How happy are you living with
someone else's idea of how a "mode" should work?  If I embed
some SQL (or HTML, etc.) *inside* a "C" source file, will you
be smart enough to recognize this and provide the same level
of (ahem) "help" that you try to provide for the C source?
*Or*, for that SQL if it had been freestanding in a ".SQL"
file??

Give me a mechanism to move characters around on a screen.  I
don't need you to tell me that "if" (in this context) is a
keyword -- if I don't know that, your help is too little, too
late!  :>  A compiler can tell me if I forgot to close a string
six lines back (i.e., it is the compiler's responsibility to
be language cop -- not the text editor!)  Implement fast/flexible
searches.  Support non-ASCII character encodings.  etc.

If I want to adopt a particular style (e.g., how I present some
embedded SQL statements within Limbo source so that they are easily
recognizable as such) for expressing my algorithms, let me do that
without trying to coerce it to comply with *your* idea of what
I might be doing (or, providing NO help at all).

Then, get out of my way.

Don Y wrote:
> On 8/30/2013 4:22 AM, Hans-Bernhard Br�ker wrote:
>> E.g., and just because this
>> particular editor hasn't been mentioned yet: in plain old vi, that
>> would be
>>
>> :1,$s/<Figure \([^:]*\): continued on Page \([^)]\)>/<Illustration \1:
>> <italic>(see page \2)<\italic>>/g
>>
>> (all in one line, not really tested)
> 
> And *that* is the problem ^^^^^^^^^^^^!  Unless you want to invest
> lots of time learning to be an RE guru (and then complaining when
> some tool doesn't support them!), you're never quite sure you've
> got it right when you hit ENTER.

If you got it wrong, every editor worth its money allows you to undo and
try again. No problem.

> Write a piece of code to perform the same sort of thing and you
> can easily (i.e., with a high degree of success) change a stub
> that emits "found <foo> at file offset <x>; replacing with <bar>"
> (i.e., used to let you preview the actions that the code will
> ultimately take) with one that writes <bar> directly to the desired
> output file (without fear of overwriting the original input!).

If you asked me to write that piece of code, it would most likely be a
Perl one-liner looking almost like Hans-Bernhard's vi snippet. Normally
I do such things using Emacs' query-replace-regexp, though, because that
saves me one level of escaping.

> And, there are problems that just don't lend themselves to an RE
> sort of solution (e.g., transposing a matrix is easy to do with
> keystroke macros or "a piece of code" -- considerably harder
> "out of the gate" with a set of RE's!)

And this is where an editor with a pipe-block-through-a-program function
comes in handy. That single feature alone is enough reason for me to use
Emacs; all of the "modern" IDEs lack it.

>> And you really shouldn't be.  Any programmer's editor really worth
>> having has some sort of "rectangle fill" feature.  E.g. in Notepad++,
>> you would just <Alt>-mark the column (i.e. drag the mouse while holding
>> <Alt>, or move the cursor from one end to the other while holding
>> Alt+Shift), then type a single $.  Done.  For more complicated cases, it
>> can even fill in a sequence of numbers
> 
> Do you *only* deal with "programmer's editors"?

Most of the time.

> E.g., when I type
> code fragments into a FrameMaker document (to formally document
> something that I've created), *where* the cursor ends up if I type
> <down_arrow> depends on my position in the current line and
> the "font" used on that line and the line that follows.  The
> idea of a "rectangular fill/copy/delete" simply doesn't apply
> (note that this isn't just the proportional/fixed width font
> issue but also the *sizes* of the typefaces comes into play!)
> 
> What's the keystroke sequence to cut/paste/fill a rectangular region
> while composing in Thunderbird?  (or, do you never share code
> fragments with colleagues electronically)
> 
> Should I keep Emacs open in a second window, type whatever "code"
> I want in that window (using the tools emacs makes available to
> me) and then *paste* it into whatever application I happen to
> be *actively* working in at the time?

Actually, that's what I often do. I draft a piece of code in Emacs, and
when I got it ready, paste it into Word, or Thunderbird, or whatever is
needed at the time (or from the C file into the LaTeX file in Emacs).

> Over the years, I've found that the more "features" you rely on,
> the more you *need* those features in your normal workflow.

So what? I spend my whole workday in front of an editor, so of course I
try to make that as efficient as possible. Of course I *can* write C
with Notepad, but that is very efficient for programs exceeding the
complexity of a "hello world" (... "blink LED", "jump to reset vector").

Your argument sounds like telling your carpenter he should use fewer
tools so he doesn't rely on them in his normal workflow. After all, he
can probably build a house with nothing more than a sharp screwdriver.


  Stefan

Don Y wrote:
> On 8/30/2013 5:30 PM, Randy Yates wrote:
>> However, elisp makes this the most configurable/customizable editor.
>> Ever. I've written entire code generation templates in elisp that allow
>> me to, e.g., create an entire, compilable testbench template (for C) in
>> 30 seconds.
> 
> I see "configurable" as a double-edged sword.  Yeah, you have the
> *ability* to customize it to your task.  But, you now have the
> *responsibility* of customizing it for your task!  (or, hope
> someone else shares your idea of *how* it should be customized,
> etc.)

Only if the author of the "configurable" tool used that as an excuse to
deliver it with no sensible default configuration. I cannot say that of
Emacs.

> E.g., emacs is wonderful in how flexible it *can* be.  But, if
> someone hasn't already spent the time preparing a suitable
> "mode" for you, then that task falls on your shoulders.

So, where's the difference to other editors? If nobody has written an
Eclipse or Visual Studio extension for your task, you're lost, too. The
difference being that with Emacs you don't need a compiler, but just a
lisp-interaction buffer to start with your own extension.

> And, unless you can drag your environment/toolchain around *everywhere*
> you might want to use it, you often end up fighting someone
> else's idea of how *their* instance of the toolchain should be
> configured (*assuming* they actually use it!).  Or, finding
> that the tool isn't available where you are, currently.

Duplicating an Emacs environment is a matter of copying a folder full of
*.el files from your home directory. You don't even need to mess with
DLLs that may need admin permissions, Java runtime versions, etc.

> By way of example, there is no *effective* Limbo mode.  And,
> I'm the only one who is likely to write a mode for *my* IDL.
> 
> How much time do you throw into these sorts of "tool building"
> tasks?  How much time do you expect them to *save* from the
> "real work" you have to do?  How happy are you living with
> someone else's idea of how a "mode" should work?

I spent considerable amount of time adjusting cc-mode's imagination how
C files should look like. Now, 99% of the time it formats a piece of
code other than I think it should, it's because I forgot a parenthesis,
semicolon, or quote, saving me a compile cycle. I spent a day or so to
build an "add an #include directive at the top of this file", either
with filename completion or by deriving it from a class name, using our
project's convention. Almost no compile errors due to forgotten includes
(and if there are still some, they're fixed with a keystroke).

I think that paid out.

> If I embed
> some SQL (or HTML, etc.) *inside* a "C" source file, will you
> be smart enough to recognize this and provide the same level
> of (ahem) "help" that you try to provide for the C source?
> *Or*, for that SQL if it had been freestanding in a ".SQL"
> file??

There is a "multiple major modes" extension, intended for files with
mixed HTML, JavaScript and CSS. Probably it can also work with mixed C
and SQL, I never tried.

> Give me a mechanism to move characters around on a screen.  I
> don't need you to tell me that "if" (in this context) is a
> keyword -- if I don't know that, your help is too little, too
> late!  :>

Can you spot the syntax error in
   /* read key from ini file, return default if key isn't in file */
   const char* getConfigValue(const char* key, const char* default);
? Took me an afternoon to figure out (compiler messages were NOT
helpful), and convince me of the advantages of syntax coloring.

> A compiler can tell me if I forgot to close a string
> six lines back (i.e., it is the compiler's responsibility to
> be language cop -- not the text editor!)  Implement fast/flexible
> searches.  Support non-ASCII character encodings.  etc.
> 
> If I want to adopt a particular style (e.g., how I present some
> embedded SQL statements within Limbo source so that they are easily
> recognizable as such) for expressing my algorithms, let me do that
> without trying to coerce it to comply with *your* idea of what
> I might be doing (or, providing NO help at all).
> 
> Then, get out of my way.

Emacs' get-out-of-my-way command is M-x fundamental-mode.


  Stefan

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?

> 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.

> "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.

> 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}.

> 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).

> 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.

> *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.


  Stefan

Stefan Reuther <stefan.news@arcor.de> writes:

> Don Y wrote:
>> On 8/30/2013 5:30 PM, Randy Yates wrote:
>>> However, elisp makes this the most configurable/customizable editor.
>>> Ever. I've written entire code generation templates in elisp that allow
>>> me to, e.g., create an entire, compilable testbench template (for C) in
>>> 30 seconds.
>> 
>> I see "configurable" as a double-edged sword.  Yeah, you have the
>> *ability* to customize it to your task.  But, you now have the
>> *responsibility* of customizing it for your task!  (or, hope
>> someone else shares your idea of *how* it should be customized,
>> etc.)
>
> Only if the author of the "configurable" tool used that as an excuse to
> deliver it with no sensible default configuration. I cannot say that of
> Emacs.
>
>> E.g., emacs is wonderful in how flexible it *can* be.  But, if
>> someone hasn't already spent the time preparing a suitable
>> "mode" for you, then that task falls on your shoulders.
>
> So, where's the difference to other editors? If nobody has written an
> Eclipse or Visual Studio extension for your task, you're lost, too. The
> difference being that with Emacs you don't need a compiler, but just a
> lisp-interaction buffer to start with your own extension.
>
>> And, unless you can drag your environment/toolchain around *everywhere*
>> you might want to use it, you often end up fighting someone
>> else's idea of how *their* instance of the toolchain should be
>> configured (*assuming* they actually use it!).  Or, finding
>> that the tool isn't available where you are, currently.
>
> Duplicating an Emacs environment is a matter of copying a folder full of
> *.el files from your home directory. You don't even need to mess with
> DLLs that may need admin permissions, Java runtime versions, etc.
>
>> By way of example, there is no *effective* Limbo mode.  And,
>> I'm the only one who is likely to write a mode for *my* IDL.
>> 
>> How much time do you throw into these sorts of "tool building"
>> tasks?  How much time do you expect them to *save* from the
>> "real work" you have to do?  How happy are you living with
>> someone else's idea of how a "mode" should work?
>
> I spent considerable amount of time adjusting cc-mode's imagination how
> C files should look like. Now, 99% of the time it formats a piece of
> code other than I think it should, it's because I forgot a parenthesis,
> semicolon, or quote, saving me a compile cycle. I spent a day or so to
> build an "add an #include directive at the top of this file", either
> with filename completion or by deriving it from a class name, using our
> project's convention. Almost no compile errors due to forgotten includes
> (and if there are still some, they're fixed with a keystroke).
>
> I think that paid out.
>
>> If I embed
>> some SQL (or HTML, etc.) *inside* a "C" source file, will you
>> be smart enough to recognize this and provide the same level
>> of (ahem) "help" that you try to provide for the C source?
>> *Or*, for that SQL if it had been freestanding in a ".SQL"
>> file??
>
> There is a "multiple major modes" extension, intended for files with
> mixed HTML, JavaScript and CSS. Probably it can also work with mixed C
> and SQL, I never tried.
>
>> Give me a mechanism to move characters around on a screen.  I
>> don't need you to tell me that "if" (in this context) is a
>> keyword -- if I don't know that, your help is too little, too
>> late!  :>
>
> Can you spot the syntax error in
>    /* read key from ini file, return default if key isn't in file */
>    const char* getConfigValue(const char* key, const char* default);
> ? Took me an afternoon to figure out (compiler messages were NOT
> helpful), and convince me of the advantages of syntax coloring.
>
>> A compiler can tell me if I forgot to close a string
>> six lines back (i.e., it is the compiler's responsibility to
>> be language cop -- not the text editor!)  Implement fast/flexible
>> searches.  Support non-ASCII character encodings.  etc.
>> 
>> If I want to adopt a particular style (e.g., how I present some
>> embedded SQL statements within Limbo source so that they are easily
>> recognizable as such) for expressing my algorithms, let me do that
>> without trying to coerce it to comply with *your* idea of what
>> I might be doing (or, providing NO help at all).
>> 
>> Then, get out of my way.
>
> Emacs' get-out-of-my-way command is M-x fundamental-mode.
>
>
>   Stefan

I'm with you, Stefan. How can an editor that gives you extra
configurability ever be considered a bad thing? If you don't need that
extra configurability, or don't want to spend the time, then (duh!)
don't.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Stefan Reuther <stefan.news@arcor.de> writes:
> [...]
> Duplicating an Emacs environment is a matter of copying a folder full of
> *.el files from your home directory. You don't even need to mess with
> DLLs that may need admin permissions, Java runtime versions, etc.

Prezactly. I regularly migrate my customizations from linux (Fedora - my
main OS), to various Windoze machines. Little to no problems and
practically instant setup.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com