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

Groups > linux.debian.user > #186488 > unrolled thread

Re: Suitable text editor [NOT word processor] or workaround?

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Suitable text editor [NOT word processor] or workaround? kamaraju kusumanchi <raju.mailinglists@gmail.com> - 2017-09-06 06:20 +0200
    Re: Suitable text editor [NOT word processor] or workaround? Gene Heskett <gheskett@shentel.net> - 2017-09-06 08:40 +0200
      Re: Suitable text editor [NOT word processor] or workaround? Erik Christiansen <dvalin@internode.on.net> - 2017-09-06 09:20 +0200
        Re: Suitable text editor [NOT word processor] or workaround? <tomas@tuxteam.de> - 2017-09-06 10:30 +0200
        Re: Suitable text editor [NOT word processor] or workaround? Gene Heskett <gheskett@shentel.net> - 2017-09-06 15:10 +0200
          Re: Suitable text editor [NOT word processor] or workaround? kamaraju kusumanchi <raju.mailinglists@gmail.com> - 2017-09-06 18:30 +0200
            Re: Suitable text editor [NOT word processor] or workaround? Gene Heskett <gheskett@shentel.net> - 2017-09-06 20:30 +0200
      Re: Suitable text editor [NOT word processor] or workaround? Dan Ritter <dsr@randomstring.org> - 2017-09-06 16:10 +0200
        Re: Suitable text editor [NOT word processor] or workaround? <tomas@tuxteam.de> - 2017-09-06 16:50 +0200
      OT: Re: Suitable text ed Mike McClain <mike.junk.46@att.net> - 2017-09-07 07:50 +0200
        Re: OT: Re: Suitable text ed Jan-Peter Rühmann <jan-peter@ruehmann.name> - 2017-09-07 09:10 +0200
          Re: OT: Re: Suitable text ed David Wright <deblis@lionunicorn.co.uk> - 2017-09-07 19:30 +0200
            Re: OT: Re: Suitable text ed Gene Heskett <gheskett@shentel.net> - 2017-09-07 20:50 +0200
              Re: OT: Re: Suitable text ed Joe <joe@jretrading.com> - 2017-09-07 21:40 +0200
                Re: OT: Re: Suitable text ed Gene Heskett <gheskett@shentel.net> - 2017-09-08 02:30 +0200
                  Re: OT: Re: Suitable text ed David Wright <deblis@lionunicorn.co.uk> - 2017-09-08 23:50 +0200
              Re: OT: Re: Suitable text ed David Wright <deblis@lionunicorn.co.uk> - 2017-09-07 22:30 +0200
        Re: OT: Re: Suitable text ed Gene Heskett <gheskett@shentel.net> - 2017-09-07 09:20 +0200
    Re: Suitable text editor [NOT word processor] or workaround? deloptes <deloptes@gmail.com> - 2017-09-06 19:40 +0200
      Re: Suitable text editor [NOT word processor] or workaround? Gene Heskett <gheskett@shentel.net> - 2017-09-06 21:10 +0200
        Re: Suitable text editor [NOT word processor] or workaround? deloptes <deloptes@gmail.com> - 2017-09-07 00:00 +0200

Page 1 of 2  [1] 2  Next page →

#186488 — Re: Suitable text editor [NOT word processor] or workaround?

On Fri, Mar 17, 2017 at 7:37 AM, Gene Heskett <gheskett@shentel.net> wrote:
> On Friday 17 March 2017 05:49:30 Jonathan Dowland wrote:
>
>> On Thu, Mar 16, 2017 at 09:54:42AM -0400, Gene Heskett wrote:
>> > gedit has caused me to have to start over again, 3 times, on a 600+
>> > line configuration file for machine control on several occasions. As
>> > the file it trashed was 6 months worth of adding new features to
>> > that machines control, that was not appreciated. 1st time is a wtf?,
>> > 2nd time sends me a message, 3rd time I shut it down w/o the save
>> > and never ran it again.
>>
>> Whilst this is very frustrating, one other thing it tells me is you
>> need to set up a backup system (although you are quite right to
>> abandon gedit based on your experiences)
>
> I do, I am a very longtime user of amanda, since 1998 TBE. I've never
> contaminated my thinking with a windows install, going from a coco3 with
> nitros9, to amigados, to linux at RH-5.0. amanda does all 5 of these
> machines every night at about 1:20 AM and it got used all 3 times. The
> problem with that is that the status of the backup was 15 to 20 hours
> old, so I lost that days work and had to re-invent that particular batch
> of work.


