Alternatives to DrRacket

[Stephen De Gabrielle]

Hi,

I’ve noticed some list members use other editors or IDE’s. 

I know two big reasons for using a complex tool is it’s stickiness factors; normally a combination of familiarity (hence speed) with a lot of powerful features and non-transportable customisation.

Putting stickiness factors aside, what features in other editors/IDE’s would you like to see in DrRacket?

Kind regards,

Stephen

--

Kind regards,
Stephen
--
Ealing (London), UK

['Royall Spence' via users-redirect]

One thing I appreciate about racket-mode in emacs is the more detailed syntax highlighting. I've attached two screenshots of the same code in emacs and DrRacket. I think what's happening here is that racket-mode highlights `for-clause` names and function applications (sometimes?) while DrRacket does not. I might be misunderstanding what I'm looking at.

Looking at the two screens, I didn't realize how much DrRacket was highlighting until I tried to describe the differences. Now I've adjusted DrRacket to match my emacs colors and find the code a bit easier to navigate. The default dark colors in DrRacket seem to prefer bolding over color change, which is less distinct to me.

I've got to say, though, that unlike most other IDEs (for any language), DrRacket actually does the things it claims to do and isn't a broken mess.

--

You received this message because you are subscribed to the Google Groups "Racket Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Neil Van Dyke]

DrRacket is never going to be able to do everything as well as Emacs
(and DrRacket can do some things a lot better than Emacs), but a few
small conveniences that I'd like to see in DrRacket when I use it:

* Visually distinguish identifiers that start special syntax separate
from `#lang racket/base` (or whatever Scheme-like lang), so, when
reading code, you know whether some identifier you don't recognize JUST
CHANGED ALL THE RULES.  See black bold variable names in screenshot:
http://www.neilvandyke.org/temporary/20171126-quack.png

* Visually distinguish identifiers that define top-level names
(variables, syntax extensions, unhygienic structs ahem, etc.).  See blue
in screenshot.  I often visually scan for these names, and making them
more prominent helps.  (Non-top-level, such as in `let` forms, would
also be nice, though I don't have Quack doing that, and Quack just uses
regexp kludges for the top-level ones.)

* Have Emacs-like "filling" of paragraphs of text in comments, including
support for prefixed paragraphs like bulleted lists.  I sometimes make a
lot of multiline TODO and code-explanatory comments, and as a compromise
with the simple text-file representation of source code, and considering
various 80-column tools and screen sizes that might be involved, I try
to keep most of the code within the historical 79 columns. So, after I
touch comments in DrRacket, I have to go to Emacs to re-fill them.

* Have a "tidy" feature like Quack's, which converts tabs&formfeeds to
spaces, removes extraneous whitespace (ends of lines, multiple blank
lines, beginning and end of file), and reindents the entire buffer. 
(This doesn't do automatic comment-filling in Emacs, because sometimes
that requires human discretion or crafting, and can be a mess if the
code already wasn't written for filling (e.g., if it loses some other ad
hoc formatting, and ends up blending paragraphs together, destroying
tables and ASCII art, etc.)

* Emacs-like indenting of comments with 1-semicolon (i.e., indented to a
column independent of indent level and whether there is preceding code
on the line; the column position is either a fixed one (40), or, if the
preceding line has a 1-semicolon comment beyond that fixed column, then
the column of that preceding comment).  This is an old Emacs
convention.  I could live without this, but DrRacket's 1-semicolon
comments indenting to the code indent level means that they get messed
up when indenting in Emacs or DrRacket, or when doing Quack tidy.

Also, for experienced use of DrRacket (not for intro students), I'd like
to get rid of some of the clutter outside of the text widgets, such as
buttons and indicators that I don't need.  And I wish that various
message subwindows that pop into the frame and then need their close
boxes to be clicked would go away automatically (see how Emacs uses the
message&minibuffer area, does isearch, etc.).

[David Thrane Christiansen]

Hi Stephen,

