Editor recommendation

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 
 Click to see the full signature
Reply to
Randy Yates
Loading thread data ...

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 
 Click to see the full signature
Reply to
Randy Yates

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 
 Click to see the full signature
Reply to
Randy Yates

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 ?Bézier?, herein, shall refer to cubic Bé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.

Reply to
Don Y

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

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.

Reply to
Don Y

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

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

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

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

Reply to
Stefan Reuther

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.

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.

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.

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.

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.

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.

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

Stefan

Reply to
Stefan Reuther

Why on earth do you need to display all that in the final layout during document preparation?

That's a matter of Unicode support. Both é and the quotes are Unicode characters.

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.

OK, Thus, \term{$C_1$ Continuity} implies \term{$G_1$ Continuity}. However, the reverse is not true.

It's probably a reference somewhere? Let's make it a link. For examples of these degenerate cases, see \ref{Special Cases}.

When working with the text, it's all the same size for me. Fixedsys Excelsior, 16 px (I believe).

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.

I wouldn't call using LaTeX a custom tool or a trick.

Stefan

Reply to
Stefan Reuther

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 
 Click to see the full signature
Reply to
Randy Yates

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 
 Click to see the full signature
Reply to
Randy Yates

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.

Reply to
bbhack

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

Reply to
bbhack

formatting link

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

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

Reply to
bbhack

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

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)

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, 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?)

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?

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

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"

Reply to
Don Y

It's 1650 dots.

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.

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

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

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

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

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

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.

Reply to
Don Y

Le 31/08/13 19:03, bbhack a écrit :

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.

Reply to
Habib Bouaziz-Viallet

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.

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.

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.

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.

[...]

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

Reply to
Stefan Reuther

Hear, hear!

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.