Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #13216 > unrolled thread

Editor recommendation

Back to article view | Back to comp.arch.embedded

Contents

  Editor recommendation Roberto Waltman <usenet@rwaltman.com> - 2013-08-28 16:18 -0400
    Re: Editor recommendation David Brown <david.brown@removethis.hesbynett.no> - 2013-08-28 22:46 +0200
      Re: Editor recommendation chris <meru@devnull.com> - 2013-08-28 22:10 +0000
        Re: Editor recommendation dp <dp@tgi-sci.com> - 2013-08-29 09:23 -0700
          Re: Editor recommendation Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-08-29 17:15 +0000
            Re: Editor recommendation dp <dp@tgi-sci.com> - 2013-08-29 10:38 -0700
              Re: Editor recommendation Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-08-29 17:49 +0000
                Re: Editor recommendation dp <dp@tgi-sci.com> - 2013-08-29 12:19 -0700
            Re: Editor recommendation Paul Rubin <no.email@nospam.invalid> - 2013-08-29 12:16 -0700
          Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-29 11:32 -0700
            Re: Editor recommendation Paul Rubin <no.email@nospam.invalid> - 2013-08-29 12:15 -0700
            Re: Editor recommendation dp <dp@tgi-sci.com> - 2013-08-29 14:04 -0700
              Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-29 14:25 -0700
                Re: Editor recommendation Robert Wessel <robertwessel2@yahoo.com> - 2013-08-29 17:05 -0500
                  Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-29 16:32 -0700
                Re: Editor recommendation dp <dp@tgi-sci.com> - 2013-08-29 15:44 -0700
                  Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-29 18:02 -0700
                    Re: Editor recommendation Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-30 13:22 +0200
                      Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-30 15:00 -0700
                        Re: Editor recommendation Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-31 02:17 +0200
                        Re: Editor recommendation Stefan Reuther <stefan.news@arcor.de> - 2013-08-31 11:36 +0200
            Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-08-30 20:30 -0400
              Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-31 00:50 -0700
                Re: Editor recommendation Stefan Reuther <stefan.news@arcor.de> - 2013-08-31 11:54 +0200
                  Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-08-31 10:17 -0400
                  Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-08-31 10:20 -0400
          Re: Editor recommendation chris <meru@devnull.com> - 2013-08-30 13:29 +0000
            Re: Editor recommendation dp <dp@tgi-sci.com> - 2013-08-30 15:04 -0700
      Re: Editor recommendation George Neuner <gneuner2@comcast.net> - 2013-08-30 13:05 -0400
        Re: Editor recommendation chris <meru@devnull.com> - 2013-08-30 22:55 +0000
    Re: Editor recommendation Les Cargill <lcargill99@comcast.com> - 2013-08-28 21:22 -0500
      Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-28 19:54 -0700
        Re: Editor recommendation Les Cargill <lcargill99@comcast.com> - 2013-08-28 22:28 -0500
          Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-28 22:38 -0700
      Re: Editor recommendation George Neuner <gneuner2@comcast.net> - 2013-08-30 12:42 -0400
        Re: Editor recommendation Paul Urbanus <urb@urbonix.com> - 2013-09-02 21:20 -0500
          Re: Editor recommendation Paul Urbanus <urb@urbonix.com> - 2013-09-04 01:20 -0500
          Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-09-04 07:22 -0400
    Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-28 19:52 -0700
    Re: Editor recommendation bbhack <bbhack@gmail.com> - 2013-08-28 22:41 -0500
      Re: Editor recommendation chris <meru@devnull.com> - 2013-08-29 12:19 +0000
        Re: Editor recommendation bbhack <bbhack@gmail.com> - 2013-08-31 11:54 -0500
          Re: Editor recommendation chris <meru@devnull.com> - 2013-09-03 15:32 +0000
    Re: Editor recommendation Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-08-29 09:19 +0300
    Re: Editor recommendation Roberto Waltman <usenet@rwaltman.com> - 2013-08-29 10:01 -0400
      Re: Editor recommendation Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-08-29 18:45 +0300
      Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-29 12:04 -0700
        Re: Editor recommendation Robert Wessel <robertwessel2@yahoo.com> - 2013-08-29 16:31 -0500
          Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-29 15:00 -0700
          Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-08-30 20:50 -0400
        Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-08-30 20:37 -0400
          Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-30 21:15 -0700
            Re: Editor recommendation Stefan Reuther <stefan.news@arcor.de> - 2013-08-31 12:05 +0200
              Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-31 11:26 -0700
                Re: Editor recommendation Stefan Reuther <stefan.news@arcor.de> - 2013-09-01 20:21 +0200
                  Re: Editor recommendation Don Y <this@isnotme.com> - 2013-09-01 17:02 -0700
                    Re: Editor recommendation Stefan Reuther <stefan.news@arcor.de> - 2013-09-02 19:55 +0200
                      Re: Editor recommendation Don Y <this@isnotme.com> - 2013-09-02 16:22 -0700
                        Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-09-02 19:39 -0400
                          Re: Editor recommendation Don Y <this@isnotme.com> - 2013-09-02 17:51 -0700
                          Re: Editor recommendation Don Y <this@isnotme.com> - 2013-09-02 18:49 -0700
            Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-08-31 15:13 -0400
              Re: Editor recommendation Don Y <this@isnotme.com> - 2013-08-31 13:45 -0700
    Re: Editor recommendation Habib Bouaziz-Viallet <h.bouazizviallet@free.fr> - 2013-08-29 16:31 +0200
      Re: Editor recommendation bbhack <bbhack@gmail.com> - 2013-08-31 12:03 -0500
        Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-08-31 13:27 -0400
          Re: Editor recommendation bbhack <bbhack@gmail.com> - 2013-08-31 13:17 -0500
        Re: Editor recommendation Habib Bouaziz-Viallet <h.bouazizviallet@free.fr> - 2013-09-01 19:16 +0200
          Re: Editor recommendation Randy Yates <yates@digitalsignallabs.com> - 2013-09-01 19:52 -0400
            Re: Editor recommendation chris <meru@devnull.com> - 2013-09-03 14:41 +0000
    Re: Editor recommendation jhallen@TheWorld.com (Joseph H Allen) - 2013-08-29 20:09 +0000
    Re: Editor recommendation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-04 12:10 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#13272

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