FWIW, I also thought that you lost 6 months of work based on what you
wrote initially. Happy to hear that the damage is much less. But even
that can be very frustrating, right?

Along with the backups, may I suggest you to store all your work in
version control such as git so that even if the editor crashes, you
can recover everything up until the last commit.

-- 
Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog

[toc] | [next] | [standalone]

#186494

On Wednesday 06 September 2017 00:09:31 kamaraju kusumanchi wrote:

> On Fri, Mar 17, 2017 at 7:37 AM, Gene Heskett <gheskett@shentel.net> 
wrote:
> > On Friday 17 March 2017 05:49:30 Jonathan Dowland wrote:
> >> On Thu, Mar 16, 2017 at 09:54:42AM -0400, Gene Heskett wrote:
> >> > gedit has caused me to have to start over again, 3 times, on a
> >> > 600+ line configuration file for machine control on several
> >> > occasions. As the file it trashed was 6 months worth of adding
> >> > new features to that machines control, that was not appreciated.
> >> > 1st time is a wtf?, 2nd time sends me a message, 3rd time I shut
> >> > it down w/o the save and never ran it again.
> >>
> >> Whilst this is very frustrating, one other thing it tells me is you
> >> need to set up a backup system (although you are quite right to
> >> abandon gedit based on your experiences)
> >
> > I do, I am a very longtime user of amanda, since 1998 TBE. I've
> > never contaminated my thinking with a windows install, going from a
> > coco3 with nitros9, to amigados, to linux at RH-5.0. amanda does all
> > 5 of these machines every night at about 1:20 AM and it got used all
> > 3 times. The problem with that is that the status of the backup was
> > 15 to 20 hours old, so I lost that days work and had to re-invent
> > that particular batch of work.
>
> FWIW, I also thought that you lost 6 months of work based on what you
> wrote initially. Happy to hear that the damage is much less. But even
> that can be very frustrating, right?
>
> Along with the backups, may I suggest you to store all your work in
> version control such as git so that even if the editor crashes, you
> can recover everything up until the last commit.

I have considered something along those lines, but mentally I can't seem 
to make the coupling between a single file that has to be ready to go 
anytime I run linuxcnc -l (where the -l says to use the same config it 
used the last time) and a git database that usually has to be compiled 
before its capable of running.  Normally we keep a separate directory 
for each machine configuration, although there may be N parallel 
directories as the configuration is developed. A milling machine may 
start out with 3 axis's of motion, and may have up to 9 degrees of 
movement freedom as accessories such as a rotating table, which may be 
mounted to the xy table with its axis of movement aligned with any of 
the other 3 axis's.  Or the actual cutting spindle may get mounted in 
such a manner as the be tiltable in both directions so it can reach into 
the nooks and crannies.  This is generally geared together 
electronically so that the cutting tool is motionless on the workpiece 
as it tilts unless you specifically drive it otherwise. This of course 
requires very carefull tool length calibrations to pull off well, but 
the math to sub-micron accuracy is already modularized.

The total configuration generally is not a single file, usually broken up 
according to its order in the programs bootup, first being the basic 
config, then the first of what could be 2 or 3 .hal files, some of which 
can't be run until the gui is started, then once the gui is drawn, more 
gui for accessory tally's, spindle speed/direction, and dials to replace 
the cranks that no longer exist, usually written in xml or pyvcp, or 
gladevcp is done, which adds the "hal pins" that connect the machine gui 
to the machine. It can get complex.  This most recent lathe has over 
1200 lines of code just in the configuration files.  And I still do not 
have any coolant or lube facilities under control.  Stuff I have yet to 
build or buy. :)



Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#186495

On 06.09.17 02:31, Gene Heskett wrote:
> On Wednesday 06 September 2017 00:09:31 kamaraju kusumanchi wrote:
> 
> The total configuration generally is not a single file, usually broken up 
> according to its order in the programs bootup, first being the basic 
> config, then the first of what could be 2 or 3 .hal files, some of which 
> can't be run until the gui is started, then once the gui is drawn, more 
> gui for accessory tally's, spindle speed/direction, and dials to replace 
> the cranks that no longer exist, usually written in xml or pyvcp, or 
> gladevcp is done, which adds the "hal pins" that connect the machine gui 
> to the machine. It can get complex.  This most recent lathe has over 
> 1200 lines of code just in the configuration files.  And I still do not 
> have any coolant or lube facilities under control.  Stuff I have yet to 
> build or buy. :)