> I’ve noticed some list members use other editors or IDE’s.
>
> I know two big reasons for using a complex tool is it’s stickiness factors;
> normally a combination of familiarity (hence speed) with a lot of powerful
> features and non-transportable customisation.
>
> Putting stickiness factors aside, what features in other editors/IDE’s
> would you like to see in DrRacket?

I use both Emacs and DrRacket for Racket code, Emacs for basically
everything else.

As you surmise, there are generally-useful Emacs packages and features
that keep me there. In particular:

1. Paredit: The DrRacket Paredit emulation is different enough to make
it much less convenient. In particular, it leaves lots of extra closing
parens floating around.

2. helm-ag: This lets me very quickly search everything in the closest
Git repo, without it having to be a big ceremony.

3. Magit: This is the best interface to Git on the planet, and having it
in the same editor is much more convenient than switching over to Emacs
just to Git.

4. Speed. Emacs is very snappy, while DrRacket sometimes noticably lags
after input.

5. General editing: Emacs has things like keyboard macros and the
ability to write a quick little on-off bit of elisp that make
large-scale editing far more convenient. As far as I can tell, I'd need
to write a DrRacket tool to make this happen, and that involves a lot
more ceremony than a quick defun in *scratch*. And filling is hard to do
without.

6. M-/ for autocomplete of anything open anywhere.

