Discussion:
Editor of choice
(too old to reply)
HenHanna
2024-05-30 20:05:38 UTC
Permalink
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).
Lawrence D'Oliveiro
2024-05-30 20:40:55 UTC
Permalink
Post by HenHanna
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.
G
2024-05-31 10:05:30 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by HenHanna
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
Kenny McCormack
2024-05-31 11:43:52 UTC
Permalink
Post by G
Post by Lawrence D'Oliveiro
Post by HenHanna
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 -
Spiros Bousbouras
2024-05-31 16:59:21 UTC
Permalink
On Fri, 31 May 2024 11:43:52 -0000 (UTC)
Post by Kenny McCormack
Post by G
Post by Lawrence D'Oliveiro
Post by HenHanna
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.
[...]
Post by Kenny McCormack
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.
Lawrence D'Oliveiro
2024-06-01 00:24:01 UTC
Permalink
Post by Spiros Bousbouras
There is only 1 vim , 1 neovim , 1 vi .
Which is the one that uses Lua as its macro language?
Spiros Bousbouras
2024-06-01 19:11:43 UTC
Permalink
On Sat, 1 Jun 2024 00:24:01 -0000 (UTC)
Post by Lawrence D'Oliveiro
Post by Spiros Bousbouras
There is only 1 vim , 1 neovim , 1 vi .
Which is the one that uses Lua as its macro language?
Scripting language , not macro language. The answer is neovim , the other
two predate Lua and vi doesn't have a scripting language anyway (but it
supports macros).
Lawrence D'Oliveiro
2024-06-01 23:12:58 UTC
Permalink
Post by Spiros Bousbouras
Scripting language , not macro language.
In Emacs, there is no difference: the macro language is the scripting
language.
Kenny McCormack
2024-06-02 00:33:27 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Spiros Bousbouras
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
Axel Reichert
2024-06-02 05:42:09 UTC
Permalink
Post by Kenny McCormack
Post by Lawrence D'Oliveiro
Post by Spiros Bousbouras
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.
Interesting. I read some more about languages in vi and clones. It seems
that there is still the old "ex" style (giving commands with ":" as
prefix). This of course was very limited, so VimL or Vim script extended
this (YASL, Yet Another Scripting Language) in a more powerful, but
quite ideosyncratic way. Vim9 script tries to sanitize the language
somewhat (and includes compilation to byte code), but in the meantime
Neovim was forked, which includes Lua as extension language.

(Please excuse if this brief and cursory summary is way off, it was
written by an outsider with feet firmly planted in Emacs country. Feel
free to correct/comment.)

From my Emacs point of view, this all seems quite familiar. Emacs had
very early a very capable Lisp (which was a much more common language
back then) dialect for extension, which spawned tons of packages, to the
point that package managers and package repository servers were
necessary.

So no need to reinvent the editor wheel if you are unhappy, just extend
Emacs. I assume that this very early powerful extensibility caused Emacs
fans to go wild with configuration, while the more mundane extensibility
caused vi fans to stay more vanilla (sane?). This might apply to
veterans more than to newbies who came to scene later, when Vimscripting
was already firmly established. The posts of Anthony and Janis at least
point into this direction.

Years later, when even Emacs Lisp was perceived as too limiting by some
hackers, discussion about replacing Emacs Lisp by something even more
capable (Scheme, in form of the Guile dialect, or Common Lisp). This has
led to some new branches/rewrites/dead ends.

Now the "Eastern Orthodox Editors" I referred to else-thread were
extended using Rexx, also a quite fully-fledged language, and, back in
the days, rather common on OS/2 and Amiga. This choice, however, even
though there seem to be quite a lot of programmed extensions, obviously
has not prevented a slow dying of these editors, maybe because the
critical mass was too small from the start.

In my professional context (simulation of structural mechanics) the
situation is similar: There were tools with proprietary extension
languages (typically rather crippled) and others with more
common/powerful/generic ones (Lisp, Tcl, Python). The former tools over
the decades have often changed to these "better" languages as well.

From a business point of view, users who invested heavily in
customizing/extending a tool (because it is easy with a well-chosen
language) will not run to other tools as easily. This can ensure
live-long loyalty.

Best regards