Gene, a version control utility allows you to commit a complete
directory tree of as many config files as you wish, organised as
desired. If we imagine them as source files not requiring compilation
prior to use, then the versioning config repository is not so foreign.

Having used cvs for decades, I am one of the dinosaurs still using it
despite many more modern offerings having replaced it. It can be a pig
if you mistreat it, and subversion is supposed to be better, Git has
followers and detractors. Then there's mercury. I've used the latter two
only very superficially. There'll be more users to advise on these more
current offerings.

A VCS only allows you to retrieve versions which have been checked in,
but that might help if it encourages you to do that immediately at the
end of an editing session, rather than exposing the edits to data loss
during the hours before a midnight backup. And a pre-lunch commit
minimises loss to half a day.

But a simple scp or rsync snapshot to another host might be a quick
stopgap?

Erik

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

#186499

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Sep 06, 2017 at 05:12:36PM +1000, Erik Christiansen wrote:

[...]

> A VCS only allows you to retrieve versions which have been checked in,
> but that might help if it encourages you to do that immediately at the
> end of an editing session, rather than exposing the edits to data loss

[...]

What is't mentioned often (perhaps because those not using VCS have no
notion of it and those accustomed to don't realize because it has
become second nature) is that a VCS nudges you to attach some mumblings
to each commit ("disabled $foo after $script bit my small toe off").

Whenever you feel a bit disoriented about "where you are", this log
of mumblings is gold.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmvsHsACgkQBcgs9XrR2kYNFQCdFvidBPHa/3GoIxFvmQFMYka+
538AnRLXt1U8Bua4g4fsTclVzrR8nGCV
=a0/K
-----END PGP SIGNATURE-----

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

#186510

On Wednesday 06 September 2017 03:12:36 Erik Christiansen wrote:

> On 06.09.17 02:31, Gene Heskett wrote:
> > On Wednesday 06 September 2017 00:09:31 kamaraju kusumanchi wrote:
> >
> > The total configuration generally is not a single file, usually
> > broken up according to its order in the programs bootup, first being
> > the basic config, then the first of what could be 2 or 3 .hal files,
> > some of which can't be run until the gui is started, then once the
> > gui is drawn, more gui for accessory tally's, spindle
> > speed/direction, and dials to replace the cranks that no longer
> > exist, usually written in xml or pyvcp, or gladevcp is done, which
> > adds the "hal pins" that connect the machine gui to the machine. It
> > can get complex.  This most recent lathe has over 1200 lines of code
> > just in the configuration files.  And I still do not have any
> > coolant or lube facilities under control.  Stuff I have yet to build
> > or buy. :)
>
> Gene, a version control utility allows you to commit a complete
> directory tree of as many config files as you wish, organised as
> desired. If we imagine them as source files not requiring compilation
> prior to use, then the versioning config repository is not so foreign.
>
> Having used cvs for decades, I am one of the dinosaurs still using it
> despite many more modern offerings having replaced it. It can be a pig
> if you mistreat it, and subversion is supposed to be better, Git has
> followers and detractors. Then there's mercury. I've used the latter
> two only very superficially. There'll be more users to advise on these
> more current offerings.
>
> A VCS only allows you to retrieve versions which have been checked in,
> but that might help if it encourages you to do that immediately at the
> end of an editing session, rather than exposing the edits to data loss
> during the hours before a midnight backup. And a pre-lunch commit
> minimises loss to half a day.
>
> But a simple scp or rsync snapshot to another host might be a quick
> stopgap?
>
> Erik

When I am finished with a particular edit, it gets saved on the spot, and 
a test run made immediately so I can fix my inevitable typu's.  The 
session is resaved after the typu is fixed, and if that runs ok, then 
the editor is closed, usually w/o a final save.  The save is 
my "commit".  The close is generally when the added function I was 
working on, works as I had it in mind to work. If that function is to be 
copy/pasted to another axis, a fresh editing session will be started. I 
don't generally add more than 10 to 50 LOC in any one session.

To that copy/paste end, there is one function that could be added to a 
good code editor, which may in fact exist but I've not found it yet.

The ability to edit the copy buffer in a different tab, doing a buffer 
wide edit to change the axis references in the buffer, so that those 
edits are done and stand a chance of being correct when the main buffer 
has been scrolled to the point where the just edited buffer is to be 
pasted back into the main file.

If such an editor exists, I'll take it for a walk. But editors that 
require more than 2 fingers to accomplish the copy/paste need not apply.  
Same for editors whose fonts are stick figures one pixel wide and can't 
be changed to something like "hack, bold".

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#186518

