Inconsistent Project Name Handling: Spaces vs Dashes

[chrisweis]

Summary

Project names are handled inconsistently between file-based project detection and plugin editing, causing the same project to appear as two separate entries.

Description

When a project is derived from an Obsidian file name, spaces are preserved in the project name. However, when tasks are edited through the plugin interface, project names have spaces converted to dashes for tag formatting. This creates inconsistent project naming that causes the same logical project to appear as separate entities.

Steps to Reproduce

1. Create an Obsidian file named "My Project Name.md"
2. Add a task that gets automatically assigned to the "My Project Name" project (via file-based detection)
3. Edit a task through the plugin interface and assign it to the same project
4. Observe that the plugin creates tags like #project/My-Project-Name (with dashes)
5. Notice that these appear as two different projects in project views

Expected Behavior

The same project should have consistent naming regardless of whether it's detected from file names or assigned through plugin editing.

Actual Behavior

• File-based detection: Project appears as "My Project Name" (spaces preserved)
• Plugin editing: Project appears as "My-Project-Name" (spaces converted to dashes)

Technical Details

Root Cause

Inconsistent normalization between two code paths:

1. File name parsing (src/parsers/file-metadata-parser.ts:402-403)

const fileName = filePath.split('/').pop() || filePath;
return fileName.replace(/\.md$/i, '');

Preserves spaces in project names

2. Task writing (src/dataflow/api/WriteAPI.ts:402-405)

const sanitizedProject = String(args.project)
    .trim()
    .replace(/\s+/g, "-");
metadata.push(`#${projectPrefix}/${sanitizedProject}`);

Converts spaces to dashes for tag formatting

Suggested Solution

Standardize project name normalization across both parsing and writing processes by either:

• Always converting spaces to dashes in both file name parsing and tag generation
• Using a consistent project identifier that handles spaces properly in both contexts
• Implementing a centralized project name normalization function used by both code paths

Environment

• Task Genius version: 9.8.14
• Impact: Project organization and filtering functionality

[chrisweis]

Note: I analyzed the code using the latest version in this repo (9.9.0-beta.6)

[chrisweis]

Proposed Solution with Code (generated by AI)

I suggest implementing a centralized project name normalization function to ensure consistency across both file-based detection and plugin editing.

---

Implementation

1. Create a Centralized Normalization Utility

File: src/utils/project-name-utils.ts

/**
 * Centralized project name normalization utility
 * Ensures consistent project naming across file-based detection and plugin editing
 */

export interface ProjectNameOptions {
  preserveSpaces?: boolean;
  separator?: string;
}

/**
 * Normalize project name for consistent handling
 */
export function normalizeProjectName(
  projectName: string,
  options: ProjectNameOptions = {}
): string {
  const { preserveSpaces = false, separator = "-" } = options;
  if (!projectName) return "";

  let normalized = projectName.trim();

  // If we don't preserve spaces, convert them to the separator
  if (!preserveSpaces) {
    normalized = normalized.replace(/\s+/g, separator);
  }

  return normalized;
}

/**
 * Get project name for display (always preserve spaces)
 */
export function getDisplayProjectName(projectName: string): string {
  if (!projectName) return "";
  return projectName.replace(/-/g, " ").trim();
}

/**
 * Get project name for tags (always use dashes)
 */
export function getTagProjectName(projectName: string): string {
  return normalizeProjectName(projectName, { preserveSpaces: false });
}

---

2. Update File Metadata Parser

File: src/parsers/file-metadata-parser.ts

import { normalizeProjectName } from "../utils/project-name-utils";

// Replace:
const fileName = filePath.split('/').pop() || filePath;
return fileName.replace(/\.md$/i, '');

// With:
const fileName = filePath.split('/').pop() || filePath;
const rawProjectName = fileName.replace(/\.md$/i, '');
return normalizeProjectName(rawProjectName, { preserveSpaces: false });

---

3. Update WriteAPI

File: src/dataflow/api/WriteAPI.ts

import { getTagProjectName } from "../utils/project-name-utils";

// Replace:
const sanitizedProject = String(args.project)
  .trim()
  .replace(/\s+/g, "-");

// With:
const sanitizedProject = getTagProjectName(String(args.project));

---

4. Update Display Components

For any components that display project names, use the display utility:

import { getDisplayProjectName } from "../utils/project-name-utils";

// When displaying project names in UI:
const displayName = getDisplayProjectName(task.metadata.project);

---

Benefits

1. Consistency – All project names are normalized using the same logic
2. Flexibility – Easy to change normalization strategy globally
3. Backward Compatibility – Existing projects can be migrated gradually
4. Clear Separation – Display names vs. tag names are handled explicitly

---

Migration Strategy

To handle existing inconsistent project names, add a migration function:

/**
 * Migrate existing inconsistent project names
 */
export function migrateProjectNames(tasks: Task[]): Task[] {
  const projectNameMap = new Map<string, string>();

  tasks.forEach(task => {
    if (task.metadata.project) {
      const normalized = normalizeProjectName(task.metadata.project);
      const display = getDisplayProjectName(task.metadata.project);

      // Map both variants to the normalized form
      projectNameMap.set(task.metadata.project, normalized);
      projectNameMap.set(display, normalized);
    }
  });

  // Apply the mapping
  return tasks.map(task => {
    if (task.metadata.project && projectNameMap.has(task.metadata.project)) {
      return {
        ...task,
        metadata: {
          ...task.metadata,
          project: projectNameMap.get(task.metadata.project)
        }
      };
    }
    return task;
  });
}

This ensures "My Project Name" and "My-Project-Name" are treated as the same project going forward.

[chrisweis]

A temporary workaround for this problem is to duplicate the "project" name in frontmatter in every file, but that is inconvenient if I have many projects all in individual files:

---
project: My-Project-Name
---

[malekcellier]

I am having the exact same problem and I am happy you took the time to create an issue.