This is probably somewhat related to the MS repo stuff but I thought I'dpi/
pass it along for interested parties: https://betanews.com/2021/02/12/microsoft-visual-studio-code-raspberry-
On Fri, 12 Feb 2021 13:36:50 -0600, TCW wrote:
This is probably somewhat related to the MS repo stuff but I thought I'dpi/
pass it along for interested parties:
https://betanews.com/2021/02/12/microsoft-visual-studio-code-raspberry-
This has pretty much been done to death: those who don't want it have probably installed it already while those who don't will have made sure
the M$ repo isn't in their sources.list because apparently lookups are
slow.
So, why have you brought it up again?
On 12/02/2021 20:19, Martin Gregorie wrote:
On Fri, 12 Feb 2021 13:36:50 -0600, TCW wrote:
This is probably somewhat related to the MS repo stuff but Ipi/
thought I'd pass it along for interested parties:
https://betanews.com/2021/02/12/microsoft-visual-studio-code-raspberry-
This has pretty much been done to death: those who don't want it
have probably installed it already while those who don't will have
made sure the M$ repo isn't in their sources.list because
apparently lookups are slow.
So, why have you brought it up again?
I think the guy is talking about the VSCode, a code editor/light
weight ide.
I have used it a little to develop code for the rpi, it looks
promising. However I develop on the PC and run the produced code on a headless rpi, as opposed to running VSCode native on a rpi desktop.
Yes, I wondered why anyone would actually write code on an RPi. Anyone
who really wants to use VS rather than, say, emacs, will surely want to
use the real thing on its native Windows, and cross-compile.
The Pi4 is now fairly powerful, but that's in comparison to phones and earlier Pis, not compared to a recent workstation or expensive laptop.
I think the guy is talking about the VSCode, a code editor/light
weight ide.
I have used it a little to develop code for the rpi, it looks
promising. However I develop on the PC and run the produced code on a
headless rpi, as opposed to running VSCode native on a rpi desktop.
Yes, I wondered why anyone would actually write code on an RPi. Anyone
who really wants to use VS rather than, say, emacs, will surely want to
use the real thing on its native Windows, and cross-compile.
On Sat, 13 Feb 2021 08:49:33 +0000
Joe <joe@jretrading.com> wrote:
Yes, I wondered why anyone would actually write code on an RPi. Anyone
who really wants to use VS rather than, say, emacs, will surely want to
use the real thing on its native Windows, and cross-compile.
The Pi4 is now fairly powerful, but that's in comparison to phones and
earlier Pis, not compared to a recent workstation or expensive laptop.
Compared to most of the machines I've developed software on the Pi4
is a supercomputer! It makes the finest workstation ever produced by Sun, Apollo or even SGI look like a toy. It is a sad testimony to bloat that you find it inadequate to run an IDE.
On 13/02/2021 09:57, Ahem A Rivet's Shot wrote:
On Sat, 13 Feb 2021 08:49:33 +0000
Joe <joe@jretrading.com> wrote:
Yes, I wondered why anyone would actually write code on an RPi. Anyone
who really wants to use VS rather than, say, emacs, will surely want to
use the real thing on its native Windows, and cross-compile.
The Pi4 is now fairly powerful, but that's in comparison to phones and
earlier Pis, not compared to a recent workstation or expensive laptop.
Compared to most of the machines I've developed software on the
Pi4 is a supercomputer! It makes the finest workstation ever produced
by Sun, Apollo or even SGI look like a toy. It is a sad testimony to
bloat that you find it inadequate to run an IDE.
VSCode, I would not run on a slow Pi with limited memory.
Unless it's a small project.
On Sat, 13 Feb 2021 08:49:33 +0000
Joe <joe@jretrading.com> wrote:
Yes, I wondered why anyone would actually write code on an RPi.
Anyone who really wants to use VS rather than, say, emacs, will
surely want to use the real thing on its native Windows, and
cross-compile.
The Pi4 is now fairly powerful, but that's in comparison to phones
and earlier Pis, not compared to a recent workstation or expensive
laptop.
Compared to most of the machines I've developed software on
the Pi4 is a supercomputer! It makes the finest workstation ever
produced by Sun, Apollo or even SGI look like a toy.
It is a sad
testimony to bloat that you find it inadequate to run an IDE.
You can get 8GB on a Pi4, if that's not enough then it's a very sad testimonial to bloat - some of the workstations we all used to lust after
had as much as a thousandth of that much memory.
Joe in data 13/2/2021 09:49 ha scritto:
Yes, I wondered why anyone would actually write code on an RPi. Anyone
who really wants to use VS rather than, say, emacs, will surely want to
use the real thing on its native Windows, and cross-compile.
VS Code is Electron based, so I'm not so sure we can define it
native on Windows.
On 13/02/2021 11:17, Joe wrote:
Not that I've done any ARM coding for more than forty years.
ARM is only about 30 years old?
On Sat, 13 Feb 2021 09:57:25 +0000
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Sat, 13 Feb 2021 08:49:33 +0000
Joe <joe@jretrading.com> wrote:
Yes, I wondered why anyone would actually write code on an RPi.
Anyone who really wants to use VS rather than, say, emacs, will
surely want to use the real thing on its native Windows, and
cross-compile.
The Pi4 is now fairly powerful, but that's in comparison to phones
and earlier Pis, not compared to a recent workstation or expensive
laptop.
Compared to most of the machines I've developed software on
the Pi4 is a supercomputer! It makes the finest workstation ever
produced by Sun, Apollo or even SGI look like a toy.
It is a sad
testimony to bloat that you find it inadequate to run an IDE.
I didn't say that. Given a choice of development environments, I would
not expect the PI, even a 4, to be preferred.
Not that I've done any ARM coding for more than forty years.
Not that I've done any ARM coding for more than forty years.
ARM is only about 30 years old?
On Sat, 13 Feb 2021 12:29:11 +0000
Pancho <Pancho.Dontmaileme@outlook.com> wrote:
Not that I've done any ARM coding for more than forty years.
ARM is only about 30 years old?
Sorry, yes, it was 32 years ago. Memory failing...
On 13/02/2021 13:39, Joe wrote:
On Sat, 13 Feb 2021 12:29:11 +0000
Pancho <Pancho.Dontmaileme@outlook.com> wrote:
Not that I've done any ARM coding for more than forty years.
ARM is only about 30 years old?
Sorry, yes, it was 32 years ago. Memory failing...
It's ok, as long as you don't tell me you had an Archimedes. Even 32
years on the jealousy is still real and I would have to hate you.
It's ok, as long as you don't tell me you had an Archimedes. Even 32
years on the jealousy is still real and I would have to hate you.
On 13/02/2021 13:39, Joe wrote:
On Sat, 13 Feb 2021 12:29:11 +0000 Pancho
<Pancho.Dontmaileme@outlook.com> wrote:
Not that I've done any ARM coding for more than forty years.
ARM is only about 30 years old?
Sorry, yes, it was 32 years ago. Memory failing...
It's ok, as long as you don't tell me you had an Archimedes. Even 32
years on the jealousy is still real and I would have to hate you.
This build is just over a month old,
which reminds me it's time I updated it again.
VSCode, I would not run on a slow Pi with limited memory.
Unless it's a small project.
You can get 8GB on a Pi4,
testimonial to bloat - some of the workstations we all used to lust after
had as much as a thousandth of that much memory.
VSCode, I would not run on a slow Pi with limited memory.
Unless it's a small project.
You can get 8GB on a Pi4, if that's not enough then it's a very sad testimonial to bloat - some of the workstations we all used to lust after
had as much as a thousandth of that much memory.
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
You can get 8GB on a Pi4, if that's not enough then it's a very sad >> testimonial to bloat - some of the workstations we all used to lust after
had as much as a thousandth of that much memory.
EMACS: 'Eight Megs And Constantly Swapping' was once the byword for bloat. Looks like there is a new pretender to the crown.
Anyone have any recommendations for modern open-source GUI editors that *don't* use Electron as a framework? I've been trying out Onivim but interested in others.
On 13/02/2021 13:39, Joe wrote:
On Sat, 13 Feb 2021 12:29:11 +0000
Pancho <Pancho.Dontmaileme@outlook.com> wrote:
Not that I've done any ARM coding for more than forty years.
ARM is only about 30 years old?
Sorry, yes, it was 32 years ago. Memory failing...
It's ok, as long as you don't tell me you had an Archimedes. Even 32
years on the jealousy is still real and I would have to hate you.
On 2021-02-13, Theo <theom+news@chiark.greenend.org.uk> wrote:
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
You can get 8GB on a Pi4, if that's not enough then it's a very sad
testimonial to bloat - some of the workstations we all used to lust after >> had as much as a thousandth of that much memory.
EMACS: 'Eight Megs And Constantly Swapping' was once the byword for bloat. Looks like there is a new pretender to the crown.
Anyone have any recommendations for modern open-source GUI editors that *don't* use Electron as a framework? I've been trying out Onivim but interested in others.
Emacs is now a gui editor!
On 13/02/2021 10:38, Ahem A Rivet's Shot wrote:
if that's not enough then it's a very sad
testimonial to bloat - some of the workstations we all used to lust
after had as much as a thousandth of that much memory.
True. Think though the safest minimum now is to have some sort of source control system while ye are hacking, or continuous backup and some 'order'
On Sat, 13 Feb 2021 16:22:24 +0000, David Higton wrote:
This build is just over a month old, which reminds me it's time I updated it again.
A weekly update is better - there have been and are quite a lot of
security holes being discovered and fixed recently.
My personal recommendation: turn off any automatic updates you might have configured and every week make a backup using rsync [1] followed
immediately by a Raspbian update and reboot.
[1] use rsync because its about the fastest backup program. On an RPi
using a SD filing on an 8-18GB card system you may as well back up everything, but really, all you need to backup is /home *provided that*
you keep copies of every file you change in /etc in a special directory structure in /home or in your usual login.
I use a pair of 1TB WD Essentials portable USB drives for two generations
of backups, but of course ymmv - you can equally use a couple of SD cards, but they may fail silently - while a portable SSD or HDD is more likely to give you warnings, particularly if you fsck it as the last action in every backup run. Note:
- Write a shell script to automate the backup process - makes life a
lot easier
- Using a set of biggish backup devices and makes it easy to back up
several systems onto a single device set of HDDS or SSDs.
- Always keep the backup set offline, preferably in a firesafe or in a
separate building or garden shed.
The nice thing about the Acorns was a decent BASIC with a built-in
assembler. I eventually bought a PC and was astounded that I had to
*buy* a useful programming environment, all it came with was GW BASIC,
which wasn't great. I took the Delphi path, which is why I've never
more than dabbled in C.
In message <s0943v$of1$1@dont-email.me>
Martin Gregorie <martin@mydomain.invalid> wrote:
On Sat, 13 Feb 2021 16:22:24 +0000, David Higton wrote:
This build is just over a month old, which reminds me it's time IA weekly update is better - there have been and are quite a lot of
updated it again.
security holes being discovered and fixed recently.
My personal recommendation: turn off any automatic updates you might
have configured and every week make a backup using rsync [1] followed
immediately by a Raspbian update and reboot.
[1] use rsync because its about the fastest backup program. On an RPi
using a SD filing on an 8-18GB card system you may as well back up
everything, but really, all you need to backup is /home *provided that*
you keep copies of every file you change in /etc in a special directory
structure in /home or in your usual login.
I use a pair of 1TB WD Essentials portable USB drives for two
generations of backups, but of course ymmv - you can equally use a
couple of SD cards,
but they may fail silently - while a portable SSD or HDD is more
likely to give you warnings, particularly if you fsck it as the last
action in every backup run. Note:
- Write a shell script to automate the backup process - makes life a
lot easier
- Using a set of biggish backup devices and makes it easy to back up
several systems onto a single device set of HDDS or SSDs.
- Always keep the backup set offline, preferably in a firesafe or in a
separate building or garden shed.
I don't think you read what I posted, Martin. I use RISC OS.
In message <20210213191237.45fb83be@jresid.jretrading.com>
Joe <joe@jretrading.com> wrote:
The nice thing about the Acorns was a decent BASIC with a built-in assembler. I eventually bought a PC and was astounded that I had to
*buy* a useful programming environment, all it came with was GW
BASIC, which wasn't great. I took the Delphi path, which is why
I've never more than dabbled in C.
Get yourself a Raspberry Pi, install RISC OS on it, and enjoy those
pleasures again - but the OS and the BASIC have had the benefit of
many years of improvement since the Archimedes days.
The nice thing about the Acorns was a decent BASIC with a built-in
assembler. I eventually bought a PC and was astounded that I had to
*buy* a useful programming environment, all it came with was GW BASIC,
which wasn't great. I took the Delphi path, which is why I've never
more than dabbled in C.
Anyone have any recommendations for modern open-source GUI editors that *don't* use Electron as a framework? I've been trying out Onivim but
Re: Re: Adding VS Code to Pi
By: Theo to Ahem A Rivet's Shot on Sat Feb 13 2021 11:27 am
Anyone have any recommendations for modern open-source GUI editors that *don't* use Electron as a framework? I've been trying out Onivim but
Have you seen Geany?
Phigan <nospam.Phigan@f1.n770.z1104.fidonet.org> wrote:
Re: Re: Adding VS Code to Pi
By: Theo to Ahem A Rivet's Shot on Sat Feb 13 2021 11:27 am
> Anyone have any recommendations for modern open-source GUI editors that >> > *don't* use Electron as a framework? I've been trying out Onivim but
Have you seen Geany?
I've used it before. What's notable about it? I didn't really explore, but it looked to me fairly basic - like a slightly fancier version of gedit.
Theo
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Dana Tue, 16 Feb 2021 02:24:59 +0000, The Natural Philosopher <tnp@invalid.invalid> napis'o: [snip]
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Why not?
Even vim is enought to write any book in LaTeX.
On Tue, 16 Feb 2021 08:17:53 -0000 (UTC)
Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> wrote:
Dana Tue, 16 Feb 2021 02:24:59 +0000, The Natural Philosopher
<tnp@invalid.invalid> napis'o: [snip]
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Why not?
Even vim is enought to write any book in LaTeX.
You could probably do that in Edlin.
But there's a big difference between 'enough' and 'I would use it by preference'.
Dana Tue, 16 Feb 2021 09:28:39 +0000, Joe <joe@jretrading.com> napis'o:
On Tue, 16 Feb 2021 08:17:53 -0000 (UTC)
Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> wrote:
Dana Tue, 16 Feb 2021 02:24:59 +0000, The Natural Philosopher
<tnp@invalid.invalid> napis'o: [snip]
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Why not?
Even vim is enought to write any book in LaTeX.
You could probably do that in Edlin.
But there's a big difference between 'enough' and 'I would use it by
preference'.
But I do prefere vim and I do prefere LaTeX for anything that needs to
look right... as a proper document or a book.
And yes, I do prefere keyboard over mouse. :) It's faster!
On Tue, 16 Feb 2021 08:17:53 -0000 (UTC)
Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> wrote:
Dana Tue, 16 Feb 2021 02:24:59 +0000, The Natural Philosopher
<tnp@invalid.invalid> napis'o: [snip]
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Why not?
Even vim is enought to write any book in LaTeX.
You could probably do that in Edlin.
But there's a big difference between 'enough' and 'I would use it by preference'.
I wouldn't use it to write a book in.
On 16/02/2021 10:39, Nikolaj Lazic wrote:
Dana Tue, 16 Feb 2021 09:28:39 +0000, Joe <joe@jretrading.com> napis'o:
On Tue, 16 Feb 2021 08:17:53 -0000 (UTC)
Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> wrote:
Dana Tue, 16 Feb 2021 02:24:59 +0000, The Natural Philosopher
<tnp@invalid.invalid> napis'o: [snip]
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Why not?
Even vim is enought to write any book in LaTeX.
You could probably do that in Edlin.
But there's a big difference between 'enough' and 'I would use it by
preference'.
But I do prefere vim and I do prefere LaTeX for anything that needs to
look right... as a proper document or a book.
And yes, I do prefere keyboard over mouse. :) It's faster!
Yes, we all know a proper vi user uses h j k l instead of cursors, so
they don't move their fingers from the touch typing default position.
Back in 1995 the team I worked on was allowed to switch c++ development
from unix/vi to the Microsoft C++ IDE, pretty much everyone switched.
For Latex try TexStudio.
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
You can get 8GB on a Pi4, if that's not enough then it's a very sad >> testimonial to bloat - some of the workstations we all used to lust after
had as much as a thousandth of that much memory.
EMACS: 'Eight Megs And Constantly Swapping' was once the byword for bloat. Looks like there is a new pretender to the crown.
Anyone have any recommendations for modern open-source GUI editors that *don't* use Electron as a framework? I've been trying out Onivim but interested in others.
There's plenty of books written in LaTeX it's not a bad option,
better than troff in many ways - but both were designed for the job of producing books and they're pretty good at it. These day's I'd be more inclined to use docbook and forget all about the layout until print time.
Doesn't do drop caps, automatic index, illustrations, and emphasised text.
Even vim is enought to write any book in LaTeX.
I wouldn't write a book in Latex, either
On 16/02/2021 10:56, Pancho wrote:
On 16/02/2021 10:39, Nikolaj Lazic wrote:back in the day we could either edit in vi on the PDP 11, or use
Dana Tue, 16 Feb 2021 09:28:39 +0000, Joe <joe@jretrading.com> napis'o: >>>> On Tue, 16 Feb 2021 08:17:53 -0000 (UTC)
Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> wrote:
Dana Tue, 16 Feb 2021 02:24:59 +0000, The Natural Philosopher
<tnp@invalid.invalid> napis'o: [snip]
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Why not?
Even vim is enought to write any book in LaTeX.
You could probably do that in Edlin.
But there's a big difference between 'enough' and 'I would use it by
preference'.
But I do prefere vim and I do prefere LaTeX for anything that needs to
look right... as a proper document or a book.
And yes, I do prefere keyboard over mouse. :) It's faster!
Yes, we all know a proper vi user uses h j k l instead of cursors, so
they don't move their fingers from the touch typing default position.
Back in 1995 the team I worked on was allowed to switch c++
development from unix/vi to the Microsoft C++ IDE, pretty much
everyone switched.
wordstar on DOS and upload the code for compilations. I don't think
anyone worked in vi from choice except for minor mods.
I cant remember how we uploaded the code either - there was certainly no TCP/IP - must have been over serial.
For Latex try TexStudio.
Must I?
On 16/02/2021 11:01, The Natural Philosopher wrote:
On 16/02/2021 10:56, Pancho wrote:
On 16/02/2021 10:39, Nikolaj Lazic wrote:back in the day we could either edit in vi on the PDP 11, or use
Dana Tue, 16 Feb 2021 09:28:39 +0000, Joe <joe@jretrading.com> napis'o: >>>>> On Tue, 16 Feb 2021 08:17:53 -0000 (UTC)
Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> wrote:
Dana Tue, 16 Feb 2021 02:24:59 +0000, The Natural Philosopher
<tnp@invalid.invalid> napis'o: [snip]
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Why not?
Even vim is enought to write any book in LaTeX.
You could probably do that in Edlin.
But there's a big difference between 'enough' and 'I would use it by >>>>> preference'.
But I do prefere vim and I do prefere LaTeX for anything that needs to >>>> look right... as a proper document or a book.
And yes, I do prefere keyboard over mouse. :) It's faster!
Yes, we all know a proper vi user uses h j k l instead of cursors, so
they don't move their fingers from the touch typing default position.
Back in 1995 the team I worked on was allowed to switch c++
development from unix/vi to the Microsoft C++ IDE, pretty much
everyone switched.
wordstar on DOS and upload the code for compilations. I don't think
anyone worked in vi from choice except for minor mods.
I cant remember how we uploaded the code either - there was certainly no
TCP/IP - must have been over serial.
One of the guys I worked with wrote an emacs like editor for DEC, when
we moved from VMS to ultrix/sparcs he used vi, even after he got a unix
port of his editor.
The funny thing coding full time with vi is that my fingers didn't
forget it even after decades of not using it. I found it hard to
verbalise the keys I was using but my fingers just seemed to know.
On Tue, 16 Feb 2021 19:15:42 +0000, TimS wrote:
A *manual*? For a fucking *editor*? What are these guys smoking?
Quite right. Every editor should have a built-in, context sensitive help system. However, every Linux user should have a basic knowledge of vi
because of its ability the use 'hjkl' as cursor keys. This makes it
usable in an almost totally borked system and that knowledge may be
useful of you managed to achieve full borkage. It also has excellent,
fast search&replace capabilities.
That said, my preferred text editor is microEmacs because its fast,
doesn't require me to use a mouse when editing and I've never hit its
limit for the number of files it can edit at once. microEmacs and tidy
are my preferred way of working with HTML pages, microemacs and make for
C programming and microemacs and ant for Java.
A *manual*? For a fucking *editor*? What are these guys smoking?
I got bored waiting for this debate to conclude,
then found the Ultrix box had dxnotepad. So I spent 5 minutes learning
how to use a mouse-based editor, and got on with writing large amounts of
C.
Phigan <nospam.Phigan@f1.n770.z1104.fidonet.org> wrote:
Re: Re: Adding VS Code to Pi
By: Theo to Ahem A Rivet's Shot on Sat Feb 13 2021 11:27 am
Anyone have any recommendations for modern open-source GUI editors that >> > *don't* use Electron as a framework? I've been trying out Onivim but
Have you seen Geany?
I've used it before. What's notable about it? I didn't really explore, but >it looked to me fairly basic - like a slightly fancier version of gedit.
my absolute favourite wordprocessor would
still be Microsoft Word for DOS because, again, you could do everything without taking your hands from the keyboard and its use of function keys
was really well thought out - much better that the scrambled mess that
was WordPerfect - and Word was faster too.
Simply being able to use the same editor *everywhere* is incredibly
useful. I use it for composing E-Mail, editing wiki pages, even filling forms in Firefox.
On Tue, 16 Feb 2021 10:54:57 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
Doesn't do drop caps, automatic index, illustrations, and emphasised text.
Sure it does, you just have to use the right markup.
Even vim is enought to write any book in LaTeX.
I wouldn't write a book in Latex, either
There's plenty of books written in LaTeX it's not a bad option,
better than troff in many ways - but both were designed for the job of producing bo
and they're pretty good at it. These day's I'd be more
inclined to use docbook and forget all about the layout until print time.
--
Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN
| A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
On Tue, 16 Feb 2021 20:02:26 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
my absolute favourite wordprocessor would still be Microsoft Word for
DOS because, again, you could do everything without taking your hands
from the keyboard and its use of function keys was really well thought
out - much better that the scrambled mess that was WordPerfect - and
Word was faster too.
I vastly preferred WordPerfect - provided you had a keyboard with function keys to the left and control next to A - then that apparent
mess turns into a really efficient layout that was surprisingly easy to remember.
On 15 Feb 2021 21:56:36 +0000 (GMT), Theo
<theom+news@chiark.greenend.org.uk> wrote:
Phigan <nospam.Phigan@f1.n770.z1104.fidonet.org> wrote:
Re: Re: Adding VS Code to Pi
By: Theo to Ahem A Rivet's Shot on Sat Feb 13 2021 11:27 am
Anyone have any recommendations for modern open-source GUI editors that >> > *don't* use Electron as a framework? I've been trying out Onivim but >>Have you seen Geany?
I've used it before. What's notable about it? I didn't really explore, but >it looked to me fairly basic - like a slightly fancier version of gedit.
It's much more than that. It is a fully-fledged IDE for source code.
You get syntax-highlighting, you can start a compiler, assembler and
linker, or call up the makefile. Then you can start the program, or
call it up in a debbuger. All very customizable. The rules for most programming languages are already built in, and if you use a new one
you can write them yourself.
Dana Tue, 16 Feb 2021 11:09:02 +0000, Ahem A Rivet's Shot <steveo@eircom.net> napis'o:
There's plenty of books written in LaTeX it's not a bad option,
better than troff in many ways - but both were designed for the job of
producing books and they're pretty good at it. These day's I'd be more
inclined to use docbook and forget all about the layout until print time.
That is exactly my point. Final layout is just the final step after structuring your tekst. And LaTeX does that really nice.
Just few corrections and that's it.
On 16 Feb 2021 at 12:18:41 GMT, Pancho <Pancho.Dontmaileme@outlook.com> wrote:
On 16/02/2021 11:01, The Natural Philosopher wrote:
On 16/02/2021 10:56, Pancho wrote:
On 16/02/2021 10:39, Nikolaj Lazic wrote:back in the day we could either edit in vi on the PDP 11, or use
Dana Tue, 16 Feb 2021 09:28:39 +0000, Joe <joe@jretrading.com> napis'o: >>>>>> On Tue, 16 Feb 2021 08:17:53 -0000 (UTC)
Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> wrote:
Dana Tue, 16 Feb 2021 02:24:59 +0000, The Natural Philosopher
<tnp@invalid.invalid> napis'o: [snip]
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Why not?
Even vim is enought to write any book in LaTeX.
You could probably do that in Edlin.
But there's a big difference between 'enough' and 'I would use it by >>>>>> preference'.
But I do prefere vim and I do prefere LaTeX for anything that needs to >>>>> look right... as a proper document or a book.
And yes, I do prefere keyboard over mouse. :) It's faster!
Yes, we all know a proper vi user uses h j k l instead of cursors, so >>>> they don't move their fingers from the touch typing default position. >>>>
Back in 1995 the team I worked on was allowed to switch c++
development from unix/vi to the Microsoft C++ IDE, pretty much
everyone switched.
wordstar on DOS and upload the code for compilations. I don't think
anyone worked in vi from choice except for minor mods.
I cant remember how we uploaded the code either - there was certainly no >>> TCP/IP - must have been over serial.
One of the guys I worked with wrote an emacs like editor for DEC, when
we moved from VMS to ultrix/sparcs he used vi, even after he got a unix
port of his editor.
The funny thing coding full time with vi is that my fingers didn't
forget it even after decades of not using it. I found it hard to
verbalise the keys I was using but my fingers just seemed to know.
Daer oh dear. Hopeless, isn't it. I remember - and it must be 30 years ago now
- when the Lab I worked at got a few unix machines. I was given an Ultrix box and told to get on with doing something with it. So I started to use it for network monitoring using SNMP.
Previously, most of us had been using editors that made various uses of ASCII terminals - Ann Arbor Ambassadors mostly that could give you 43 lines on the screen and pretend to be full-screen by using cursor addressing.
So everyone assumed we'd continue doing much the same, and the debate turned onto which editor everyone would be trained to use under unix. Would it be vi,
emacs, jove, something else. I got bored waiting for this debate to conclude, then found the Ultrix box had dxnotepad. So I spent 5 minutes learning how to use a mouse-based editor, and got on with writing large amounts of C. Six months later I found that the debate about which editor to use had made no progress, so I carried on using dxnotepad, which although not a patch on something like BBedit, was still better than any ASCII-terminal-based junk, all of which is obsolete. Why are they obsolete? Because they are bad tools. They require you to remember stuff just to use them. Even vi has a manual that
is 127 pages long. A *manual*? For a fucking *editor*? What are these guys smoking?
Plus, it didn't have or need the
'reveal codes' mode that everybody needed use to disentangle a WordPerfect document sooner or later.
I've never understood the big advantage of this sort of IDE over doing
each of those things (edit, compile, run/test) in separate terminal
windows. I have a syntax highlighting editor that runs in a terminal.
Again the *huge* advantage of running everything in terminal windows
running a (bash) shell is that one is using the same working
environment for everything, whether your compiling and testing code,
doing some housekeeping, checking E-Mails or whatever.
On 16/02/2021 19:15, TimS wrote:
On 16 Feb 2021 at 12:18:41 GMT, Pancho <Pancho.Dontmaileme@outlook.com>I don't remember ever reading vi's manual.
wrote:
On 16/02/2021 11:01, The Natural Philosopher wrote:
On 16/02/2021 10:56, Pancho wrote:
On 16/02/2021 10:39, Nikolaj Lazic wrote:back in the day we could either edit in vi on the PDP 11, or use
Dana Tue, 16 Feb 2021 09:28:39 +0000, Joe <joe@jretrading.com> napis'o:
On Tue, 16 Feb 2021 08:17:53 -0000 (UTC)
Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> wrote:
Dana Tue, 16 Feb 2021 02:24:59 +0000, The Natural Philosopher >>>>>>>> <tnp@invalid.invalid> napis'o: [snip]
But what do you mean by 'editor'
I wouldn't use it to write a book in.
Why not?
Even vim is enought to write any book in LaTeX.
You could probably do that in Edlin.
But there's a big difference between 'enough' and 'I would use it by >>>>>>> preference'.
But I do prefere vim and I do prefere LaTeX for anything that needs to
look right... as a proper document or a book.
And yes, I do prefere keyboard over mouse. :) It's faster!
Yes, we all know a proper vi user uses h j k l instead of cursors, so >>>>> they don't move their fingers from the touch typing default position. >>>>>
Back in 1995 the team I worked on was allowed to switch c++
development from unix/vi to the Microsoft C++ IDE, pretty much
everyone switched.
wordstar on DOS and upload the code for compilations. I don't think >>>> anyone worked in vi from choice except for minor mods.
I cant remember how we uploaded the code either - there was certainly no
TCP/IP - must have been over serial.
One of the guys I worked with wrote an emacs like editor for DEC, when
we moved from VMS to ultrix/sparcs he used vi, even after he got a unix >>> port of his editor.
The funny thing coding full time with vi is that my fingers didn't
forget it even after decades of not using it. I found it hard to
verbalise the keys I was using but my fingers just seemed to know.
Daer oh dear. Hopeless, isn't it. I remember - and it must be 30 years ago now
- when the Lab I worked at got a few unix machines. I was given an Ultrix box
and told to get on with doing something with it. So I started to use it for >> network monitoring using SNMP.
Previously, most of us had been using editors that made various uses of ASCII
terminals - Ann Arbor Ambassadors mostly that could give you 43 lines on the
screen and pretend to be full-screen by using cursor addressing.
So everyone assumed we'd continue doing much the same, and the debate turned
onto which editor everyone would be trained to use under unix. Would it be vi,
emacs, jove, something else. I got bored waiting for this debate to conclude,
then found the Ultrix box had dxnotepad. So I spent 5 minutes learning how to
use a mouse-based editor, and got on with writing large amounts of C. Six >> months later I found that the debate about which editor to use had made no >> progress, so I carried on using dxnotepad, which although not a patch on
something like BBedit, was still better than any ASCII-terminal-based junk, >> all of which is obsolete. Why are they obsolete? Because they are bad tools.
They require you to remember stuff just to use them. Even vi has a manual that
is 127 pages long. A *manual*? For a fucking *editor*? What are these guys >> smoking?
I just asked the bloke next to me. I think someone printed up a card
with the basic cursors on it
Someone else showed me basic regex search and replace and that's as far
as I needed to go to write probably a million pages of code
I've never understood the big advantage of this sort of IDE over doing
each of those things (edit, compile, run/test) in separate terminal
windows. I have a syntax highlighting editor that runs in a terminal.
On 16 Feb 2021 19:15:42 GMT
TimS <timstreater@greenbee.net> wrote:
I got bored waiting for this debate to conclude,
then found the Ultrix box had dxnotepad. So I spent 5 minutes learning
how to use a mouse-based editor, and got on with writing large amounts of
C.
That's fine and dandy when you have the option of running a GUI app
on the box with the code that needs editing - this tends to be problematic when the box in question is on another continent (or even just in another building), at which point being good with a terminal based editor is
helpful.
On 16/02/2021 19:15, TimS wrote:
Even vi has a manual that is 127 pages long. A *manual*? For a fucking
*editor*? What are these guys smoking?
That's because it's an enormously powerful text manipulation program,
and not just a text box with a cursor like Notepad.
---druck
Again the*huge* advantage of running everything in terminal windows
running a (bash) shell is that one is using the same working
environment for everything,
Even vi has a manual that is 127 pages long.
A *manual*? For a fucking *editor*? What are these guys smoking?
On 16/02/2021 19:15, TimS wrote:
Even vi has a manual that is 127 pages long.
A *manual*? For a fucking *editor*? What are these guys smoking?
That's because it's an enormously powerful text manipulation program,
and not just a text box with a cursor like Notepad.
On 16.2.21 21.15, TimS wrote:
Even vi has a manual that is 127 pages long. A *manual*? For a fucking *editor*?
What are these guys smoking?
So what?
Emacs manual (emacs 7x9.pdf) is 651 pages.
On 16/02/2021 22:24, Martin Gregorie wrote:
Plus, it didn't have or need the
'reveal codes' mode that everybody needed use to disentangle a WordPerfect >> document sooner or later.
A huge loss, since it was impossible to disentangle Word documents *at
all* without simply deleting and staring over...
On 16/02/2021 12:16, Nikolaj Lazic wrote:
Dana Tue, 16 Feb 2021 11:09:02 +0000, Ahem A Rivet's Shot <steveo@eircom.net> napis'o:yup. Latex is ok for tech stuff. But you can use page layout stuff like scribus ...I am writing a book in Libre office, because it has just
There's plenty of books written in LaTeX it's not a bad option,That is exactly my point. Final layout is just the final step after
better than troff in many ways - but both were designed for the job of
producing books and they're pretty good at it. These day's I'd be more
inclined to use docbook and forget all about the layout until print time. >>
structuring your tekst. And LaTeX does that really nice.
Just few corrections and that's it.
enough features to do the job I want to do and its free, and I never
used Latex enough to be handy with it, and Scribus is overkill
I use Scribus for adverts and brochures and the like where page
presentation is important. Geany for code. Lire office for not too
technical docs and books and pluma for unstructured plain text.
For editing config files on non GUI clients vi or joe.
*shrug* i ain't got religion, just a selection of imperfect tools
On 17/02/2021 10:20, druck wrote:
On 16/02/2021 19:15, TimS wrote:
Even vi has a manual that is 127 pages long. A *manual*? For a fucking
*editor*? What are these guys smoking?
That's because it's an enormously powerful text manipulation program,
because it hasn't got a gui, it needs to be. Remember Vi was first
written for teletypes. You know. Go to line 32 and replace 'grsx' with
'grrr'
I use Scribus for adverts and brochures and the like where pageIn case of posters and things like that I use Inkscape.
presentation is important. Geany for code. Lire office for not tooYeah. That's it. Every tools has a purpose. You can write .svg
technical docs and books and pluma for unstructured plain text.
For editing config files on non GUI clients vi or joe.
*shrug* i ain't got religion, just a selection of imperfect tools
in vim, but it's easier to do that visually in Inkscape.:)
But I do write .html in vim.:)
It's again all about the document structure.
Editing files on my remote servers using a GUI and NFS* is faster than
it used to be over coaxial ethernet in the same room.
*I have a fixed IP address. the firewalls at each end know what to do.
If someone in the middle really wants my source code that bad, they can
have it. If I want access globally I use sshfs
On 17/02/2021 08:56, Chris Green wrote:
Again the*huge* advantage of running everything in terminal windows running a (bash) shell is that one is using the same working
environment for everything,
that is spurious. I remeber writing in Wordstar, on a PC, uploading to a
PDP 11, using a terminal emulator on the PC to compile and VI to edit te makefile before downloading the code into an in circuit emulators
pretending to be a 6809 microprocessor ...driving an oscilloscope
Never mind different windows I was working on 4 totally different
machines...
On Wed, 17 Feb 2021 08:56:40 +0000
Chris Green <cl@isbd.net> wrote:
I've never understood the big advantage of this sort of IDE over doing
each of those things (edit, compile, run/test) in separate terminal windows. I have a syntax highlighting editor that runs in a terminal.
The best unix IDE is urxvt with tmux.
I use sshfs all the time, since I have ssh set up to connect to every
system I'm interested in it's actually easier to use sshfs than setting
up nfs.
On 17/02/2021 11:40, Nikolaj Lazic wrote:
Does inkscape do multipage PDFs? Every time I've used it it hasnt workedI use Scribus for adverts and brochures and the like where pageIn case of posters and things like that I use Inkscape.
for me and I never bothered to delve into it enough. I have Corel Draw
on an XP virtual machine if I need a drawing program
Scribus does a better job of formatting
presentation is important. Geany for code. Lire office for not tooYeah. That's it. Every tools has a purpose. You can write .svg
technical docs and books and pluma for unstructured plain text.
For editing config files on non GUI clients vi or joe.
*shrug* i ain't got religion, just a selection of imperfect tools
in vim, but it's easier to do that visually in Inkscape.:)
But I do write .html in vim.:)
It's again all about the document structure.
I write it in Geany.
Got used to the highlighting
And function collapse..and..and..just got used to it is all.
My code is mainly PHP/HTML/CSS/Javascript or C and that combo sits well
on Geany.
Since I don't really do it professionally the learning curve to move to
an unfamiliar editor, is significant.
On Wed, 17 Feb 2021 11:54:57 +0000
Chris Green <cl@isbd.net> wrote:
I use sshfs all the time, since I have ssh set up to connect to every system I'm interested in it's actually easier to use sshfs than setting
up nfs.
Apart from anything else sshfs doesn't require admin access to the server. IME though the latency in a remote FS mount either by NFS over VPN
or sshfs over anything can be painful compared to using the command line
and tmux over an ssh connection to a box or VM that's in the data centre where everything else is.
On 16/02/2021 22:24, Martin Gregorie wrote:
Plus, it didn't have or need the
'reveal codes' mode that everybody needed use to disentangle a
WordPerfect
document sooner or later.
A huge loss, since it was impossible to disentangle Word documents *at
all* without simply deleting and staring over...
On 16/02/2021 22:24, Martin Gregorie wrote:
Plus, it didn't have or need the 'reveal codes' mode that everybody
needed use to disentangle a WordPerfect document sooner or later.
A huge loss, since it was impossible to disentangle Word documents *at
all* without simply deleting and staring over...
Chris Green <cl@isbd.net> wrote:
I've never understood the big advantage of this sort of IDE over doing
each of those things (edit, compile, run/test) in separate terminal
windows. I have a syntax highlighting editor that runs in a terminal.
Again the *huge* advantage of running everything in terminal windows
running a (bash) shell is that one is using the same working
environment for everything, whether your compiling and testing code,
doing some housekeeping, checking E-Mails or whatever.
Somebody asked what I'm looking for. That's a good question. Currently I
do what you say - edit most things in a terminal window, because that environment is universal whether I'm editing locally or remotely (I probably do >70% of my editing remotely, including most mail and Usenet).
So I suppose what I'm after is something that makes a compelling reason for editing locally, where I will put up with the hassles of bringing the files to me because it gives me something extra.
I'm not terribly bothered by being able to compile stuff from an editor - on a terminal the shell is always the 'quit' keystroke away, and I can flip
back to the editor with up-arrow and Enter. So that's a non-problem as far as I'm concerned. It is nice to be able to compile when looking at the
code, but two terminal windows give me that.
One good reason for a GUI editor is mouse-based selection. I much prefer
the keyboard, but sometimes you're moving big chunks of text around (say refactoring code or a document) and it's easier to point and drag than lots of cursor manipulation (start-marker, end-marker, cut, move, paste, etc) Almost very GUI editor does that (with the exception of gvim, which is a bit weird) so it's not really a discriminating factor.
One thing I do appreciate though is being able to operate everything
smoothly from the keyboard when I don't need the mouse. One wordprocessor required me to use the menu shortcuts (something like Alt-E-F-S for strikeout) and that was awkward. Yes there was a button on the toolbar, but switching keyboard-mouse-keyboard is time consuming.
Syntax highlighting is also a given, but with a wide set of rules. I opened a device tree .dts file in geany yesterday and was surprised it didn't highlight. It did highlight C code.
Another desirable feature would be code navigation - click on a function
call to go to its definition, bring up the API documentation in some kind of popup, grep-style search where you get a list of results and can click on a result to go to that file.
Similarly code folding - being able to collapse functions (or sections in your Latex or whatever) so it's easier to skip over those you aren't working on. Saves scrollbar time.
Another useful feature is debugger integration - not just running gdb alongside, but being able to set breakpoints with clicks on source lines, when you get to the breakpoints being able to see the tree of variables in a window that you can navigate by mouse, rather than typing out search
patterns at a gdb prompt.
Basically this sounds something a bit more IDE like but not tied to a particular language/toolchain - often IDEs are strongly tied to particular environments (Java, embedded, etc) and it feels awkward if you're using them for something else, so you end up flitting between multiple IDEs. I suppose I'm looking for an editor with IDE features rather than an IDE with editor features.
Answers on a postcard...
On 16.2.21 21.15, TimS wrote:
Even vi has a manual that is 127 pages long. A *manual*? For a fucking *editor*?
What are these guys smoking?
So what?
Emacs manual (emacs 7x9.pdf) is 651 pages.
On 17/02/2021 10:20, druck wrote:
On 16/02/2021 19:15, TimS wrote:
Even vi has a manual that is 127 pages long. A *manual*? For a fucking
*editor*? What are these guys smoking?
That's because it's an enormously powerful text manipulation program,
because it hasn't got a gui, it needs to be. Remember Vi was first
written for teletypes. You know. Go to line 32 and replace 'grsx' with
'grrr'
you used it with a heavily marked up printout of your source code and
the errors coming out of the compilers.
At te days end you submitted your code and et operators would print it
out and try and compile it again
My first simple FORTRAN program took 12 weeks to write and debug
and not just a text box with a cursor like Notepad.
Nothing wrong with notepad
I've never understood the big advantage of this sort of IDE over doing
each of those things (edit, compile, run/test) in separate terminal
windows. I have a syntax highlighting editor that runs in a terminal.
On 17/02/2021 10:20, druck wrote:
and not just a text box with a cursor like Notepad.Nothing wrong with notepad
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 17/02/2021 10:20, druck wrote:vi mostly certainly *wasn't* "written for teletypes", it's name gives
On 16/02/2021 19:15, TimS wrote:
Even vi has a manual that is 127 pages long. A *manual*? For a fucking >>>> *editor*? What are these guys smoking?
That's because it's an enormously powerful text manipulation program,
because it hasn't got a gui, it needs to be. Remember Vi was first
written for teletypes. You know. Go to line 32 and replace 'grsx' with
'grrr'
the lie to this - vi[sual editor]. The editor for teletypes was ed, and
if you called vi as ex you got an extended version of ed.
There are GUI versions of vi, the most widely used is probably gvim but
the one I use (if I want a GUI) is xvile.
The Natural Philosopher <tnp@invalid.invalid> wrote:
I use sshfs all the time, since I have ssh set up to connect to every
Editing files on my remote servers using a GUI and NFS* is faster than
it used to be over coaxial ethernet in the same room.
*I have a fixed IP address. the firewalls at each end know what to do.
If someone in the middle really wants my source code that bad, they can
have it. If I want access globally I use sshfs
system I'm interested in it's actually easier to use sshfs than setting
up nfs.
While I could use a GUI at the client end I nearly always end up using
my standard text mode/command line tools.
On Wed, 17 Feb 2021 11:54:57 +0000
Chris Green <cl@isbd.net> wrote:
I use sshfs all the time, since I have ssh set up to connect to every
system I'm interested in it's actually easier to use sshfs than setting
up nfs.
Apart from anything else sshfs doesn't require admin access to the server. IME though the latency in a remote FS mount either by NFS over VPN
or sshfs over anything can be painful compared to using the command line
and tmux over an ssh connection to a box or VM that's in the data centre where everything else is.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 17/02/2021 08:56, Chris Green wrote:Yes, each a remote connection via a terminal window, at least this
Again the*huge* advantage of running everything in terminal windows
running a (bash) shell is that one is using the same working
environment for everything,
that is spurious. I remeber writing in Wordstar, on a PC, uploading to a
PDP 11, using a terminal emulator on the PC to compile and VI to edit te
makefile before downloading the code into an in circuit emulators
pretending to be a 6809 microprocessor ...driving an oscilloscope
Never mind different windows I was working on 4 totally different
machines...
would be the modern idiom for this.
Dana Wed, 17 Feb 2021 11:48:08 +0000, The Natural Philosopher <tnp@invalid.invalid> napis'o:
On 17/02/2021 11:40, Nikolaj Lazic wrote:
Does inkscape do multipage PDFs? Every time I've used it it hasnt workedI use Scribus for adverts and brochures and the like where pageIn case of posters and things like that I use Inkscape.
I don't think so. Posters are single page documents. Only if you
cut them in pieces and glue back after printing. :)
for me and I never bothered to delve into it enough. I have Corel Draw
on an XP virtual machine if I need a drawing program
Well... yeah... when you get used to some tool... it sticks.
Until you force yourself to switch. :)
On 17/02/2021 12:39, Ahem A Rivet's Shot wrote:
On Wed, 17 Feb 2021 11:54:57 +0000
Apart from anything else sshfs doesn't require admin access to
the server. IME though the latency in a remote FS mount either by NFS
over VPN or sshfs over anything can be painful compared to using the command line and tmux over an ssh connection to a box or VM that's in
the data centre where everything else is.
Well that again depends on your network speed. I now have a minimum
speed of 10Mbps up and that's as good as the coaxial ethernet NFS was designed for
However there's a few places (in particular my hosting provider) where
I have ssh access but don't have the option of getting my favourite
editor installed (and there other useful utilities missing as well) so
for those I sometime mount them locally using sshfs.
vi was a superstructure pasted on ed as far as I can recall
It was never designed as a CRT based editor. It is 100% line oriented
On 17/02/2021 12:39, Ahem A Rivet's Shot wrote:
On Wed, 17 Feb 2021 11:54:57 +0000
Chris Green <cl@isbd.net> wrote:
I use sshfs all the time, since I have ssh set up to connect to every
system I'm interested in it's actually easier to use sshfs than setting
up nfs.
Apart from anything else sshfs doesn't require admin access to the server. IME though the latency in a remote FS mount either by NFS over VPN or sshfs over anything can be painful compared to using the command line and tmux over an ssh connection to a box or VM that's in the data centre where everything else is.
Well that again depends on your network speed. I now have a minimum
speed of 10Mbps up and that's as good as the coaxial ethernet NFS was designed for
But the huge advantage for ME is that NFS mounted remote filesystems
appear just like local ones. Its all nicely integrated
Sure I use ssh for some stuff. But its nice to click on a directory and
open a remote server data area
I dabbled with sshfs but for some reason I abandoned it in favour of NFS
I cant remember why....
back in the day we could either edit in vi on the PDP 11, or use
wordstar on DOS and upload the code for compilations. I don't think
anyone worked in vi from choice except for minor mods.
I cant remember how we uploaded the code either - there was certainly no >TCP/IP - must have been over serial.
Latex is cool, If you have a better editor I'm all ears.
On Wed, 17 Feb 2021 20:53:14 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
vi was a superstructure pasted on ed as far as I can recall
Correct - it stands for Visual Interface.
It was never designed as a CRT based editor. It is 100% line oriented
Vi was most certainly designed as a CRT based interface to an
editor, one of the very first such. Some of the screen handling code in the original vi wound up as part of curses.
On Wed, 17 Feb 2021 20:58:39 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 17/02/2021 12:39, Ahem A Rivet's Shot wrote:
On Wed, 17 Feb 2021 11:54:57 +0000Well that again depends on your network speed. I now have a minimum
Apart from anything else sshfs doesn't require admin access to
the server. IME though the latency in a remote FS mount either by NFS
over VPN or sshfs over anything can be painful compared to using the
command line and tmux over an ssh connection to a box or VM that's in
the data centre where everything else is.
speed of 10Mbps up and that's as good as the coaxial ethernet NFS was
designed for
Latency is more of a factor than speed, I have 1Gbps down, 100Mbps
up, but if the other end is on another continent then the latency tends to make things painful.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 17/02/2021 12:39, Ahem A Rivet's Shot wrote:So do sshfs mounted ones.
On Wed, 17 Feb 2021 11:54:57 +0000Well that again depends on your network speed. I now have a minimum
Chris Green <cl@isbd.net> wrote:
I use sshfs all the time, since I have ssh set up to connect to every
system I'm interested in it's actually easier to use sshfs than setting >>>> up nfs.
Apart from anything else sshfs doesn't require admin access to the >>> server. IME though the latency in a remote FS mount either by NFS over VPN >>> or sshfs over anything can be painful compared to using the command line >>> and tmux over an ssh connection to a box or VM that's in the data centre >>> where everything else is.
speed of 10Mbps up and that's as good as the coaxial ethernet NFS was
designed for
But the huge advantage for ME is that NFS mounted remote filesystems
appear just like local ones. Its all nicely integrated
Sure I use ssh for some stuff. But its nice to click on a directory andNo, I can't see why. If you have ssh configured to connect to a
open a remote server data area
I dabbled with sshfs but for some reason I abandoned it in favour of NFS
I cant remember why....
server then mounting its files using sshfs 'just works' with no
further configuration at either end.
On 17/02/2021 21:18, Ahem A Rivet's Shot wrote:
On Wed, 17 Feb 2021 20:53:14 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
vi was a superstructure pasted on ed as far as I can recall
Correct - it stands for Visual Interface.
It was never designed as a CRT based editor. It is 100% line oriented
Vi was most certainly designed as a CRT based interface to an
editor, one of the very first such. Some of the screen handling code in
the original vi wound up as part of curses.
Er no...it wasnt
He then developed vi as a "visual interface" to ex. That
is, it allows text to be viewed on a full screen rather than only one
line at a time. vi takes its name from this fact.
On Thu, 18 Feb 2021 04:52:33 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 17/02/2021 21:18, Ahem A Rivet's Shot wrote:
On Wed, 17 Feb 2021 20:53:14 +0000Er no...it wasnt
The Natural Philosopher <tnp@invalid.invalid> wrote:
vi was a superstructure pasted on ed as far as I can recall
Correct - it stands for Visual Interface.
It was never designed as a CRT based editor. It is 100% line oriented
Vi was most certainly designed as a CRT based interface to an
editor, one of the very first such. Some of the screen handling code in
the original vi wound up as part of curses.
Your quote confirms my statement - extracting the relevant piece.
He then developed vi as a "visual interface" to ex. That
is, it allows text to be viewed on a full screen rather than only one
line at a time. vi takes its name from this fact.
I've used it before. What's notable about it? I didn't really explore, but it looked to me fairly basic - like a slightly fancier version of gedit.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 371 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 37:02:44 |
| Calls: | 7,932 |
| Calls today: | 2 |
| Files: | 12,998 |
| Messages: | 5,805,619 |