Axel
Lawrence D'Oliveiro
2024-06-02 07:01:26 UTC
Permalink
Emacs had very early a very capable Lisp ...
Fun fact: the very earliest versions of Emacs predated Lisp. They were
built on a different language--TECO. If you thought Lisp syntax was weird,
TECO was even weirder.
Now the "Eastern Orthodox Editors" I referred to else-thread were
extended using Rexx, also a quite fully-fledged language, and, back in
the days, rather common on OS/2 and Amiga.
Didn’t have proper regular expressions, though.
In my professional context (simulation of structural mechanics) the
situation is similar: There were tools with proprietary extension
languages (typically rather crippled) and others with more
common/powerful/generic ones (Lisp, Tcl, Python). The former tools over
the decades have often changed to these "better" languages as well.
Moral: proprietary tools tend to be a dead end, while open-source ones are
more future-proof.
Richard Owlett
2024-06-04 11:43:11 UTC
Permalink
Post by Lawrence D'Oliveiro
Emacs had very early a very capable Lisp ...
Fun fact: the very earliest versions of Emacs predated Lisp. They were
built on a different language--TECO. If you thought Lisp syntax was weird,
TECO was even weirder.
[SNIP]
Down memory lane ;}
I ran into TECO as an engineering tech at DEC in the 70's. Though an
analog hardware person, I was engulfed by computer nuts. A web search
turned up https://almy.us/teco.html which links to versions of TECO for
Linux and other current systems. May recreationally investigate later.

In a more practical vein, later in this thread awk is discussed. Sounded
vaguely familiar. Found that Gawk is installed on my Debian system.

Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an
appropriate tool for a personal project [removing featuritis of a large
set of HTML files].

Its been so long since I last used awk, I'll effectively be starting
from scratch. Can anyone recommend a suitable tutorial?
[many many hits on a web search ;]

TIA
Janis Papanagnou
2024-06-04 12:53:59 UTC
Permalink
Post by Richard Owlett
In a more practical vein, later in this thread awk is discussed. Sounded
vaguely familiar. Found that Gawk is installed on my Debian system.
Yes, POSIX standard asks for availability of Awk; you find it
on any standard Unix.

GNU Awk is a quality tool.
Post by Richard Owlett
Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an
appropriate tool for a personal project [removing featuritis of a large
set of HTML files].
Its been so long since I last used awk, I'll effectively be starting
from scratch. Can anyone recommend a suitable tutorial?
The book you mentioned above doesn't suit you?
Post by Richard Owlett
[many many hits on a web search ;]
I have bad experience with Web tutorials and their quality. :-/

Personally I got the first edition of the original book on The
Awk Programming Language, from Weinberger, Kernighan, and Aho
(from around 1988, I think). Meanwhile there's a recent 2nd ed.
It is well written (but quite expensive). The 200 page 1st ed.
had a 20 pages tutorial and a 45 pages language description,
which had been all I needed.

Janis
Richard Owlett
2024-06-05 12:41:04 UTC
Permalink
Post by Janis Papanagnou
Post by Richard Owlett
In a more practical vein, later in this thread awk is discussed. Sounded
vaguely familiar. Found that Gawk is installed on my Debian system.
Yes, POSIX standard asks for availability of Awk; you find it
on any standard Unix.
GNU Awk is a quality tool.
Post by Richard Owlett
Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an
appropriate tool for a personal project [removing featuritis of a large
set of HTML files].
Its been so long since I last used awk, I'll effectively be starting
from scratch. Can anyone recommend a suitable tutorial?
The book you mentioned above doesn't suit you?
In a way it's too much of a good thing.
Its goal is to be an exhaustive reference for Gawk.
[note terms used: "exhaustive" AND "reference"]
I was looking for something to give "the lay of the land".
Post by Janis Papanagnou
Post by Richard Owlett
[many many hits on a web search ;]
I have bad experience with Web tutorials and their quality. :-/
*ROFL*!!!
Been there done that ... ;}
That's why I looked for guidance.
For perspective:
1. I had contact with TECO because of my analog hardware experience.
2. I was entering construction management when the 8086 was popular.
3. I was no longer in a computer environment when i486 PCs arrived.
Post by Janis Papanagnou
Personally I got the first edition of the original book on The
Awk Programming Language, from Weinberger, Kernighan, and Aho
(from around 1988, I think). Meanwhile there's a recent 2nd ed.
It is well written (but quite expensive). The 200 page 1st ed.
had a 20 pages tutorial and a 45 pages language description,
which had been all I needed.
Janis
In my search for a suitable tool I started reading about sed.
Debian manpages on awk and sed are illuminating:
1. awk - pattern-directed scanning and processing language [1]
2. sed - stream editor for filtering and transforming text [2]