On Wed, Sep 6, 2017 at 9:01 AM, Gene Heskett <gheskett@shentel.net> wrote:
>
> The ability to edit the copy buffer in a different tab, doing a buffer
> wide edit to change the axis references in the buffer, so that those
> edits are done and stand a chance of being correct when the main buffer
> has been scrolled to the point where the just edited buffer is to be
> pasted back into the main file.
>
> If such an editor exists, I'll take it for a walk. But editors that
> require more than 2 fingers to accomplish the copy/paste need not apply.
> Same for editors whose fonts are stick figures one pixel wide and can't
> be changed to something like "hack, bold".

If I understand your workflow correctly, you might find the NrrwRgn
plugin[1] for vim very useful.

Say you have a very long file and would like to edit just 2-3
paragraphs in it but keep the rest of the file untouched. You can open
the file in vim, visually select the paragraphs to be edited (by V)
and  then press :nr . This will open a new buffer with the selected
lines. Once you make all the edits in the new buffer -> save -> close,
the changes will automatically be integrated into the original file.
You can then review the changes and save the original file.

[1] Stable version of the plugin can be downloaded from
https://vim.sourceforge.io/scripts/script.php?script_id=3075

-- 
Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog

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

#186528

On Wednesday 06 September 2017 12:27:37 kamaraju kusumanchi wrote:

> On Wed, Sep 6, 2017 at 9:01 AM, Gene Heskett <gheskett@shentel.net> 
wrote:
> > The ability to edit the copy buffer in a different tab, doing a
> > buffer wide edit to change the axis references in the buffer, so
> > that those edits are done and stand a chance of being correct when
> > the main buffer has been scrolled to the point where the just edited
> > buffer is to be pasted back into the main file.
> >
> > If such an editor exists, I'll take it for a walk. But editors that
> > require more than 2 fingers to accomplish the copy/paste need not
> > apply. Same for editors whose fonts are stick figures one pixel wide
> > and can't be changed to something like "hack, bold".
>
> If I understand your workflow correctly, you might find the NrrwRgn
> plugin[1] for vim very useful.
>
> Say you have a very long file and would like to edit just 2-3
> paragraphs in it but keep the rest of the file untouched. You can open
> the file in vim, visually select the paragraphs to be edited (by V)
> and  then press :nr . This will open a new buffer with the selected
> lines. Once you make all the edits in the new buffer -> save -> close,
> the changes will automatically be integrated into the original file.
> You can then review the changes and save the original file.
>
> [1] Stable version of the plugin can be downloaded from
> https://vim.sourceforge.io/scripts/script.php?script_id=3075

Not exactly what I was describing.  Yes, I'd like to visually select 
those lines to be buffered/edited out of a much bigger file, but after 
the editing, allow me to select, without any effect of the previously 
selected source lines, a new place in the file to insert the edited 
buffer into.  So one could snip out a piece of code that refers to axis 
X, edit it to do the exact same thing for axis Y, and then re-insert it 
into the section of the main file in the same order but in the Y section 
to have Y behave as X, but with independent actions from X.  Such things 
as accelerations and such, subject to the same rules but affecting a 
different axis's motions.

Two basic ways to move a machine, one by servo motors which require a 
feedback to tell if the motion commanded is being done at the dynamic 
accuracy required, the other by stepper motors which dispense with the 
feedback from the motor, but depend on the motor doing precisely what it 
was told to do.  This costs less, but has limits to the start and stop 
acceleration profiles.  This means they need to have those profiles set 
so as to not exceed the motors ability to do it.  Within those limits, 
one is as accurate as the other, or can be made so by suitable gear 
ratios. The problem with steppers is how fast the drive currents thru 
the coils can be changed when the inductance of the coil enters into the 
picture.  Well tuned servo's can move several meters a second, 
developing good torque at 3 thousand rpms, but steppers are dragging 
their tongues on the floor and out of usable torque as low as 10 inches 
a minute or 150 rpms.  Only by going to very high voltages, with chopper 
regulated coil currents, can some of this be overcome. With that chopper 
regulated current comes noise, both acoustical and electrically 
radiated.  Noise enough to blow 3.3 volt control circuitry all to hell.

All of which has nothing to do with editors, just intended as background 
for some of the problems that have to be solved.  My choice of editor is 
one that doesn't play mixmaster with my code on the save. Gedit fails 
that test rather miserably and will do it in less than 100 edit 
sessions. At which point the whole file looks like a kitchenaide or 
mix-master was left to churn the files contents for several hours.  
Sometimes its salvageable with several more hours work, more often you 
are best calling up amrecover to at least get back what you had at 
shutdown last night. Then go looking for a different editor that does 
not destroy your days work.  geany hasn't (yet).

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#186512

