Markdown-preview-plus PDF save


#1

When selecting Save as ... and using a PDF filename, no PDF file is created. No error/warning/info messages are presented either. I’d like the PDF file, but in addition, I’m wondering how this could be debugged since it silently does nothing. Is there a console with detailed messages/calls of Atom/Package internals?


#2

According to the code, an error message should be shown if a PDF isn’t successfully saved. Where are you selecting Save as...? Are you absolutely sure that the active item in Atom is the PDF view? What sort of file is being created?


#3

No error message is shown and no file is created. Note that Save as ... to an HTML file works.


#4

Interesting, I just Toggle LaTex Rendering and now an output is produced. What’s happening?


#5

Probably something to do with changeHandler(), but I couldn’t tell you what.


#6

Is it typical for Atom/Packages to not show toggle state? I don’t want my lesson here to be to just randomly toggle settings until I get the output I seek.


#7

Every package is different, and this has nothing at all to do with how Atom functions, so you’re completely at the whims of the package author and how they like to code.

I don’t want my lesson here to be to just randomly toggle settings until I get the output I seek.

Not randomly, no. You should systematically toggle settings, which can point you to what’s happening differently when it works than when it doesn’t.


#8

As a debugger, I agree. As a user, it makes me wonder if my blind toggling time might be better spent with a different application.


#9

As a user of open-source software in a community-driven ecosystem, you have to be willing to accept that not all packages will work perfectly. You are being given a program at no cost to which you have unparalleled access (no other editor allows you to change as much of its functionality around as Atom does) and can benefit from the inventions of a community with similar access and a radical commitment to open source. If you can’t accept periodically finding non-obvious bugs, switching packages because one doesn’t work the way you want it to, and/or engaging with the package authors to help make the tools better, then you should definitely use an editor with a more curated and proprietary set of extensions.


#10

Interesting perspective. Thank you for taking the time to share it.

[… climbs on a soapbox next to yours…]
Freedom is a means, not just an end. How’s that for radical? Anything that takes time is not free. To a user, unparalleled utility is more important than unparalleled “access”. A first experience of being unable to produce output is not non-obvious, nor periodic. “… curated and proprietary” is an option for the truly free, but provide no real guarantee for or against anything discussed here. An engaged user shouldn’t need to be a debugger.


#11

If you have an issue with the package, by all means raise it on the relevant repo. Maintainers can’t fix issues they don’t see. If you want to go the extra mile, make a PR that you think addresses it.

In this case, it’s very easy for a maintainer to be “blind” to their package. They helped build it, and have worked with it far more than most, so they fall into a trap of thinking that everything is “clear enough”, when a normal user (like you or me) have no idea what the settings do.

Your issue should explain what you wanted, what you tried, what you expected the things you tried to do, etc. This is very valuable for improving usability.

Also

Is highly subjective, but I think that’s obvious. If everybody agreed on what the best editor features are, we’d not have so many different editors.


#12

You are misusing the word “free”. In the context of open source, “free” has a very specific meaning: that the code is physically and legally available for other people to take and manipulate however they see fit and for whatever purpose they want, even commercial ones. Linux is completely free for use, but one of the negatives of that is that it takes time and effort to learn how to properly use Linux.

A first experience of being unable to produce output is not non-obvious, nor periodic.

My guess from looking at the code is that the handler doesn’t get initialized properly the first time but it does when you manually use a command that triggers the changeHandler() reset. That’s for a secondary feature of the package (saving as a PDF) and it probably didn’t get tested fully before it was implemented.

“… curated and proprietary” is an option for the truly free, but provide no real guarantee for or against anything discussed here.

Curated and proprietary is the opposite of free software, and if you have a big company like Microsoft or JetBrains doing quality assurance on extensions, you are guaranteed to have better quality across all extensions. Atom packages are written by individuals on their free time, with no mandated quality testing whatsoever.

An engaged user shouldn’t need to be a debugger.

Who is responsible for ensuring that your experience is free from the need to troubleshoot the software you’re using?


#13

I don’t restrict my definition of free/freedom to your context.

I sincerely appreciate you for looking at possible causes of the errant behavior. I submitted a GitHub issue before finding this community.

Good to know about Atom package quality expectations.

Ultimately, I’m responsible for my software experience. That’s why real and true freedom is so important.


#14

And, just to complete the success story …

The developer has already fixed the bug. My user tests seem to show that it’s working now.