Font size on Android + enhancement #100

referenceutilise commented 2026年06月11日 23:28:38 +02:00

Hi Helix Note maintainers,

First of all, thank you for the work on this application. It is a really solid and well-designed tool, and I’ve already adopted it in my workflow. I appreciate the overall philosophy and simplicity of the project.

I am writing this report to share a few issues I have noticed, as well as some possible improvements that could be useful.

1. Bug: Font scaling not working on Android

On the Android application, everything works well in general, but I have encountered a clear issue regarding font scaling.

When I go into the settings and change the font size, nothing happens. The font remains exactly the same size regardless of the selected value.

This is particularly important in my view, because font scaling is a key accessibility and usability feature, especially depending on screen size and user preferences. On my device, this setting currently has no effect at all.

2. Code/Markdown editing mode: lack of line wrapping

When switching to code mode to edit the original Markdown content, there does not seem to be any automatic line wrapping.

If a line becomes long (for example, long paragraphs), it requires horizontal scrolling using the bottom bar, which becomes quite inconvenient for longer texts.

It would be very helpful to either:

• enable word wrapping by default in this mode, or
• add an option in the settings to toggle line wrapping behavior.

3. Markdown handling and embedded HTML

Some users have already mentioned issues related to HTML tags being embedded inside Markdown documents during editing (for example tables, text alignment, right/left justification, or colors).

I fully understand the intention to keep the application simple and lightweight, and I think this philosophy is very good overall. However, it might still be worth considering an option in settings for a strict Markdown mode.

This could:

• enforce pure Markdown output
• prevent or strip embedded HTML tags
• possibly come with a clear warning that some formatting features would be disabled

This would give users more control, especially those who want portability and clean Markdown files.

4. Question / UX concern: folder file count only reflects root-level Markdown files

There is one additional point I would like to raise, which is not strictly a bug or a feature request, but more of a UX question.

In the left navigation panel, each folder is displayed with a number next to its name. From what I understand, this number represents the count of Markdown files located directly at the root of that folder, and it does not include files contained within subfolders.

As a result, a folder that contains only subfolders with many Markdown files inside them will still show a count of zero. This can be misleading when browsing a large structure, since some folders appear empty even though they actually contain a significant number of Markdown files deeper in the hierarchy.

Conversely, there are also cases where a folder shows zero because it genuinely contains no Markdown files, which makes sense. The issue is that the same indicator is used for both cases, even though the underlying situations are quite different.

I understand the idea of giving a quick overview of files at the folder level, and I think it is useful in principle. However, the current behavior creates some ambiguity when navigating complex directory structures. I am not sure what the best solution would be (recursive counting, different indicator, optional behavior, etc.), but I wanted to share this observation as it has been slightly confusing in practice.

Closing

Once again, thank you for your work on this project. It is a very impressive application with a lot of potential, and I am looking forward to its evolution.

Best regards,

Hi Helix Note maintainers, First of all, thank you for the work on this application. It is a really solid and well-designed tool, and I’ve already adopted it in my workflow. I appreciate the overall philosophy and simplicity of the project. I am writing this report to share a few issues I have noticed, as well as some possible improvements that could be useful. ## 1. Bug: Font scaling not working on Android On the Android application, everything works well in general, but I have encountered a clear issue regarding font scaling. When I go into the settings and change the font size, nothing happens. The font remains exactly the same size regardless of the selected value. This is particularly important in my view, because font scaling is a key accessibility and usability feature, especially depending on screen size and user preferences. On my device, this setting currently has no effect at all. ## 2. Code/Markdown editing mode: lack of line wrapping When switching to code mode to edit the original Markdown content, there does not seem to be any automatic line wrapping. If a line becomes long (for example, long paragraphs), it requires horizontal scrolling using the bottom bar, which becomes quite inconvenient for longer texts. It would be very helpful to either: * enable word wrapping by default in this mode, or * add an option in the settings to toggle line wrapping behavior. ## 3. Markdown handling and embedded HTML Some users have already mentioned issues related to HTML tags being embedded inside Markdown documents during editing (for example tables, text alignment, right/left justification, or colors). I fully understand the intention to keep the application simple and lightweight, and I think this philosophy is very good overall. However, it might still be worth considering an option in settings for a strict Markdown mode. This could: * enforce pure Markdown output * prevent or strip embedded HTML tags * possibly come with a clear warning that some formatting features would be disabled This would give users more control, especially those who want portability and clean Markdown files. ## 4. Question / UX concern: folder file count only reflects root-level Markdown files There is one additional point I would like to raise, which is not strictly a bug or a feature request, but more of a UX question. In the left navigation panel, each folder is displayed with a number next to its name. From what I understand, this number represents the count of Markdown files located directly at the root of that folder, and it does not include files contained within subfolders. As a result, a folder that contains only subfolders with many Markdown files inside them will still show a count of zero. This can be misleading when browsing a large structure, since some folders appear empty even though they actually contain a significant number of Markdown files deeper in the hierarchy. Conversely, there are also cases where a folder shows zero because it genuinely contains no Markdown files, which makes sense. The issue is that the same indicator is used for both cases, even though the underlying situations are quite different. I understand the idea of giving a quick overview of files at the folder level, and I think it is useful in principle. However, the current behavior creates some ambiguity when navigating complex directory structures. I am not sure what the best solution would be (recursive counting, different indicator, optional behavior, etc.), but I wanted to share this observation as it has been slightly confusing in practice. ## Closing Once again, thank you for your work on this project. It is a very impressive application with a lot of potential, and I am looking forward to its evolution. Best regards,