The featuritis laden HTML files are chapters of the KJV Bible.
My goal is a pleasant reading experience a set of Senior Citizens with
mild vision impairment [including myself]. As "everyone" has a browser,
HTML is a logical choice. By avoiding JavaScript/CSS/etc and using only
about a half-dozen tags, compatibility issues are all but eliminated.

There are many _study_ oriented tools available.
I didn't find something that met all my idiosyncratic preferences.
Rolling my own allows me to:
1. learn HTML by doing.
2. have a pleasant reading reading experience.
3. create something useful to others.

[ https://ebible.org/Scriptures/eng-kjv2006_html.zip as starting point]







[1] https://manpages.debian.org/bookworm/9base/awk.1plan9.en.html
[2] https://manpages.debian.org/bookworm/sed/sed.1.en.html
Lawrence D'Oliveiro
2024-06-04 23:19:35 UTC
Permalink
Post by Richard Owlett
Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an
appropriate tool for a personal project [removing featuritis of a large
set of HTML files].
I wouldn’t bother. Having spent some time learning Perl, I would say Perl
does everything Awk/Gawk can do, just as concisely, and it can do more
besides.
Janis Papanagnou
2024-06-05 08:54:20 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Richard Owlett
Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an
appropriate tool for a personal project [removing featuritis of a large
set of HTML files].
I wouldn’t bother. Having spent some time learning Perl, I would say Perl
does everything Awk/Gawk can do, just as concisely, and it can do more
besides.
Yes, "it can do more"; but this is not necessarily a determining
argument for Richard (or for other folks new to Awk or Perl).

If all he wants to do is text processing why learn a tool (Perl)
that
* has a much more cryptic syntax
* is much more complex[*]
* requires a lot more time learning[**]
* is non-standard (may not be available on POSIX systems)[***]

It's certainly good to know a text processing tool like Awk.

Janis

[*] Richard already identified Awk to be the "appropriate tool",
so obviously no need for additional complexity or more features.

[**] Richard also said he already used Awk in the past, which is
an additional time saver beyond the inherent huge effort to learn
a large tool like Perl.

[***] Richard works on his his own Debian, so being non-standard
is no problem. But for people on standard POSIX systems it may be.
Richard Owlett
2024-06-05 13:09:32 UTC
Permalink
Post by Janis Papanagnou
Post by Lawrence D'Oliveiro
Post by Richard Owlett
Browsing the first ~30 pages of _Gawk: Effective AWK Programming_
[ https://www.gnu.org/software/gawk/manual/ ] suggests it would be an
appropriate tool for a personal project [removing featuritis of a large
set of HTML files].
I wouldn’t bother. Having spent some time learning Perl, I would say Perl
does everything Awk/Gawk can do, just as concisely, and it can do more
besides.
Yes, "it can do more"; but this is not necessarily a determining
argument for Richard (or for other folks new to Awk or Perl).
If all he wants to do is text processing why learn a tool (Perl)
that
* has a much more cryptic syntax
* is much more complex[*]
* requires a lot more time learning[**]
* is non-standard (may not be available on POSIX systems)[***]
It's certainly good to know a text processing tool like Awk.
Janis
[*] Richard already identified Awk to be the "appropriate tool",
so obviously no need for additional complexity or more features.
Referring to my post earlier this this morning, Awk is demoted to
a "possible tool" ;/ Suspect I was conflating features of Awk and TECO.

Currently investigating sed. I don't recall having used sed but have
used something "sed-like".
Post by Janis Papanagnou
[**] Richard also said he already used Awk in the past, which is
an additional time saver beyond the inherent huge effort to learn
a large tool like Perl.
[***] Richard works on his his own Debian, so being non-standard
is no problem. But for people on standard POSIX systems it may be.
Debian is less restrictive than M$.
Janis Papanagnou
2024-06-03 14:25:56 UTC
Permalink
Post by Axel Reichert
Interesting. I read some more about languages in vi and clones. It seems
that there is still the old "ex" style (giving commands with ":" as
prefix). This of course was very limited, [...]
Don't understate the 'ex' editor (or 'ex'-mode in Vi). You can do
powerful things out of the box that you cannot do in normal mode!

Here's a sample from a lecture I once gave (just to illustrate)[*]

:/^Start$/,$g/^# Key//Control-Key/s/Hello/Hello World/

The point of the example was editing in certain sectors and change
text only in specific text contexts across lines and sections, and
leaving other appearances untouched.

Janis

[*] Yes, it appears cryptic, but it's composed of building blocks,
and if you've learned the three concepts used in the sample it's
simply constructed.
Axel Reichert
2024-06-03 19:45:14 UTC
Permalink
Post by Janis Papanagnou
:/^Start$/,$g/^# Key//Control-Key/s/Hello/Hello World/
A little sed/awk knowledge helps. But that is the group next door. (-:

Sure, ex is the line-editing version of vi, and I have used it
occasionally, but only when forced to, because, say, the terminal was
screwed up.

Best regards

Axel
Janis Papanagnou
2024-06-03 21:18:35 UTC
Permalink
Post by Janis Papanagnou
:/^Start$/,$g/^# Key//Control-Key/s/Hello/Hello World/
An Awk solution of this 'ex' one-liner would be quite bulky.
Feel free to try that out. :-)

Also interested in provision of a 'sed' version. (Just for
comparison.)
Sure, ex is the line-editing version of vi, [...]
It's two individual (but interconnected) modes of the editor,
but their command capabilities are quite different (as can
be seen with this example).

Janis
Lawrence D'Oliveiro
2024-06-03 22:07:06 UTC
Permalink
Post by Janis Papanagnou
Post by Axel Reichert
A little sed/awk knowledge helps. But that is the group next door.
An Awk solution of this 'ex' one-liner would be quite bulky.
Whenever somebody mentions “Awk”, I immediately think “Perl does
everything that Awk does, just as concisely, and more besides”.
Janis Papanagnou
2024-06-03 22:25:53 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Janis Papanagnou
Post by Axel Reichert
A little sed/awk knowledge helps. But that is the group next door.
An Awk solution of this 'ex' one-liner would be quite bulky.
Whenever somebody mentions “Awk”, I immediately think “Perl does
everything that Awk does, just as concisely, and more besides”.
While I have a clear idea how it would look in Awk I cannot say
anything about how it would look in Perl. (I suppose the "Perl
is a functional superset of Awk" wouldn't imply that the bulky
Awk code [for the 'ex'-sample] would be more terse in Perl?)

Janis
Kenny McCormack
2024-06-04 00:20:21 UTC
Permalink
In article <v3leq9$2iqo$***@dont-email.me>,
Lawrence D'Oliveiro <***@nz.invalid> wrote:
...
Whenever somebody mentions Awk, I immediately think Perl does
everything that Awk does, just as concisely, and more besides.
Whenever I hear someone puff up Perl, I want to throw up.

Seriously, you almost never hear AWK advocacy - because there is no point
in it - we know we have the easier to use and more legible product - but
you very often see Perl people say stuff like the above quoted text. That
fact is very telling.
--
"He is exactly as they taught in KGB school: an egoist, a liar, but talented - he
knows the mind of the wrestling-loving, under-educated, authoritarian-admiring
white male populous."
- Malcolm Nance, p59. -
Eric Pozharski
2024-06-04 11:15:36 UTC
Permalink
*SKIP* [ 2 lines 2 levels deep]
Post by Kenny McCormack
Whenever I hear someone puff up Perl, I want to throw up.
You understand that any 'puff up Perl' is a troll, don't you? Mission
accomplished then.

*CUT* [ 4 lines 1 level deep]
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
Geoff Clare
2024-06-04 13:43:01 UTC
Permalink
Post by Janis Papanagnou
Don't understate the 'ex' editor (or 'ex'-mode in Vi). You can do
powerful things out of the box that you cannot do in normal mode!
Indeed, and if you combine the two you can do some amazing things.

I wrote some vi macros in 1991 for manipulating rectangular blocks.
They relied heavily on a technique whereby an ex command is
constructed on the fly using normal commands and then deleted into
a buffer and the buffer is executed. (I know vim has a built-in
feature to do this, but I wrote the macros a couple of years before
vim was ported to UNIX.)

Here's the "block delete" macro which deletes a rectangular block
from marked position `a as top left to `b as bottom right (ESC
represents an escape character):

map *d =*I:'a,'bs/ESCA\(.*\)/\1\3/ESC"***@x

It uses this =* helper macro (which also uses the same technique)
to create a "line divider" of the form \(...\)\(...\) :

map =* `a=.xI:s/^ESCA/\\(&\\)\\(/ESC"xdd`b=***@xA\)ESC

and this in turn uses an =. helper macro to create a line of "."s of
length equal to the current column position (^M is a RETURN character):

map =. mx:t.^M`xjaxESCD:s/././g

The "block copy" macro is even more complicated. It constructs a set
of ex commands to be applied, one per line, to a set of target lines,
and executes them using a single ex command of this form ('y marks the
line to which the next command should be applied):

:{range}g/^/d x|'***@x|'y+ma y

The full set of macros, along with many other sets of amazing vi macros,
were in the "comp.editors VI Archives" which can probably still be found
at one or more of the sites listed at

http://www.faqs.org/faqs/editor-faq/VI-Archive-filelist/
--
Geoff Clare <***@gclare.org.uk>
Axel Reichert
2024-06-04 16:17:10 UTC
Permalink
Post by Geoff Clare
Here's the "block delete" macro which deletes a rectangular block
from marked position `a as top left to `b as bottom right
Cool!

But I understand that this was not available out of the box in vi? I am
very sure that vim can do all this (very handy!) rectangular magic, as
can Emacs. I cannot say since when for the latter.

Many advanced features start out as a keyboard macro, which then can be
cast into the extension language of choice. For Emacs, there is even a
package which translates a keyboard macro into the equivalent Lisp
code. After all (as in vi), the keystrokes are just bound to some
low-level function call.

Best regards

Axel
Janis Papanagnou
2024-06-04 17:06:55 UTC
Permalink
Post by Axel Reichert
Post by Geoff Clare
Here's the "block delete" macro which deletes a rectangular block
from marked position `a as top left to `b as bottom right
Cool!
But I understand that this was not available out of the box in vi? I am
very sure that vim can do all this (very handy!) rectangular magic, as
can Emacs. I cannot say since when for the latter.
Yes, Vim supports visual modes where you can with Ctrl-V start spanning
a rectangular area, then typing the operator (for delete, copy, etc.).

(I think Geoff was just trying to show the possibilities of 'ex' and Vi
in general and how the modes cooperate.)

It's nonetheless an interesting sample how he uses the markers `a etc.
Post by Axel Reichert
Many advanced features start out as a keyboard macro, which then can be
cast into the extension language of choice. For Emacs, there is even a
package which translates a keyboard macro into the equivalent Lisp
code. After all (as in vi), the keystrokes are just bound to some
low-level function call.
I have a different feeling how to accurately describe how Vi operates.
Consider a command like "A 5 d 2 f* (I inserted spurious spaces just
for an easier detection of the parts). As "low-level function" we can
consider just the operator 'd' (delete). This is more like a language
[buffer] [count] {operator} [movement] with 'movement' being another
language entity like, say, [count] {move}. It's not that any keystroke
will trigger a low-level function (move or edit) as you see in other
editor designs. The example I showed activates buffer A for appending
the text that gets to be deleted, from the current cursor position up
to the target of the movement, which here is the second '*' found on
the rest of the line. This orthogonality with building-blocks is an
essential constituent of the power of Vi editing.

