MarkdownViewer++ 0.6.0 – x64 support and settings

Because of the good and constant feedback the MarkdownViewer++ plugin for Notepad++ is striving for improvements and more 🙂

With the newest release 0.6.0 several improvements, fixes and new features were integrated:

  • Now the plugin is Notepad++ x86 and x64 compatible
  • Updated dependencies for improved PDF exports
  • Several bugfixes
  • Added an options dialog to allow the customization of CSS, PDF exports, rendered files etc.

MarkdownViewer++ Options

The MarkdownViewer++ offers several options to customize your plugin experience. You can open the options dialog via the Plugins sub-menu.

MarkdownViewer++ Options


On the General tab you can configure the file extensions the MarkdownViewer++ renderer should actually display. If the box is empty all files will be rendered. If you want to limit the rendering to certain file extensions list them in the textbox as comma-separated list without leading dot.

For example, if you only want to render txt, log and md files just type in "txt,log,md".

Please note that only file extensions are compared and no certain mime types or anything. If a text document is not named XYZ.txt it will not be rendered.


On the HTML tab you can fill in Custom CSS, which is used when rendering the MarkdownViewer++ preview as well as the exported HTML. Therefore, you are able to e.g. change bullet-point-list icons or sizes of headlines. The custom CSS textbox is limited to 32767 characters.


On the PDF tab you can set the orientation and page size of the exported PDF. The content is provided by the PDFSharp enumerations.

A Notepad++ plugin for Markdown glory

Long time no see and back with a new project ^^