7. It works the same way for everything. I get all the same features
whether I'm working on Racket, Haskell, Idris, LaTeX, Agda, or a
Makefile (that's about in the order of frequency of editing for me).
It's great to have everything that makes sense in one work well in the
other.

8. Commands like motion and isearch work *everywhere*, not just in text
buffers. So there's no need for a separate search mechanism for things
like settings.

racket-mode supports some things that DrRacket doesn't, above and beyond
standard Emacs. In particular,
1. The ability to get a REPL in the context of a particular submodule,
which makes developing things like tests more convenient.

2. I can put custom indentation rules for my macros into a
.dir-locals.el so that they don't pollute a global indentation config.

3. There's a keybinding to cycle through paren shapes for the
surrounding expression, () -> [] -> {} -> (). I use this constantly.

So why use DrRacket?

1. Good support for languages like Scribble. I never got that working to
my liking in Emacs.

2. The macro stepper is extremely handy when it works, and being able to
inspect syntax objects in the interactions pane is wonderful when the
macro stepper doesn't work.

3. It's easier to create close integrations between a #lang and its
interface. For example, binding arrows, adding tooltips showing types,
and designing interactive editing commands written in Racket. Doing this
in Emacs is not nearly as fun (and I know, I've done it for Idris).

4. Students use it, so they should be supported.

5. Much better control over subprocesses. It's far easier for a runaway
process in Emacs to make the computer very slow, while DrRacket stops it
when it allocates too much.

Hope that was useful. Thanks for your interest in making things even better!

/David

[HiPhish]

I use Neovim and I'm working on a Racket client for it:
https://gitlab.com/HiPhish/neovim.rkt

One of the cool features Neovim has over Vim is that it provides an API for remote processes; a client application can connect to the editor and they can communicate with each other. What that means in practice is that my Racket client allows you to write Neovim plugins in directly Racket. This would make it possible for example to re-use parts of DrRacket to write analogous Neovim plugins without having to re-invent the wheel. I don't know much about Emacs, but from looking at Racket Mode it looks like almost 70% of it is Emacs Lisp. With a Racket client for Neovim the plugin could be written (almost?) entirely in Racket.

[Richard Cobbe]

On Sun, Nov 26, 2017 at 03:42:14PM +0000, Stephen De Gabrielle wrote:
> Hi,
>
> I’ve noticed some list members use other editors or IDE’s.
>
> I know two big reasons for using a complex tool is it’s stickiness factors;
> normally a combination of familiarity (hence speed) with a lot of powerful
> features and non-transportable customisation.
>
> Putting stickiness factors aside, what features in other editors/IDE’s
> would you like to see in DrRacket?

I generally switch back and forth between Emacs and DrRacket as appropriate
for the task at hand. DrRacket is good for code navigation, but if I'm
doing a lot of writing, I generally prefer emacs, largely for reasons that
others have mentioned in this thread.

There is one particular issue, however, that I haven't seen come up: power
usage. I haven't really investigated what's going on here, but DrRacket
drains the battery on my MacBook Pro quite rapidly (last experienced with
DrRacket 6.11 on MacOS 10.12.latest). What's more, it appears to do this
even if the app is only open in the background and I'm not actually
interacting with it. So if I don't have access to AC power, I generally
close DrRacket and stick with Emacs.

If the DrRacket maintainers are interested, I'd be happy to help diagnose
the power problem in more detail, as time permits. However, I don't really
know what tests would be useful. Suggestions welcome!

Richard

[Matthias Felleisen]

On Nov 26, 2017, at 11:27 AM, 'Royall Spence' via users-redirect <us...@plt-scheme.org> wrote:

 DrRacket actually does the things it claims to do and isn't a broken mess.

Yes, it is an amazing tool. I occasionally escape to Emacs for tasks that I can’t do easily in Dr (e.g. rectangular editing) but never for long. 

[Konrad Hinsen]

On 26/11/2017 16:42, Stephen De Gabrielle wrote:

> I know two big reasons for using a complex tool is it’s stickiness
> factors; normally a combination of familiarity (hence speed) with a lot
> of powerful features and non-transportable customisation.

A third big reason is generality. The main reason why I prefer Emacs to
DrRacket is that it does so many things unrelated to Racket. Anything
that requires a text-based interface can be done in Emacs.

> Putting stickiness factors aside, what features in other editors/IDE’s
> would you like to see in DrRacket?

Since I do use DrRacket from time to time for very Racket-specific
things (e.g. the debugger and the macro stepper), I do have a small
wishlist:

1) Paredit mode like in Emacs, sufficiently compatible that I can switch
seamlessly between the two.

Well, that's it. Just one point.

Konrad.

[Damien MATTEI]

i use emacs with all Scheme implementations and also for Racket,when debugging i can use the racket editor that display information about trace calls
but i still modify in emacs and refresh only in DrRacket, in emacs i appeciate the syntax highlighting and the search and replace fast short-cuts and because i use those features for a long time.

Damien

[Robby Findler]

It may help to disable online compilation. (Click on the little circle in the bottom to get a menu that lets you disable it.)

Robby

[Annaia Berry]

I generally use DrRacket for all my Racket dev because it "just works (tm)". I have sometimes used other editors for it, and the main things I miss from those usually are autocomplete (DrR has this but it's always been way too slow for me so I never turn it on), more detailed syntax highlighting (like royall Spence's examples), rainbow parens, and perhaps most importantly of all: Parinfer. 

Parinfer makes Lisp editing vastly less painful, though DrRacket is pretty good about visualizing bracket containment so that missing parens at least are easily spotted usually. restructuring code and so forth though is just so much more pleasant I find with Parinfer, especially the Atom version's auto-reformatting (something I miss even in my favorite, VS Code!).

for the most part though, DrRacket always seems to just be "good enough" that having everything in one easily accessed tool is worth what minor conveniences I miss out on.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Racket Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.

[Richard Cobbe]

On Mon, Nov 27, 2017 at 09:48:16AM +0000, Robby Findler wrote:
> It may help to disable online compilation. (Click on the little circle in
> the bottom to get a menu that lets you disable it.)

Ah! Thanks for the suggestion; I'll give that a try.

Richard

[David Storrs]

On Sun, Nov 26, 2017 at 12:43 PM, David Thrane Christiansen
<da...@davidchristiansen.dk> wrote:
> Hi Stephen,
>
>> I’ve noticed some list members use other editors or IDE’s.
>>
>> I know two big reasons for using a complex tool is it’s stickiness factors;
>> normally a combination of familiarity (hence speed) with a lot of powerful
>> features and non-transportable customisation.
>>
>> Putting stickiness factors aside, what features in other editors/IDE’s
>> would you like to see in DrRacket?

Multiple cursor mode. cf http://emacsrocks.com/e13.html I don't use
it all the time but when I use it it's much easier than the
alternatives.

> 2. The macro stepper is extremely handy when it works, and being able to
> inspect syntax objects in the interactions pane is wonderful when the
> macro stepper doesn't work.

Offtopic: This is the one big feature that I've tried DrRacket for,
but I've never been able to make it work. Everything gets reduced to
lambdas instead of more high-level forms so that long before I
actually see anything useful I get a giant mess. Maybe I don't
understand it well enough, or maybe there's something I need to do
differently with it? I was expecting to just keep clicking the 'step'
button; is there any sort of context or etc that I need to establish
first?

[Damien MATTEI]

Le Monday 27 November 2017 05:18:02 pm David Storrs, vous avez écrit :

>
> > 2. The macro stepper is extremely handy when it works, and being able to
> > inspect syntax objects in the interactions pane is wonderful when the
> > macro stepper doesn't work.
>
> Offtopic: This is the one big feature that I've tried DrRacket for,
> but I've never been able to make it work. Everything gets reduced to
> lambdas instead of more high-level forms so that long before I
> actually see anything useful I get a giant mess. Maybe I don't
> understand it well enough, or maybe there's something I need to do
> differently with it? I was expecting to just keep clicking the 'step'
> button; is there any sort of context or etc that I need to establish
> first?
>

not easy to use, i never succeed to use it too , any documentation somewhere about the macro-stepper use?

[Sam Caldwell]

documentation (albeit limited) on the macro stepper: http://docs.racket-lang.org/macro-debugger/index.html#%28part._.Using_the_.Macro_.Stepper%29

You can also find `expand/step` there, which I find to be a very useful complement to using DrRacket to step through the expansion of an entire module.

- Sam Caldwell

[ben.rudgers]

I use Emacs because org-mode provides Babel and Babel lets me program in a literate style.  In Emacs I can write literate code irrespective of language and I enjoy literate programming more than illiterate/unlitterate/conventional programming by a wide margin. Emacs org-mode lets me convert my literate program to web pages, markdown, and other things I don't use. So it fills in for Scribble (I found Scribble-LP challenging to use, probably in part because it does not have the same size of community). 

So I'd love to see org-mode Babel in DrRacket...or DrRacket in Emacs.

Ben

[Zelphir Kaltstahl]

I mostly like the text navigation features I have in Emacs. I also like that I can run a shell inside Emacs and manage multiple buffers easily. Installing different color themes is easy too, while in DrRacket I would probably have to configure the colors myself (I might be wrong though, not sure if there isn't an easy way to get many themes into DrRacket).

I've never used DrRacket for a long time. Even the fancy arrows where something comes from when you hover it with the mouse cursor did not do much for me, because I either already knew where it came from, because I wrote the code myself, or because the arrow would come from something out of visible area. This also happens when you have an error and it tries to help you with the arrows. If it was somehow more usable (I have no idea how), maybe it would do something for me too.

What I used DrRacket for once were the examples for multi-threading and multi-processing in the Racket guide. It has nice visualization for this stuff, which I cannot get easily from Emacs.

When I need more of a backtrace, I simply run my programs with: `racket -l errortrace -t myfile.rkt` (that is a lowercase L, not an uppercase i)

Memory limits can be easily added to a program as well with the following code:

~~~

(define (Mb-to-B n) (* n 1024 1024))
(define MAX-BYTES (Mb-to-B 128))
(custodian-limit-memory (current-custodian) MAX-BYTES)

~~~

So I am usually not missing anything DrRacket would give me. Maybe if I was using more languages or more of the debugging tooling it offers I would use DrRacket more often.

One thing I liked was the integrated package manager. But that too can be handled easily with the `raco`.

[Stephen De Gabrielle]

I don’t want to stop the responses, but I do want to say thank you to all of you. You have given me a lot to think about. 

[George Neuner]

On 11/27/2017 3:30 PM, Zelphir Kaltstahl wrote:
>
> Memory limits can be easily added to a program as well with the
> following code:
>
> ~~~
> (define (Mb-to-B n) (* n 1024 1024))
> (define MAX-BYTES (Mb-to-B 128))
> (custodian-limit-memory (current-custodian) MAX-BYTES)
> ~~~

The problem with  custodian-limit-memory  is that it doesn't actually
limit how much memory the custodian can allocate - the limit is enforced
only *after* GC runs.  Between GC runs, the custodian could allocate far
more than the limit.

I'd like a command line switch that puts a hard limit on heap size ...
similar to the server JVM.  Using ULIMIT on Linux you can restrict
process data size, but Windows offers no simple way to do that.  It can
be done clumsily on Windows using containers or with "job objects", but
few people have containers set up on their Windows boxes and the few job
objects tools I am aware of work only on already running processes ...
there's no simple way to start a process that is restricted from the
beginning.

George

[Zelphir Kaltstahl]

In practice it has often prevented stuff from filling up all RAM + swap, but I thought it was actually the memory limit and nothing can go over it. Good to know that this is wrong!
So it is rather like a "if memory usage is too much after an unknown amount of time, then kill the program", instead of "prevent the program from ever going over the limit".

[George Neuner]

On Mon, 25 Dec 2017 12:31:21 -0800 (PST), Zelphir Kaltstahl
<zelphirk...@gmail.com> wrote:

>In practice [custodian-limit-memory] has often prevented stuff from filling

>up all RAM + swap, but I thought it was actually the memory limit and
>nothing can go over it.
>Good to know that this is wrong!
>So it is rather like a "if memory usage is too much after an unknown amount
>of time, then kill the program", instead of "prevent the program from ever
>going over the limit".

Right. What is needed is a way to limit the size of the heap. You
can still get into trouble using places because they have separate
heaps [and also a shared heap], but these factors can be dealt with if
any single place heap isn't growable beyond a limit.

George

[JCG]

Sorry for the delay. 

1) Coloring of a #; commented-out S-expression, as in Emacs.

2) Code folding that is saved and yet compatible with external editors.  The way I would go about dealing with the WXME format would be be to save two files, with the WXME format hidden somewhere (Sqlite or a file) based on the hash of the content of the normal text.  If the hash matches, then utilize the extra goodies the WXME affords (e.g. code folding); otherwise just show the normal text version and nobody will be the wiser.  