On Wed, Sep 06, 2017 at 02:31:08AM -0400, Gene Heskett wrote:
> On Wednesday 06 September 2017 00:09:31 kamaraju kusumanchi wrote:
> 
> > On Fri, Mar 17, 2017 at 7:37 AM, Gene Heskett <gheskett@shentel.net> 
> wrote:
> > > On Friday 17 March 2017 05:49:30 Jonathan Dowland wrote:
> > >> On Thu, Mar 16, 2017 at 09:54:42AM -0400, Gene Heskett wrote:

> > > 3 times. The problem with that is that the status of the backup was
> > > 15 to 20 hours old, so I lost that days work and had to re-invent
> > > that particular batch of work.
> >
> > FWIW, I also thought that you lost 6 months of work based on what you
> > wrote initially. Happy to hear that the damage is much less. But even
> > that can be very frustrating, right?
> >
> > Along with the backups, may I suggest you to store all your work in
> > version control such as git so that even if the editor crashes, you
> > can recover everything up until the last commit.
> 
> I have considered something along those lines, but mentally I can't seem 
> to make the coupling between a single file that has to be ready to go 
> anytime I run linuxcnc -l (where the -l says to use the same config it 
> used the last time) and a git database that usually has to be compiled 
> before its capable of running.  Normally we keep a separate directory 
> for each machine configuration, although there may be N parallel 
> directories as the configuration is developed. 

So it looks like:

/cncmaster/cnc-machine-A-20150603.1/configfile
/cncmaster/cnc-machine-A-20150603.2/configfile
/cncmaster/cnc-machine-A-20150605.1/configfile
/cncmaster/cnc-machine-A-20150608.1/configfile
/cncmaster/cnc-machine-A-20150803.1/configfile
/cncmaster/cnc-machine-A-20150803.2/configfile
/cncmaster/cnc-machine-B-20150603.1/configfile
/cncmaster/cnc-machine-B-20150805.1/configfile
/cncmaster/cnc-machine-B-20150805.2/configfile

or something similar?

This is a perfect case for git (which does not require any
compilation).

Right now your workflow is, basically:

mkdir /cncmaster/cnc-machine-A-20170809.1
cp /cncmaster/cnc-machine-A-20150608.1/configfile \
   /cncmaster/cnc-machine-A-20170809.1/
edit /cncmaster/cnc-machine-A-20170809.1/configfile
linuxcnc /cncmaster/cnc-machine-A-20170809.1/configfile

....wait....
.... inspect ....
..... sigh .....
edit /cncmaster/cnc-machine-A-20170809.1/configfile

and loop until you get it right?

Replace all that file and directory management with git.

edit /cncmaster/cnc-machine-A/config
git commit /cncmaster/cnc-machine-A/config 
linuxcnc /cncmaster/cnc-machine-A/config

and when you want to go back to a previous version you can
either get a diff to apply or pull the old version out directly.

Subversion (SVN) would also work well instead of git, here.
git is more powerful, but not necessarily in a compelling way
for you.

-dsr-

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

#186513

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Sep 06, 2017 at 10:02:45AM -0400, Dan Ritter wrote:

[...]

> Replace all that file and directory management with git.
> 
> edit /cncmaster/cnc-machine-A/config
> git commit /cncmaster/cnc-machine-A/config 

To harp on my previous post:

  git commit -am "Loosened the all-too tight path with the 3/8 gremlin tool"

> linuxcnc /cncmaster/cnc-machine-A/config
> 
> and when you want to go back to a previous version you can
> either get a diff to apply or pull the old version out directly.
> 
> Subversion (SVN) would also work well instead of git, here.
> git is more powerful, but not necessarily in a compelling way
> for you.

Oh, yes: no connectivity to server needed (a feature it shares
with hg, bazaar, darcs and some others).

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmwCfIACgkQBcgs9XrR2kbxDgCfdQvx9a1znyWkVniexTV6vF/7
cKwAniZ6MzeNBfi1yVUcVlmiaQGnzi4c
=4Ol5
-----END PGP SIGNATURE-----

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

#186545 — OT: Re: Suitable text ed