I am writing everything in Markdown syntax (you should see my many “notes.txt” or “” files ^^#) As such, I also export HTML and PDF files from them and I am constantly checking how it looks. So far, I was using Dillinger or StackEdit. Great tools, actually awesome. That is why I used them for years now.

But, Notepad++ is my main editor, opened 24/7 basically. And to always track my files in the browser and “export” them to my local filesystem just didn’t seem reasonable and feasible anymore. That’s why I went for a MarkdownViewer++, with basic rendering, HTML and PDF export.

I made a Notepad++ plugin to render the current open (Markdown) file in a dockable window as a rendered HTML to see all changes and Markdown “beautified” in an instant. It can be found at GitHub MarkdownViewer++.


Current basic features are:

  • Dockable panel (toggle) with a rendered HTML of the currently selected file/tab
  • CommonMark compliant (0.27)
  • Links open in a separate Browser
  • Basic HTML Export
  • Basic PDF Export
  • Unicode Notepad++ 32-bit plugin

Go try, if you like to. And leave a comment, issue, suggestion etc. if it should be improved. It is not perfect, I know it underperforms with large documents and am working on it. But I am also happy about any feedback.

CDI – DIY – Manual Injection

Enterprise development can be good and bad: It may support you with great managed environments, awesome conventions and configuration possibilities. But sometimes it also forces you into too tight railings, thinking it would be for your best, having you answering: “Wait… why… WTF?”

Unmanaged Dependency Injection

One trend especially jumps between brilliance and madness: Dependency Injection! To feature a common, broad context management supporting your needs with simple references, view and scope management is something very intriguing. But beware if you only peak out the window for once… it will immediately drop all its support for you and your code.

A managed environment can be supportive in many ways and eases our every day life but often misses the scope of Software Engineering and its possible uses. This leads to limitations or horrible inter-configuration-setup-libraries architecture that no one can manage but god himself.

Manual Dependency Injection

Therefore, it might happen that you have to jump between e.g. two components of managed and unmanaged source, in desperate need to access the managed environment. For that you can manually check the registered BeanManager and grab your managed resources yourself.

By checking the local context and grabbing the BeanManager you have the foundation to fiddle around and grasp of the managed entities.

With the BeanManager you are now able to look up the managed beans by class or name and iterate over what you are looking for. Below you can find an example how to look for the first managed bean of a given class, if any.

Of course, I would always encourage to stay as managed as possible, if you develop in such an environment. But especially if you have to deal with legacy modules, or dedicate multi-purpose components (which I had to), this solution encapsulated in a utility helper can save you many brain cells and long evenings spending with real development ^^’.

Big thanks to Dominik Dorn for this life saving hint.

Under Pressure

The issue tracker is overflowing and the deadline is inexorably coming near: The milestone 4 build has to be reached! Feature-set B15 has to be fully implemented and needs to be QA approved but bugs still occur and some features haven’t even been worked on. Everything needs to be crunched in there somehow as bug fixing is not limited by the announced feature freeze… and so it happens that you go into overtime!

Because of actual events in my last weeks and months this topic just pops up again and again with me: Crunch and Overtime! Nowadays, these are even accepted as “normal” in not only Games but general IT and Development. I know only few other industries and departments that take crunch-time for granted… especially in the end of any project.

As soon as overtime happens it is already too late. As no project manager (should) plans with crunch-time something went wrong if it happens anyway. In some cases this is not necessarily bad. Most people do what they do, work at what they work because they like the challenge, they like the environment… they just like what they do.
But no matter how much you love your work, after 12, 18, 24 hours day after day after day no Red Bull nor a single good night sleep can help to keep you really focussed and up to the task that you are actually on.

I do not want to go into detail why something like overtime happens but there are some things professionally and socially that I observed over the last years and especially months I want to share if you have to crunch to release a feature in dependency with others!

Documentation vs. Communication (or “State the obvious”)

Pressure pushing down on me
Pressing down on you no man ask for

It may be so easy: You get your Game Design, your Technical Design, Interfaces, Standards etc. defined and start developing from top to bottom. In the end everything works out, interconnected and your task is finished. Great!
This perfect world is pretty rare and in most cases does not reflect the “real life“. In most cases many things have to be reworked or clarified and therefore communication socially and professionally is one of the most important factors when it comes to development in larger teams.
Nevertheless, especially after 12, 14 hours of work or during a night the receptivity starts to lack the focus it needs for intense communication and dialogues. People start starring at their displays trying to get around that one oddness or gaze into the coffee/energy drink creeping over the floor. People that normally question anything start developing “till the end” and not “to finish a task successfully” meaning they “crunch” all what is left into their current objective, finish it up as quickly as possible top to bottom based on the docs… and as clarification takes time if the design itself can also be interpreted in a specific implementation kind of way: It will be!
So, in the end of any project, after many hours of work, during nights etc. try and start being pro-active: If you crunch with others, state the obvious! If you do overtime yourself, start questioning the most simple things! This may sound annoying but is most important as the most well-formed process is nothing worth after four+ weeks of crunching. Normal things like “Did you add the graphics of that item?” or “Have you added the i18n key?” are the first things that get lost as soon as a narrowed mind is focussing on fixing a bug or finishing up a feature.

Crunch in Overtime (or “The right Task at the right Time”)

Insanity laughs under pressure we’re cracking
Can’t we give ourselves one more chance

Don’t get me wrong: Sometimes overtime can be very healthy for a project and team if e.g. a small group of people focus on one small feature-set altogether and try to reach a goal in a given time frame. Tasks get crunched, time just passes by and everybody is happy (with some pizza and beer of course this can be a wonderful achievement).
Nonetheless, very often overtime is used or has to be used to finish up tasks that are unfinished or even untouched. This leads to crunching in all the different tasks that just have to be done before a milestone or deadline is reached. So, the overtime is used to clear out the issue tracker and not to finish what the main goal was.
If overtime happens use it wisely and plan what to do! You are not in your right state of mind after hours and hours of coding, drawing, layouting, … and deprivation of sleep can lead to similar effects as alcohol e.g. headache or dizziness. The efficiency may seem increased after some energy drinks but based on experience and code review… it is not! You cannot state a number but if the efficiency and focus is decreased, plan in some laborious work, some monotonic tasks, clean up and work off method sets etc. Complete new structures, concept arts (depends on the crazy creativity ^^), calculations or templates especially interfacing with others (see above) are detrimental. Crunching has to be planned and should not just occur!

Social Competence (or “To Develop is Human”)

Watching some good friends
Screaming ‘Let me out’

During daytime everybody is calm, touched by the sun, always having a smile on their faces. But after 15 hours from dawn till dusk the smile starts to vanish from their faces as the sun sets.
It is no matter how “nice” somebody is during the day: during overtime and crunching tasks every mood starts to swing. If set under pressure over weeks, sleepless for days and crunching code into a machine people get nervous and tetchy.
Now it is important to be sensitive. Not only developers, artists, … in-between but also a managing director has to apply his best soft-skills and pressurize focussed but appreciative. Even ironic jokes that would cheer up anybody during daytime can break loose hell if people spend 20 hours working on one bug! This emotional intelligence is a major issue when it comes to delegated work. Nobody intentionally tries to not finish any task so do not sound like this.
To loosen up a little and see the crunching time as a task of the team. Do not take it too serious… it is more important to sometimes just take a walk and have a little water cooler talk. I am a non-smoker but if it is getting dark it can be helpful to just go with the crowd and to keep together. Share thoughts, introduce pair-programming (if not already given, 200% more effective during overtime in my opinion) and try to help each other as together the longest nights can become the best stories for the next day.

Stay Focussed (or “Utopia is nowhere near”)

It’s the terror of knowing
What this world is about

In 90% of cases overtime and crunch-time happens because a goal has to be reached in time. A milestone, a release build, … whatever. Unfortunately, during crunch-time it often occurs that some people see this time as “additional” hours to use (see above). They try to achieve 200% and not to reach bug-free 100%. Such ideas come from management/directors but also from developers that tend to pressurize themselves. If they do not get to see their bed for days at least this time has to pay out.
Always be realistic about what the goal is and try to not loose focus of what can be achieved during this overtime. As stated above crunching should be planned and therefore plan against the origin of that specific overtime. If people are under pressure it is more important to eliminate all mush and narrow down what you want to achieve. Overtime pays out in work and even for the person itself if something has been achieved. A e.g. developer that works all through the night coding and coding without having achieved what he wanted in the morning is only half the developer for the coming hours and days. But if you clearly achieve your realistic goal you are happy and produce endorphins. Your body is powered up and you can shed any sorrows of work. This is the best sleep you will have for months!

Keep the Balance (or “The equilibrium of Life and Work”)

And love dares you to care for
The people on the edge of the night

Overtime happens and crunching some work, too. This can be manageable to some degree. But if your whole purpose in life is work and you are crunching everyday, hour after hour, seeing sunlight only as a reflection of your display you will “dry up”.
As much as overtime has to be planned (see above), the balance of overtime, crunching and regeneration has to be maintained, too. Otherwise the productivity and benefit of the additional time decreases down to a (negative) point of no return… yes, negative. At least in many cases I have seen, people actually fixed and created productive resources and code up to a specific point where the amount of positives fell below the amount of negatives. And this just happened over one day. When days went by the amount of time that produced good quality decreases and got inferior to the amount of time producing crap. And the most important issue is: Those errors have to be cleaned up, too!
This is something general and may sound corny but to keep a good Work/Life balance is most important and overtime is no contradiction to it. But crunched overtime needs different compensation to be regenerated. As mentioned, a good night sleep might not be enough for a 80 hours week. Fresh air, sunlight, healthy drinks and food are a necessity to “survive” not only the crunch-time but the time after (downfall).

Post Mortem (or “The Lessons we Learned”)

This is our last dance
This is ourselves
Under pressure

This is not necessarily something to keep in mind during a crunch-phase but afterwards. Always recapture what happened! Always try to learn from the lessons made! A retrospective or post mortem should help to pinpoint problems, miscommunication, bad planning etc. for the coming tasks and have to be used for positive and directed criticism.
A review about every process, not only meta or technical processes but also socially can help to suffocate future errors. Especially critique is hard to deal with and often taken personal. But what directed criticism (a director that guides the review is most important. Reviewing, not discussing when it comes to focussed critique) should provide is what we require to grow, to evolve. Because that is what we all want: To become better! It may sound unfortunate but people outside ourself often provide a better view on us than we ever can.
Therefore, always have a retrospective, a review, a post mortem, a lessons learned meeting, … call it whatever you (or your project management philosophy) like, but do it!

So, if we have a look at the lessons we learned:

  • State the obvious
  • Plan your overtime
  • Be social
  • Be realistic
  • Keep a Work/Life balance

and always recapture your work!

All this may sound general and soooo obvious but after weeks of overtime, pressure from the management and the deadline coming near it gets lost pretty easy.
Overtime happens and sometimes it can even be fun to see “this one feature being finished”, “this one bug being fixed”, especially in a nice social environment. Nevertheless, if you have to crunch keep in mind that not everybody is in the right state of mind and always remember some general work rules… maybe even pin them on a wall in front of you!

Written for #AltDevBlogADay

(Don’t Fear) The (C)Reaper

I have to be honest: My C and C++ skills are bad! Besides some personal tries in my “early years” and lessons at the University I never had a good connection to the world of C. Nevertheless, I got my degree, became a developer, working for nearly a decade now in my young life and I call myself a successful Software Engineer, even developing games… but in Java, JavaScript and C#. So, my dreams of getting into what I love most (Gaming) became real, doing what I like all day!
But still I feel inferior to the “real” developers because of my bad C expertise and especially my personal ignorance to really focus on it.

All my history…

I got in touch with computers and gaming early in my life through my brother. I started with a C16, C64 and Amiga 500 besides my GameBoy until I got my first (nowadays) classic PC. I was always intrigued by what was possible, the magic, playing Pong, Maniac Mansion, Zork and watching Scene Demos and Cracktros from legends such as The Black Lotus or the Animators. I wanted to do the same stuff, I wanted to (text-)wander through my own forests, wanted to have colorful spinning balls on the screen… so I began learning how to do so.
I started off on the Amiga with Assembler, got into QBasic later, Pascal, Delphi (loved its structure), Visual Basic (quick results) and very early PHP (the Internet) through early Web-Development tests and HTML/CSS. About ten years ago I got into Java at version 1.1 and am still on it. At every Job I had before and during my studies I was able/forced to use Java and it kept that way until today. Besides Java I had a look at and use Python, Scala (what I like about Java+functional programming), Actionscript, … and even Perl (just in one project) out of personal interest or for personal stuff.
Just from my history my expertise developed early around object-oriented programming which appealed to me the most, so I stayed. Therefore, very early in my “personal development” my development expertise was already conquered by Delphi and Java that formed my view on OOP and general Application Development besides their originators being influenced by C++ (good or bad). But there were still the games I liked the most. So, I had to learn C and C++. Teach myself the language of my favourite entertainment.

Try, Fail, Ignore

I bought books about C, about C++, about Game Development, about DirectX, about OpenGL, got into boards, searched the net for every tutorial I could find, tried everything and even got some minor things to work so that something moved on my screen… and it was programmed in C++. But something clicked in my head, spreading bad thoughts such as:

  • This could be easier!
  • Linkage and IDE is clumsy, Eclipse is way superior!
  • These design patterns are native in Java!

I read more and more, tried more and more and unfortunately failed more often. The initial fun and ambition faded away with every single compilation that turned out to not work as expected, crashed or ended up in memory leaks.
Even with every interest and devotion I had to learn, to me it was “just” another syntax complicating things. Pretty much everything I learned and did I was able to reproduce in Java in less time and with more comfort and less errors. I got lazy!

Coding Personality

So, even if I tried to seriously learn and get into C and C++ it just did not reach me, did not touch me. From my history and my experience with other languages, IDEs and projects I knew that there were different ways to achieve nearly the same things. And it was not only my laziness from very elegant development environments or library usage, also the code itself appeared to be cryptic to my eyes.
No matter if I read Java, Python or PHP code nowadays: Besides the fact that every code can be beautiful and ugly I understand Java code instantly; I recognize the Python functionality; I get what the PHP developer meant to do! Even in the last years as I was checking examples and help sites for iOS and Android NDK coding out of interest I could not get rid of the thought: I can achieve the same thing with the Android SDK! (PS: Objective-C is pretty ugly ^^)
And it is not that I do not like any other languages any more: I was “forced” to use Haskell and dismissed it; tried Scala and loved it! Fooled around with Ruby and had fun; Prolog and Lisp… na; Eiffel and C#, olé!
Especially C# instantly appealed to me: The syntax, the structures, the functionality and the ideas filled the holes that Java left over the years. It may be a coincidence that Anders Hejlsberg, a main man behind “my” Delphi is the lead designer of C# but maybe we think alike. And with the advent of XNA I even had a connection to game development again… and it started with a C! The commonality of course was a similar syntax, similar principles and the idea of a Virtual Machine executing and “managing” my code. No changes for specific operating systems (at least in the perfect sales world ^^), just develop and it would work… now with easy native Windows “ways”!
But the thing that always struck me again were games. Even XNA seemed “unreal” for real game developments.

Games are developed in C

If I would have gotten one cent for every time I read this exact line on a board, tutorial or e-mail… you know what I would be then as you probably think the same right now. And I believed it! It was like this; It stays like this!
But over time I got more experienced in developing and engineering applications and solutions and I realized that in most cases the programming language is just the tool to fulfil the requirements: And my requirement was still to make the things I have in my head!
I started to look around and found games such as Spiral Knights, Puzzle Pirates, Jake2 (a Quake2 Java port), Chrome using Java for scripting and even EVE Online from CCP. A Server and Client nearly 100% developed in Stackless Python; a dynamic programming language in a multi-micro-threaded environment. Easy to read and learn, hard to master.
But probably the biggest counterexample today would be Minecraft. The biggest Indie sensation last year is developed in Java and even if I never really got into the game, I admire Notch for what he did and achieved… and everything in Java. And Minecraft was not the first but Wurm Online already showed where Notch could go… in Java.

With these great examples of Games not developed in C/C++ I felt more confident in following my own way that I have successfully gone for years now.

To be or TioBe

I do not intend to defy C or C++ but if I am not required to use C for the games I want to create and other segments and industries can be conquered by languages such as Java, too (as shown in the Tiobe Index), why should I?
Especially in enterprise environments Java is a strong candidate for projects: From a Manager perspective the Java salesman argues with operating system independence, easy extended library architecture, basic native Database framework and UI support… sold! Enterprise Java is still a keyword for international research projects today. And with JME and Android even the mobile sector is invaded by Java for years now.
And with Android supporting Java as well as Microsoft supporting C# I can be everywhere: On PCs, on Consoles, on Mobile Phones and on Browsers. With languages I know, am experienced with and that appeal to me.
So, do I still have to put all my power in re-learning what I already know in other languages? Where I have intensive practical knowledge? Where I can craft my dreams?

Ignorance is bliss

Even with my underwhelming C skills I get along very well. Tiobe proves me right and until now I always solved the problems given to me or achieved and created what I wanted. I am working in the games industry, worked on large and international projects for big companies, wrote some publications and most results were accepted just fine. I even remember some projects and programs created by me that I am still proud of and this does not happen very often as every developer I know normally wants to change the code he wrote the second he/she finished the last line ^^.
I am aware that for the last performance tweak, for the most awesome graphics engine I would have to use C (or Assembler) and I am aware that the foundation for all that I use such as the Java or the .net VM an explicit knowledge is required. Nevertheless, I do not state that nobody should use C or C++. It is just that I want to raise awareness for people that complain about people not knowing C, labelling these as non-programmers. These guys are able, too. And if they want to Write Games, not Engines they might even be better for game logic and not “just” tools. These guys are also able to know what really happens underneath as that is a mandatory pre-requisite and not the knowledge of a syntax.
Therefore, besides all my years trying to get into “the game” of learning C and C++ I turned out pretty well, with experience in large projects, systems and now games. I call myself a game developer. And if many decline my languages I decide for myself that (C+)Ignorance Is Bliss…

Part of the Challenge: Show your ignorance! for #AltDevBlogADay

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.