[toc] | [prev] | [next] | [standalone]

#13266

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

[toc] | [prev] | [next] | [standalone]

#13270

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.

[toc] | [prev] | [next] | [standalone]

#13273

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

[toc] | [prev] | [next] | [standalone]

#13275

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

[toc] | [prev] | [next] | [standalone]

#13276

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

[toc] | [prev] | [next] | [standalone]

#13259

On 08/29/13 16:23, dp wrote:

>
> So the rest of the world slowly catches up I gather :-)?

Well, yes, in the context of readily available quality free
editors in the early nineties, there really wasn't much
choice. Coming to unix from a dec background, it was quite
disappointing to be presented with thing like vi, when dec
systems had full screen keypad editors for 10 years or more.

Don't know if you have bothered to look at nedit, but it has
a lot of other features, like tabbed editing, multi language
sensitivity, macros and loads more. All I really need from
an editor is a flexible set of core features, not a load of
eye candy and obscure "features" that no one ever uses. It
also needs to be easy to get started without looking at the
manual, which often is a key indicator of how intuitive and
user friendly a product is.

NEdit evelopment stopped around 2001, but this page gives gives
a little history:

http://nedit.gmxhome.de/history.html

"To the best of my knowledge, NEdit was begun in 1991 as a
short project to explore the Motif text widget and provide a
simple editor for programmers to use at Fermilab. At that
time Fermilab was beginning its migration from VAX/VMS systems
to Unix systems, and one of the first stumbling blocks that
physicists, and some programmers there, came up against was
editing. Most VMS users used EDT or EVE, and the Unix editors
were very different from these...."