On Wed, Sep 06, 2017 at 02:31:08AM -0400, Gene Heskett wrote:
>
> The total configuration generally is not a single file, usually broken up
> according to its order in the programs bootup, first being the basic
> config, then the first of what could be 2 or 3 .hal files, some of which
> can't be run until the gui is started, then once the gui is drawn, more
> gui for accessory tally's, spindle speed/direction, and dials to replace
> the cranks that no longer exist, usually written in xml or pyvcp, or
> gladevcp is done, which adds the "hal pins" that connect the machine gui
> to the machine. It can get complex.  This most recent lathe has over
> 1200 lines of code just in the configuration files.  And I still do not
> have any coolant or lube facilities under control.  Stuff I have yet to
> build or buy. :)

Damn, that sounds like fun.
Mike
--
Go to heaven for the climate, hell for the company.
    - Mark Twain

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

#186547 — Re: OT: Re: Suitable text ed

Hello

Am 07.09.2017 um 07:50 schrieb Mike McClain:
> On Wed, Sep 06, 2017 at 02:31:08AM -0400, Gene Heskett wrote:
>>
>> The total configuration generally is not a single file, usually broken up
>> according to its order in the programs bootup, first being the basic
>> config, then the first of what could be 2 or 3 .hal files, some of which
>> can't be run until the gui is started, then once the gui is drawn, more
>> gui for accessory tally's, spindle speed/direction, and dials to replace
>> the cranks that no longer exist, usually written in xml or pyvcp, or
>> gladevcp is done, which adds the "hal pins" that connect the machine gui
>> to the machine. It can get complex.  This most recent lathe has over
>> 1200 lines of code just in the configuration files.  And I still do not
>> have any coolant or lube facilities under control.  Stuff I have yet to
>> build or buy. :)
> 
> Damn, that sounds like fun.
> Mike
> --
> Go to heaven for the climate, hell for the company.
>     - Mark Twain
> 
I prefer vi on the Console and Atom in the UI.
before I found Atom I loved Kate very much and I still like mcedit in the Console and via ssh.

Good Luck,
-- 
<pre>
-=============================== Jan-Peter Rühmann & Kuma ===============================-
 Gubkower Str.7       [ Tel.:  +49 (38205) 65484 (Privat) ] Mail: jan-Peter@ruehmann.name
 18195 Cammin         [ Tel.:  +49 (38205) 65215 (Firma)  ] Web: http://www.ruehmann.name
 Deutschland          [ FAX:   +49 (38205) 65212          ]
                      [ Mobil: +49 (162) 1316054          ] Beruf:    IT-Servicetechniker
 ICQ: 288192920     Ring: JPRuehmann      WhatsApp: 491621316054     Twitter: @JPRuehmann
-========================================================================================-
                  Die Verwendung der Daten zu Werbezwecken ist verboten.
</pre>
--

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

#186575 — Re: OT: Re: Suitable text ed

On Thu 07 Sep 2017 at 08:42:54 (+0200), Jan-Peter Rühmann wrote:
> Hello
> 
> Am 07.09.2017 um 07:50 schrieb Mike McClain:
> > On Wed, Sep 06, 2017 at 02:31:08AM -0400, Gene Heskett wrote:
> >>
> >> The total configuration generally is not a single file, usually broken up
> >> according to its order in the programs bootup, first being the basic
> >> config, then the first of what could be 2 or 3 .hal files, some of which
> >> can't be run until the gui is started, then once the gui is drawn, more
> >> gui for accessory tally's, spindle speed/direction, and dials to replace
> >> the cranks that no longer exist, usually written in xml or pyvcp, or
> >> gladevcp is done, which adds the "hal pins" that connect the machine gui
> >> to the machine. It can get complex.  This most recent lathe has over
> >> 1200 lines of code just in the configuration files.  And I still do not
> >> have any coolant or lube facilities under control.  Stuff I have yet to
> >> build or buy. :)
> > 
> > Damn, that sounds like fun.
> > Mike
> > --
> > Go to heaven for the climate, hell for the company.
> >     - Mark Twain
> > 
> I prefer vi on the Console and Atom in the UI.
> before I found Atom I loved Kate very much and I still like mcedit in the Console and via ssh.