3) Having the ability for the Run button to execute a different process would allow crash-prone C/C++/Go/Rust extensions not annihilate the GUI.

4) The first attempt to get assistance from meta-/ takes quite a while yet excludes operators defined in the current file.  Given that it's not including local definitions and/or tokens, and that the next time I start DrRacket, the same list will slowly appear, it ought to be cached.

5) Easy way to avoid byte-code incompatibility, e.g. I download 6.12.0.3 and run into a repetitive dialog about 6.10 byte-code incompatibility without any option for correction.

6) In the preferences dialog (on a Mac at least), the "Revert All Preferences to Defaults" is unclear about whether the defaults are for the displayed tab or for all preferences.  At least twice in the past, I've incorrectly assumed that the defaults were for the topic displayed and not all preferences.  I fiddled with the background expansion and finally decided "Oh, I'll just put it back to whatever is suggested - bam, all my other settings were gone."

7) Finally, the tools tab has doubtful defaults for preloading tools, e.g. Algol 60.   Then there is the question about what "Skip the tool" means.  Does that mean that I cannot access these in a running Dr Racket? 

Thanks for asking suggestions.

-John

[Jos Koot]

+1

On windows it is the same.

It would be nice to have the option to revert defaults for the current tab only.

Jos

---

From: racket...@googlegroups.com [mailto:racket...@googlegroups.com] On Behalf Of JCG
Sent: viernes, 12 de enero de 2018 01:38
To: Racket Users
Subject: [racket-users] Re: Alternatives to DrRacket

 snip 

6) In the preferences dialog (on a Mac at least), the "Revert All Preferences to Defaults" is unclear about whether the defaults are for the displayed tab or for all preferences.  At least twice in the past, I've incorrectly assumed that the defaults were for the topic displayed and not all preferences.  I fiddled with the background expansion and finally decided "Oh, I'll just put it back to whatever is suggested - bam, all my other settings were gone."

 snip