For me, there are 2 main editor requirements: The first for
quick fixes on short files, for which I use vi on unix, pfe
on windows (ancient, but still useful) and for serious work,
nedit on unix, windows / cygwin, notepad++ on windows. Nedit
also has the advantage that there are binaries for just about
every flavour of unix and Linux.

> 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.
> I wonder if the world has caught up with some useful key
> combinations I introduced for myself back then (shift-up
> or shift-down moves 4 lines, shift right moves to next
> word etc.).

You were obviously well ahead of the curve at the time, but
if you don't publish or make your work available to others,
who will ever know about it ?.

> I suppose my editors (two of them, the second one came
> for DPS around 1996 or 1997) have been a significant part
> of what has made me as efficient as I am.
>
> Sorry for the OT as I can't recommend any of the PC based
> editors but sometimes like all of us I also need to talk
> to people who understand what I am talking about :-).
>
> Dimiter

Well, that's the problem with being a genius ahead of the
curve; No one understands you .

(Sorry, couldn't resist :-)...

Chris

[toc] | [prev] | [next] | [standalone]

#13263

On Friday, August 30, 2013 4:29:59 PM UTC+3, chris wrote:
> On 08/29/13 16:23, dp wrote:
>  ....
> >
> > 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.
> > I wonder if the world has caught up with some useful key
> > combinations I introduced for myself back then (shift-up
> > or shift-down moves 4 lines, shift right moves to next
> > word etc.).
> 
> You were obviously well ahead of the curve at the time, but
> if you don't publish or make your work available to others,
> who will ever know about it ?.

Well my purpose back then was just to have a useful tool for
myself, not to publish it. Since it worked on my hardware only
which would have no chance on the market as a general platform
I did not even consider expanding this way. But people who have
had such devices in their hands (the oldest of nukemans) would
have seen it (and would be uninterested, they would be using
a spectrometer as a spectrometer :-) ). Come to think of it,
nowadays things haven't changed much, netmca users have a lot
more available than what old nukeman users used to have but are
still using their spectrometers as spectrometers.... :-) .