I didn't know you could edit files side by side in mcedit.
(I take it we're talking MidnightCommander rather than Minecraft.)

Cheers,
David.

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

#186579 — Re: OT: Re: Suitable text ed

On Thursday 07 September 2017 13:26:13 David Wright wrote:

> On Thu 07 Sep 2017 at 08:42:54 (+0200), Jan-Peter Rühmann wrote:
> > Hello
> >
> > Am 07.09.2017 um 07:50 schrieb Mike McClain:
> > > On Wed, Sep 06, 2017 at 02:31:08AM -0400, Gene Heskett wrote:
> > >> The total configuration generally is not a single file, usually
> > >> broken up according to its order in the programs bootup, first
> > >> being the basic config, then the first of what could be 2 or 3
> > >> .hal files, some of which can't be run until the gui is started,
> > >> then once the gui is drawn, more gui for accessory tally's,
> > >> spindle speed/direction, and dials to replace the cranks that no
> > >> longer exist, usually written in xml or pyvcp, or gladevcp is
> > >> done, which adds the "hal pins" that connect the machine gui to
> > >> the machine. It can get complex.  This most recent lathe has over
> > >> 1200 lines of code just in the configuration files.  And I still
> > >> do not have any coolant or lube facilities under control.  Stuff
> > >> I have yet to build or buy. :)
> > >
> > > Damn, that sounds like fun.
> > > Mike
> > > --
> > > Go to heaven for the climate, hell for the company.
> > >     - Mark Twain
> >
> > I prefer vi on the Console and Atom in the UI.
> > before I found Atom I loved Kate very much and I still like mcedit
> > in the Console and via ssh.
>
> I didn't know you could edit files side by side in mcedit.
> (I take it we're talking MidnightCommander rather than Minecraft.)
>
> Cheers,
> David.

Neither did I, but then it seems to be a coin toss as to whether mc calls 
nano, or uses its own editor. Something controls it, but I haven't 
sussed what. Two side by side sessions on a high res screen would be 
handy, like awesome.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#186582 — Re: OT: Re: Suitable text ed

On Thu, 7 Sep 2017 14:40:22 -0400
Gene Heskett <gheskett@shentel.net> wrote:


> 
> Neither did I, but then it seems to be a coin toss as to whether mc
> calls nano, or uses its own editor. Something controls it, but I
> haven't sussed what. 

Options -> Configuration.. use internal edit  X

-- 
Joe

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

#186596 — Re: OT: Re: Suitable text ed

On Thursday 07 September 2017 15:38:24 Joe wrote:

> On Thu, 7 Sep 2017 14:40:22 -0400
>
> Gene Heskett <gheskett@shentel.net> wrote:
> > Neither did I, but then it seems to be a coin toss as to whether mc
> > calls nano, or uses its own editor. Something controls it, but I
> > haven't sussed what.
>
> Options -> Configuration.. use internal edit  X.

Thanks.  Turned out the diff was as me, or as root

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#186618 — Re: OT: Re: Suitable text ed

On Thu 07 Sep 2017 at 20:25:23 (-0400), Gene Heskett wrote:
> On Thursday 07 September 2017 15:38:24 Joe wrote:
> > On Thu, 7 Sep 2017 14:40:22 -0400 Gene Heskett <gheskett@shentel.net> wrote:
> > > Neither did I, but then it seems to be a coin toss as to whether mc
> > > calls nano, or uses its own editor. Something controls it, but I
> > > haven't sussed what.
> >
> > Options -> Configuration.. use internal edit  X.
> 
> Thanks.  Turned out the diff was as me, or as root

Fair enough. That probably wouldn't cross my mind as there are
programs I never use as root; amongst them, mc, emacs, browsers,
and X itself of course.

Cheers,
David.

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

#186585 — Re: OT: Re: Suitable text ed

On Thu 07 Sep 2017 at 14:40:22 (-0400), Gene Heskett wrote:
> On Thursday 07 September 2017 13:26:13 David Wright wrote:
> > On Thu 07 Sep 2017 at 08:42:54 (+0200), Jan-Peter Rühmann wrote:
> > >
> > > I prefer vi on the Console and Atom in the UI.
> > > before I found Atom I loved Kate very much and I still like mcedit
> > > in the Console and via ssh.
> >
> > I didn't know you could edit files side by side in mcedit.
> > (I take it we're talking MidnightCommander rather than Minecraft.)
> 
> Neither did I, but then it seems to be a coin toss as to whether mc calls 
> nano, or uses its own editor. Something controls it, but I haven't 
> sussed what. Two side by side sessions on a high res screen would be 
> handy, like awesome.

I don't use the internal editor as it buys me nothing, so I have

  use_internal_edit=0

in my ini file (~/.config/mc/ini) and

  include/editor
      Open=%var{EDITOR:less} %f

at the top of the extension file (~/.config/mc/mc.ext). In
addition, I have   EDITOR=less PAGER=less   set in bash's
invocation function.

I do use the internal viewer, so for a text file, my user-
definable keys are set to view ascii (F3), view hex (F4)
and view the output of file command (Return).

(All my files above are actually links for supporting
different Debian versions.)

Cheers,
David.

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

#186548 — Re: OT: Re: Suitable text ed

On Wednesday 06 September 2017 18:14:56 Mike McClain wrote:

> On Wed, Sep 06, 2017 at 02:31:08AM -0400, Gene Heskett wrote:
> > The total configuration generally is not a single file, usually
> > broken up according to its order in the programs bootup, first being
> > the basic config, then the first of what could be 2 or 3 .hal files,
> > some of which can't be run until the gui is started, then once the
> > gui is drawn, more gui for accessory tally's, spindle
> > speed/direction, and dials to replace the cranks that no longer
> > exist, usually written in xml or pyvcp, or gladevcp is done, which
> > adds the "hal pins" that connect the machine gui to the machine. It
> > can get complex.  This most recent lathe has over 1200 lines of code
> > just in the configuration files.  And I still do not have any
> > coolant or lube facilities under control.  Stuff I have yet to build
> > or buy. :)
>
> Damn, that sounds like fun.

And when it all works, the grin reaches your ears. :)  One of the 
problems in cnc'ing a lathe is that its not possible to mount a switch 
at the zero radius or diameter point, there's nothing there but air.  So 
you make a cut, then run the tool away in the z axis, measure the cut, 
and then tell to software how big the x cut is as measured with the 
highest accuracy measuring tool in the drawer. And that calibration is 
only good for THAT cutting tool since each one is a different length or 
width.  There are ways to measure and set that of course, as long as the 
tool holder isn't moved on the carriage. Turn it 5 degrees to get a 
cleaner cut and the tool table might as well be straight out of urandom 
since that 5 degrees is moving the tool tip in an arc,