Janis
Spiros Bousbouras
2024-06-04 17:31:29 UTC
Permalink
On Tue, 4 Jun 2024 19:06:55 +0200
Post by Janis Papanagnou
I have a different feeling how to accurately describe how Vi operates.
Consider a command like "A 5 d 2 f* (I inserted spurious spaces just
for an easier detection of the parts). As "low-level function" we can
consider just the operator 'd' (delete). This is more like a language
[buffer] [count] {operator} [movement] with 'movement' being another
language entity like, say, [count] {move}. It's not that any keystroke
will trigger a low-level function (move or edit) as you see in other
editor designs. The example I showed activates buffer A for appending
the text that gets to be deleted, from the current cursor position up
to the target of the movement, which here is the second '*' found on
the rest of the line. This orthogonality with building-blocks is an
essential constituent of the power of Vi editing.
Register a , not buffer A .Note that :registers shows them in low case
letters.
Janis Papanagnou
2024-06-04 18:28:49 UTC
Permalink
Post by Spiros Bousbouras
On Tue, 4 Jun 2024 19:06:55 +0200
[... about "A ...]
Register a , not buffer A .
Yes, "register" not "buffer". - Thanks!
Post by Spiros Bousbouras
Note that :registers shows them in low case letters.
Yes, they can only use one representation for the register name
since "a and "A respectively identify the _same_ register,
there's only a functional difference that using the lower case
letters will set the respective register while using the upper
case letter will append to that register.

Janis
Janis Papanagnou
2024-06-04 19:00:09 UTC
Permalink
Post by Janis Papanagnou
Post by Spiros Bousbouras
On Tue, 4 Jun 2024 19:06:55 +0200
[... about "A ...]
Register a , not buffer A .
Yes, "register" not "buffer". - Thanks!
Sorry, audience! I got confused Spiros' post. - Despite Vim's
'registers' command it's officially called "buffer".[*]

The term "register" isn't mentioned at all in the POSIX document.

And don't confuse the term "buffer" with the term "edit buffer".
(POSIX differentiates these.)

In my Vi/Vim lecture document I used (coined?) the term "paste-
buffer" to better differentiate it from "buffer" or "edit buffer".

Janis

[*] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
Spiros Bousbouras
2024-06-05 21:31:53 UTC
Permalink
On Tue, 4 Jun 2024 21:00:09 +0200
Post by Janis Papanagnou
Post by Janis Papanagnou
Post by Spiros Bousbouras
On Tue, 4 Jun 2024 19:06:55 +0200
[... about "A ...]
Register a , not buffer A .
Yes, "register" not "buffer". - Thanks!
Sorry, audience! I got confused Spiros' post. - Despite Vim's
'registers' command it's officially called "buffer".[*]
The term "register" isn't mentioned at all in the POSIX document.
Interesting. I wonder which vi clones call it "buffer" and which
"register". There may even exist more terminologies for all I know.
Post by Janis Papanagnou
And don't confuse the term "buffer" with the term "edit buffer".
(POSIX differentiates these.)
In my Vi/Vim lecture document I used (coined?) the term "paste-
buffer" to better differentiate it from "buffer" or "edit buffer".
Janis
[*] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
Janis Papanagnou
2024-06-06 00:13:17 UTC
Permalink
Post by Spiros Bousbouras
On Tue, 4 Jun 2024 21:00:09 +0200
Post by Janis Papanagnou
The term "register" isn't mentioned at all in the POSIX document.
Interesting. I wonder which vi clones call it "buffer" and which
"register". There may even exist more terminologies for all I know.
Personally I think that both terms are no good choice; in my ears they
Post by Spiros Bousbouras
Post by Janis Papanagnou
In my Vi/Vim lecture document I used (coined?) the term "paste-
buffer" to better differentiate it from "buffer" or "edit buffer".
Also; generally I consider a "register" (in IT context) a small entity
and "buffer" as something large (certainly larger than a "register").
And the "paste buffer" ("register", "buffer") in Vi/Vim can hold very
large entities, so some sort of "buffer" fits better (IMO).

I used the "paste" prefix to remove the unfortunate genericity of the
term (as POSIX used the "edit" prefix for the edit buffer).

Janis
Lawrence D'Oliveiro
2024-06-04 23:18:04 UTC
Permalink
Post by Spiros Bousbouras
Register a , not buffer A .
Interesting that Emacs also uses the term “register”. Here the term
actually came from TECO, where they were called “Q-registers” because they
were accessed with the “Q” command. There were 26 of them, and each one
held an integer and a string. Notice that this matches the Emacs concept,
too.

Does vi/vim also derive its terminology from the same source, I wonder?
Janis Papanagnou
2024-06-05 08:26:41 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Spiros Bousbouras
Register a , not buffer A .
Interesting that Emacs also uses the term “register”. Here the term
actually came from TECO, where they were called “Q-registers” because they
were accessed with the “Q” command. There were 26 of them, and each one
held an integer and a string. Notice that this matches the Emacs concept,
too.
Does vi/vim also derive its terminology from the same source, I wonder?
Can't tell for [origin of] Vim terminology. But for Vi, as already
said, the official (POSIX) terminology is "buffer" (not "register").
It's likely, though, that Bram has chosen Vim terminology from some
existing source since the official term "buffer" may be confusing.

Janis
Janis Papanagnou
2024-06-01 10:55:07 UTC
Permalink
[comp.lang.lisp removed from x-post]
Post by Spiros Bousbouras
On Fri, 31 May 2024 11:43:52 -0000 (UTC)
Post by Kenny McCormack
Post by G
Post by Lawrence D'Oliveiro
Post by HenHanna
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.
[...]
Post by Kenny McCormack
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.)
Axel Reichert
2024-06-01 11:46:55 UTC
Permalink
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
Anthony Howe
2024-06-01 13:50:54 UTC
Permalink
Post by Axel Reichert
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.
Post by Axel Reichert
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.
Post by Axel Reichert
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.
Post by Axel Reichert
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
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
***@snert.com BarricadeMX & Milters
http://nanozen.snert.com/ http://software.snert.com/
Janis Papanagnou
2024-06-01 15:00:33 UTC
Permalink
[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
Lawrence D'Oliveiro
2024-06-02 01:50:37 UTC
Permalink
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.
Kenny McCormack
2024-06-02 11:59:29 UTC
Permalink
Post by Lawrence D'Oliveiro
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
Janis Papanagnou
2024-06-03 13:34:47 UTC
Permalink
Post by Lawrence D'Oliveiro
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
Janis Papanagnou
2024-06-01 15:21:45 UTC
Permalink
Post by Anthony Howe
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.
Post by Anthony Howe
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.
Janis Papanagnou
2024-06-01 14:17:50 UTC
Permalink
Post by Axel Reichert
As I am an adherent to the other editor, this reminds me on the
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
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.)
Post by Axel Reichert
Best regards
Axel
Julieta Shem
2024-06-01 19:33:30 UTC
Permalink
Janis Papanagnou <janis_papanagnou+***@hotmail.com> writes:

[...]
Post by Janis Papanagnou
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?
Kenny McCormack
2024-06-01 21:07:05 UTC
Permalink
Post by Julieta Shem
[...]
Post by Janis Papanagnou
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.
Janis Papanagnou
2024-06-03 13:37:26 UTC
Permalink
Post by Kenny McCormack
Post by Julieta Shem
[...]
Post by Janis Papanagnou
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
Axel Reichert
2024-06-02 07:58:57 UTC
Permalink
Post by Janis Papanagnou
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.
Post by Janis Papanagnou
=> none (in my case), just a few simple adjustments and user settings
=> 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.
Post by Janis Papanagnou
(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
Janis Papanagnou
2024-06-03 14:13:46 UTC
Permalink
Post by Axel Reichert
Post by Janis Papanagnou
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.)
Post by Axel Reichert
A vanilla Emacs roughly needs
(setq line-number-mode nil)
(font-lock-mode 1)
(setq tab-width 4)
for similar behaviour.
Post by Janis Papanagnou
=> none (in my case), just a few simple adjustments and user settings
=> 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.
Post by Axel Reichert
Post by Janis Papanagnou
(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.
Post by Axel Reichert
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
Post by Axel Reichert
[...]
Janis Papanagnou
2024-06-06 08:23:27 UTC
Permalink
Post by Kenny McCormack
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
Janis Papanagnou
2024-06-06 08:25:50 UTC
Permalink
Post by Janis Papanagnou
Post by Kenny McCormack
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.
:set background=dark
: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.
Post by Janis Papanagnou
Janis
Kenny McCormack
2024-06-08 03:45:02 UTC
Permalink
Post by Janis Papanagnou
Post by Kenny McCormack
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.
:set background=dark
: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
Loading...