XPost: comp.lang.lisp

On 5/29/2024 6:34 PM, steve wrote:

WHat editor do people use these days? any favorites? i still use emacs;
i have tried atom and vscode but could not get the REPL server right.

Does anyone know what kind of interface do they need? I feel like
someone is going to say JSON.

it would be nice in kate to open a lisp terminal like the regular
terminal it comes with. I am inspired by this. it is almost like commint mode. maybe an emacs server could work?

I don't know much about vscode studio or atom; but interested. how well
do they work for C or is everything java these days...

Vim does fine with Python and Lisp (Scheme).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.lisp

On Thu, 30 May 2024 13:05:38 -0700, HenHanna wrote:

Vim does fine with Python and Lisp (Scheme).

The thing with Vim is, there are so many Vims, and Neovims, and Vis, and
Gvims, and what all to choose from. And they are all subtly different ...
and incompatible.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.lisp

In comp.editors Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 30 May 2024 13:05:38 -0700, HenHanna wrote:

Vim does fine with Python and Lisp (Scheme).

The thing with Vim is, there are so many Vims, and Neovims, and Vis, and Gvims, and what all to choose from. And they are all subtly different ...
and incompatible.

I use Vim and I don't have any problem with the other that I don't use, just choose one and use it. Besides the core commands are the same, the others just add something but never change the base.

G

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.lisp

In article <lbtlnaFmerlU1@mid.individual.net>, G <g@nowhere.invalid> wrote: >In comp.editors Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 30 May 2024 13:05:38 -0700, HenHanna wrote:

Vim does fine with Python and Lisp (Scheme).

The thing with Vim is, there are so many Vims, and Neovims, and Vis, and
Gvims, and what all to choose from. And they are all subtly different ...
and incompatible.

I use Vim and I don't have any problem with the other that I don't use, just >choose one and use it. Besides the core commands are the same, the others just >add something but never change the base.

Vim and GVIM are the same thing - just different looks. Personally, I use
GVIM for everything. Plain VIM (in the terminal) is unusable on the
Raspberry Pi, because the colors are f***ed up. Yes, this is fixable, but
it is not worth the trouble.

As usual, LDO's comments (quoted above) are nonsense.

--
Kenny, I'll ask you to stop using quotes of mine as taglines.

- Rick C Hodgin -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.lisp

On Fri, 31 May 2024 16:59:21 -0000 (UTC), Spiros Bousbouras wrote:

There is only 1 vim , 1 neovim , 1 vi .

Which is the one that uses Lua as its macro language?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[comp.lang.lisp removed from x-post]
On 31.05.2024 18:59, Spiros Bousbouras wrote:

On Fri, 31 May 2024 11:43:52 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:

In article <lbtlnaFmerlU1@mid.individual.net>, G <g@nowhere.invalid> wrote: >>> In comp.editors Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 30 May 2024 13:05:38 -0700, HenHanna wrote:

Vim does fine with Python and Lisp (Scheme).

The thing with Vim is, there are so many Vims, and Neovims, and Vis, and >>>> Gvims, and what all to choose from. And they are all subtly different ... >>>> and incompatible.

I use Vim and I don't have any problem with the other that I don't use, just
choose one and use it. Besides the core commands are the same, the others just
add something but never change the base.

Vim and GVIM are the same thing - just different looks.

[...]

As usual, LDO's comments (quoted above) are nonsense.

I second this. There is only 1 vim , 1 neovim , 1 vi .They are all examples of vi-like editors of which there are several.