ArkHost commented 2026年06月11日 23:44:55 +02:00

Thanks for the kind words and the detailed report.

1. Font size on Android: confirmed bug, fixed for 1.3.1. The mobile editor was hardcoding 16px and ignoring your setting; it now respects the font-size setting (in both the normal and source editing views).
2. Line wrapping in source mode: reasonable, I'll look at wrapping long lines instead of horizontal scroll.
3. Strict Markdown mode: I appreciate the thought, and the portability goal. Honestly though, this is a large change that conflicts with several existing features (tables, alignment, colors all rely on a bit of HTML), so I'm going to park it rather than promise it. Noted for the future.
4. Folder counts: that's intentional today: the number is the notes directly in that folder, matching what you see when you open it. But you're right that 0 with full subfolders is ambiguous. I'll think about whether a recursive count or a different indicator reads better. Not a quick change, but it's a fair point.

Thanks again. This kind of feedback is genuinely useful.

Thanks for the kind words and the detailed report. 1. Font size on Android: confirmed bug, fixed for 1.3.1. The mobile editor was hardcoding 16px and ignoring your setting; it now respects the font-size setting (in both the normal and source editing views). 2. Line wrapping in source mode: reasonable, I'll look at wrapping long lines instead of horizontal scroll. 3. Strict Markdown mode: I appreciate the thought, and the portability goal. Honestly though, this is a large change that conflicts with several existing features (tables, alignment, colors all rely on a bit of HTML), so I'm going to park it rather than promise it. Noted for the future. 4. Folder counts: that's intentional today: the number is the notes directly in that folder, matching what you see when you open it. But you're right that 0 with full subfolders is ambiguous. I'll think about whether a recursive count or a different indicator reads better. Not a quick change, but it's a fair point. Thanks again. This kind of feedback is genuinely useful.

referenceutilise commented 2026年06月13日 08:20:08 +02:00

Thank you for your reply.

Regarding point #3, about HTML being inserted into notes when creating or editing files, I would like to share some additional thoughts.

First, this is partly a philosophical and design question. My understanding is that Helix Note is trying to achieve two goals at the same time:

• provide a simple, accessible, and streamlined writing experience;
• keep users in control of their data by relying on an open and interoperable format such as Markdown.

I completely understand and appreciate this approach. It avoids the complexity of large systems with countless options, plugins, and compatibility issues. However, I think there is a tension between ease of use and true interoperability, and this becomes visible in a few specific cases.

From my perspective, there is an important distinction between:

1. features that intentionally generate HTML because the user explicitly requests formatting that Markdown does not support;
2. transformations that happen automatically, even when the original file was fully standard Markdown.

The first category is generally not a problem. For example, if a user chooses to apply text colors, alignment, or other formatting features that are not part of standard Markdown, it is reasonable to expect HTML to be generated. Anyone familiar with Markdown understands that such formatting may not be portable across all editors.

The second category is where I see a more fundamental issue, and tables are the best example.

When a table is created inside Helix Note, it is stored as an HTML table. That is a design choice, and as long as users are aware of it, that is perfectly understandable.

The larger problem is what happens to existing Markdown tables. If I create a note in another editor—or even in a plain text editor such as Notepad—using a standard Markdown table, then open that file in Helix Note, save it once, and later reopen it in another Markdown editor, the table has been converted to HTML.

This means that simply opening and saving a file in Helix Note can permanently change the underlying representation of existing content.

The consequences depend on the editor used afterward. Many Markdown applications render embedded HTML without any issue. However, some editors intentionally do not. A good example is Zettlr, which I consider one of the most serious and standards-oriented Markdown editors available. In its preview mode, HTML tables are not rendered. As a result, a table that was originally valid Markdown becomes effectively unusable there after passing through Helix Note.