> 
> > I suppose my editors (two of them, the second one came
> > for DPS around 1996 or 1997) have been a significant part
> > of what has made me as efficient as I am.
> >
> > Sorry for the OT as I can't recommend any of the PC based
> > editors but sometimes like all of us I also need to talk
> > to people who understand what I am talking about :-).
> >
> > Dimiter
> 
> Well, that's the problem with being a genius ahead of the
> curve; No one understands you .
> 
> (Sorry, couldn't resist :-)...
> 
> Chris

Well, nowadays I am kinda used to it.
(sorry, that was hard to resist, too :D ).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[toc] | [prev] | [next] | [standalone]

#13261

On Wed, 28 Aug 2013 22:46:35 +0200, David Brown
<david.brown@removethis.hesbynett.no> wrote:


>I used to find Eclipse too big, slow and clumsy - but it has improved 
>enormously in the last couple of years.  If it is a while since you last 
>used it, I recommend trying again with the latest version.

Which is still too big, slow and clumsy for what it does.  Eclipse's
major asset is being [relatively] cross platform.  

However - for my taste anyway - there still are too many annoying
differences between the Windows and Linux versions:  same functions
found in different places, dialogs laid out differently, etc.  [never
mind the issues of setting up external tool locations and command
lines].  It's more difficult than I think it should be to go back and
forth between them.

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#13264

On 08/30/13 17:05, George Neuner wrote:

>
> However - for my taste anyway - there still are too many annoying
> differences between the Windows and Linux versions:  same functions
> found in different places, dialogs laid out differently, etc.  [never
> mind the issues of setting up external tool locations and command
> lines].  It's more difficult than I think it should be to go back and
> forth between them.
>
> YMMV,
> George

It does tend towards the bloatware end of the spectrum, looks like it
was designed by committee, all things to all men etc and is complex to
set up, so I don't use it here. I like lightweight tools, ideally separate
functionality and find that editors that come with ide's usually only do
half a job. All I really expect to find is a good editor, compiler and
debug link to hardware. Anything over that is luxury, but really don't
want a load of features and "options" that just add to the noise and
never get used.

Have been having a look at the Insight gui wrapper for gdb in the past
year or so. Slightly unstable in the environment here (Solaris Sparc, but
definately usable. That and ocd provide a complete lightweight toolchain
end to end...

Chris

[toc] | [prev] | [next] | [standalone]

#13220

Roberto Waltman wrote:
>
> What editor would you recommend for code development?
> Looking for something that understands C & C++ syntax, can define
> projects, run external compilations, etc. and has active support.
> My choice would be CodeWrite, (if it was still supported.)


You can still find both SlickEdit and CodeWright. And there is a for-real
version of Brief available.


http://www.softwaremedia.com/embarcadero/codewright/
Dunno about support; I have never made a support call for
a text editor.

http://www.slickedit.com/

http://www.briefeditor.com/

> For some reason never got used to Emacs, and Eclipse is too ginormous
> for my taste.
>
> Alternatives?
>
> Thanks,
> --
> Roberto Waltman
>
> [ Please reply to the group,
>    return address is invalid ]
>

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#13223

Hi Les,

On 8/28/2013 7:22 PM, Les Cargill wrote:

> And there is a for-real version of Brief available.

Do you know if this is based on the original sources (MASM?)
or a "work-alike" (like Crisp  :< )?

[toc] | [prev] | [next] | [standalone]

#13224

Don Y wrote:
> Hi Les,
>
> On 8/28/2013 7:22 PM, Les Cargill wrote:
>
>> And there is a for-real version of Brief available.
>
> Do you know if this is based on the original sources (MASM?)

Brief was written mainly in Brief (macros).

> or a "work-alike" (like Crisp  :< )?
>

"Brief was written from the ground up in 2006 as a Windows application."
http://www.briefeditor.com/faq.htm

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#13226

Hi Les,

On 8/28/2013 8:28 PM, Les Cargill wrote:
> Don Y wrote:
>> On 8/28/2013 7:22 PM, Les Cargill wrote:
>>
>>> And there is a for-real version of Brief available.
>>
>> Do you know if this is based on the original sources (MASM?)
>
> Brief was written mainly in Brief (macros).

I'd have imagined the original Brief was a LISP dialect
interpreter.  E.g., the macros were C-like functions but
with LISP-like syntax.

>> or a "work-alike" (like Crisp  :< )?
>
> "Brief was written from the ground up in 2006 as a Windows application."
> http://www.briefeditor.com/faq.htm

Ah, that is unfortunate.  Not worth the bother exploring, then.  :<

[toc] | [prev] | [next] | [standalone]

#13260

On Wed, 28 Aug 2013 21:22:59 -0500, Les Cargill
<lcargill99@comcast.com> wrote:

>You can still find both SlickEdit and CodeWright. And there is a for-real
>version of Brief available.

Most versions of Codewright will not run on Win 7 or 8 [if that
matters].  However, I haven't tried v7.

George

[toc] | [prev] | [next] | [standalone]

#13302

On 8/30/2013 11:42 AM, George Neuner wrote:
> On Wed, 28 Aug 2013 21:22:59 -0500, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>> You can still find both SlickEdit and CodeWright. And there is a for-real
>> version of Brief available.
>
> Most versions of Codewright will not run on Win 7 or 8 [if that
> matters].  However, I haven't tried v7.
>
> George
>
I've been running Codewright v7.5 on my Win 7 Pro machine for almost 2 
years. Works great and is my everyday editor, primarily for VHDL. I also 
have a syntax coloring file for Xilinx UCF files. I've thought about 
switching to something more modern and made a few weak attempts. But 
Codewright fits like a glove so I continue driving it...

[toc] | [prev] | [next] | [standalone]

#13307

On 9/2/2013 9:20 PM, Paul Urbanus wrote:
> On 8/30/2013 11:42 AM, George Neuner wrote:
>> On Wed, 28 Aug 2013 21:22:59 -0500, Les Cargill
>> <lcargill99@comcast.com> wrote:
>>
>>> You can still find both SlickEdit and CodeWright. And there is a
>>> for-real
>>> version of Brief available.
>>
>> Most versions of Codewright will not run on Win 7 or 8 [if that
>> matters].  However, I haven't tried v7.
>>
>> George
>>
> I've been running Codewright v7.5 on my Win 7 Pro machine for almost 2
> years. Works great and is my everyday editor, primarily for VHDL. I also
> have a syntax coloring file for Xilinx UCF files. I've thought about
> switching to something more modern and made a few weak attempts. But
> Codewright fits like a glove so I continue driving it...

Posting test...please ignore.

[toc] | [prev] | [next] | [standalone]

#13308

Paul Urbanus <urb@urbonix.com> writes:

> On 8/30/2013 11:42 AM, George Neuner wrote:
>> On Wed, 28 Aug 2013 21:22:59 -0500, Les Cargill
>> <lcargill99@comcast.com> wrote:
>>
>>> You can still find both SlickEdit and CodeWright. And there is a for-real
>>> version of Brief available.
>>
>> Most versions of Codewright will not run on Win 7 or 8 [if that
>> matters].  However, I haven't tried v7.
>>
>> George
>>
> I've been running Codewright v7.5 on my Win 7 Pro machine for almost 2
> years. Works great and is my everyday editor, primarily for VHDL. I
> also have a syntax coloring file for Xilinx UCF files. I've thought
> about switching to something more modern and made a few weak attempts.
> But Codewright fits like a glove so I continue driving it...

What if you want to use linux? And you shucked out $300? 
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

[toc] | [prev] | [next] | [standalone]

#13222

Hi Roberto,

On 8/28/2013 1:18 PM, Roberto Waltman wrote:
>
> What editor would you recommend for code development?
> Looking for something that understands C & C++ syntax, can define
> projects, run external compilations, etc. and has active support.

What about VCS support?

> My choice would be CodeWrite, (if it was still supported.)
> For some reason never got used to Emacs, and Eclipse is too ginormous
> for my taste.
>
> Alternatives?

I'm guessing you're working under Windows (re: your CodeWright
reference)?  Is that the *only* place where you develop code?
Or, do you also have to develop/maintain in other environments?

Under DOS (and ancient Win's), Brief was my hands-down favorite.
But, as machines got faster, Brief became unusable (IIRC, Brief
had some keyboard repeat timing loops that didn't hook the system
timer; as a result, you could *touch* a key and end up with
a screenful of that keystroke...).

CodeWright was good under Windows.  But, the GUI doesn't seem to
add much to usefullness (IMO) and can be distracting as your hands
tend to come off the keyboard too easily.

Emacs is comparable under X.  And, *can* be very helpful -- but
really only if you are writing mainstream code (i.e., something
where someone has already created a *robust* "mode").

Currently, I spend more time in simple text editors (no syntax
highlighting, macro support, etc.) because the effort to support a 
*single* editor across different development platforms (and tasks!)
is just too much work (perhaps if you have "support staff" it is
easier?)  I rely on plumbing in the window manager to move stuff
from "window" (session!) to "window" (session).

[It also gets too tedious trying to get fancier tools to coexist
with a variety of different vendor tools -- none of which appear
to have been created with any of the others in mind!  Esp when
everyone wants to make your life *easier* -- and ends up doing the
exact oppopsite!   ("No, I *don't* want all those spaces replaced
with tabs, thankyouverymuch!")]

[toc] | [prev] | [next] | [standalone]

#13225

On 08/28/2013 03:18 PM, Roberto Waltman wrote:
>
> What editor would you recommend for code development?
> Looking for something that understands C & C++ syntax, can define
> projects, run external compilations, etc. and has active support.
> My choice would be CodeWrite, (if it was still supported.)
> For some reason never got used to Emacs, and Eclipse is too ginormous
> for my taste.
>
> Alternatives?
>
> Thanks,
> --
> Roberto Waltman
>
> [ Please reply to the group,
>    return address is invalid ]
>

Try Netbeans.

https://netbeans.org/

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web