---
# System prepended metadata

title: Spring 2024 Lurch to-do list

---


# Spring 2024 Lurch to-do list

## Things to discuss

- :new: Tiny bug.  There are situation where the expression or expository math editor lets you press ENTER but then doesn't insert any atom into the document.  One example is entering `$` in the expository math editor and then pressing ENTER. 
- :new: Minor clean-up. There are starting to be combinations of settings and modes that don't make sense together. Example: If Lurch is embedded then it doesn't make sense to have a 'fixed width' editor appearance setting since one would assume the iframe will set it's width. 
 - One of Ken's students tried the Insert>Empty Paragraph Above/Below menu items to enter new paragraphs, which naturally was having no effect because she wasn't using any shells, but it was confusing her because nothing was happening.
     - A few possibilities here; which of these do you prefer (or both):
     - We could disable these unless your cursor is inside an environment. This should probably be done no matter what else we choose to do.
     - We could rename them from "Empty paragraph above/below" to "Paragraph above/below environment" or "Empty paragraph above/below environment," but that last one is kind of long.
 - One of Ken's students assumed that what was wrong with Insert > Empty paragraph above/below was that the menu said CMD+SHIFT+ENTER but she said "I don't have an ENTER key because I have a Mac... I only have a RETURN key."
     - I don't know if we can easily control this.  TinyMCE chooses those pieces of text.  We could write some tool that, after the menus have been built, traverses their DOM (iff you're on a Mac) and replaces "Enter" with "Return."  Doesn't seem high priority, but could be done.
 - We started going through all Ken's one-off tweaks on his local server but we quit when Nathan got finicky.  Should we finish?
 - Do we want to design a robust status mechanism that shows not just the filename next to the menus, but other things, like whether there's content in the header?
 - Originally Ken asked for the File > Save As... dialog to contain a filename blank, so that the *system* save dialog was autopopulatd with that name.  Then later he asked to have that removed, because it was unnecessary.  But note that if we remove it, since we have no way to detect the filename the user chose for their download using the system dialog, they will need to retype that filename every time they save.  Is that what we want?
 - Does Ken still want the following?  It is related to the idea of no-shells Lurch that Nathan once wanted.  Ken suggested it to try to deal with some of the unexpected behavior of TinyMCE re: shells.
     - Have two modes, 'edit' mode and 'presentation' mode.
     - Instead of converting between the two with the minimal/boxed CSS styles, the presentation mode will have no shells, and switching between the modes will convert every shell div to a start/end atom pair, and vice versa in the other direction.
     - Note: We had a design discussion on 2/6 in which Ken pointed out that this toggle-ability makes it so that the no-shells mode is much less ugly.  No need for ugly "DONE" atoms everywhere--they'll still exist, but they can be invisible in presentation mode.  (We'd just have to make sure that invisible things are not accidentally deletable.  Unless of course you're deleting their partner at the same time.  Some design work needed here.)
 - Nathan has in his own personal notes a list of to-dos regarding how to overhaul the whole filesystem situation.  This should make it easier to enable/disable the file storage locations preferred by one instructor, should make it easier to recursively refresh dependencies (when that's possible), and other things.  But (a) it's a lot of work and (b) we haven't talked about it in awhile so the plan might be out of date.  We should touch base to be sure that plan still describes what we want before Nathan invests time in building it.
 - Nathan has some ideas for how we can incorporate labels and references, and we should talk them out.
     - We discussed this a bit on Feb 8, in the AM, by chat
 - Labels and references are also related to questions about dumbing down the uber-smart Lurch to something more pedantic (and the full spectrum in between), which it would be nice to make plans about.

## Things Nathan must do

 - Enhance `createApp()` help menu items so they can be hierarchically organized into subitems.
 - Context menu improvements
     - Make "View meaning" work on shells, which will require an overhaul of how document meaning is computed (but in a way that will help make the app code better in the long run, so it's worth it).
     - Make "View meaning" work on the whole document, which will require similar work to the previous item.
     - Add a context menu item for dependency atoms "View contents" that will open it in another tab, so you don't have to (a) edit the thing, (b) open the preview, then (c) when you come back cancel the edit.
     - When right-clicking any kind of environment in minimal mode, the context menu should contain an item to indent/unindent it (which toggles a CSS class).
     - For environments that contain environments, have two other items, one for indenting it and all children, one for unindenting it and all children.
     - For the context menu for the document, outside of all environments, have a context menu item for indenting all environments, and another for unindenting all environments.
 - Fix the bug about shells at the top of documents, described in detail in Nathan's own notes file.
 - Add a new Developer menu item that shows the whole document in Lurch notation, using these steps:
     - Ensure that every expression knows how to represent itself in Lurch notation.
     - Ensure that every shell knows how to represent itself using putdown, with the recursion on inner shells/atoms eventually using Lurch notation for the base case.
 - Other misc bug reports Nathan has in his own notes file
 - Make expressions be able to be shown as now, inline, or in "display mode," using DIVs instead of SPANs.  It should be a toggle on the context menu.  This will enable us to customize the CSS for such tings to make spacing before/after them look nicer, and eventually later will let us put labels in the right margin.  Try to also get the MathLive typesetting tool to use display mode when you do this.

## Things Ken must do

 - Optional: Double-check the following stuff Nathan did
     - Tab key now does indent (and shift-tab does unindent)
     - The main repo should now successfully close the advanced mode editor when it loses focus.
     - Lurch now has a spell checker.
     - Lurch now highlights selected atoms, making select/copy/paste/etc. easier.
 - Eventually solve the problem of pointing whatever domain we want to our github site.
 - Ken said he did a whole bunch of CSS fixes that should enable Nathan to do the following two things, but Ken said maybe he didn't put them in the main repo yet?  I couldn't tell.  Please explain.
     - What Nathan is supposed to do:
        - Rename the document setting on this matter from "boxed" and "minimal" to "presentation mode" and "editing mode".
        - Fix this bug: when you load a document that was saved in `minimal` it renders in `boxed`. (You can only change it back by first going into document setting and changing it to `boxed` then go in again and change it to `minimal`).
    - What Ken did (I think):
        - In presentation mode, you already have mouse hover highlights for shells, that's done, nothing to do here.
        - In presentation mode, you don't yet have mouse hover highlights for atoms, so add that, in a similar style (light blue background).
        - In editing mode, we have borders around shells, but not around atoms.  Add a light gray border around atoms.
        - In editing mode, you don't yet have mouse hover highlights for shells, so add that, in a similar style (just darken/thicken the existing border).
        - In editing mode, you don't yet have mouse hover highlights for atoms, so add that, in a similar style (just darken/thicken the existing border).
        - Commit and push these changes, together with the ones you've already done in this file, to the main UI repo.
 - LaTeX-to-Lurch parser bug report: It gets confused if given LaTeX like `e^x-1`, because it converts that to `e^ x -1`, which then gets parsed by the Lurch-to-putdown parser into two separate LCs, `(^ e x)` and `(- 1)`.  This means that if someone opens a dialog box and types $e^x-1$ into the MathLive editor (or even just edits the MathLive that was put there when they typed `e^x-1` into the Lurch zone) the expression has the wrong meaning.
 - Some old bug reports for the Lurch-to-LaTeX parser that may no longer be relevant, and some of which also apply to the Lurch-to-putdown parser:
     - Invalid declarations parse validly as multiple things.  Example: `Let x be such that` parses into `Let x` followed by 3 identifiers, `be`, then `such`, then `that`.  This makes the advanced mode editor able to submit a half-built declaration, but its meaning is completely unexpected.
     - Introduce some easy/obvious notation for multiplication.  For example, "2x" could be seen as "2 cdot x" under the hood.  Or "2*x" instead if juxtaposition-for-multiplication is not part of the plan (in which case are we really doing AsciiMath? there were clear statement made about the relationship of Lurch notation to both AsciiMath and LaTeX that seem to have become unreliable...).
     - Create some obvious notation for typesetting an array of LCs, so that when the user writes something that didn't parse as expected (e.g., "2x" as "2" then separately "x") they see immediate visual signalling of this (e.g., `2 ; x` or `2 then x` or `2 ... x` or something) to eliminate user confusion.
     - `Declare pi` typesets without a space, "Declarepi".  If multiple things were declared, there are not spaces between them either, e.g., "DeclareAndOrNot".

## Things that are done (and we will later delete)

In other words, we put things here to record that we did them, but I don't want this note to grow to be 7 million lines long, so we can delete things from here without warning as needed.  The repo contains a complete history of all of our changes anyway.

 - The new CLI that hasn't yet been tested, but is a tool that gives us recursive dependency loading and document validation on the console, before we've officially created LFYs.
