Feedback
Completed
[The post "Reporting issues with the nvUltra beta" says it is the "right place" for posting issues, but it's closed for comments. :) Feel free to move this if I'm not putting it in the right place.]
Some feedback from a first-time user, using 1.0.0 (33):
- The font in the note-editing window is odd; it's very small, but it has a huge line size, so big it looks double-spaced (and the line cursor is huge compared to the letters).
- If the very first line in the note isn't a header, it's rendered in grey for some reason.
- When you enter a "# Header" and hit enter, it adds an extra sharp "#" to the end of the line, same with second-level header etc. I'm not sure if this is some other style of Markdown; it doesn't appear e.g. in https://www.markdownguide.org/basic-syntax/ and isn't how I'm used to formatting my MD documents.
- Numbered lists need some work. (a) When you hit tab to indent, in the note-editing window it continues the numbering from the parent's number, rather than create another level of numbers/letters starting with "a." or "i." etc. (b) In the preview window it uses numbers for every level; most previewers I use will use letters or "i. ii." etc. for sublevels.
Brent
-
There are settings in the Preferences for some of these. You can change the font size and line spacing (as well as padding, etc.) under the Appearance tab. I immediately changed line spacing to 1, since I prefer a more compact line height.
I'm also pretty sure nvUltra defaults to MultiMarkdown. There's a checkbox in the MMD tab of preferences to "Limit to 'Strict' Markdown functionality' -- I haven't tried that, however. Maybe more to the point, the Editing tab includes an option for "Append '#' to end of headings" -- I think if you uncheck that, nvUltra will no longer enclose your headings with # marks.
For what it's worth, the [Daring Fireball: Markdown Syntax Documentation](https://daringfireball.net/projects/markdown/syntax) calls closing # signs optional:
> Optionally, you may “close” atx-style headers. This is purely cosmetic — you can use this if you think it looks better. The closing hashes don’t even need to match the number of hashes used to open the header. (The number of opening hashes determines the header level.)
0 -
Thanks for the input, Brent!
This Community section is the right place for feedback and questions, not that particular post. It would be terribly unruly to have all feedback in a single thread.
1. The editor is completely customizable. It sounds like you possibly saw something different than the defaults we intended, but you can modify all of these settings in Preferences, as theofrancis pointed out. I'd be interested in a screenshot if you haven't already changed the settings.
2. If the first line isn't a header and includes a colon, it's interpreted as MultiMarkdown metadata.
3. Ditto the above post, it's a style choice and can be disabled in Preferences->MMD.
4. This is valid feedback and has been brought up before. Thanks for the input!
0 -
OK great! Thanks to you both; appreciate the answers. Sounds like I need to read up on MultiMarkdown and how that differs from straight MD.
Here's the screen shot you asked for (I haven't touched anything in Preferences yet):
You can see the high line spacing between the bullets, and the huge "insert" line cursor at the end of the last line. Those I guess I can change.
But note also the even huger gap between the numbered points. I was only hitting return once after "a point" and "a counter-point" etc., but in this case it's actually adding an extra blank line. You can see it in the ".md" file.
0 -
Preferences->Editing, Skip line between list items. That item should not be enabled by default, will check into that.
-Brett
0 -
I'm a new beta user as well and was confused by many of the same things. It sounds like it's mostly a case of defaults (line spacing, closing hashtag and list spacing). Defaulting to justified text was another one that I wouldn't expect and quickly turned off.
I really like the metadata idea. It would be useful to see an example -- I assume in the full release you'd include some sample files on startup. Without that it's hard to envision what to put there. (I'm not new to markdown but haven't used it with metadata like that before.)
Likewise on the closing hashtags -- if it's just a style choice that's cool, but it got me thinking that there must be some reason for it, like enabling better cross-linking between notes and headers or something. So if it's going to be on by default that might be worth mentioning in sample/startup files, as well as info on why you might use it and how to turn it off.
Overall though, I'm very happy with how it's working, and add me to the list of longtime nvALT users who are super excited and grateful that you are making this!
Kevin
0 -
MultiMarkdown features are documented here: https://fletcher.github.io/MultiMarkdown-6/
Closing headers are purely stylistic.
0 -
I am adding to this thread as it seems similar. It took some fiddling to get things closer to my liking.
[Bug] I went with line spacing and it took a few times of going into Preferences for it to work. The number 1 stayed there, but the lines stayed at 1.5 for a long time. I think i figured it out. If you change the Spacing and close the Preferences without tabbing out of the field, the changes do not take effect, but it saves the value.
My Preference was to tighten things up and I went with HelveticaNeue 14 which is what I have on nvAlt (can't remember if that is the default there).
0 -
Rob O'Keefe -- correct. This is a common idiom for text fields on macOS -- you tab out or hit enter to "set" the value. This is particularly common when a "halfway-finished" value would cause undesired results.
For example, typing a font name. When typing "Palatino", you first have to go through multiple nonsense values (e.g. "Pal"). Attempting to update the displayed font to "Pal" would not give the desired results, so the value is not "set" until you finalize it.
In my testing, if I close the preference window without setting the value, nothing happens. But as soon as I reopen the preferences window, the previously typed value is loaded and "set", triggering an update to the displayed text.
In any event, it's a good habit to be in of tabbing out of text fields after you update the value to declare that you are "finished."
0 -
Thanks for the explanation. I went back looking at Preferences for various apps, and couldn't find any open text box preferences, most have checkboxes and drop downs. For those there is no concept of tabbing out of a field to save it.
I did confirm it works as you said -- change the value without tabbing out of the field SAVES the preference but does not activate it. Reopening the preferences and doing nothing then ACTIVATES the previous change.
I am not a UI guy, so I will take what you said at face value that this is some expected behavior, but to me I would not want the behavior in effect to be different than the saved preference. In your font example, I would think you would not let a user save an invalid font rather than saving the word Pal without changing the font.
Thanks for your explanations though, they are helpful!
0 -
The specifics probably don't matter to you, but it is slightly different than you describe. (Just for future reference to anyone else, not specifically relevant to your comments.)
When you close the window, apparently the new value is not saved as a preference, but simply remains as the text inside the text field, which never received a "I am finished" action. When you open the dialog, the text field reappears and then recognizes the "new" text (which is no longer quite as new), and at that point the preferences is saved, which triggers an update of the text view.
To be clear -- when the preference is changed in the live macOS defaults database (regardless of how), the text view gets a signal that it was changed, and therefore updates how it is displayed.
0
Please sign in to leave a comment.
Comments
10 comments