Generally, the home switches on a lathe are to establish the work 
envelope only, stopping you from carving up the chuck jaws if you get 
too close.  So I normally write gcode so z is touched off at 0.0000 at 
the end of the workpiece.  Then I can make a dozen identical bolts by 
sliding the workpiece out until its resting on the tool, tighten the 
chuck, touch Z off to 0.000, and hit r on the keyboard. 4 minutes and 3 
toolchanges later another nice shiny brass 8mmx1mm pitch bolt with a 
1/2" hex head falls into the chip tray.  Sure I can buy them online for 
less, but they are also 2 to 3 weeks away, and a heck of a lot poorer 
fit.

> Mike
> --
> Go to heaven for the climate, hell for the company.
>     - Mark Twain


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#186525

kamaraju kusumanchi wrote:

> FWIW, I also thought that you lost 6 months of work based on what you
> wrote initially. Happy to hear that the damage is much less. But even
> that can be very frustrating, right?
> 
> Along with the backups, may I suggest you to store all your work in
> version control such as git so that even if the editor crashes, you
> can recover everything up until the last commit.

I use "ne" which luckily is part of the debian package repo. Great for work
in console.

For the GUI ... well we stayed with KDE3 on purpose - kate is great.

I had same experience with GTK gedit & friends 14y ago ... since then I
don't want to hear about gnome or whatever alike ... but well, there are
allways exceptions - like gimp.

regards

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

#186532

On Wednesday 06 September 2017 13:39:01 deloptes wrote:

> kamaraju kusumanchi wrote:
> > FWIW, I also thought that you lost 6 months of work based on what
> > you wrote initially. Happy to hear that the damage is much less. But
> > even that can be very frustrating, right?
> >
> > Along with the backups, may I suggest you to store all your work in
> > version control such as git so that even if the editor crashes, you
> > can recover everything up until the last commit.
>
> I use "ne" which luckily is part of the debian package repo. Great for
> work in console.
>
> For the GUI ... well we stayed with KDE3 on purpose - kate is great.
>
I gave up on the kde breakage that never gets fixed by kde, and on this 
boxen, and one of my more well-endowed cnc boxes its TDE r14.0.0.x all 
the way down, so I am still running kmail 1.9, its had at least 99% of 
all the kde bugs swatted.  Its a fork of kde 3.5.

> I had same experience with GTK gedit & friends 14y ago ... since then
> I don't want to hear about gnome or whatever alike ... but well, there
> are allways exceptions - like gimp.

Which changes fast enough I have to learn it all over again everytime I 
need to use it.  Like adding captions and arrows, last upgrade uses a 1 
pt font for text and I had a heck of a time blowing it up to a usable 
size. I think there is an excedrin headache number for that. Has to 
be... :)

> regards

Thanks kamaraju kusumanchi.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web