For me, this raises a genuine interoperability concern. If preserving portable Markdown files is important, then I must either avoid using tables in Helix Note altogether or avoid opening notes containing Markdown tables. While conversion back to Markdown is always possible, it introduces additional work that defeats the purpose of having a simple and frictionless workflow.

In summary, I understand the desire to keep Helix Note simple and avoid becoming a highly configurable system. However, I think the automatic conversion of existing Markdown tables into HTML creates a conflict with the idea that users retain full ownership and portability of their data.

The issue is not that Helix Note can generate HTML when requested. The issue is that existing Markdown content can be automatically transformed into a different format merely by opening and saving a file. In my opinion, this is a fundamental design concern because it affects both data integrity and interoperability across the Markdown ecosystem.

Thank you for your reply. Regarding point #3, about HTML being inserted into notes when creating or editing files, I would like to share some additional thoughts. First, this is partly a philosophical and design question. My understanding is that Helix Note is trying to achieve two goals at the same time: * provide a simple, accessible, and streamlined writing experience; * keep users in control of their data by relying on an open and interoperable format such as Markdown. I completely understand and appreciate this approach. It avoids the complexity of large systems with countless options, plugins, and compatibility issues. However, I think there is a tension between ease of use and true interoperability, and this becomes visible in a few specific cases. From my perspective, there is an important distinction between: 1. features that intentionally generate HTML because the user explicitly requests formatting that Markdown does not support; 2. transformations that happen automatically, even when the original file was fully standard Markdown. The first category is generally not a problem. For example, if a user chooses to apply text colors, alignment, or other formatting features that are not part of standard Markdown, it is reasonable to expect HTML to be generated. Anyone familiar with Markdown understands that such formatting may not be portable across all editors. The second category is where I see a more fundamental issue, and tables are the best example. When a table is created inside Helix Note, it is stored as an HTML table. That is a design choice, and as long as users are aware of it, that is perfectly understandable. The larger problem is what happens to existing Markdown tables. If I create a note in another editor—or even in a plain text editor such as Notepad—using a standard Markdown table, then open that file in Helix Note, save it once, and later reopen it in another Markdown editor, the table has been converted to HTML. This means that simply opening and saving a file in Helix Note can permanently change the underlying representation of existing content. The consequences depend on the editor used afterward. Many Markdown applications render embedded HTML without any issue. However, some editors intentionally do not. A good example is Zettlr, which I consider one of the most serious and standards-oriented Markdown editors available. In its preview mode, HTML tables are not rendered. As a result, a table that was originally valid Markdown becomes effectively unusable there after passing through Helix Note. For me, this raises a genuine interoperability concern. If preserving portable Markdown files is important, then I must either avoid using tables in Helix Note altogether or avoid opening notes containing Markdown tables. While conversion back to Markdown is always possible, it introduces additional work that defeats the purpose of having a simple and frictionless workflow. In summary, I understand the desire to keep Helix Note simple and avoid becoming a highly configurable system. However, I think the automatic conversion of existing Markdown tables into HTML creates a conflict with the idea that users retain full ownership and portability of their data. The issue is not that Helix Note can generate HTML when requested. The issue is that existing Markdown content can be automatically transformed into a different format merely by opening and saving a file. In my opinion, this is a fundamental design concern because it affects both data integrity and interoperability across the Markdown ecosystem.

ArkHost commented 2026年06月13日 12:39:18 +02:00

You're right about the mechanism: right now the editor stores every table as HTML (so it can support merged cells and block content that Markdown tables can't), which means opening and saving even a plain Markdown table rewrites it as HTML. For a simple table that round-trip shouldn't change the format.

I'll change the save path so a simple table (single header, no merged cells, inline content only) is written back as a standard Markdown pipe table, and HTML is only used when the table genuinely needs it. That keeps portable tables portable through an open/save cycle.

Targeting the release after 1.3.1. Thanks for the concrete example.

You're right about the mechanism: right now the editor stores every table as HTML (so it can support merged cells and block content that Markdown tables can't), which means opening and saving even a plain Markdown table rewrites it as HTML. For a simple table that round-trip shouldn't change the format. I'll change the save path so a simple table (single header, no merged cells, inline content only) is written back as a standard Markdown pipe table, and HTML is only used when the table genuinely needs it. That keeps portable tables portable through an open/save cycle. Targeting the release after 1.3.1. Thanks for the concrete example.

ArkHost commented 2026年06月19日 10:14:07 +02:00

This should be fixed in the newest version. Closing this issue

Separate issue exists for MD/HTML table handling.

This should be fixed in the newest version. Closing this issue Separate issue exists for MD/HTML table handling.