Julia Evans expresses frustration with several common terminal shortcomings. She highlights the difficulty of accurately selecting and copying text, especially across multiple lines or with special characters, often resorting to workarounds like opening the command in a text editor. Additionally, she points out the inconsistency of terminal escape codes leading to unpredictable behavior between different terminals and programs. Finally, she laments the lack of a standardized method to directly interact with and manipulate the output of a previously executed command, requiring awkward copying or screenshotting for further analysis. These limitations, she argues, interrupt her workflow and make the terminal less efficient than it could be.
This blog post presents a simple bookmarklet designed to remove fixed position headers on websites. The author, frustrated by obstructive sticky headers, created a JavaScript snippet that can be saved as a bookmark. When clicked, this bookmarklet iterates through all elements on the current page, identifies those with a fixed position (typically headers), and sets their position to static, effectively removing the sticky behavior. The post highlights the bookmarklet's effectiveness in reclaiming screen real estate and improving the browsing experience. It also includes the code snippet for easy copying and implementation.
Hacker News users generally praised the bookmarklet for its simplicity and effectiveness in removing annoying sticky headers. Some users expressed concerns about potential website breakage, while others offered alternative solutions like browser extensions (e.g., uBlock Origin) or Stylish. A few commenters suggested improvements to the bookmarklet's code, such as handling elements with position: fixed differently or providing an option to restore the original header. The discussion also touched upon the broader issue of intrusive web design and the ongoing battle between users and websites trying to maximize ad revenue. One commenter even shared a personal anecdote about creating a similar tool years prior, highlighting the long-standing frustration with sticky headers.
After 75 years, the Society for Technical Communication (STC) is permanently closing, effective July 15, 2024. Facing declining membership and revenue, the organization's Board of Directors determined it could no longer sustain operations. STC will cease all activities, including its annual summit, publications, and certification programs. The organization expressed gratitude for its members and their contributions to the field of technical communication.
HN commenters lament the closure of the Society for Technical Communication (STC), expressing surprise and sadness at the loss of a long-standing organization. Several speculate on the reasons for the closure, citing declining membership, the rise of free online resources, and the changing nature of technical communication. Some question the STC's relevance in the modern landscape, while others highlight its historical importance and the valuable resources it provided. A few commenters express hope that another organization will fill the void left by the STC, preserving its archives and continuing its mission of advancing the field of technical communication. Some users discuss their personal positive experiences with the organization. One notes a large amount of student debt held by the organization.
Chimera Linux is focusing on simplicity and performance in its desktop environment. The project uses a custom-built desktop built on Wayland, emphasizing minimal dependencies and a streamlined experience. This includes a basic compositor called Chimera-wm, along with self-developed components like a file manager and terminal emulator, to minimize bloat and maintain a tight control over the user experience. While still under heavy development, the project aims to provide a fast, clean, and easily adaptable desktop environment built from the ground up.
HN commenters generally express interest in Chimera Linux's approach of using a modern init system and focusing on a straightforward desktop experience. Some praise its potential for stability and performance by sticking with known-good components. Others are skeptical of its niche appeal, questioning whether simplifying the desktop is a significant enough draw. A few commenters raise concerns about the sustainability of a project reliant on a single developer, while others commend the developer's clear vision and execution. The discussion also touches on the limitations of systemd and the challenges of balancing minimalism with user expectations. Some express hope for Chimera becoming a viable alternative to established distributions.
The post "UI is hell: four-function calculators" explores the surprising complexity and inconsistency in the seemingly simple world of four-function calculator design. It highlights how different models handle order of operations (especially chained calculations), leading to varied and sometimes unexpected results for identical input sequences. The author showcases these discrepancies through numerous examples and emphasizes the challenge of creating an intuitive and predictable user experience, even for such a basic tool. Ultimately, the piece demonstrates that seemingly minor design choices can significantly impact functionality and user understanding, revealing the subtle difficulties inherent in user interface design.
HN commenters largely agreed with the author's premise that UI design is difficult, even for seemingly simple things like calculators. Several shared anecdotes of frustrating calculator experiences, particularly with cheap or poorly designed models exhibiting unexpected behavior due to button order or illogical function implementation. Some discussed the complexities of parsing expressions and the challenges of balancing simplicity with functionality. A few commenters highlighted the RPN (Reverse Polish Notation) input method as a superior alternative, albeit with a steeper learning curve. Others pointed out the differences between physical and software calculator design constraints. The most compelling comments centered around the surprising depth of complexity hidden within the design of a seemingly mundane tool and the difficulties in creating a truly intuitive user experience.
Git's autocorrect, specifically the help.autocorrect setting, can be frustratingly quick, correcting commands before users finish typing. This blog post explores the speed of this feature, demonstrating that even with deliberately slow, hunt-and-peck typing, Git often corrects commands before a human could realistically finish inputting them. The author argues that this aggressive correction behavior disrupts workflow and can lead to unintended actions, especially for complex or unfamiliar commands. They propose increasing the default autocorrection delay from 50ms to a more human-friendly value, suggesting 200ms as a reasonable starting point to allow users more time to complete their input. This would improve the user experience by striking a better balance between helpful correction and premature interruption.
HN commenters largely discussed the annoyance of Git's aggressive autocorrect, particularly git push becoming git pull, leading to unintended overwrites of local changes. Some suggested the speed of the correction is disorienting, making it hard to interrupt, even for experienced users. Several proposed solutions were mentioned, including increasing the correction delay, disabling autocorrect for certain commands, or using aliases entirely. The behavior of git help was also brought up, with some arguing its prompt should be less aggressive as typos are common when searching documentation. A few questioned the blog post's F1 analogy, finding it weak, and others pointed out alternative shell configurations like zsh and fish which offer improved autocorrection experiences. There was also a thread discussing the implementation of the autocorrection feature itself, suggesting improvements based on Levenshtein distance and context.
Summary of Comments ( 3 )
https://news.ycombinator.com/item?id=42959824
HN users generally agreed with the author's frustrations regarding terminal emulators. Several commenters pointed to specific pain points like inconsistent copy/paste behavior, difficulties with selecting text, and the lack of proper mouse support across different terminals. Alacritty and Warp were frequently mentioned as modern alternatives attempting to address some of these issues, though some users expressed reservations about Warp's closed-source nature and Electron base. Others discussed the challenges inherent in terminal emulation given its historical baggage and the trade-offs between features, performance, and compatibility. The desire for a truly modern and consistent terminal experience was a recurring theme.
The Hacker News post "Some Terminal Frustrations" discussing Julia Evans' blog post of the same name generated a robust discussion with over 100 comments. Several key themes and compelling points emerged from the conversation.
Many commenters echoed Evans' frustrations with terminal emulators, highlighting inconsistencies and quirks across different platforms and implementations. The lack of standardization and the slow pace of improvement were common complaints. Several users shared their personal struggles with features like copy/paste, scrolling, and font rendering, agreeing that these seemingly basic functionalities often fall short.
A significant portion of the discussion revolved around the complexities of terminal escape codes. Commenters debated the balance between backward compatibility and the need for modernization. Some argued that the legacy of escape codes is holding back terminal development, while others emphasized the importance of preserving existing functionality for older applications. The difficulty of working with and debugging escape sequences was also a recurring theme.
Several commenters suggested alternative approaches to terminal emulation, including using web-based terminals or entirely new terminal implementations. Projects like Zellij and Warp were mentioned as potential solutions offering more modern features and user interfaces. The idea of treating the terminal as a more structured data interface, rather than relying solely on text manipulation, also gained traction.
The conversation also touched on the challenges of cross-platform compatibility. Users highlighted the differences in terminal behavior between operating systems like Linux, macOS, and Windows, making it difficult to develop applications that work consistently across different environments.
Some commenters shared their preferred terminal configurations and tools, offering recommendations for improving the terminal experience. These included tips for customizing keybindings, color schemes, and font settings, as well as suggestions for specific terminal emulators like Alacritty and Kitty.
A few dissenting voices argued that the existing terminal ecosystem is sufficient and that the proposed improvements are unnecessary or overly complex. However, the majority of commenters seemed to agree that the terminal experience could be significantly improved.
Finally, the discussion extended beyond purely technical aspects, touching on the cultural and historical significance of the terminal. Some commenters reflected on the enduring appeal of the command line interface, while others speculated about the future of terminal emulation in a world increasingly dominated by graphical user interfaces. The thread reflects a community grappling with the desire for a more modern and efficient terminal experience while acknowledging the complexities and historical baggage associated with this fundamental computing tool.