These clones (and branches) is probably what LdO wanted to express?
(At least I interpreted it that way.) But it's anyway a non-issue,
IMO, since I second what G said. Actually most of the power of VIs
is due to the underlying design (and features) of the VI base (that
the clones support). But while I also tried or used some Vi clones
in the past (back in the 1990's?) I think most of them are nowadays
anyway obsolete. Personally I use the Vim/Gvim since decades now
and almost never[*] had any reason to switch, also because of its
design-wise coherent extensions of the VI base that Vim introduced.

Janis

[*] It was in a commercial Unix environment where there was only
a standard VI installed. (Still a lot better than anything else
available. And good that it's Unix standard; a reliably available
yet extremely powerful editor.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

Actually most of the power of VIs is due to the underlying design (and features) of the VI base (that the clones support). But while I also
tried or used some Vi clones in the past (back in the 1990's?) I think
most of them are nowadays anyway obsolete. Personally I use the
Vim/Gvim since decades now and almost never[*] had any reason to
switch, also because of its design-wise coherent extensions of the VI
base that Vim introduced.

As I am an adherent to the other editor, this reminds me on the
discussion in "The Church of Emacs":

There are many, many Emacs relatives/clones/... available. Most share a
basic set of short-cuts and some basic usage paradigms, so even with,
say, "atto", see

https://github.com/hughbarney

a standard Emacs user will feel right at home. However, most clones
clearly and severly lack GNU Emacs's extensibility, see

https://www.gnu.org/software/emacs/emacs-paper.html#SEC25

Since my vi/vim/gvim knowledge is very basic (probably equivalent to
using atto's features), I have no idea about how the situation is on the
other side:

Could you (or others) please comment how common it is in vi-land to use
a bunch of extension packages and have configuration files larger than,
say, 10 kB to customize every imaginable feature to one's peculiar
needs?

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-06-01 07:46, Axel Reichert wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

Actually most of the power of VIs is due to the underlying design (and
features) of the VI base (that the clones support). But while I also
tried or used some Vi clones in the past (back in the 1990's?) I think
most of them are nowadays anyway obsolete. Personally I use the
Vim/Gvim since decades now and almost never[*] had any reason to
switch, also because of its design-wise coherent extensions of the VI
base that Vim introduced.

First there is a POSIX standard for what it means to be `vi` (as originally imagined by Bill Joy). Now there are variants pre/post POSIX and some of those maintain complete backward compatibility while adding non-conflicting features, like `nvi` available on BSD systems and closest to historical.

Then there is (umm) `vim` on Linux systems, that as I recall was created around the time POSIX.2 was still being balloted, so diverged in some places (I never use it because of this) before the standard was complete. It has opted to go with lots of extra stuff (cruft IMO) and extensions, in the GNU fashion.

There are many, many Emacs relatives/clones/... available. Most share a
basic set of short-cuts and some basic usage paradigms, so even with,
say, "atto", see

https://github.com/hughbarney

Having written `ae` originally with a `vi` like command set (modal), then later add some minor changes to be `emacs` like (mode-less) and allow you to configure
your preference (modal, mode-less), you can see what's under the hood is the same core, just the UI changes.

a standard Emacs user will feel right at home. However, most clones
clearly and severly lack GNU Emacs's extensibility, see

https://www.gnu.org/software/emacs/emacs-paper.html#SEC25

The question you need to ask yourself is how often will extensibility be used, do I really all those plugins, should I really need to customise my bindings up the wazoo to a point that if at sit at a new install (or someone else's terminal) I can't do squat because I am so used to changing all the defaults.

When there were lots of variety in serial terminals, keyboards, ESC codes, etc. allowing some customisation of bindings made sense. These days, keyboards tend be fairly standard for Windows or Mac.

Since my vi/vim/gvim knowledge is very basic (probably equivalent to
using atto's features), I have no idea about how the situation is on the other side:

Could you (or others) please comment how common it is in vi-land to use
a bunch of extension packages and have configuration files larger than,
say, 10 kB to customize every imaginable feature to one's peculiar
needs?

Personally I avoid vim, replace it with nvi when ever possible. I don't need the
features; I learnt to write code without syntax highlighting (I've used it and it can be handy at times). If you need some special editing, often that can be just a simple filter of some text through a command-line.

A classic vi .exrc will probably twiddle a handful of options, maybe some macros, so most of the time you're looking at less than 256 bytes of configuration, if any.

Now if you know `ed` (The Standard Editor) there is only one command-line option
that lets you set a prompt. There is something to be said about a Spartan editor -- spend more time coding, no time fussing with the knobs, because there aren't any. To paraphrase renowned scientist Dr. Emmett Brown:

Options?! Who needs options.

--
Anthony C Howe
achowe@snert.com BarricadeMX & Milters http://nanozen.snert.com/ http://software.snert.com/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01.06.2024 15:50, Anthony Howe wrote:

[Vim] It has opted to go with lots of extra stuff (cruft IMO) and extensions, in the GNU fashion.

It should be noted that Vi has a lot of alternative ways to edit
various text entities. Primitive ones as well as sophisticated
ones that users may explore/experience with continuing learning.
It's not necessary to use or know them all (especially not from
the beginning); just use the things you're familiar with or with
what you feel comfortable and ignore (generally or for the moment)
the more sophisticated features.

I can't tell what Anthony is considering "cruft", but as Vi has
sets of sophisticated very useful features, Vim continues that
path with more typical contemporary features fitting well in the
Vi philosophy. - Purists may refrain from using them, but other
folks (like me) will/do certainly appreciate them for sure. And
(as with Vi) you can ignore all or any of the the Vim features
as well if you don't see a gain in using them.

(I don't see how the Vim features have anything to do with GNU.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01.06.2024 13:46, Axel Reichert wrote:

As I am an adherent to the other editor, this reminds me on the
discussion in "The Church of Emacs":

There are many, many Emacs relatives/clones/... available. Most share a
basic set of short-cuts and some basic usage paradigms, so even with,
say, "atto", see

https://github.com/hughbarney

a standard Emacs user will feel right at home. However, most clones
clearly and severly lack GNU Emacs's extensibility, see

https://www.gnu.org/software/emacs/emacs-paper.html#SEC25

Since my vi/vim/gvim knowledge is very basic (probably equivalent to
using atto's features), I have no idea about how the situation is on the other side:

Could you (or others) please comment how common it is in vi-land to use
a bunch of extension packages and have configuration files larger than,
say, 10 kB to customize every imaginable feature to one's peculiar
needs?

I cannot comment on any "common" usages, I can only speak for myself
(and from what I've seen from specific folks), and here specifically
from the vi or vim/gvim perspective.

Personally I (as a proficient and experienced vi and vim user) never
had the need for any "extension package". All I need to edit sources
of whatever syntax or type is the standard installation (vim/gvim in
my case). I have some options set as standard in my .vimrc resource
file that I generally use for almost all text source types, literally
just these settings

set noruler
set noic
set modeline
set modelines=5
set smc=10000
set ts=4
set sw=4

and that's it. (If in specific situations I want different behavior I
just overwrite the default in my editor session by, say, :set ic
for case-insensitive searches.)

The point with vi/vim is that it has everything for "basic" _editing_;
"basic" in quotes, because its editing power is (IMO) extraordinary.

(I recall someone (LdO?) posting some (I think) lisp code that serves
some purpose for Emacs, but in Vim that was a standard feature so no
necessity to configure or implement it or load it as some additional
package in the first place.)

I know of folks that have a set of macros defined for their projects;
for language specific editing and convenience features, for example
macros that react on keywords, build the whole constructs, and place
the cursor at appropriate places. (And other things like that.) Such definitions I've seen typically were about one or two screen pages.
I also know folks who have defined macros to _create an application_
(e.g. a diary/log book with time stamps, specific formatting, etc.);
all this done with a couple macros in Vim. - But mind that this is
exceeding pure editing; it's actually creating specific applications
using the Vim tool. (Anyway impressive to see how easy such things
can be done with that editor, and mostly just with simple macros.)

I recall that I once added code[*] to a syntax definition file for
the Unix shell language to make it possible to correctly highlight
not only the shell code syntax but also embedded Awk code syntax;
i.e. highlighting two different syntaxes in one source. (But that
also wasn't much code; just a few lines IIRC.)

Re (how common it is in vi-land to use a bunch of extension packages):

none (in my case), just a few simple adjustments and user settings

Re (and have configuration files larger than, say, 10 kB):

none (in my case and I've not seen such large files for Vim; YMMV)

Re (to customize every imaginable feature to one's peculiar needs?)

this can't be generally answered; I'm sure there's geeks that

configure Vim, say, to play chess (or have other pathological uses)
(You may want to rephrase your question without the unanswerable
"every imaginable feature" for a more realistic scenario.)

But Vim supports besides other standard mechanisms also a scripting
language, so you can do anything to any complexity (if you feel the
need or some urge for it).

Janis

[*] It was code that Kaz may have provided, if I recall correctly.
(Apologies if it was someone else.)

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01.06.2024 15:50, Anthony Howe wrote:

First there is a POSIX standard for what it means to be `vi` (as
originally imagined by Bill Joy).

Yes, I spoke about standard Vi upthread; thought it would be clear
what "standard" was meant to mean.

Now there are variants pre/post POSIX
and some of those maintain complete backward compatibility while adding non-conflicting features, like `nvi` available on BSD systems and
closest to historical.

Then there is (umm) `vim` on Linux systems, that as I recall was created around the time POSIX.2 was still being balloted, so diverged in some
places (I never use it because of this) before the standard was
complete. [...]

Could you be more concrete where it deviates from the standard[*]?
And how it (badly) affected your editing in Vim in practice?

I'm seriously asking since the changes in Vim usually fixed an
issue I knew from Vi so it was practically not a problem but an
improvement in the "user experience" (for me).

Janis

[*] I'm not asking for deviations from Bill Joy's old Vi, since
Vim also fixed some bugs and inconsistencies from original Vi.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

[...]

Personally I (as a proficient and experienced vi and vim user) never
had the need for any "extension package". All I need to edit sources
of whatever syntax or type is the standard installation (vim/gvim in
my case).

How do you file your IRS forms?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <87cyp031bp.fsf@yaxenu.org>, Julieta Shem <jshem@yaxenu.org> wrote: >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

[...]

Personally I (as a proficient and experienced vi and vim user) never
had the need for any "extension package". All I need to edit sources
of whatever syntax or type is the standard installation (vim/gvim in
my case).

How do you file your IRS forms?

I doubt Janis has to deal in any way with the (US) IRS.

He probably doesn't even know what you are talking about.

--
Many (most?) Trump voters voted for him because they thought if they
supported Trump enough, they'd get to *be* Trump.

Similarly, Trump believes that if *he* praises Putin enough, he'll get to *be* Putin.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 1 Jun 2024 19:11:43 -0000 (UTC), Spiros Bousbouras wrote:

Scripting language , not macro language.

In Emacs, there is no difference: the macro language is the scripting
language.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v3g9tp$30ko4$4@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sat, 1 Jun 2024 19:11:43 -0000 (UTC), Spiros Bousbouras wrote:

Scripting language , not macro language.

In Emacs, there is no difference: the macro language is the scripting >language.

I don't care about "Emacs", but there *is* a difference.

Vim has both - a macro langauge and a scripting language - and they are different things that do different things.

In fact, Vim has many different scripting languages - including a brand new
one in Vim9 - that I know next to nothing about.

--
Adderall, pseudoephed, teleprompter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 1 Jun 2024 17:00:33 +0200, Janis Papanagnou wrote:

It should be noted that Vi has a lot of alternative ways to edit various
text entities.

But still, it assumes that what it is editing is text.

Emacs isn’t just a text editor, it’s an editor. I have successfully used
it to directly edit binary files.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

set noruler
set noic
set modeline
set modelines=5
set smc=10000
set ts=4
set sw=4

OK, so really basic: No line/column numbers, case-sensitive search, mode detection, syntax highlighting limits, tab spacing. A vanilla Emacs
roughly needs

(setq line-number-mode nil)
(font-lock-mode 1)
(setq tab-width 4)

for similar behaviour.

Re (how common it is in vi-land to use a bunch of extension packages):

none (in my case), just a few simple adjustments and user settings

Re (and have configuration files larger than, say, 10 kB):

none (in my case and I've not seen such large files for Vim; YMMV)

Interesting. As I suspected else-thread, maybe that is due to the availability/lack of powerful extension languages in the early days of Emacs/vi: The "tweakers" and "vanilla" people neatly separated on
different sides of the fence, with enough opportunity for holy wars.
(-:

(e.g. a diary/log book with time stamps, specific formatting, etc.);
all this done with a couple macros in Vim. - But mind that this is
exceeding pure editing; it's actually creating specific applications
using the Vim tool.

Sounds like "Org",

https://orgmode.org/features.html

one of the most popular extensions for Emacs. And a large one ...

In fact, Org is responsible for a lot of my configuration
settings. Another big chunk is for "dired" ("directory editing", a file
manager for/in Emacs). And another one for "gnus", an e-mail and usenet
client for/in Emacs). The rest is mostly small convenience stuff,
shortcuts etc. In total, it is about 10 kB.

While going through it, I notice that some dust has accumulated over the decades. It might be an interesting project to restart from scratch
(vanilla Emacs) and see what settings I really feel are necessary. Some
Emacs defaults have changed, as might have my personal preferences.

Thanks for the inspiration and best regards!

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v3gj5c$31rjc$10@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sat, 1 Jun 2024 17:00:33 +0200, Janis Papanagnou wrote:

It should be noted that Vi has a lot of alternative ways to edit various
text entities.

But still, it assumes that what it is editing is text.

Emacs isnt just a text editor, its an editor. I have successfully used
it to directly edit binary files.

As does Vi(m). So, no diff.

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/CLCtopics

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02.06.2024 03:50, Lawrence D'Oliveiro wrote:

On Sat, 1 Jun 2024 17:00:33 +0200, Janis Papanagnou wrote:

It should be noted that Vi has a lot of alternative ways to edit various
text entities.

But still, it assumes that what it is editing is text.

Emacs isn’t just a text editor, it’s an editor. I have successfully used it to directly edit binary files.

As Kenny already said, this is no difference.

The more "important" difference is the observation that Emacs is not
only an editor but much more. (I don't need that so I don't use it.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01.06.2024 23:07, Kenny McCormack wrote:

In article <87cyp031bp.fsf@yaxenu.org>, Julieta Shem <jshem@yaxenu.org> wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

[...]

Personally I (as a proficient and experienced vi and vim user) never
had the need for any "extension package". All I need to edit sources
of whatever syntax or type is the standard installation (vim/gvim in
my case).

How do you file your IRS forms?

I doubt Janis has to deal in any way with the (US) IRS.

He probably doesn't even know what you are talking about.

Indeed. (Both assumptions are correct.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02.06.2024 09:58, Axel Reichert wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

set noruler
set noic
set modeline
set modelines=5
set smc=10000
set ts=4
set sw=4

OK, so really basic: No line/column numbers, case-sensitive search, mode detection, syntax highlighting limits, tab spacing.

Note: For line numbers I use :set nu or :set nonu respectively.

The tab stop is different from shift width setting; you can control
both separately (but don't need to).

The syntax highlighting (context size) setting is due to an effect
depending on how syntax highlighting is done in Vim. There's no
built-in syntax knowledge in Vim, rather it has a simple language
that operates on language specific syntax files (that usually are
part of the installation but can be extended for own languages).[*]
There's some context considered for the syntax heuristics that in
my case proved to be too narrow so I extended it (from the default
to a larger value).

I started with much less configuration settings (only 'modeline'),
but extended it as it seems to fit for convenience.[**]

[*] In my old installation there are 500+ languages supported, the
individual syntax file size depends on the language complexity; it
ranges from a handful of lines up to 2000+ lines (for perl).

[**] 'ts' and 'sw' just recently. Before that I had defined it in
the "modelines" of some files until I noticed that this setting
makes sense in 95% of my file/language types, so I defined it.
'smc' was also just a recent addition. (And I don't recall why I
have the 'noruler' thing in the file. But I don't care; it's just
a few lines of text.)

A vanilla Emacs roughly needs

(setq line-number-mode nil)
(font-lock-mode 1)
(setq tab-width 4)

for similar behaviour.

Re (how common it is in vi-land to use a bunch of extension packages):

none (in my case), just a few simple adjustments and user settings

Re (and have configuration files larger than, say, 10 kB):

none (in my case and I've not seen such large files for Vim; YMMV)

Interesting. As I suspected else-thread, maybe that is due to the availability/lack of powerful extension languages in the early days of Emacs/vi: The "tweakers" and "vanilla" people neatly separated on
different sides of the fence, with enough opportunity for holy wars.
(-:

I haven't participated and rarely was in editor NGs; in my opinion
editors are tools that should be used as it individually fits best.

WRT extension languages; I don't use any with Vim, never needed any
with Vi. There is a scripting language in Vim, though, and I know
that some folks like to use them. Since in my professional contexts
I often had to work on proprietary Unixes where only Vi was available
I tried to not rely on fancy extensions, but privately I use some of
them and appreciate that they are existing with Vim/Gvim; wouldn't
want to miss them.

(e.g. a diary/log book with time stamps, specific formatting, etc.);
all this done with a couple macros in Vim. - But mind that this is
exceeding pure editing; it's actually creating specific applications
using the Vim tool.

Sounds like "Org",

I cannot tell. A friend of mine (listed on the Vim acknowledgements
page) does a lot with such specific usages. Myself I use it just for
exiting of all sorts of texts.

https://orgmode.org/features.html

one of the most popular extensions for Emacs. And a large one ...

Oh! - I recall that the Vim macros for that haven't been much code.
(I can ask him about the details if someone's interested.)

Janis

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06.06.2024 10:23, Janis Papanagnou wrote:

On 31.05.2024 13:43, Kenny McCormack wrote:

Vim and GVIM are the same thing - just different looks. Personally, I use >> GVIM for everything. Plain VIM (in the terminal) is unusable on the
Raspberry Pi, because the colors are f***ed up. Yes, this is fixable, but >> it is not worth the trouble.

Just stumbled across a possible (simple) solution for that in the Vim manual...

[...]
If Vim guessed wrong the text will be hard to read. To solve this,
set the 'background' option.

For a dark background:
:set background=dark
And for a light background:
:set background=light

Make sure you put this _before_ the ":syntax enable" command, [...]

So it might be just an entry in your .vimrc file.

And I suppose also another one in your .gvimrc file if you have
different bg-colors on command line and in the Gvim window.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31.05.2024 13:43, Kenny McCormack wrote:

Vim and GVIM are the same thing - just different looks. Personally, I use GVIM for everything. Plain VIM (in the terminal) is unusable on the Raspberry Pi, because the colors are f***ed up. Yes, this is fixable, but
it is not worth the trouble.

Just stumbled across a possible (simple) solution for that in the Vim
manual...

[...]
If Vim guessed wrong the text will be hard to read. To solve this,
set the 'background' option.

For a dark background:
:set background=dark
And for a light background:
:set background=light

Make sure you put this _before_ the ":syntax enable" command, [...]


So it might be just an entry in your .vimrc file.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v3rrm0$1e6d7$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 31.05.2024 13:43, Kenny McCormack wrote:

Vim and GVIM are the same thing - just different looks. Personally, I use >> GVIM for everything. Plain VIM (in the terminal) is unusable on the
Raspberry Pi, because the colors are f***ed up. Yes, this is fixable, but >> it is not worth the trouble.

Just stumbled across a possible (simple) solution for that in the Vim >manual...

[...]
If Vim guessed wrong the text will be hard to read. To solve this,
set the 'background' option.

For a dark background:
:set background=dark
And for a light background:
:set background=light

Thanks, but the main problem is that I have a zillion of the little
buggers, so I'd have to change it everywhere. That's the part that is too
much trouble. Then I'd have to remember to undo it when not on a Pi or
when the Pi people change things up - as they frequently do.

There was another "solution" posted here a while back - that I played with
a bit - it seemed to work. It was something like set tc_Col=0 or something like that - which inhibited all coloring, leaving everything black and
white.

--
"The most unsettling aspect of my atheism for Christians is
when they realize that their Bible has no power to make me
wince. They are used to using it like a cattle prod to get
people to cower into compliance." - Author unknown

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)