Problem Description

We've discovered that bash-language-server (v5.6.0) has inconsistent function detection when processing textDocument/documentSymbol requests. Some bash function syntaxes are not reliably detected, leading to incomplete symbol information.

Expected Behavior

All valid bash function definitions should be detected and returned as symbols with kind: 12 (Function) in document symbol requests.

Actual Behavior

The language server inconsistently detects functions, particularly:

• Functions with mixed syntax styles within the same file
• Functions with different indentation or formatting patterns
• Some function name() { ... } vs name() { ... } syntax variations

Examples

Test File Content (main.sh)

#!/bin/bash
# Function using 'function' keyword
function greet_user() {
 local name="1ドル"
 case "$name" in
 "admin"|"root")
 echo "Welcome, administrator!"
 ;;
 *)
 echo "Hello, $name!"
 ;;
 esac
}
# Function using traditional syntax 
function process_items() {
 for item in "$@"; do
 echo "Processing: $item"
 done
}
# Another function using traditional syntax
main() {
 echo "Starting main function"
 greet_user "user"
 process_items "item1" "item2" "item3"
}

Expected LSP Response

Should return 3 function symbols for greet_user, process_items, and main.

Actual LSP Response

Often returns fewer than 3 functions or inconsistent results across different files with similar patterns.

Workaround

We've implemented a hybrid detection approach that combines LSP results with regex-based fallback detection to ensure comprehensive function discovery. However, this shouldn't be necessary if the LSP server had consistent function detection.

Environment

• bash-language-server version: 5.6.0
• Node.js version: Various (tested on multiple versions)
• Operating System: macOS, Linux, Windows

Additional Context

This issue was discovered while implementing bash language support in Serena, where reliable symbol detection is crucial for code editing operations. The inconsistency affects the reliability of symbolic editing tools that depend on accurate function location information.

Would it be possible to improve the function detection reliability in future versions? We'd be happy to provide additional test cases or collaborate on fixes if helpful.