Pmate Editor

[Elan Paznesh]

Hi,

if anyone here recalls the dos editor pmate (was distributed by Digital
Research some ten or so years ago), pls. let me know! Ten years later and
it still comes back to haunt me.

Perhaps there is a version available somewhere online?

[steve.z...@gmail.com]

Try notepad++. Runs on Windows platforms. You can record keystroke macros, if that's the feature you're missing from pmate. (It's now 2013)

[siam...@gmail.com]

Hi there. It was the first decent Editor I every used. Small (24k .com) and fast. Full Screen mode and line editor mode. Also had macro language. I still have copies of it running on DOS (yes I have DOS) and XP-Pro. It is my goto editor when I need to do alot of text manipulation on many files, fast. I know you can use sed and many such unix tools strung along. But pmate has a special place for me. This is 20 years on from your email. I donno if it will reach you. But if you need a copy, let me know. I managed to reach the original programmer to see if he still had the source code, alas! he had not kept it.

Cheers

Siamak

[Gyurika Semjén]

Hi there. It was my absolute favorit program editor between in the ´80-s.
30 years later... It moved me.

Please, send me a copy!

Cheers

Gyurika

[solan...@gmail.com]

Yay! Long Live PMATE! Even though the year is 2017, and I am writing this response on a MacBook Pro, I still use it every single day, as I write all my source code and numerous text documents in MS-DOS (actually Windows 98SE in DOS mode). I love its simplicity and power of its macro language. I even have PMATE on this Mac - running in a WIn98SE/DOS implementation in Fusion 8!

Brian

[byte...@googlemail.com]

I have long ago lost my copy of PMate - probably when I moved to Mac - where can I get a copy? And a manual? I’m always telling people about how good it was - so much better than anything else that I’ve used since.

[cosys...@gmail.com]

On Monday, 30 October 2017 17:13:05 UTC+1, byte...@googlemail.com wrote:
> I have long ago lost my copy of PMate - probably when I moved to Mac - where can I get a copy? And a manual? I’m always telling people about how good it was - so much better than anything else that I’ve used since.

Oh yeah.... Who could ever forget this awesome DOS editor, which was in my opinion the only decent editor in those days. I LOVED it! But, in the late eighties, it became unusable for me, because of long filenames and other issues (PMate needs 8.3 filename convention and won't run on Win32 platforms). However, I still store the latest copy in a save place.

I was very desperate that time and struggled hard to find an alternative. The only worthy replacement for PMate was Vi/Vim, which I use since then. I would recommend this editor to PMate fans. Although the commands are completely different, there is a structural similarity, like mode switching (command/insert/replace) and macro capability.
Vim is well maintained, fully featured and available for almost every platform. And it is free. Watch out for it.

[I...@papet.com]

Le mercredi 13 novembre 1996 09:00:00 UTC+1, Elan Paznesh a écrit :

> Hi,
>
> if anyone here recalls the dos editor pmate (was distributed by Digital
> Research some ten or so years ago), pls. let me know! Ten years later and
> it still comes back to haunt me.
>
> Perhaps there is a version available somewhere online?

HELLO
i have versions of pmate (since original distribution by PHOENIX COMPAGNIE) and documentation.
please contact for best partage
alain bordeaux FRANCE

[downin...@gmail.com]

Can anyone who is interested in Pmate (or Zmate) please contact me: nick "AT" ndcode "DOT" org.

I have a solution to the long filenames issue which works in Windows 98. It is a TSR (Terminate-and-Stay-Resident) program called XLLFN.COM, this stands for "translate long filenames".

What XLLFN does is to translate the INT 21H calls made by PMATE.COM, such as INT 21H with AX=3D02H which asks MS-DOS to open a file, into the corresponding long-filename INT 21H calls. The translation is transparent to PMATE and it works very well. XFMy Long Filename.txt$$ works fine. I cannot remember if the functions like directory listing work; I think they do.

A slight limitation with XLLFN is that it only works after Windows 98 has been loaded. So if you booted into DOS by changing the MSDOS.SYS file to stop the automatic loading of Windows 98 then long filenames will not be available until you load Windows 98. This is a limitation of Microsoft's underlying implementation. As to the DOS Box in Windows NT-derived systems such as Windows XP, I do not know if they support TSRs or long filenames. They might.

Another thing that I have done, if I can find it, is to make a soft-copy of the PMATE manual in HTML format. I did this by simply typing in the entire manual. I won't bother to go looking for this document in my archives unless somebody wants it. Similarly the XLLFN program, which I do not use anymore.

Anyway, I am now a Linux user and I use vim as suggested above, but I have not lost hope that PMATE may some day be available again as my daily editor.

People here might not be aware that PMATE (originally ZMATE) is a derivative of the TECO editor that was available on DEC mainframes since the early 70s.

PMATE does have some new features relative to TECO:

1. The auto buffering, which makes it read more from the file when cursor tries to move past the start or end of buffer T, or in global commands like UStext$$.

2. Visual editing and the instant commands. In TECO all editing is done from the command area with commands such as Itext$$, you cannot type directly into the document or use instant commands such as arrow keys, Ctrl-T, Ctrl-E, Ctrl-Z. Still, TECO can optionally provide a visual display similar to PMATE's.

3. The word wrap, and Ctrl-F lines which allow to set word-wrap, tab stops and so on, embedded in the document and local to specific parts of the document.

There are also some strange incompatibilities such as XFmyfile.txt$$ is called EBmyfile.txt$$ in TECO, and must be followed by Y$$ to read the first page of the file which is automatic in PMATE. The L commands work normally but for some reason the M command does not work in Teco, there may be an equivalent? Also, TECO has a more advanced scheme of buffers (I think 36 buffers not just 10) and seems to merge the meaning of the Q-variables and the buffers in some way.

So it would be potentially possible to add these features to one of the TECO implementations. I have source for a nice minimal TECO from Ultrix and a much more overblown and complex TECO called TECOC. If I was going to add the PMATE features I would probably add it to the minimal TECO from Ultrix. However, it seems like a big job since many incompatibilities would need to be resolved.

Another possibility would be to disassemble the PMATE.COM (for MS-DOS) or the ZMATE.COM (for CP/M) executable and convert it to C. I have made fairly significant progress on the disassembly in various bursts at different times.

Indeed, back in the DOS days I created a 32-bit PMATE.COM which ran under a DOS extender and could edit multi-megabyte files, but unfortunately it would occasionally crash for some reason, so it wasn't useful for day-to-day use.

I think I did another one in C for MAC OSX which contained a Z80 emulator and allowed to run ZMATE from the MAC OSX command line and edit files, I'm not sure if I would be able to find this again, but possibly it's in my archives.

Another thing I did was to analyze CONPMATE.COM and extract the macro from the permanent macro area that runs when you run CONPMATE.COM on a configuration file. The macro had been minified so it was quite hard to read, but once I indented it properly and made it readable again, it was clear that CONPMATE uses the "poke" command to change various locations in the PMATE.COM executable and hence change things like the screen size, and so on. It also installs the table which maps instant commands to permanent macros. Unfortunately, I then lost the reverse-engineered CONPMATE macro in a disk crash or similar.

Really, the conversion effort would have to be re-started from scratch with a Linux and C target if it was to be any use. I can't really commit to this project now, but if somebody else wants to, I can hand over what I have.

Anyway, let me have your thoughts if anyone is still reading this discussion.

cheers, Nick

[a.andre...@gmail.com]

On Tuesday, 20 December 2016 04:00:08 UTC+11, siam...@gmail.com wrote:
> Hi there. It was the first decent Editor I every used. Small (24k .com) and fast. Full Screen mode and line editor mode. Also had macro language. I still have copies of it running on DOS (yes I have DOS) and XP-Pro. It is my goto editor when I need to do alot of text manipulation on many files, fast. I know you can use sed and many such unix tools strung along. But pmate has a special place for me. This is 20 years on from your email. I donno if it will reach you. But if you need a copy, let me know. I managed to reach the original programmer to see if he still had the source code, alas! he had not kept it.
>

Given it's a 24k .COM, would not be hard to reverse engineer it. Look for byte value 55h to delineate the functions. [That should bring back memories for some]

PUSH BP
MOV BP, SP
...
POP BP
RET

ahhh the memories.

[ivan watson]

Hi there - as tis thread is pretty old I dont know if anyone will see it, but... I am also one of those lovers of good old PMATE and have found a very old copy but it can run in windows. Anyone have one that runs in windows? -
Thanks!
Ivan

[Daiyu Hurst]

On Wednesday, November 13, 1996 at 3:00:00 AM UTC-5, Elan Paznesh wrote:
> Hi,
> if anyone here recalls the dos editor pmate (was distributed by Digital
> Research some ten or so years ago), pls. let me know! Ten years later and
> it still comes back to haunt me.
> Perhaps there is a version available somewhere online?

Originally called MATE (Mike Aronson's Text Editor), Mike either sold it to Phoenix Associated in the early days, or worked for them.

I bought the retail package, which included a nice manual. Lost now. I had the original 8080 version which I used on two machines, the Molecular Supermicro which was a "network in a box", it had a Z-80 service processor. and a series of Z-80 "application processors", each of which were connected to either terminals or modems. It's OS was a hybrid of CP/M and MP/M-11.

I also used the 8080 version on the Televideo TS-850, an all-in-one Z-80 based PC that ran CP/M. At the company where I worked, I enhanced CP/M using ZCPR/2.

As others noted, Phoenix had other products, and while I lost the 8080 stuff, I still have the 8086 linker and library editor.

-Dai

[Eli the Bearded]

In comp.editors, Daiyu Hurst <daiyu...@gmail.com> wrote:
> On Wednesday, November 13, 1996 at 3:00:00 AM UTC-5, Elan Paznesh wrote:

That's a long time ago.

>> if anyone here recalls the dos editor pmate (was distributed by Digital
>> Research some ten or so years ago), pls. let me know! Ten years later and
>> it still comes back to haunt me.
>> Perhaps there is a version available somewhere online?

Looks like may be _now_. This DOS editor called PMATE was uploaded
February 2021, but I can't tell if it is the same one. The details
here imply this is a French language program.

https://archive.org/details/PMATE
https://archive.org/download/PMATE

> Originally called MATE (Mike Aronson's Text Editor), Mike either sold it
> to Phoenix Associated in the early days, or worked for them.

Searching for "Phoenix mate" at archive.org turns up a ton of stuff,
including the ship's lot of the whaling bark Phoenix, covering some months
of the year 1858[*]. The only match on the CD ROM archives appears to
be separate programs in one collection each matching one of the words.

> I bought the retail package, which included a nice manual. Lost now. I
> had the original 8080 version which I used on two machines, the
> Molecular Supermicro which was a "network in a box", it had a Z-80
> service processor. and a series of Z-80 "application processors", each
> of which were connected to either terminals or modems. It's OS was a
> hybrid of CP/M and MP/M-11.
>
> I also used the 8080 version on the Televideo TS-850, an all-in-one Z-80
> based PC that ran CP/M. At the company where I worked, I enhanced CP/M
> using ZCPR/2.
>
> As others noted, Phoenix had other products, and while I lost the 8080
> stuff, I still have the 8086 linker and library editor.

Have you considered uploading to archive.org?

[*] The bad weather leading to the sinking appears to start on page 28.
The 19c cursive is hard for me to follow in places, as is the curt
style of log books of that era.
https://archive.org/details/ms220log197/page/n27/mode/2up

Elijah
------
there are quite a few whaling log books there

[Andrew Clarke]

On Tuesday, 27 July 2021 at 11:15:58 am UTC+10, Eli the Bearded wrote:

> Looks like may be _now_. This DOS editor called PMATE was uploaded
> February 2021, but I can't tell if it is the same one. The details
> here imply this is a French language program.
>
> https://archive.org/details/PMATE
> https://archive.org/download/PMATE

This upload may be the work of "I...@papet.com" who posted at 31 Dec 2017, 8:49:13 am.

Also, "downin...@gmail.com" posted at 3 Nov 2018, 12:39:19 pm:

>Can anyone who is interested in Pmate (or Zmate) please contact me: nick "AT" ndcode "DOT" org.

Don't know how I missed Nick's posting; but sure, I'll bite! I was going to reverse engineer it myself if ever a copy turned up. I'll try contacting him directly if that email still works, otherwise, Nick, let's make contact thru here?

Cheers,
Andrew Clarke

[Brian D Steel]

Hi folks,

Well the year is 2023, and FWIW, I *still* use PMATE on a near-daily basis! It's one of the reasons I run an MS-DOS system (actually the DOS subsystem from Windows 98SE, without the GUI) in a virtual machine both on my Windows 11 PC and Intel MacBook Pro.

Simply, I have never found a macro-equipped editor for simple ASCII text which works as well, on either Windows or the Mac. Nearly all current "text" editors for either platform are vastly bloated with syntax colouring, debugging, project hierarchies, etc.

I would love to find a Windows equivalent, to stop having to switch in and out of DOS boxes, but try as I might, I have yet to discover anything that will do what I can in PMATE!

Any suggestions?!

Best,

Brian D Steel

[Janis Papanagnou]

On 08.03.2023 16:17, Brian D Steel wrote:
> Hi folks,
>
> Well the year is 2023, and FWIW, I *still* use PMATE on a near-daily
> basis! It's one of the reasons I run an MS-DOS system (actually the
> DOS subsystem from Windows 98SE, without the GUI) in a virtual
> machine both on my Windows 11 PC and Intel MacBook Pro.
>
> Simply, I have never found a macro-equipped editor for simple ASCII
> text which works as well, on either Windows or the Mac. Nearly all
> current "text" editors for either platform are vastly bloated with
> syntax colouring, debugging, project hierarchies, etc.

You seem to be speaking of IDEs here, not about editors. (Although
even simple editors nowadays come with syntax highlighting, but of
course you don't need to use that feature. And some editors easily
give the impression that they actually are sort of an IDE, I agree.)

>
> I would love to find a Windows equivalent, to stop having to switch
> in and out of DOS boxes, but try as I might, I have yet to discover
> anything that will do what I can in PMATE!

If I understand correctly, you use a very old text editor on a very
primitive "OS".

Don't expect that we try to create such an environment and install
ancient software to find out what that is that "anything that will
do what I can in PMATE". Instead please just say what features you
expect from your editor, then I'm sure we can more accurately help.

>
> Any suggestions?!

Without further information, if powerful editing without bloat is a
requirement, I suggest to use vim/gvim. (But I have some doubts that
it fits you if only primitive [and non-modal] editors have yet been
used. But maybe gvim in "easy mode" will serve you.) It certainly
works on all the typical client platforms (Linux, Mac/OS-X, Windows).
From the hint you gave above; g/vim supports macros in various ways.
What else do you need?

That all said; if someone uses three decades the "same ol' editor"
I'd expect that a switch to something better (but less accustomed)
like any change will be hard. But let's see...

Janis

[Kenny McCormack]

In article <tuablg$vild$1...@dont-email.me>,
Janis Papanagnou <janis_pap...@hotmail.com> wrote:
...

>That all said; if someone uses three decades the "same ol' editor"
>I'd expect that a switch to something better (but less accustomed)
>like any change will be hard. But let's see...

Keep in mind that 3 decades from now, I [*] will probably still be using
Vim (and Gvim) as my editor. Will you be making the same deragotory cracks
about me and my "3 decades 'same ol' editor'" then?

[*] And probably you as well.

--
To my knowledge, Jacob Navia is not a Christian.

- Rick C Hodgin -

[Janis Papanagnou]

On 08.03.2023 17:50, Kenny McCormack wrote:
> In article <tuablg$vild$1...@dont-email.me>,
> Janis Papanagnou <janis_pap...@hotmail.com> wrote:
> ...
>> That all said; if someone uses three decades the "same ol' editor"
>> I'd expect that a switch to something better (but less accustomed)
>> like any change will be hard. But let's see...
>
> Keep in mind that 3 decades from now, I [*] will probably still be using
> Vim (and Gvim) as my editor. Will you be making the same deragotory cracks
> about me and my "3 decades 'same ol' editor'" then?
>
> [*] And probably you as well.
>

First; there was no offense intended! And the answer is multifold...
I cannot speak for (or about) you, just for me. I am using vi since
the 1980's, and yes, *I* certainly wouldn't _want_ to switch (for two
reasons at least; the important one is the powerful vi-concept, but
own personal habits are certainly also a factor).
Generally I observed over these decades many editors and saw people
using them. Some are repelled from complexity - and vi/vim is complex!
Some are just used to specific functionality and don't want to switch.
Both are habits to be respected. The 4+ decades old 'vi' concepts I
consider to have been "ahead of time" then, and I consider them still
outstanding even nowadays.
Concerning the DOS platform in passing I followed the tools there; e.g.
not supporting regular expressions, later only by explicitly activating
them, and so on, and so on. Usually most editing tools were primitive.
Two notable (and widely known) exceptions had been vi and emacs.[*]
Vi had always restricted itself closely to the editing process - that
was what the OP was also focusing on. Emacs had always been bulkier -
that was what the OP seems to try to avoid (remember the joke "EMACS"
= "Eight Megabytes And Constantly Swapping").
I know the human reluctance of switching, more so if the concepts are
so extremely different as a primitive WYSIWYG editor compared to a
powerful "IDE-like" Emacs or "modal" Vi/Vim/Gvim.
The intention of my post was therefore also preparing the OP to not
expect that there's a simple change with these editors if one is
accustomed to some "same ol' editor", and whether it's a good one or
not is usually a secondary factor in human decisions. In my experience.

Janis

[*] Situation may likely be different nowadays. Especially since
the IDE-centric and GUI-focused designs support other principles
and biases, e.g. for software development, and not primarily for
efficient text manipulation and text editing.

[Axel Reichert]

Janis Papanagnou <janis_pap...@hotmail.com> writes:

> I cannot speak for (or about) you, just for me. I am using vi since
> the 1980's, and yes, *I* certainly wouldn't _want_ to switch (for two
> reasons at least; the important one is the powerful vi-concept, but
> own personal habits are certainly also a factor).
> Generally I observed over these decades many editors and saw people
> using them. Some are repelled from complexity - and vi/vim is complex!
> Some are just used to specific functionality and don't want to switch.
> Both are habits to be respected. The 4+ decades old 'vi' concepts I
> consider to have been "ahead of time" then, and I consider them still
> outstanding even nowadays.
> Concerning the DOS platform in passing I followed the tools there; e.g.
> not supporting regular expressions, later only by explicitly activating
> them, and so on, and so on. Usually most editing tools were primitive.
> Two notable (and widely known) exceptions had been vi and emacs.[*]

When a couple of years ago a new employee was struggling with a task I
had assigned to him, to my surprise the editor was the culprit: It
slowed down so much that efficiently editing a 300 MB file was not
possible. I recommended the "youngster" to use Emacs instead of his
current editor (gedit?). After finishing the tutorial he was hooked and
speedily completed the task. However, I felt a little bad about
"forcing" such arcane tools on a fresh colleague, so I investigated a
little using

https://en.wikipedia.org/wiki/Comparison_of_text_editors

as a reference. To my surprise, with only a couple of crucial features,

- Open Source
- Available for Windows, macOS, and Linux
- Editing of large files (> 500 MB)
- Editing of rectangles/columns
- Allows for several instances of the editor running simultaneously
- Allows for opening the same file twice (viewing different parts)
- Allows for for multiple frames/windows in the same editor instance

only the emacs and vi "editor families" remained in the game. Most of
the other contestants failed miserably with large files, and there was
not even need to assess the features for using regexes both for the
search and replace patterns (which rules out many other candidates as
well).

So there I was, the last men standing both born in 1976 (depending on
what you count as the ancestor of the families), rendering my
recommendation to my "recruit" rather reasonable (I am fine with every
vi fan). I informed him about the "bad" news, "Sorry, no newer
alternatives", but he was happily editing away ever since.

I started with emacs in 1995, and one of the good things of using a tool
for so long is that it really pays off to increase your knowledge,
especially about a tool that is so powerful, extensible, and well
documented. This way, power really grows on you.

Best regards

Axel

[Spiros Bousbouras]

On Wed, 8 Mar 2023 16:50:07 -0000 (UTC)
gaz...@shell.xmission.com (Kenny McCormack) wrote:
> In article <tuablg$vild$1...@dont-email.me>,
> Janis Papanagnou <janis_pap...@hotmail.com> wrote:
> ...
> >That all said; if someone uses three decades the "same ol' editor"
> >I'd expect that a switch to something better (but less accustomed)
> >like any change will be hard. But let's see...
>
> Keep in mind that 3 decades from now, I [*] will probably still be using
> Vim (and Gvim) as my editor. Will you be making the same deragotory cracks
> about me and my "3 decades 'same ol' editor'" then?
>
> [*] And probably you as well.

Which derogatory remarks did Janis make ? The only slightly negative (but
correct) thing he said is that "will do what I can in PMATE" does not provide
any useful information.

I have been using (g)vi(m) for close to 20 years and have written thousands
of lines of vimscript code some of which I use daily so that alone would
make it difficult for me to switch unless the new editor can also interpret
vimscript .Having said that , I'm somewhat curious to try out an IDE ,
ideally on a sizeable software project , to see what the experience is like.
I haven't actively searched the matter but I have only seen Eclipse for
Linux and I don't want to install Java dependencies.

Are IDEs on topic on this group ?

--
vlaho.ninja/prog

[Janis Papanagnou]

On 10.03.2023 12:13, Spiros Bousbouras wrote:
>
> [...] Having said that , I'm somewhat curious to try out an IDE ,

> ideally on a sizeable software project , to see what the experience is like.
> I haven't actively searched the matter but I have only seen Eclipse for
> Linux and I don't want to install Java dependencies.
>
> Are IDEs on topic on this group ?

My own experience with Eclipse stems from almost 2 decades ago. As
far as editing is concerned, the problem with that IDE[*] had been
that "editing" is not the focus; it is more that language specific
features are supported, and project oriented development supported,
i.e. _it has another perspective_. Starting from simple things like
language specific syntax highlighting[**] up to providing contextual
selection lists on what item-name is to be inserted at the current
editing position. I cannot tell for Eclipse's Emacs support, but
the Vi plug-in available at that time was a horror (for [advanced]
Vi users); it was more an alibi than a sensibly implemented feature.
With that [bad] philosophy or [badly done] software architecture
design one cannot expect much from the "text editing" perspective.
With Vi (or Emacs, or ...) I can edit everything, any programming
language, any html, javascript, xml, any article, any novel, any
data formatted in any way, logfiles, structured or unstructured.
A good editor will make it possible to edit all sorts of text or
data efficiently. Those IDE editors, or (re-)implemented editors
in any other application, will not be able to do that; unless they
found an architectural design to bind external "editors of choice".
But typically each tool will require you to "learn" that specific
editor's interface, and also typically it's just a primitive subset
what usual "user-friedly" beginners' editors support. If you have
your focus only in a specific area, e.g. Java software development,
then IDEs like Eclipse support that extremely well. Only that you
don't (and certainly don't need to) edit the "classical way" here.

Janis

[*] As with so many applications that need an editing functionality,
but aren't capable of using an interface to bind an editor of choice
to it, instead decide to implement their own stripped down clones.

[**] As opposed to (e.g. vim's) externality of language specific
highlighting.

[Spiros Bousbouras]

On Fri, 10 Mar 2023 13:35:57 +0100
Janis Papanagnou <janis_pap...@hotmail.com> wrote:
> On 10.03.2023 12:13, Spiros Bousbouras wrote:
> >
> > [...] Having said that , I'm somewhat curious to try out an IDE ,
> > ideally on a sizeable software project , to see what the experience is like.
> > I haven't actively searched the matter but I have only seen Eclipse for
> > Linux and I don't want to install Java dependencies.
> >
> > Are IDEs on topic on this group ?
>
> My own experience with Eclipse stems from almost 2 decades ago. As
> far as editing is concerned, the problem with that IDE[*] had been
> that "editing" is not the focus; it is more that language specific
> features are supported, and project oriented development supported,
> i.e. _it has another perspective_. Starting from simple things like
> language specific syntax highlighting[**]

I don't like syntax highlighting because I find it distracting rather than
useful so I would be turning this off.

> up to providing contextual
> selection lists on what item-name is to be inserted at the current
> editing position.

Yes , that's one of the main things I want to try out. I don't use Java
but I would want to use it in C .So lets say I have

struct my_struct my_object ;
[...]
my_object.

and at this point I press a key and it presents me with a list of the fields
(possibly also fields of fields) that struct my_struct has and I get to
choose from a menu. Another feature I've seen in screenshots (for IDEs in
general) is that they can present you with an overview of the code like the
list of functions and you can click on one and it will take you to the code
for the function. Such things seem pleasant and I am curious to try them out.
I have seen such extensions (specifically , for context sensitive selection
from a menu and insertion) for vim (and I'm sure they exist for emacs too)
but I've never tried them.

[...]

> [*] As with so many applications that need an editing functionality,
> but aren't capable of using an interface to bind an editor of choice
> to it, instead decide to implement their own stripped down clones.
>
> [**] As opposed to (e.g. vim's) externality of language specific
> highlighting.

--
The final twist is not signaled strongly enough to give smarter audience
members a decent chance of foreseeing it.
https://www.imdb.com/review/rw0057246/

[Spiros Bousbouras]

On Fri, 10 Mar 2023 12:56:40 -0000 (UTC)
Spiros Bousbouras <spi...@gmail.com> wrote:
> On Fri, 10 Mar 2023 13:35:57 +0100
> Janis Papanagnou <janis_pap...@hotmail.com> wrote:
> > up to providing contextual
> > selection lists on what item-name is to be inserted at the current
> > editing position.
>
> Yes , that's one of the main things I want to try out. I don't use Java
> but I would want to use it in C .So lets say I have
>
> struct my_struct my_object ;
> [...]
> my_object.
>
> and at this point I press a key and it presents me with a list of the fields
> (possibly also fields of fields) that struct my_struct has and I get to
> choose from a menu. Another feature I've seen in screenshots (for IDEs in
> general) is that they can present you with an overview of the code like the
> list of functions and you can click on one and it will take you to the code
> for the function. Such things seem pleasant and I am curious to try them out.
> I have seen such extensions (specifically , for context sensitive selection
> from a menu and insertion) for vim (and I'm sure they exist for emacs too)
> but I've never tried them.

For example
https://www.vim.org/scripts/script.php?script_id=3302

[Spiros Bousbouras]

On Fri, 10 Mar 2023 13:44:51 -0000 (UTC)

And analogous for emacs :
https://github.com/m2ym/gccsense . (It took some effort to find the relevant
links in my files and that's why I didn't put it in the previous post)

The github page links to http://cx4a.org/software/gccsense/ which is no
longer available but I had checked it years ago and I was most impressed with
the amount of work the author (Tomohiro Matsuyama) had done. I may have the
details wrong but from what I remember he had modified the source code of
gcc to provide parsing information and written scripts in Emacs Lisp and
vimscript to take advantage of that. I don't know how well it works but it
is certainly an ambitious effort.

--
All these measures may seem a bit much, but there are really only 2 options: either
the organizers trust the grandmasters (as in all other tournaments) and exert no
control, or they impose tight measures. In Elista nobody trusted anybody, and so
things went the latter way.
Page 23 of "Topalov - Kramnik" by Topalov and Ginchev

[Janis Papanagnou]

On 10.03.2023 13:56, Spiros Bousbouras wrote:
>
> I don't like syntax highlighting because I find it distracting rather than
> useful so I would be turning this off.

To each his own. But I understand that. In the past I demanded that the
source code should be structured and organized in ways that it can be
maintained also without coloring and can be comfortably analyzed in b/w
printouts as well. For some (inherently cryptic) languages I consider
it helpful, though; for example for shell programs. It also helps to
locate syntactical errors early ("in statu nascendi") while typing.
Whether it's distracting depends [for me] on the chosen color set.
Vim's coloring is fine and works well for me. Only in very rare cases
I switch it off.

>
>> up to providing contextual
>> selection lists on what item-name is to be inserted at the current
>> editing position.

BTW; have a look whether your IDE supports that feature with keyboard
control (not mouse) to keep typing speed high. (Personally I hate to
be forced to the mouse and severely slow down the typing process.)

>
> Yes , that's one of the main things I want to try out. I don't use Java

> but I would want to use it in C . [...]

I have no experience with actual C supporting IDEs. Last time I used
(faintly) something like that it was ctags and the edit/compile/link/
error-edit cycle that vi(m) supports; in other words only primitive
editor features.

Janis